The launch of the HealthCare.gov Web application is now an infamous example of Web development and project management malfunction. The fault does not lay in the health insurance being offered on the site, but in the technical decisions made during the software development cycles. As a software project manager, when I first read about this release, I thought of all the different decisions the developers, project managers and their executive administrators could have made to avoid the Healthcare.gov technical problems they experienced.
This article identifies the key problems experienced by the project management and development teams, what is being done to correct the problems, and offers a prediction of what will happen and what it will mean to the people who use the site. I have also added relevant advice for project managers throughout the article.
Where HealthCare.gov went wrong
Two high-level goals of President Obama's HealthCare.gov website are to simplify the way people can comparison-shop for health insurance and to allow them to purchase their preferred health insurance coverage online. For example, in June 2013, the HealthCare.gov project decided to deploy an upgrade to the site to promote the upcoming October 1 launch. The goal of the June site was to prepare people for what they could expect in October when they began ordering their health insurance on the site. The June site was designed, developed and launched in a 90-day time frame.
This short turnaround, pretty much unheard of for a government IT project, was successful because experts from the private sector were brought in to help. This is particularly true with the homepage, developed by Development Seed, a small firm that laid much of the groundwork for the homepage that millions of Americans still use today. The site was built in public and iteratively, using project managers and developers who leveraged Agile development and cutting-edge, open source technologies. The June version of the site was lean and proved to be successful due to the strong collaboration across the government and private sectors.
Always bring in experts during the design and development phases if you know your project team lacks the required expertise. These experts will know how to leverage and apply cutting-edge technology to the most complex of projects. The government did just this for the June release and it worked. Makes one wonder what happened with the October 1 release.
The October website, which had been under construction for a few years when the June website went live, had been using the Waterfall methodology. Although I cannot find the reasoning why the government chose to stay with Waterfall after the successful June release, I am assuming changing to an Agile methodology three months before the big launch would have proven too great of a challenge with so much code already written.
The major challenges the project team faced with the October release included fixing hundreds of bugs weeks before the release, overworked testers, and a site that kept crashing when performing simple tasks, such as setting up an account. There were also concerns about the accuracy of the data.
As we all know, fixing hundreds of bugs right before a release can have a crippling effect on software and is guaranteed to create additional bugs that will not be caught in the final testing phases. That is, unless you have seasoned testers who know how to expand upon the documented test cases during the final integration testing. Unfortunately, the testers for the October release involved 200-300 government and insurance employees who tested only a few days before launch. Load testing also appears to have been performed by these same testers over various time periods while working at their desks. Add this to a very complex technical specification and architectural design, and you have a site that was obviously not going to be ready for prime time.
As project managers, we owe it to our developers to document the problems they are having. In addition, we must document that our executives have received timely notice of the problems. Without this documentation, our developers can be accused of not having the required expertise to work on the project and of sloppy work. I have worked with a lot of developers over my time and I have yet to meet one that is not skilled enough to write solid code given a reasonable time frame. However, they need time to fix bugs and cannot be held responsible for problems that occur with scope changes that come in at the last minute. Be a great project manager and protect your developers with strong documentation.
HealthCare.gov developers complained to each other about the problems they were experiencing, but it is still unclear if their concerns made their way up to the government's administrators who were responsible for the overall program. CBS News reported that testers were never able to successfully browse the site, and one unidentified source stated it was "unequivocally clear from testing … [that it] wasn't ready." However, government officials, such as Marilyn Tavenner, administrator for Centers for Medicare and Medicaid Services (CMS), have gone on record saying they were unaware of any problems prior to launch.
What is the government doing today to help this crippled website? Since its first viewing in October, hundreds of the bugs have been fixed and the site has shown marked improvement with stability through additional hardware. Resources from the private sector, such as Red Hat and Oracle, are now involved to assist with reliability, stability and scalability, sharing their Agile expertise. In addition, President Obama met with other key Silicon Valley executives in December to rally their support and expertise.
An area of improvement we can hope to see in the near future is having the development process become more agile for leaner and quicker release cycles. There is also talk about creating a new federal IT project management office (PMO) unit dedicated to larger technical projects. The new IT PMO would effectively remove the ability for each government organization to act as its own general contractor on projects such as CMS did with HealthCare.gov. President Obama's administration is also keenly aware of the difficulty to hire skilled technical staff quickly, and is looking into how it can reduce the amount of time it currently takes for the hiring process.
If your organization is decentralized when it comes to IT projects, think about centralizing your projects under one PMO umbrella. PMOs allow standardization across projects and leverage expertise and resources. However, be sure to also look at how a PMO would be able to lower overall costs, as this is not always the case, per a survey conducted by PMI. When it comes to hiring practices for a PMO team, be sure the candidates have the ability to work across the board on different platforms and teams. This is no time for a project manager who will only work on one project at a time.
With these recent bug and hardware enhancements, along with the talk of leveraging Agile methodology, the new PMO unit, and improving hiring practices for skilled IT personnel, the future looks positive for HealthCare.gov.
As seasoned project managers, we know software is often released even when we are aware of critical bugs impacting the user experience. After a disastrous release, we quickly evaluate the impact, prioritize the change requests and bug fixes, and move forward at a frantic speed until the project is stable, supportable and feature-rich. Fortunately, memories prove short when it comes to releasing software before its time. For example, Medicare Part D had similar rollout problems when it was initially released in 2006. Users complained that the site was too slow, their data wasn't accurate, and there were possible security breaches. Sound familiar? And yet, today, eight years later, the Medicare Part D website provides a popular prescription drug program among seniors.
With the attention the HealthCare.gov technical problems are getting from the press, as well as the political implications, highly skilled resources are being applied to the site. There are now top executives from Silicon Valley on the case. They are experts when it comes to releasing and maintaining websites that have millions of hits each day. How long will it take for HealthCare.gov to become feature-rich, stable and popular like Medicare Part D? With the progress we've seen to date, certainly not eight years, but we will need to give the project managers and developers at least a year to 18 months to work through the hundreds of remaining bugs, to enhance the security, and to ensure the data is accurate. Not an easy task, but with the teams currently under consideration, we will one day forget about the initial release and will enjoy comparing insurance policies and purchasing healthcare from HealthCare.gov.