Unless you have been living under a rock, you’re aware of the problems with the launch of HealthCare.gov, a key part of the Affordable Care Act. It is a debacle and largely seems to be the result of some common IT project mistakes – mistakes that those of us who work in the industry have seen before, unfortunately too often.
There are many examples to choose from but let’s start with these:
- Incomplete understanding of the business
- Uncertainty regarding the specifications
- Unrealistic deadlines
- No proper end to end testing and verification
- Ignoring warnings that things were not well
First, successful websites are built by companies and people that understand their business very well and have spent adequate time understanding the exact specifications needed to produce the right end product, period. If either of these components is missing at the front end of a project, failure of some sort is almost guaranteed. According to the NY Times, a McKinsey & Company report last spring said “construction of the federal website had been hamstrung by the fact that the project had no clearly identified leader and that government contractors received conflicting instructions.” That would indicate that specifications were not clearly communicated, quite the opposite, and no one had clear authority for the project overall or the ability to resolve conflicts and issues. Ring any bells with anyone?
Second, politics has driven unrealistic deadlines. This is not exclusive to a government project, competing priorities within a business and “office politics” can create the same problems if project teams are not careful. In the case of HealthCare.gov, it’s clear that maneuvering by both parties and all branches of the government resulted in completely unrealistic deadlines that did not leave appropriate time for the real work to be done. The “specifications” for the project are essentially the 2000+ pages of the ACA. It’s a tremendously complex undertaking that was never given the time it needed to be planned for and developed properly. Perception, popular opinion, poll results, budget fights –all influenced decisions about when things would be rolled out more than the actual time needed to properly complete the project, and they continue to do so. There are a reported 5,000,000 lines of code that need to be corrected and various dates that have been discussed (11/1, 12/1, or after 12/15) are all pretty unrealistic!
Third, they launched the site without proper end-to-end testing and verification. The McKinsey report also warned that there was “insufficient time for “end-to-end testing” creat[ing] risks that the website would not work” and Mitre Corporation recently released a separate statement saying, “we were not asked, nor did we perform, end-to-end security testing.” This is really IT 101; you simply have to test and verify the functionality of the product. Yet who among us hasn’t had to argue about the necessity of proper testing before rolling something out at one time or another? When project timelines get tight or missed, testing and verification are often the first things that get squeezed out, particularly since they occur nearer the end of the project. It’s tempting to not want to delay things anymore but it is such a critical mistake to curtail or eliminate proper testing, as we can all see in this case.
Finally, McKinsey’s warnings were ignored and one can imagine a host of internal warnings were too. This is also a common problem on IT projects – no one wants to hear about problems. I think non-IT team members may have a misguided faith in the ability of IT managers to solve any issue without consequence to the schedule. Their lack of knowledge causes them to underestimate the severity of problems and the time it will take to fix them. Then there are those who willfully ignore what they fully understand to be an issue or sugar coat it and downplay the problems to senior leadership, classic management issues that can easily derail an IT project.
One might be tempted to cut them a break since healthcare is complicated and the site requirements are highly complex but many private sector businesses have equally complex business models. We work with financial institutions whose web sites must handle millions of transactions daily, accurately processing customer information, merchant transactions, reconciliations, and complying with privacy rules and other legal requirements – and they do it successfully! Whether it’s Zappos or Amazon or Bank of America, these businesses have developed technology that works and they did it by knowing their business better than anyone else, taking the time to plan properly, and understanding the exact specifications of the project. They did it by setting realistic project milestones, continuously planning for enhancements, and hiring the right outside help when they needed it. We’ve provided IT contractors to help with hundreds of these kinds of projects at our clients and I can tell you, there’s a thing or two that the government could learn from the private sector!
There’s certainly something that we can learn from this fiasco. There’s no skipping steps or rushing important parts of the development and quality assurance processes, not without consequences, possibly severe ones. Proper project planning, management and leadership are critical to success.
Any other lessons that you can think of?
Jerry Brenholz
President and CEO
ATR International
{{cta(‘cafaa948-56c8-4841-83ef-91384d3fc906’)}}
Leave a Reply