You can refer to my overall analysis of the ACA here.
On 1 October 2013, the healthcare exchanges officially launched. While this was a milestone for the ACA, there were significant technical problems on the Federal healthcare.gov website which resulted in a large amount of press. Since the deadline was known well in advance, how did these problems reach a significant magnitude at and after the launch of the exchange site?
For an interesting exercise, I have been analyzing this from a project management perspective. This event can be utilized as a case study for project pitfalls, risk, scope, and quality management. There was hard end date of 1 October 2013 and a fixed budget, which is the nature of government contracts.
My analysis applies to the Federal exchange, as the state exchanges are in better shape for the most part. The Federal exchange handles insurance exchanges in 36 states. The major contractor for this initiative was CGI Federal. This vendor has a storied history, with a failed online medical registry in Canada. There was also a vendor who designed the front end (Development Seed) and a series of vendors who assisted and consulted on the back-end.
Root Cause Analysis:
- According to a NY Times report, CGI Federal won its contract in December 2011, but the government delayed release of specifications that the contractor did not begin work until Spring 2013.
- The above resulted in an impossible situation, where any extensive test strategy would have been impossible given the constraints of time and resources.
- The bid process also appears inadequate, per my earlier comments on CGI Federal. There should have been a qualitative and quantitative analysis to select a business partner who could increase the probability of success.
- Concerns were raised over the course of a few months by the GAO and other entities. Due to political pressures, the 1 October deadline was not moved. In a less politicized environment, the deadline would have been moved and most stakeholders would have understood.
- Improper assumptions made about the volume of users.
- Improper programming design. When a user creates an account on the site, it loads a large amount of files and software. The two way communication between the site and the browser overwhelms the system.
- Improper topology and architecture of the solution. There was a mixture of old and new servers supporting this solution with a centralized data hub. With this architecture, if one server crashed, this can cause a domino effect.
- CMMS (Centers for Medicare and Medicaid Services) played a management role (PMO) in this project. They were ill equipped to manage a technical project of this scope and complexity.
- This site was implemented with an “all-or-nothing” approach, possibly using an outdated Waterfall type methodology.
Recommendations:
- The way the government selects vendors for IT projects should be revisited and revised. They should shift to a more results based model of selection.
- Design future projects with extensive testing periods in mind for planning purposes. Focus on extensive use cases and integration testing.
- Ensure that the IT specifications are known by all parties and are issued in a timely manner. The manner in which the government develops specifications and then communicates them out needs to be evaluated and streamlined.
- Refine project management model to ensure that the PMO is capable to handle technical projects.
- Consider adapting an Agile development model and utilize smaller scale roll-outs (pilots) before the large scale deployment. This will help refine requirements, enhance testing effectiveness, and eliminate bugs from the final product.
