Building Team Skills to Win The EHR War

I had the pleasure of being in a small audience to hear Wisconsin’s own Quint Studer speak. Most healthcare folks will recognize Quint as the guru of approaches to achieve great results in hospitals (patient satisfaction, employee engagement, financial performance and quality).

Quint criticized healthcare organizations that have tried to address financial challenges by reducing training budgets. I have been guilty of this short-sightedness in the past. However it is now clear to me that the only way we can continue to address the continually increasing demand for IT is to better leverage our employees. As we ask more employees to lead more complex projects they need the support and education to be successful.

I am working on several fronts to address this. One small but meaningful effort is to encourage employees to read. Recently I sent every IT team member a Barnes and Noble gift card so they can get a book. The only thing I asked in return is that they post a short book review on our internal social networking site (we user Yammer). Some bought traditional books, some of our road warriors bought audio books and others bought ebooks for their nook.

I love the Dave Ramsey quote: “You are the same today as you’ll be in five years except for two things: the books you read and the people you meet.”

I told my team that the book did not have to be related to their work. I did not want people to buy SQL Server Administrator guides that would collect dust on a shelf next to the Lotus 1-2-3 floppies. As I have have blogged in the past, inspiration will come from unlikely sources as long as you are open to it.

To that end I just finished Operation Mincemeat. This is a wonderful non-fiction account of a British WWII deception plot. Toward the end of the book I was struck by this quote:

“Wars are won by men…storming up the beach with all guns blazing…They are won by planners correctly calculating how many rations and contraceptives an invading force will need. By tacticians laying out grand strategy. By generals inspiring the men they command. By politicians galvinizing the will to fight. And, by writers putting war into words.”

At the risk of being overly dramatic, it strikes me that large IT projects (like an EHR) are similar. They need champions willing to take on risks; great planners; people that envision how the system will serve a larger strategy; people at the top that can motivate the team and the users; and people communicating the right message to the right target audience. Contraceptives are probably not so important.

I am also developing a multi-day curriculum for IT Analysts that will make them more effective project leaders and team members. It is essentially a brain dump of everything our IT veterans have learned (often the hard way) implementing healthcare IT systems. I am thinking about opening it up to people outside of our organization. Let me know if you think there would be an interest.

Managing The Project Pipeline

Annually I work with Ministry’s IT Customer Advisory Board (our IT Steering committee) to identify the IT projects for the coming year.  Like all capital budgeting processes, we have a IT capital target that is based upon a number of factors like recent financial performance and competing capital projects (usually new imaging equipment and construction projects).

At Ministry we really have two targets, money and time.  As I have posted Metal pipespreviously, we estimate how much time each IT employee has to work on projects (as opposed to support).  We add all of that time to determine the total project time for the year.  I am simplifying things, but you get the idea.

If we don’t spend as much capital as we had planned then we can save that money to spend in the future.  However, time is different.  Every hour that we had reserved for projects is lost forever if we are not using it that way.

We have such a great demand for IT projects, it is important to make sure we do not let that time go unused.  In past years we approved projects, then waited for those championing the project to bring them forward.  The problem with that approach is that our managers are so busy they tend to wait until the latter half of the year to get things going.  In the mean time that time set aside for projects is going unused.

This year we are encouraging our business leaders to getting things moving sooner and telling them the resources are available now.  This should better use scarce IT time and reduce the number of projects that carry-over into the next year (which ultimately reduces our capacity for a given year).

I will let you know how that works.

6:3:1

Now that we have been using our disciplined Project Management approach at Ministry for 3 years we have collected a lot of project data.  Reviewing the larger projects I have observed the typical IT project work effort is provided by:

  • IT – 60%
  • Business – 30%
  • Project Management Office – 10%
Does anyone know of similar statistics (yours or published)?

It’s Quiet Out There, Too Quiet

At any moment in time our IT organization is involved in 40+ IT projects.  An IT initiatives has to be greater than 100 hours to be considered a project.  The only way we can do this with an acceptable level of success is with the support of our Project Management Office.

Our Project Managers do not usually get involved in completing the tasks in a project (although they will occasionally pitch in).  Generally they are assisting the IT and business champions with developing a plan and managing to that plan.  There are a number of project controls that leadership relies on to monitor projects and get involved when necessary.  The status report is one of those controls.  Every Friday the Project Managers update all of the status reports.  I spend a lot of time reading status reports.

When projects are behind schedule, not receiving the anticipated level of effort or in jeopardy of not meeting its objectives I tend to get involved and see what is necessary t get on track.  Often this is just a phone call with some words of advice.  I think the phone call and attention may be more important than the actual advice.

But, some projects with glowing status reports will receive a lot of attention from me.  I am sure my IT teammates must think I randomly decide to get involved in some projects.  Our very observant CMIO, Dr. Pete Sanderson, has cracked the code.  This is what Pete recently observed…

While the status reports are an important project control, the issues list is even more important to me.  I have a sense of how many issues a project should be generating based on size and complexity.  I expect issues.  Surfacing issues is a sign of progress.  Typically the status report will identify how many issues that project is managing.  If I don’t see that information in the status report I will pull reports out of our issue tracking system.

The ideal project will have lots of issues with lots of progress addressing those issues.  On-time projects with no issues bother me more than late projects with lots of issues.

If you don’t have an online system for managing project issues it is time, in my opinion, to make that a priority.  Excel doesn’t work.  You need something that can be edited simultaneously by multiple users.  I prefer QuickBase (www.quickbase.com).  But, there are lots of options.

Killing Projects – Embrace The Concept

My recent post on project failure was one of my all-time favorites. While I wrote about failure from the top of my head, the reader comments were really well considered. Between my thoughts and the reader observations I think we have a great summary of the main reasons IT projects fail. I plan to turn that into a presentation.

Taken by tstadler and shared via FlickrOf course you do not want projects to fail. The preferred alternative is success. But there is a 3rd option, if a project is clearly not meeting your expectations you should kill it. Wayward projects are those suffering from cost and schedule overruns; are clearly going to require more resources than planned; and/or are not going to meet the original expected benefits.

Our organization has learned to embrace killing projects. And I think it is very healthy. In the recent Baseline Magazine, there is an excellent article on Project Lust. The story quotes Michael Krigsman, CEO of Asuret, a project-management consultancy: “It’s very common to see both IT and the line-of-business folks become enamored with a project and continue, blinded by the risks, when a third-party objective participant would say that there is failure coming down the line out there”

I believe project lust is common in most corporate cultures. The result is throwing good money after bad. At Ministry our IT Steering Committee congratulates business leaders that have the insight to see when something will not meet the planned expectations and having the courage to kill the project.

Every year we refine our project to discipline to better ensure success. But we are still a long way from perfect. Bad IT projects are still a fact of life. Killing them preserves your resources for the good stuff. I would encourage IT and organizational leaders to let embrace the idea of killing projects as something much better than failure.

The starting point for all of this is having the discipline to determine the success (or failure) of each project. If everything completed is considered a success, then there is no reason to stop.

If you are not killing a project or two each year you are going to suffer more failures.

Thanks to tstadler for making the picture available via flickr us Creative Commons Licensing.