13

Nov

Crash & Burn – The Sad Tale of healthcare.gov

Crash & Burn – The Sad Tale of healthcare.gov

Where was the Project Manager (PM) for healthcare.gov while it was crashing on takeoff? It’s too bad we will probably never know what really happened since spin is all you get in DC. “There’s never time to do it right the first time, but there is always time (& money) to do it again” is the Beltway mantra. Out here in the real world we don’t have that luxury; our projects are expected to succeed the first time. You always hate throwing anyone under the bus, but barring any further information being released, this failure falls squarely on the shoulders of the PM.

Traditionally, the PM is responsible for:

  • Ensuring that the development team completes the project.
  • Developing the project plan with the team and managing the team’s performance of project tasks.
  • Securing acceptance and approval of deliverables from the project sponsor (in this case, the HHS / Federal Government).
  • Communication, including status reporting, risk management, escalation of issues that cannot be resolved in the team, and, in general, making sure the project is delivered in budget, on schedule, and within scope.

That last item is what usually gets projects into trouble. Hope and optimism are the enemies of any project. PMs have to assume everything will go wrong and develop contingency plans for all the possibilities. I know that sounds depressing but projects of this magnitude are bound to have numerous problems needing to be addressed along the way.

I have never been a fan of the “pure” Project Manager. Don’t get me wrong, I fully believe in the structured project management methodology and its execution. However, being just PMI certified doesn’t get it done.

There are layers to a successful PM. The complete package is what WAKE TSI calls a Technical Project Manager.

Technologist – First and foremost, the PM has to be a technologist. Having a solid foundation in technology is critical. It’s a “been there / done that” thing. If you have a technical background, it is far easier to determine the validity of what the project teams are telling you. Having this background is what I call the “BS Meter”. Without this technical experience, a traditional PM may not be able to determine when team members are not being entirely honest. And yes, it does happen!

Project Manager – It is important to have the PM discipline. If you do not adhere to the traditional PM responsibilities, your project is at risk. Without the methodology, successful project execution becomes a matter of luck. This ranks up there with “hope”. Not a good way to run a project.

Management – This is a skill or trait that is often overlooked. And it’s not just management, but leadership. When managing/leading a project, you are managing/leading people.

Getting back to the healthcare.gov failure (Yes, it was a failed project), it would make an interesting case study in what NOT to do. However, we are talking about DC so I’m not optimistic we will ever know the whole story.

Since we live in the real world, our projects are not allowed to fail.

Everything WAKE TSI does is firmly rooted in Technical Project Management. Our clients count on us to make sure that their projects succeed regardless of the technological initiative we are tackling. Failure is not an option. Unlike healthcare.gov, our projects take off and fly.

11/22/13 UPDATE: This story found on FierceHealthIT is timely. Check it out: Under pressure: Most hospital CIOs have knowingly launched error-filled projects. We at WAKE TSI can head this off from happening by providing regular communication with the CIO and other stakeholders so they know the real status. There are no surprises.