Newly released documents reveal that the Obama administration had private consultants from McKinsey & Co. perform an evaluation of the HealthCare.gov website’s progress in late March. McKinsey’s analysis wasn’t good and the Health and Human Services Department and White House knew of the issues back then. But six lessons revealed in the document risk getting lost in the politics of the website’s rollout. More than a pawn in a Republican vs. Democrat chess game, HealthCare.gov is a case study for all future web development clients on how to not build a website. Here are six reasons why, from Page 5 of the McKinsey analysis:
Evolving requirement: HHS was ill prepared to hand their vendors the requirements and information needed to build HealthCare.gov. HHS was still giving developers its requirements during the site design and construction phase, and even after. This means the designers and developers had to create and recreate graphics and code with every new requirement that the HHS handed them. They had no consistent road map with which to work.
Multiple definitions of success: There was no universal, cohesive definition of what the final HealthCare.gov website was to be when it launched. This should have been one of the easier decisions for HHS and the White House to make since they knew that the website wasn’t fully operational.
Significant dependency on external contractors: HealthCare.gov had at least four major contractors: CGI Federal, QSSI, Serco and Equifax. That means HHS was listening to at least four opinions on how things should be done. In actuality, CGI Federal should have been the final decision maker on functionality. Additionally, since contractors also hire out to other contractors on big projects, there could possibly have been eight-plus entities working on this site at once. This many entities working on the same project can easily break it down.
Parallel “stacking” of all phases: There is a reason designer and developers require all content and information before starting the design phase of a website. Designers need that information to make the wireframes, interface and navigation optimal while developers need it to map out the best programming path. Both need all the necessary information beforehand to guarantee they choose the best industry practices to build the website’s components. Poor planning and preparation by a client can kill a project. Poor planning significantly reduces productivity and often drastically increases costs.
Insufficient time and scope of end-to-end testing: So HHS had a website cobbled together by numerous contractors with different visions of success and no clear end goal. Add in that HHS was still giving its contractors additional requirements for the site well past the planning stage. Welcome to a testing nightmare. The contractors likely weren’t testing the site because HHS was still feeding them information, which would mean they would have to retest all over again after implementing the new requirements. Because of these add-ons, testing became an afterthought.
Launch at full volume: McKinsey’s analysts knew HealthCare.gov would be a disaster back in March and thought it a fool’s errand to try launching the full website, especially after seeing the development nightmare. They even point out specific problem areas to HHS and the White House on page 15 of their presentation, and call for an end to scope creep – those additional requirements – until version 2.0.
McKinsey’s analysts noted that CGI Federal was trying to make things work as of the end of March, but obviously CGI Federal’s efforts weren’t enough. CGI isn’t responsible for that though: A lack of client planning will always kill a product.
This website’s failure falls on the shoulders of HHS and the White House. They had two full years to plan this site but they failed miserably to do basic planning and research to make the initial launch a success. It is clear through this assessment that the current administration created this horrific mess themselves and their contractors have little responsibility for this technology train wreck.
Stephan Hilbelink is a website designer and developer with the Family Research Council.
