The headlines and political repercussions from the HealthCare.gov debacle continue unabated. The focus is unsurprising, given the polarizing debate that proceeded the passage of the Affordable Care Act (ACA). As this is a technology management blog, I’ll refrain from adding to the angry, partisan debate. Instead I’d like to focus on the lessons IT leaders and project managers can glean from this unfortunate event. Let’s start with some historical background.
The ACA was signed into law by the president on March 23, 2010. It was a dramatic piece of legislation, long envisioned by Democrats and critical to Obama’s legacy. It represented the most significant overhaul of the nations’s healthcare system since the implementation of Medicare and Medicaid in 1965. But unlike Medicare and Medicaid, the ACA was enacted in the Internet era, with high expectations of web based enrollment capabilities. Spinning up a massive agency with paper-based sign-up processes would be expensive and a logistical nightmare.
A centerpiece of the legislation was the concept of state based insurance marketplaces, or exchanges. These websites would give citizens the ability to comparison shop different policies and to apply for coverage. However, only 23 states (and the District of Columbia) decided to set up an independent, state-run exchange. The remainder, defaulted to the federally managed exchange or engaged in a state-federal partnership. This left the federal government with the responsibility of creating and operating an exchange on behalf of 37 states.
In order for the ACA to be effective, Americans would have to be registered, with active policies, by January 1, 2014. To accommodate this deadline, the Obama administration determined that the federal marketplace, aka HealthCare.gov, would open for enrollment on October 1st. Furthermore, this would be a “big bang” event, without any phasing in of enrollment populations. There was also a requirement that individuals first sign-up prior to using the site to evaluate and compare policies.
The project to create the website was massive in scope. While run by the Centers for Medicare and Medicaid Services (CMS), it involved the coordination of numerous federal and state agencies. It also involved 47 different contracting firms. It is fair to say that it was the most ambitious public facing, transactional website ever created by the federal government.
Even prior to the site’s high-profile startup failures in October, it was apparent that potential trouble was looming. Several months earlier, the project manager, Henry Chao sent emails to other officials at CMS warning that the site could “crash the plane upon takeoff”. He described serious issues with software, contractors and staffing shortages. The emails, made public as part of congressional hearings, should have served notice to rational individuals that a successful October launch was highly unlikely. In mid-September, with the launch date only two weeks out, the system failed a test that simulated a mere 500 concurrent users.
As they say, “the rest is history”. The launch was an abysmal failure, with virtually no usable services. The sign-up portion of the site was overwhelmed with performance issues, with only 6 people able to successfully establish coverage on the first day! The response was angry and dramatic. Even proponents of the new law were publicly critical of the Obama administration and their handling of this project. His approval ratings are down, and his legacy is potentially threatened if this “ship is not righted”.
As of this blog post, the administration has moved into crisis management mode, spending the last two months remediating the numerous issues plaguing the website. They added “SWAT” team resources from private industry who have a track record of building high volume websites. All of this, to get the site in working order by a promised date of the end of November. This morning, the administration is boldly claiming that the site is now fixed. I’ll reserve judgement till we get through the enrollment period. Only then will it be apparent whether the dramatic repair efforts were sufficient to meet the original design requirements of this system.
So how did we get here? How did such an important initiative get so radically off-track, leading to a disastrous “opening night performance”? In hindsight, there were several contributing factors that made failure a predictable outcome:
Complexity – This was an enormously complex project, involving the coordination of numerous organizations and resources. Complexity has a tendency to increase geometrically, quickly leading to challenges in forecasting, coordination, status assessment, and ultimately to delivery. That’s one reason behind the growth in iterative delivery models. Progressive organizations understand that one way to address complexity is to limit the amount of functionality that is delivered with a given wave of development. Unfortunately, the politics surrounding HealthCare.gov provided back pressure against any adjustments in features or delivery dates.
Novelty – The ability to accurately plan and deliver a complex project is hampered by the novelty of that effort. That is, projects with no similar historical parallel lack reference points for accurate project forecasting. Furthermore, human nature often leads to a gross underestimation of completion times. In fact, this phenomenon has a name – the planning fallacy. In the case of HealthCare.gov, the project had no reasonably similar forerunners. Therefore, a more conservative stance was warranted regarding estimations of timelines.
Politics – The contentious nature of the ACA meant that the stakes would be high regarding the success of the website. The Obama administration desperately needed the site to be available on-time and to perform as advertised. There was little room for compromise on requirements or deadlines. This led to two well known phenomenons:
First, there is the problem of the “slain messenger”. When people are told that a “damn the torpedoes” directive is in play, they will ultimately stop raising issues about an initiative. No one wants to be labeled a complainer or a poor team player. An atmosphere that discourages constructive feedback will ultimately result in projects that move forward without adequate risk assessment. It is typically the technicians – the folks at “ground level” – who have the most accurate understanding of a project’s issues. If those people are muffled, management will cluelessly believe that their high priority initiative is on track. Like the Emperor who was assured that he had new clothes, management will be forced into reality when their project walks “naked” through the streets.
Secondly, the leaders of the project, ultimately including the president, fell victim to plan continuation bias. This well documented phenomenon occurs when people refuse to cancel an effort or change direction, despite obvious issues. Human nature dictates that people will be influenced by inertia when dealing with key initiatives. They will continually look for evidence confirming their original plans and will discount information critical to their efforts.
A common idea used to frame the priorities of a project is – “good, fast, cheap; pick any two”. This saying highlights the notion that you can’t “have your cake and eat it”. That is, all projects involve tradeoffs. A project of very high quality will require a greater investment in time and resources. A project done quickly may not have the same level of quality. Unfortunately, there are additional limitations to this “rule”. Some projects are so complex, or have such tight deadlines, that no amount of additional resources can make them successful. In the case of HealthCare.gov, the government set constraints on two of the dimensions. They had unyielding expectations on fast (an October 1st deadline) and good (specific features, capacity and service levels). Trying to add additional resources at the 11th hour was wholly insufficient to offset the other firmly determined dimensions.
What lessons can your organization learn from HealthCare.gov? Are you unwittingly setting the stage for your own similar failures? When you are planning important initiatives, keep the following concepts in mind:
- Avoid setting inflexible deadlines and functional requirements. While there are times (e.g. complying with a new law or regulation) when this is necessary, it is often done for political reasons.
- Utilize an iterative approach to project delivery with functionality and user populations implemented in a progressive fashion.
- Create a culture that encourages constructive criticism from all project participants.
- Establish a “pre-mortem” process (in the planning stage) where project participants brainstorm possible scenarios that could derail an initiative.
- Utilize historical examples as part of the project planning process. Those efforts with a limited historical base should be planned in a more conservative fashion.
- Be mindful of plan continuation bias. It is better to make course corrections than to plow into an iceberg.