Category Archives: methodology

The Magic Answer

Posted on by

Every good geek (and Google) knows that the answer to life and everything is 42.  This is a famous line from The Hitchhiker’s Guide to the Galaxy.

But it seems like there is a more sensible magic answer: In order for things to go well, there needs to be a high level of specification.

Yes, ambiguity kills.  In fact, it literally kills according to a study by Spear and Schmidhofer that was recently published in the Annals of Internal Medicine.  The authors found that high performing organizations achieve results “by specifying how work is expected to proceed—who will do what for whom, with what purpose, when, where, and how—before work is actually done. Then, when anything contrary to expectations occurs, it is immediately identified as a problem.”

Medication errors may be one of the most critical examples where a high level of specification is needed.  But, I run into this everywhere.

This year I brought in consultant Kevin Behr to analyze our IT Operations.  The single most significant finding is the IT Operations in my organization suffers because of a lack of definition.  When everyone is left to define how work gets done there is bound to be mistakes and mis-connects.  Our organization needs to dedicate time to evaluating what we are doing and how it needs to be done.  All work must be EXPLICITLY defined, otherwise talented people (like I am blessed with) can’t achieve their full potential.

I believe my organizations do a superb job of running large and complex projects.  That is because we spend so much time defining the right process, then learning from our mistakes and re-defining our methodologies.

Job descriptions are the same way.  If you are not explicit about a person’s role and what they are expected to produce you should expect to get something unsatisfactory.

How many times have your interfaces gone through multiple re-writes because you did not have a high degree of specification when you started working on them?

Is this so basic that it is not worth a blog post?  If so, why do I see so little definition of work or processes to a high level of specification?

Failure

Posted on by

My person approach to IT management centers around success.  Most IT projects fail.  Some quite spectacularly, but most in a quieter way.  I believe these are the three leading contributors to failure:

Poor Project Plans and Resource Allocation

My personal experience is that most IT departments do not have a good sense for the amount of time they have to spend on IT projects.  All of the data I have collected since I have been studying this suggests that only 15% to 25% of total staff time is available to work on new projects.  If organizations take on more work than they can complete, everything proceeds at a snail’s pace and nothing ever truly gets done.

The only way to manage resources in a large organization is to have detailed plans for every project and to look at the resource requirements across all of your plans.

Vendor Performance

Just as IT departments over-allocate their resources, so do vendors.  Vendor performance issues are usually more related to them not providing services in the time expected (or not having a common expectation with the vendor) than bad software.  However, sucky software is still an issue.

Lack of Clear Expectations

If someone’s goal is just to implement some software than, in my opinion, they have failed by default.  Each IT implementation should have clear business benefits and those benefits need to remain insight throught the effort.

Am I missing other common contributors to failure?

Project Governance

Posted on by

When we organize medium to large size projects we like to create two main committees to ensure the success of the project.  The Project Leadership committee typically includes the IT Leader, the Project Champion (non-IT), and the project manager.  This committee meets regularly, at least 3 hours a week.  This group is charged with:

  • Tracking the project plan, taking corrective action where necessary
  • Tracking the budget
  • Reviewing the issues list
  • Planning what updates should be communicated to various audiences
  • Summarize all of this in a regular status report

The Project Oversight Committee is comprised of the Project Leadership team and senior leaders with accountability for the success of the project.  It is their job to:

  • Regularly review the project controls
  • Resolve issues that require senior leader decision making
  • Sign off on any decisions that have a significant impact on the goals of the project
  • Keep the project leadership team focused on achieving the project goals

This structure has worked well for me and I recommend using this approach as a starting point for your project governance.

EHR Resource Estimates

Posted on by

I don’t think most healthcare leaders understand the effort these Electronic Health Records systems require.  While the hardware and software expenses are significant, they are dwarfed by the level of implementation effort required.  I am working on a number of resource estimate models to implement a “fairly comprehensive” EHR for a 400 physician medical group.  While the hour estimates can vary be EHR product all of the estimates are breathtaking.  Currently, the high end of the range looks like 300,000 hours.  But, we still aren’t done scrubbing the numbers.