(What follows is a politically dispassionate and technologically candid view of healthcare.gov, its creators, its critics, & its supporters.)
Should you find yourself now crawling out from under a rock, Healthcare.gov — the primary vehicle for purchasing individual health insurance plans provisioned by the Affordable Care Act — has hit major technical roadblocks in its national rollout.
Amidst the punditry, partisan noise, and general hullabaloo to invariably surround such a monumental glitch, it’s important to put Healthcare.gov in the appropriate business and technology context. At the very least, everyone should know why they’re complaining and to what degree the President’s technology team screwed up.
Two Important Points of Clarification on Healthcare.gov That Reflect Often-Unspoken Realities in the Tech World:
Most software fails. Literally. Statistically. This is a McKinsey-&-Oxford University-quantified (see graph below), Gartner-validated and many-other-researchers-endorsed truth. This failure isn’t the venture-backed, "my-new-app-to-locate-asian-fusion-food-trucks-just-crashed" kind of failure. This failure is a colossal, "Fortune 1000, big freaking companies spending (see: burning) tens of millions of dollars on software and technology projects that never show an ROI, run significantly over budget, sail past the shipping deadline, or never make it out of the lab" kind of failure.
Most software sucks. Of the websites and software platforms that don’t fail — i.e. of the websites and software that show a minimal ROI — the majority are truly painful to use. They’re overloaded with unnecessary features, slow, stodgy, ugly, grey, boxy, and are all-around classic _Office Space-_style software & technology.
Consider the entire pantheon of digital technology, and it’s clear the significant and vast majority of websites and software are effectively non-functional or non-valuable — ergo — most software sucks. Right now, Healthcare.gov sucks. It is effectively nonfunctional. (“Sucks” is not a technical or industry term. It carries the same social connotations in the software world as it does in every other facet of life.)
Keep this fail-suck paradigm in mind, it will be quantified later on.
A Good Looking Failure…
To reiterate, Healthcare.gov is failing. Most users are still experiencing significant log-in, interface, and enrollment completion issues. On top of that, many insurance companies can’t gather or process the information they need to allocate policies. [SOURCE: CNN, “Healthcare.gov: What Works, What Doesn’t”].
Granted, from a purely aesthetic standpoint, it’s a fairly clean and easy to use website (i.e. web-based software application). However, the design, and the process by which the design was created, has never been a point of criticism. [SOURCE: The Atlantic, “Healthcare.gov: Code Developed by the People and for the People, Released Back to the People”]
Healthcare.gov Is In Good Company…
The hard truth is that Healthcare.gov is (unfortunately) performing just like the vast majority of first-time software projects. In other words, MOST SOFTWARE PROJECTS FAIL.
Most enterprise-caliber (i.e. really, really big, really, really complex, multi-multi-million dollar) software projects fail by overrunning budgets, missing timetables, not shipping at all, or just generally not working.
Talk to any Fortune 1000 CIO and they’ll confirm this reality (off the record, of course). As companies and entrepreneurs buy and/or invent new software, more often than not, that purchase or that invention falls flat on its face. Employees hate to use it, it doesn’t communicate well with other systems, it fails to actually solve problems.
Whatever the reason may be, historical statistics tell us that most software fails. So, Mr. President, you and your team dropped the ball, but at least you’re all in good company.
Qualifying The Fail-Suck Paradigm: i.e. Why You Hate Your Company’s Software
Not only do most software projects fail, but even the ones that functionally succeed are still mostly loathed.
Think about the last website or software platform you logged into at work. Your email platform. Your sales CRM. That database your boss yells at you to update. Does it look or feel like that simple iPhone to-do list app that you love oh so very much? Probably not.
The processes that go into building business software are light years apart from how your so-loved app was designed and built. Which is why using business software feels onerous, and using consumer software (i.e. “apps”) feels joyful.
Why Is Fail-Suck So Prevalent?
Why do software projects fail, and why do most business software platforms suck? More to the point, why is Healthcare.gov woefully non-functional? Because its creation followed the same thematic process that guides the creation of most other business software. This process is known as Waterfall Software Development.
Waterfall is the old-school way of building technology. With Waterfall, a client tells his/her third-party software provider, “I want a platform to manage my sales pipeline.” That third party then runs away to a lab for six months, conjures whatever platform their people think has the coolest/greatest bells and whistles, and then comes back to the client and says, “Here ya’ go!”
The client has zero input on features (i.e. what the software does) and design (i.e. how it looks) but is expected to use it nonetheless. And to pay a lot of money for it. It’s like telling your tailor, “I want a suit.” After three months, he hands you a lime green size 64L when you wanted a navy 42R. Then, he still charges you $50K for it. Yeah, technically it’s what you asked for, but it’s not really what you wanted.
Progressive technology’s answer to “Waterfall” is “Agile” software development.
The Agile process means that software developers take a far more iterative, platform-agnostic, and user-centric approach to solving problems with technology. When a client tells an Agile software shop, “I want a platform to manage my sales pipeline,” the Agile team’s first question (of many, many more to come) is “Why?”.
Agile developers get to the heart of the problem that needs solving, they work to understand the actual flesh-and-blood people who will use the software (i.e. what people like and don’t like in technology), and they work with the client on a daily/weekly/monthly basis to garner feedback on the software as it is created. The goal is not to deliver software, it’s to solve a problem.
The difference between Waterfall and Agile in the technology world is akin to the difference between your doctor bloodletting you and your doctor using crazy-smart robots to execute flawless surgical procedures. The latter is just better and smarter.
Healthcare.gov’s Creators Used Both Waterfall & Agile
What’s interesting about Healthcare.gov is that it was built with both Waterfall and Agile methodologies. SOURCE: [Businessweek, “Obamacare Didn’t Have to Fail”]
Businessweek’s Paul Ford does a great job of breaking down the Waterfall and Agile elements of Healthcare.gov.
As Ford aptly describes, every software platform has a “front-end” (i.e. the screens and displays that people actually see and click) and a “back-end” (i.e. all the crazy machinations and integrations that occur in the background to make software work).
To clarify Ford’s analogy, think of software and websites like a popular restaurant. The dining room is the front-end i.e. the part that you, as the consumer, experience. The kitchen is the back-end, i.e. the part you don’t see.
Quite simply, the front-end of Healthcare.gov was built via Agile processes. Under White House CTO Todd Park, the government commissioned several progressive technology companies to devise the user-experience and design. Consistent with Agile and open-source philosophies, these companies published their progress via the code-sharing platform, Github. [SOURCE: The Atlantic, “Healthcare.gov: Code Developed by the People and for the People, Released Back to the People”]
Publishing on Github means that anybody and everybody in the tech universe could see the code that these folks were writing on the front-end and could provide input on the way in which they were building the software. Think of it like crowd-sourced, best practices.
The outcome of this Github-friendly, open-source initiative is what you see on Healthcare.gov. The website is pretty sharp and easy-to-use… right up to the point where you try enrolling in a healthcare plan.
In short, Agile development methodologies — which, by the way are secure and prevalent across other government departments, including the Department of Defense [SOURCE: Businessweek, “Obamacare Didn’t Have to Fail”] — enabled the most successful part of Healthcare.gov, the part that you see.
Unfortunately, what you see on Healthcare.gov is not what you get. When website visitors reach the point of actual plan enrollment, the Healthcare.gov back-end takes over. At this point, the trouble starts.
The back-end is what you don’t see; the technological machinations that enable Healthcare.gov to communicate with the hundreds of insurance company software platforms. It’s in this communication between the two systems where an individual’s information is processed and health insurance plan options are generated for their consideration and potential enrollment.
So why is the back-end messed up?
In large part because the process of making two (or two thousand) disparate software systems communicate is inherently challenging, particularly when they’re transferring complex and secure data like personal and health insurance information.
More concretely, the back-end of Healthcare.gov — the real software-y part of the system— is flawed in large part due to two realities:
It was built in an ass-backwards, non-progressive way by flawed and technologically-dated partners, chief among them CGI Federal. (More info on CGI from the Washington Post, “Meet CGI Federal, the company behind the botched launch of HealthCare.gov”.)
The data integration process was/is (supposedly) overseen by non-technical government departments (Health & Human Services + Centers for Medicare & Medicaid). [SOURCE: WSJ, “Data Integration Challenges Underpin Balky Health Exchanges”
Whereas the front-end was built by progressive third-party technology creators (i.e. non-traditional gov’t contractors), the back-end was built with closed processes by un-progressive long-standing gov’t partners and the back-end integrations overseen by monolith gov’t agencies with little to no understanding of technology.
The Generally Overlooked Moral Of The Story = Healthcare.gov Is On-trend With Most Fortune 1000 Technology…
The reality is that the President’s team has handled Healthcare.gov in the same way many, many midcap and enterprise companies handle their technology:
Non-tech-savvy leaders making uninformed technology decisions. That’s it. Bottom-line. And this is costing companies millions.
Most business leaders are incredibly well qualified for their respective functions. No one gets to be a Chief Sales Officer, a VP of Operations, Director of Finance, or SVP of Marketing without merit and demonstrable success. However, functional savvy does not translate to success in conceiving and building strong technology solutions. More often than folks outside of the tech world may think, successful-but-tech-unsavvy business leaders take on a software project and then pick the wrong partners, leverage the wrong technology, practice the wrong process, and deliver the wrong software.
The President did the same thing here.
Where The President & His Team Screwed Up
Hired a flawed Canadian company to build the core delivery vehicle of a marquee domestic program. Shop smart, and shop local Mr. President. There are plenty of progressive US technology companies here that could have better tackled that back-end.
Empowered HHS and/or CMS to oversee the data integration. This is like getting your lawyer to manage a space mission to Mars. It’s not that your lawyer is unintelligent, it’s that your lawyer is fundamentally ill-equipped for that nuanced and extremely technical task.
Allowed just four-to-six days for a Healthcare.gov testing period [SOURCE: Washington Examiner, “Troubled Obamacare website wasn’t tested until a week before launch”]. This is just ludicrous and is an example of profoundly mismanaged timetables and expectations over a multi-year period.
Failed to roll-out the software in stages and/or pursue pilot programs in incentivized states. They should have treated Healthcare.gov like most smart companies treat new tech product rolls-outs: test in small markets to get user feedback before deploying to the entire user base. Couldn’t certain states have been incentivized to deploy state-level exchanges sooner in the interests of providing feedback to improve Healthcare.gov? Couldn’t they have introduced scaled-back versions of the exchange, with a handful of insurance partners, to stress test the integrations? Well… yeah.
(Potential) Ways Sec. Sebelius and President Obama Can Banish the Suck…
Below are potential ameliorative actions to be taken by the folks in charge (POTUS, Sec. Sebelius, WH CTO Todd Parks) to potentially begin earning back the faith of insurance-buyers and the tech community:
Cop to the colossal tech screw up, and go beyond a postured Rose Garden speech. Be raw, be vulnerable, be honest. Delineate between the overall law, and the software (a lot of people probably don’t get the difference). To his credit, it feels like the President is steering the conversation in that direction. [SOURCE: WashingtonPost, “Transcript of President Obama’s Oct. 21 remarks on problems with the Obamacare rollout”]
Recognize that the federal government is a digital business, and empower it to change. The NSA and CIA sure as hell know this (though have allegedly taken it to dangerous ends). It’s about time everybody else came around and got digital-progressive, starting with the President. Deborah Bryant, an Open Source Strategist recently quoted by Businessweek, is spot-on “I think that the White House developing an executive order in the area of open source would be extremely helpful. For every [civil servant] who has gone forward on doing something with open source, there are probably another dozen who would like to have that kind of cover.” Deborah[SOURCE: BusinessWeek, “Obamacare Didn’t Have to Fail”, page 2.]
Treat the back-end like the front-end. This is a lot easier said than done. The process of linking Healthcare.gov to a myriad of insurance databases and processing platforms is astronomically complicated. That said, the President’s team did hire progressive and non-traditional third-parties to focus on the user experience. However, they screwed up in not selecting similarly progressive companies to create a cohesive and efficient back-end and data integration.
The next wave of technology will be ridden proudly by those who can elegantly, tastefully, and powerfully re-imagine how traditionally large and ugly back-end business software systems talk to each other (kind of like A Beautiful Mind but on a computer, not a library window).
Although Healthcare.gov unquestionably sucks right now, the country shouldn’t indulge the jerks who will use the website’s failings as a crutch for their “government shouldn’t invest in technology” or “government can’t succeed in technology” arguments. These are profoundly lazy, partisan, and uninspired sentiments.
Government should, and can, lead the technological way. Local, state, and federal technology should be so freaking advanced, and so freaking awesome to use, that startups and established tech pioneers are clambering for the opportunity to partner up and work on these projects.
The way to get there is simple: don’t pick vendors who compete on price, insist on finding new and progressive partners (read: traditionally NOT gov’t contractors), and empower those partners to deliver disruptive and painfully creative solutions.