Who botched Healthcare.gov? The contractors, politicians, and president all claim that they are not responsible – and they are all right. Forcing a new idea into a locked government business model virtually guaranteed that problems would arise. Further understanding how an organization’s capabilities define its actions can help explain how problems arose with Healthcare.gov and, in the second post in this series, help illuminate how these problems can be fixed.
Why Successful Organizations Struggle to Implement New Ideas
Sometimes innovations fail because of a fatal technological flaw or because markets are too immature to support their development. More often than not, however, they fail because of internal implementation issues – the managers or organizations responsible simply do not have the capabilities required to develop significantly new innovations.
Why do successful organizations with a long track record lack these skills? Simply put, organizations’ capabilities to do some things well all the time create inherent disabilities when they try to use the same capabilities to do new, different things. Hence it’s no surprise that the same government that successfully administers an extraordinarily complex tax code and collection system every single year can simultaneously bungle the one-time development of a data-backed online marketplace.
Defining Capabilities, Or Why What Seems Right is Often Wrong
An organization’s capabilities are the combination of three components: Resources, Processes, and Values (RPV). Every organizational function leverages each of these components in order to generate outcomes.
- Resources: Measurable or semi-measurable assets and relationships, including people, equipment, technology, design, brands, information, cash, relationships with suppliers and distributors, etc.
- Processes: The methods of interaction, coordination, communication, and decision making through which organizations transform resource inputs into valuable outputs.
- Values: The standards by which organizations employees make prioritization decisions – how they decide which customers are important, what new ideas are worth pursuing, etc.
As an organization becomes successful, its business model rightly “locks” around the RPV combination that generated past success. This becomes problematic, however, when an organization attempts to leverage existing resources, processes, and values to deliver certain outcomes significantly different from past projects.
Take mainframe and minicomputer manufacturers, for example. The personal computer entered the scene while minicomputer manufacturers where making 45% margins on $20,000 sales. No sane manager would ever have diverted existing resources towards making personal computers – the person who proposed taking engineers away from minicomputers to prioritize making a toy computer that sold for $2,000 with 25% margin would have been laughed out of the office!
How the Government Blocked Healthcare.gov
Rather than falling victim to “cronyism, secrecy, and authoritarianism,” we posit that, like mainframe and minicomputer manufacturers, Healthcare.gov fell victim to the government’s own established resources, processes, and values.
Concerning social programs, the U.S. government has traditionally performed three tasks outside of legislation:
- Provided funding to private providers (via research grants, for example)
- Contracted directly with private providers for services (via Medicare and Medicaid, or through specific contracts)
- Provided or gathered data (Weather.gov, FederalReporting.gov)
Healthcare.gov, an online marketplace meant to connect individuals with private insurance companies while verifying their eligibility for subsidies, does not fall into any of these three categories.
Because Healthcare.gov is a new, innovative task for the federal government, leveraging old resources, processes, and values inevitably created internal conflict that manifested itself in a long contracting process, drawn-out political conflict and unwillingness of any single party to accept responsibility for failure.
These problems were foreseeable: the project was unique, deadlines mattered, and the customer base was unclear. So why didn’t the government get it right?
Imagine that you are a federal employee responsible for procuring contracts to build Healthcare.gov. You see the problems, put out a call for applications, and receive a number of proposals. How do you choose which to accept?
Ideally, you go with the companies who have experience dealing with the problems that you expect to confront. You find an IT company that has a history of delivering on time, and one that is good at dealing with unclear customer segments, refining as it goes.
But you can’t. You sit looking at the pile of applications, almost all of them from companies who have entire divisions dedicated to obtaining government contracts by navigating the obtuse system the applications has to navigate before they even reached your desk. Then, instead of picking the businesses that can best address the specific challenges of the situation, you pick up your congress-mandated rubric of criteria.
Has this contractor completed government work in the past? Check (though you think to yourself, as you check the box, that they have never completed an IT project on time).
Does this contractor promise the most features for the lowest price? Check (that line sounded better in legislation than it does in implementation – features never come in at the prices promised).
Has the contractor demonstrated that they have sufficient technical and computer coding ability? Check (CGI, the primary Healthcare.gov contractor, had worked successfully on U.S. government technical projects before – but never of the type proposed now).
You sit with your completed rubric and realize that you have no choice. Either you pick the contractor who has no real and relevant experience but can check the boxes, or you do nothing. Concerned about keeping your job, you decide sign the paper and forward it to the next person in the command line.
Healthcare.gov didn’t crash because people were inept or stupid. It just became a victim of federal procedure that aligns RPV in a manner useful for many projects but hostile to innovation.
Hindsight is Always 20/20
It’s easy to criticize failure, but not so simple to point out opportunities to progress. We hope that this post can provoke reconsideration of the government contracting process and RPV framework in relationship to innovative projects. Moving forward, the next post in this two-part series will examine important principles that could enable the revival of Healthcare.gov.
See The Innovator’s Solution chapter seven, “Is Your Organization Capable of Disruptive Growth?” by Christensen and Raynor for more comprehensive treatment of these topics.
