The Failure of Governmental IT (Learnings From HealthCare.gov)

The failure of Healthcare.Gov has been discussed a lot but the main causes of the failure are unrelated to the project or to technology and apply similarly to other governments / large projects.

According to some reasonable articles, the main problems were:

1. Byzantine procurement process - those with the best lawyers and experience, not the most capable ones get the job
2. Size - the project is "too important to fail" - and thus also too big to succeed; +- 55 contractors creating SW with fixed date, integrating hundreds of insurence providers and some 36 states and various agencies; big-bang style of development and deployment
3. Fragmented responsibility and lack of ability - no one both with enough knowledge and power responsible for the whole project (and lack of the best talent in government IT in general), responsibility spread across tens of contractors and officials likely driven by cover-my-ass motivation (e.g. the procurement officer interested in selecting the cheapest offer that checks all the checkboxes instead of the best one - because who can fire her/him for doing that?)
4. Niagara Falls of waterfall development, constrained by rules and bureaucracy to immobility - extensive legislation, rules, and security requirements together with a fear/blame-driven organization or not good for agile approaches

BTW, according to L. Hart (below), 0 federal projects over $5M were delivered on time, only 6.4% of those over $10M have succeeded and full 40% of such projects were canceled. So, under those circumstances, Healthcare.Gov is actually a small miracle.

Sources:

• Laurence Hart: Healthcare.Gov Fiasco Shows the Problems in Federal IT - insight into the broken procurement and many obstacles any federal IT project faces by a person with rich experience with it
• Merici Vinton: 9 Things You Should Know Before Debating HealthCare.gov, From Someone Who Actually Launched a Successful Government Website - an important story: it is possible to launch a successful government website but it requires special effort and approach. The main advice is:
  1. "Never build a website that's too big to fail; instead, start small" - the CFPB "launched a pretty basic, consumer facing public website in six to eight weeks" then gradually added intake for complains regarding various products, one by one. "We did each rollout in small chunks and built more and more based on what we learned with each integration."
  2. "Let's do open source when possible (preferably always)."
  3. "Let's have in house strategy, design, and tech." - i.e. do not outsorce those
  Also, involve IT people in the procurement and hiring.
• Tim Murphy: Could Obama's Campaign Tech Gurus Fix Healthcare.gov? Let's Ask 'Em! - the answer is no, mostly not - due to the sheer size, the procurement process, and all the legislation. Quotes the campaign's CTO's twitter: "The 'secret' here is that the problems are not about tech at all," he tweeted on Monday. "It is about procurement. I can't fix that with my tech chops or my team."

By the way, the Government Digital Service team in the UK has become "recently" famous for bringing effective IT to the government. It is interesting to read about the UK DS strategy, based on delivery - frequent, iterative, repeatedly successfull.

Thanks to @flowchainsensei and @timoreilly for the links.

Tags: methodology