By contrast, McKinsey noted, the federal marketplace’s design was marked by “evolving requirements” that shifted throughout the design phase, leaving scant time to test the system before its launch.
The Washington Post had an informative article today about a presentation delivered by the consulting firm McKinsey & Co. to federal officials. This post is not about the politics of the situation, but my take on organization challenges that decreased the likelihood of success for HealthCare.gov.
It’s Web Development!
The creation of the health exchange is a software development project. It’s the same as adding features to Facebook, building a Twitter or an Amazon, or any web-based software project.
There are processes companies put in place to increase the likelihood of success for a development process. Oftentimes this involves a Product Manager, which is a field I have some experience in. Definitions vary, but generally speaking the PM is responsible to deliver clear, detailed requirements to the engineering team so they can focus on building what customers want.
Successful internet companies such as Amazon, Google, Facebook, and a host of others have mastered the development process and it’s a big reason for their success. They spend years and years tuning this process, finding the right organization structure and dynamics that results in the delivery of products customers love. The government can learn a thing or two from these companies, and it sounds like they’re pursuing just that. But is it too little too late?
The Process
“a camel is a horse designed by committee.”
HealthCare.gov is a huge project involving multiple powerful constituents…but the same rules of success apply. At a high level, many successful development projects follow these steps –
- Someone is assigned as the owner of the project, oftentimes a product manager (PM). This person meets with the business sponsor (or government leader) to understand the goals and key metrics. This is oftentimes an executive who has been empowered to make big decisions around the project.
- The PM summarizes the project to engineering stakeholders, and they collaboratively agree on a realistic scope and rough timeline. There shouldn’t be major scope changes after development on that piece of the project has started, but…
- …if there are significant scope changes, this is reviewed and signed off by the business sponsor.
- The PM goes writes the requirements (how it should work) for the project, while collaborating with engineering when necessary.
- When ready, the first requirements are handed off to engineering. Format and level of detail will vary based on organization and project.
- As the stories are worked, the PM is on-call to answer any “blockers” engineering may have. This could be an open question, a conflicting requirement, or anything preventing the project from moving forward.
- PM conducts an acceptance test as new work is released to production.
- As the project nears completion, the PM ensures internal stakeholder understand the impact and exactly what is being delivered.
- PM tracks usage and identifies blockers to adoption. Continually work with stakeholders to iterate and improve.
The consulting firm suggested that some of the project’s troubles occurred because there was “no single empowered decision-making authority,” or person in charge, who could make changes or define what constituted success…
Absent an executive sponsor or product owner, the chances of success sharply decline. You can see from the above what an important role these people play in the success of a software project.
Without strong leadership the team responsible for actually building the product will get conflicting direction from multiple stakeholders. In the case of HealthCare.gov these were very powerful stakeholders with a lot on the line.
Why does this matter? Because if the team building the product listens to each stakeholder, you get conflict. This conflict plays out in the product because it isn’t delightful to use. What if an ad executive who wanted more ad revenue insisted that Google show display ads on their search engine? Or a finance executive at Amazon says Amazon Prime has to be $10 more expensive to fatten margins? Or Twitter decided to keep building new features and never address stability issues? The list goes on.
What happens? The customer suffers.
The Case of HealthCare.gov
…Parts of the project that users would see — notably the Web portal, HealthCare.gov — are 100 percent finished, he said. But “the accounting systems, the payment systems, they still need to be” completed, Chao said.
The truth is that software projects fail or run behind – that’s part of the business. HealthCare.gov happens to be a high visibility and highly politicized project that is running behind.
Now we’re hearing that up to 40% of back-office functions are yet to be built. This part of a project is frequently addressed last, perhaps because it’s the least visible to the average user, and back office systems aren’t sexy when presented to the media. However this infrastructure is critical to project success. Think about the infamous Twitter fail-whale. That’s what happens when you neglect your infrastructure.
The Path Ahead
At this point the story seems to be playing out in the media, as various parties leak information that shifts the blame to other agencies. Today’s Washington Post article shifts some blame to the White House and officials including Secretary Sebelius, Marilyn Tavenner and [CMS official] Gary Cohen. The implication is that they knew the project was in serious risk, but still painted a rosy picture to the media and legislators. The White House said that they were aware of the issues, but not the severity. Maybe they should have asked some tough questions? (I can’t help but think of what a Steve Jobs or Jeff Bezos would do in this situation)
Right now I’m guessing (hoping?) that people are looking at the current state of HealthCare.gov and deciding what code is salvageable. It’s hard to build a building on top of a shaky foundation – something the government should consider is starting over from scratch, as much as an admission of failure that might be (but hey, the public doesn’t really need to know, they just want a working website). It might be the most cost effective option there is.
These are tax dollars we’re talking about, too – we’re all shareholders.
Implications for the Future
A few of the many questions that the HealthCare.gov project raises –
- How efficient can the government be when undergoing large scale technology projects? This one was truly a beast – is there a better structure involving public/private sector partnerships for projects like this? Who can be the objective leader/voice of reason…
- If only the sickest citizens apply for insurance on HealthCare.gov, is that an economically viable model? Insurance policies requires buy-in from a range of people with different risk profiles to be successful. (caveat – I know next to nothing about the insurance business)
- Most interesting, how will the government react to the media storm?
Let’s hope the leaders are able to get the project back on track…because that’s what matters!
You can read the full Washington Post article here.
