A couple of weeks ago, Brian did a great job explaining what retailers can learn from the healthcare.gov debacle. I was content to leave him the last word, but after receiving a newsletter from old friend Lewis Olishansky, I thought I might have a bit more to add to the tale. Lewis’ top story: a system I’d ‘saved’ in cleaning up a retail project fiasco about seventeen years ago is finally riding off into the sunset. And so I remembered some of my own lessons learned. While I posted the bulk of this story on Forbes, I thought it was also important to re-post it here.

For better or worse, I’ve got more than a little experience cleaning up a computer mess. And that’s why I’m going to talk about the disaster that is healthcare.gov. I know I’ve said this before, but I am stuck in the same questions:

What the heck has happened to the state of my old profession? How have we lost the basics of developing, testing and validating software? Where’d we go wrong?

Seriously…while it may seem to the casual app user that we’ve evolved, as an actual profession, we’ve gone backwards. I know I’ve ranted about this before, but now we’re all getting an up-front and personal glimpse of just how bad it has gotten.

If you’re a US citizen, one way or another the Affordable Care Act (ACA or “Obamacare “) is going to affect you. Most of us, regardless of our political persuasion are asking ourselves “How? ” We know that many of our current health insurance plans have been phased out, but haven’t found out what’s going to take their place. Heck, RSR’s group health plan is going away. And we don’t have a lot of answers.

So forthwith are my suggestions for solving this computer mess. I’m hoping most of you reading this will say “Of course. ” I’m afraid it will be a revelation for far too many.

1: Don’t back into a pre-planned date unless you really,
really have to.

The administration is insisting all problems will be resolved by the end of November, so deadlines don’t have to be postponed. With all due respect, how the heck do you KNOW that? When people have just barely begun to log into the system, what to speak of explore the back-ends and actually apply for coverage, you can’t possibly know what’s still buried. I don’t know a sane IT person in the world who wouldn’t accept an extension when managing a disaster of this scope. It will take as long as it takes. Is a year too long? Probably…but so what? Then you can actually exceed expectations. The “surge ” of people actually trying to log in when the thing is pronounced “working ” will be enormous if it’s close to the penalty date. Let’s all shoot ourselves in the foot! It’s not like Y2K, where we worked on the problem for anywhere from 5 to 7 years because we KNEW that date wasn’t going to change.

One caveat: Even though I recommend avoiding hard dates, there is some precedent for incentivizing based on hitting delivery dates and achieving technical objectives. IHL Consulting groups’ Jerry Sheldon reports this was a successful strategy when he worked with the Department of Defense. I also recall this strategy worked well after the Northridge earthquake in 1994. The quake badly damaged four bridges on the Santa Monica Freeway in Los Angeles. C.C. Myers, Inc. was contracted to fix them. It was stipulated that work had to be finished in 140 days, and the company would be paid a $200,000 bonus for every day it came in ahead of schedule. The company finished in only 66 days and earned a $14.8 M bonus. To my knowledge, the bridges remain in fine shape.

2: Give the end user some functionality as soon as you can.

Until late last week the amount of functionality of healthcare.gov was…none. This past week some group or another FINALLY brought a list of exchange plans available by state, by insured age onto healthcare.gov. Of course, we don’t know a lot about those plans, but just having the list to browse through is a major accomplishment. We’ve experienced so much unnecessary uncertainty, so much political posturing, and for what?

3: Find some people who are actually going to use the system and who’d like to see it succeed.

Put them on the project team. This may sound simple, but it’s actually surprisingly difficult. People can be either very risk-adverse or not interested in seeing the new technology succeed. Avoid those people. In this case, it might be appropriate to bring in some consumers as part of the testing team. Technicians can’t end-user test. They’re far too invested in their work to critique it properly, and they may not understand the most typical paths regular people take.

4: Do NOT outsource management of the project.

 I know this is counter to conventional wisdom, and in fact I read just the opposite recommendation elsewhere. Still, I stand by my statement. Systems Integrators can be helpful, but ownership must lie with an actual stakeholder. That stakeholder has to be a realist, not a political appointee.

Wise words from Cathy Hotka, retail thought leader and former Vice President of IT for the National Retail Federation suggest one other major rule for big, public projects. This was used by DC’s y2k task force: be very clear about what the project entails, delineate discrete tasks, keep communication between the players, and never allow disagreements to become public.

5: Create a prioritized list of problems and meet daily to update.

“New, fixed, and ongoing ” issues with a leadership team of no more than seven. I know this is a government driven project, and everyone’s going to want a piece of the action. That’s great. It also creates an impossible situation. Somehow our politicians must winnow down their numbers for the sake of everyone else. Obstreperousness must not be condoned or allowed. This is serious stuff.

You know, I’m reading back through this list, and I’m thinking “Dang…for a country that put men on the moon when we had far less computing power, this should be a no-brainer. ” But apparently it’s not. And that makes me sad. Where has all the talent gone? Lost in a morass of political posturing?

I know one thing. Following the simple rules I’ve described above ultimately gets you to the finish line. While it may seem like forcing an end-date is important under the old theory that “work expands to fill up the space allocated to it, ” my late (great) boss John Fiore had a very different take. He used to say, “It takes nine months to make a baby. You can’t ask nine women to make a baby in one month. ” He also was fond of urging us to avoid one other pitfall: “The good news is, we’re making good time. The bad news is, we’re lost. ” John was right on both counts. Kids, we’re lost. Let’s slow down and get it right. If necessary, let’s incentivize people to speed it up, but keep expectations reasonable. Right now, it’s a mess.