The Healthcare.gov fiasco has received more than its fair share of attention and criticism. By now, everyone knows that the rollout failed — catastrophically. It gives everyone involved in any aspect of software development a bad rap. For that reason, we should draw a few lessons from this debacle and try to avoid getting ourselves into similar situations in the future.
I’m not going to repeat the many project management lessons that have been articulated to date. We all know you need clear executive sponsorship and strong project management for any large, enterprise project to succeed. (Well, maybe the Healthcare.gov folks didn’t know that, but they do now!) Instead, I’ll focus on a handful of issues that crippled the government project and could infect yours.
- The development of Healthcare.gov was a mammoth project by any measure. That’s not a bad thing in itself but rolling out a mammoth project in one big bang is just plain dumb. Who does that? Don’t even think about doing it on your project! Think phases, iterations or sprints. Roll out segments of the feature set in waves and learn from each one.
- Scope creep is a crippling disease that infected the project. Every major software project suffers from it in varying degrees. Sources of scope creep vary from the end users to the business stakeholders to the developers themselves. Everyone wants more, more and more. Learn to negotiate and prioritize. Tell them “If you want ‘X’, you may not get ‘Y'” (Of course, extending the deadline or adding to the budget are options too).
- Quality is a key variable for controlling time and cost — but it shouldn’t be. Everyone likes to join the quality parade and say something like “…we maintain the highest levels of quality…”. Yeah, right! When time or budget runs out, quality always takes the punch. Learn to build high-quality into every software component from the start. You can’t retrofit quality.
- Healthcare.gov was “Component-Driven Development” (CDD). I say that because there were many private-industry vendors involved in developing portions of the website or related sites. That’s fine. However, the individual components may operate well in isolation and may perform poorly when integrated. There has to be an integration team with ultimate control over the entire effort. This may sound like administrative overhead but it’s not. We’re talking about huge projects not smartphone apps!
- Someone should have said “No!”. In hindsight, the failed rollout was predictable. The project suffered from a severe lack of communication — particularly with regard to bad news. Learn to deliver all the news. Stop sugar-coating the facts. Be factual and direct. Stop hearing what you want to hear and disregarding the rest. Tell it like it is.
Any software development project can fail — that includes yours. Live and learn.