Healthcare.gov – a troubled launch
We’ve been following the healthcare.gov go live process quite closely. For those of you that haven’t been following it, healthcare.gov is a website intended to create an online marketplace for US citizens to go choose their healthcare insurance from a range of healthcare providers - something they had to do by law. It went live at the start of October but has suffered numerous post-launch problems.
The first thing to say here is that all of us in the hosting and web / application development world have been through this kind of nightmare. It happens. This isn’t a blame piece.
What is interesting is this. During the course of some Senate hearings a few weeks ago, some emails came to light. These emails suggest that some very senior folks involved in this huge, complex process were getting properly worried about the risks of the website not working…way before go-live day.
This is of course very common in ’normal’ web development go-lives. As the project finally takes an identifiable shape and go-live deadlines get closer, fears are offered up. Questions are asked of other teams involved. Worries bubble to the surface. Everything becomes real. Time seems to start moving more quickly. Assumptions are informally cross-examined during chance meetings at the coffee machine. Nagging anxieties are raised formally at meeting tables.
But the problem is that very often the go-live process continues at this stage. The project has it’s milestones. It has it’s actors, it’s plans. What should happen at this point, and what should have happened with healthcare.gov in those pre-launch weeks, was that the red flag should have been thrown in. Go-live: STOP.
Get a red flag
What’s a red flag? It’s an informal term, but essentially it means that someone with authority stops the go-live process, no matter what stage it is at. Formally and unequivocally. We advise all clients to make sure they know who has possession of their own red flag. If you’re reading this and are interested, that person could well be you. And if it isn’t you, make sure you pass that red flag to someone else.
Okay that red flag clearly means a difficult conversation, almost certainly with your CIO and CEO. Probably your staff too. Some key customers maybe. It’ll inevitably mean disappointment and frustration. No small amount of professional embarrassment.
But ignore that. If that red flag needs used, it needs used – there is simply no point in making something live that you know is almost certainly going to fail. Even if the problems underneath the failure are indeed corrected eventually, the damage will have been done. Or to put it another way, if healthcare.gov had been set back 3-4 weeks, would it have been catastrophic? No. A little embarrassing maybe. But that embarrassment is almost literally nothing in comparison to the massive credibility problems faced by the whole US Healthcare administration now.
Here’s how to use the red flag
Make sure you have someone you can trust to appraise you of the REAL state-of-play in the crucial 4 weeks before launch. That person will need to understand what the technology folks are and aren’t actually saying to them.
Set the expectations. Don’t allow the red flag to be used for ’normal’ project delays. It’s only for the Armageddon scenario, it’s not a get-out-of jail-free card because the project is simply behind. But you’ll need truth. You’ll need reality, offered up freely.
If you don’t want to use the red flag, give it to someone else. Someone senior. And make sure they have your absolute support in them using it. Make sure that if it is used, they feel they wont be blamed.
Know your real deadlines. Too often we’ve seen clients nearly collapse under a deadline that was nothing more than an earnest and unimportant aspiration somewhere else in the organisation. Find out what missing the deadline really, really means for those folks. TV & radio advertising slots for example normally need at least 6 weeks notice to be deferred without penalty. Ignore any ‘deadlines' that don’t have a hard penalty.
Get all your suppliers tight to the issue. Most internet hosting companies will understand a launch delay and be sympathetic to a deferral of contract start date. If the developers need more time for example, make sure the other vendors understand that under your leadership, smugness or open criticism from other vendors isn’t welcome.
Use it only once. If you throw that red flag in to the go-live process, it’s gone. And if you need more than one red flag you should look hard at the folks doing your resource sizing and planning.
Get ready for those difficult conversations after the red flag. Know all your facts. But it’s much better to have those conversations after a controlled red flag, than in a situation where the site has gone live and it’s a living nightmare. No one will thank you for trying to meet a deadline, when you knew the thing was probably going to fail. They will thank you for a red flag used well. They mightn’t show it, but they will thank you.
This stuff isn’t easy
Too often the problem with situations like healthcare.gov isn’t the technology, the planning or the execution. It’s simply the communication and empowerment at the very final stages of go live. There is no red flag.
If your website or application launch is going to fail without alternative action, then please clutch that red flag; and go and tell the folks that need to hear that. And yes, even if it’s the President of the United States – tell him, NO, we have to stop. Yes, really - even him!
