A few weeks ago, my wife had to make several phone calls to Amazon. We’d recently moved, and although she had updated our address in our Prime account, Amazon continued to send packages to the old location. She needed to call several times before the situation was rectified.
I thought of this as I listened to pundits discussing the disastrous rollout of HealthCare.gov, the consumer-facing Web portal for the Affordable Care Act. Why can’t Obama get it right? Why can’t the government do anything? Why didn’t they fly in the real pros from Silicon Valley to execute this?
In my experience, most websites work… just okay. Flawless sites are few and far between. (In general, the simpler they are, the more reliably they work.) I spend entire days working on LinkedIn, a shining example of advanced Web functionality, and not a day passes when I don’t encounter some kind of glitch – the big red bar announcing that “service is not available.” Facebook has had notable issues, and Twitter’s Fail Whale was so common in the site’s early months that it became a meme, worthy of its own Wikipedia entry.
In most of these cases, we learn to work around these glitches. But if any of these websites were providing services with life-or-death implications, consumer tolerance for their quirks would be very different. Imagine the hue and cry if the government were suddenly to mandate that every American must create an iTunes account, navigate that kludgy interface and make a purchase or face a fine.
The problem with HealthCare.gov, as far as I can tell, was mainly one of poorly managed expectations. Having been in charge of redesigns and rollouts for major consumer-facing websites, I can relate. Earlier in my career, I was on the hot seat for a top-to-bottom overhaul of major consumer-facing websites. All of these sites attracted millions of unique visitors each month; all were significantly smaller and less complex than HealthCare.gov.
At one major media company, we had an entire IT division of top-shelf developers and designers and project managers working with us on every phase of the development. Redesigning that site took more than a year. We missed a couple deadlines, launching several weeks later than our original target. There were some bugs when we went live. (In a separate adventure, that company invested millions of dollars attempting to create a proprietary content management system that never fully deployed.) At another company, our resources were not as vast, and although we followed strict Agile and Six Sigma methodology, although the blue-chip vendor charging us hundreds of thousands for the project promised repeatedly we’d hit the target date, we missed it by about six weeks, placing major ad campaigns (and major revenue) in jeopardy.
In each case, I was answering to senior management who knew little to nothing about digital infrastructure. Most CEO’s are pretty clueless about Internet launches and migrations. They like to play tough, draw a line in the sand, plant a flag (choose your own corporate cliché) on a launch date and then “hold feet to the fire” to make sure it’s accomplished. Those original targets are rarely, if ever, met. Website redesigns and relaunches are a lot like major home remodeling projects: They usually take longer and cost more, requiring compromises along the way.
The people responsible for managing the process are often reluctant to tell the whole truth to their bosses. Vendors are reluctant because they want to earn a full fee; internal managers are reluctant because their jobs are on the line and they may be replaced by a more enthusiastic “yes” man or woman. Most of the process methodologies employed to ensure quality control wind up serving primarily as CYA strategies – documentation parties can point to, shifting blame away from themselves.
The main problem with HealthCare.gov, as far as I can tell, is that expectations were not managed. Once the administration got the final green light, there was not enough time before October 1, 2013, to create and fully test a site with the requisite functionality. This was not a question of talent or resources. The process requires time – time to define the scope, design the site, build the wire frames, create the code, integrate the APIs, and test and test and test. And regardless of how much time and testing had occurred, real-world use would still inevitably have revealed flaws that would need to be fixed. That’s just the nature of the Internet. It’s all built on rapidly evolving technologies, the upgrade of any of which can create unforeseen conflicts elsewhere in the system.
Someone needed to stand up and say, “Sorry, it’s just not possible.” That way the Administration could have communicated to Congress and the public a more realistic time table.
Of course, the more likely outcome is that the responsible realist communicating that message would have been given his or her walking papers, replaced by somebody else who’d blithely say, “Can do, Chief!”
The Internet is amazing, but it ain’t magic.