Breaking Bad Healthcare: The Story of Healthcare.gov
It’s generally a good principle not to criticize something unless you’re willing to help fix it. That’s what former Microsoft exec Kurt DelBene learned, when he offered feedback on the Healthcare.gov website after its release in 2013, and instead of just providing feedback, he ended up taking the reins to fix the site.
It’s generally a good principle not to criticize something unless you’re willing to help fix it. That’s what former Microsoft exec Kurt DelBene learned, when he offered feedback on the Healthcare.gov website after its release in 2013, and instead of just providing feedback, he ended up taking the reins to fix the site. At a recent event sponsored by University of Washington’s Foster School of Business, DelBene provided a mini-business case on what went wrong with the project and how his team fixed it. With clarity, modesty, and wit DelBene both highlighted some major flaws in the process and encouraged attendees to consider a stint themselves helping out the government with major technological and business issues.
One of the first problems stemmed from an issue that is far too common in government and business: saying yes to a project before fully understanding the scope. In this case, and internal Whitehouse IT team, essentially signed up to deliver a website with requirements of something like Amazon.com without ever having built something that big. While most of us think of the consumer interface of Healthcare.gov, and the trouble that happened on that end, the actual site is extremely complex in needing to connect to hundreds of insurance plans among the major payers, and also to the IRS to verify income levels. Any facet of the site’s interface, up-time requirements, and integration needs was a daunting prospect, and the original architects didn’t have the full requirements set, and possibly the experience to know what was missing when they signed up.
Next, they chose two inappropriate technologies. One was a semi-structured database No-SQL database called MarkLogic, which they had always wanted to try out. The database choice itself was not necessarily the problem, but trying a new technology where the team did not have prior expertise for a project of this scale is risky and they chose the database without understanding the project specs. The second, was trying to use a flow-charting application that automatically generated screens to design the website. This type of application might be appropriate for an internal process application used by a small number of technical users, but it is not appropriate for a large scale consumer facing website that is intended to reach the general population, including those whose first language is not English or with a wide range of education. Software has not gotten to the point where it can design user-friendly versions of itself no matter what you read about artificial intelligence.
Another major, and widely publicized failure was delegating different parts of the project to at least 6 different contracting firms. No one took responsibility for the overall integration, and the contractors continued to point fingers about whose technology was failing.
These were only some of the problems that DelBene inherited with a hard deadline to launch the site. Other issues in site design included no failover system, no beta testing, and no instrumentation or telemetry to understand where the site might be failing. Within the development process there were also failings, for example no tracking of bugs and how much work was left to do.
DelBene started by listening, and this included to all team members not just senior leaders. Although he had to hit the ground running: briefing the President two days into the job, and famously, exiting a meeting into a closet instead of the hallway.
He then had the team prioritize what could be fixed for launch and what couldn’t.
While the site wasn’t conceived as cloud-based (in fact the original team expected the insurers to install servers in their datacenters to connect with the Healhtcare.gov site), DelBene says it was an excellent candidate for the cloud which would have been more secure and more scalable. The team did rebuild many consumer-facing parts of the site on Amazon Web Services and continued to iterate and test capabilities as the site was deployed by sending some groups of users to the new interfaces.
While DelBene was extremely modest, always citing the team, which included recruits from Google and Facebook but strangely not Microsoft, he did have some very specific advice for how to successfully run this type of government project in the first place.
The recommendations can be summed up as “run any consumer-facing government IT project the way you’d run a commercial software project.” Hire the right team, plan, test, and iterate, hold people accountable, and encourage honesty.
So much of this project’s initial issues were due to a lack of coherent team, and a lack of experience. Developing internal IT infrastructure and commercial software that is used by millions of people is very different, and requires a different skill set. As well, it requires humility as end-users outside your organization will let you know if something doesn’t work as evidenced by the negative press the original roll-out received.
DelBene, who used to run the $11B Office business for Microsoft, described this experience and work as the most important he’s done, and he ended the session by encouraging the audience of MBA candidates and alumni to consider how they could help the country. New programs like the White House Digital Services and 18F Organizations are specifically designed for people from private sector to be able to lend their expertise to government organizations for short periods of time. Considering that the future of all government transactions is digital, this is more important than ever.
