Avoid Website Development Flops By Taking A Lesson From Healthcare.gov
“We’re in charge of developing your new website. You can have it good, fast, or cheap. Pick two.”
How many times have you heard (or said) something like that on a digital experience project? With any digital initiative, one of those desires is usually odd man out. Application development and delivery pros at corporations, digital agencies, and systems integrators know this; they’re often the people talking reality in the face of the wishes of the business asking for all three (and, frequently, a fourth: “Can you make it as good as Apple.com?”).
Web projects always require compromise. The challenge is figuring out what you can live without.
It’s enlightening to apply the good/fast/cheap triangle to the Healthcare.gov snafu that’s been playing out in Washington, DC. If you’re involved in web applications, reviewing the government’s project might be one way to inoculate yourself and your team against an invitation to the hot seat by preventing website crash and burn. No one wants to be like the Secretary of Health and Human Services, Kathleen Sebelius, and her squad, who’ve had to explain the most visible website flop in history.
It makes me ask: how did the Feds deal with the good/fast/cheap question for Healthcare.gov? It’s a hard reality to deal with on any digital project, never mind a project of this scale. Where would you compromise?
- Good: This is a no-brainer. If a website (and the digital customer experience) is the digital manifestation of your business, “good” must be the primary imperative, especially if you’re overhauling the US’s public healthcare exchange. What went into preparing for quality digital outcomes and uptime? This site had to be perfect. (Sebelius and others have admitted to Congress that mere weeks of testing occurred before the site went live.)
- Fast: Here it means the speed of project from start to launch. Given the deadline set by politicians, developers had zero wiggle room. Maybe the launch could have been delayed, but it appears that political pressures to launch no matter what ruled the day. If “fast” was imperative, and “good” was non-negotiable, perhaps the definition of “good” and the necessary requirements have been defined downward so that application developers — and the whole project team — had a more workable (read: less risky) solution at the October 1 launch.
- Cheap: I’m the last one to recommend an spending more than you need on a digital project. And you really can’t spend your way to good or fast. That said, I’d ask whether the process to hire contractors to build the site was driven by “lowest bidder wins” or whether qualitative factors were important. Did the contract teams have experience in massively scalable platforms, or in data-intensive, deeply integrated, secure systems with complex logic? (The cost of Healthcare.gov is foggy, with some estimates as high as $500 million and others down in the $125 million range.)
I’m not involved in the Healthcare.gov project, but it seems clear that good got sacrificed for fast. And fast was a killer requirement due to the massive complexity of the project. I’ll go out on a limb and venture that cost (and budget) was not a barrier here. Anyone involved in application development for digital experience can bring a lesson — or maybe a warning — to the table for their next big project: In the good/fast/cheap equation, make sure that the organization thinks carefully about which trait everyone is prepared to sacrifice.