HealthCare.gov As A Project (NOT An Editorial)
Don't worry, this is not just another political rant for or against government involvement in the national healthcare system. However, since the issues surrounding the launch of the US HealthCare.gov site have gotten a lot of attention there are some really good conversations around IT and business project success that are worth reviewing.
The NY Times on Sunday published From The Start, Signs of Trouble at Health Portal, citing the largest contractor on the project who noted that, although they were awarded the contract for in December 2011, actually coding didn't start until Spring 2013, and until late September, days prior to launch, some significant features and user requirements were still being debated.
James Turner wrote at Forbes.com that You Can't Legislate Away The Time, Money and Features Law, and in a few brief paragraphs captures many of the typical failures that occur in a complex project like the healthcare portal, not the least of which is full integration late in the game.
All the way back in September 2009 Bruce Webster wrote about the proposed changes from a systems design perspective, contrasting software systems design with social or human systems design. Part II of his analysis contains some especially relevant heuristics from a couple sources, including these gems (see Webster's blog for source citations):
"A complex system that works is found to have invariably evolved from a simple system that worked."
"Don't assume that the original statement of the problem is necessarily the best, or even the right one."
"If you don't understand the existing system, you can't be sure you're re-architecting a better one."
The scope and scale of what has been attempted with the US government health exchange portal and all the related services is far beyond anything Backcountry has done. The closest project for comparison would be moving Backcountry.com to ATG. Still, some applicable lessons include:
- If you set in stone at the beginning of a project the required features, the resource allocation (people/dollars) and the date on which the project must deliver, you're gonna have a bad time.
- If you attempt to entirely rip out an existing system and replace it with a new one, you're gonna have a bad time.
- If you assume development of a system is just a technology project and your users will figure out how to use the tools you provide so you don't need to involve them along the way, you're gonna have a bad time.
- If you think that the timing of decision making and prioritization at higher levels has no effect on the people responsible for developing and implementing a business solution, you should think again.