By reader request, I’m going to grab onto the third rail and talk about the Affordable Care Act/Obamacare/healthcare.gov website fiasco.
As someone who has been involved in a large number of IT projects, inside and outside the government, successful and failed, I can speak to that. I know the burning question in everyone’s mind is how can three guys banging away at a keyboard for three days build a better web site than the United States Government?
The snarky answer is that the best projects I’ve ever worked on have been when someone asked for something, then one or two other guys sat down with me and we banged away at a keyboard for a little while and didn’t tell anyone what we were doing until we were done.
But it’s probably more complicated than that.
But first, let me reach over and find something else with high voltage running through it to grab onto with my other hand, and I’ll say it’s not a matter of whether a conservative or a liberal is in charge. I worked for a few years on a couple of failed Bush-era projects. People are still getting together twice a year, every year, and arguing over nitpicky details of that requirement. Bush ordered it during his first term. It didn’t get done in Bush’s first term, or his second. Now we’re well into the second term of Bush’s successor, and that project still isn’t done. A big part of the problem is that groups of people are arguing over details, and, in some cases, micromanaging problems they don’t understand.
I got into an argument at that meeting, like clockwork, with the same guy, every single time. “That blankety-blank standing over there said he doesn’t know what’s going on on our network and he doesn’t want to know!” he said, pointing an accusing finger.
I tried to explain the concept of encryption to him, and never could. That blankety-blank didn’t want to know what was going on on the network because it was classified, and if he could see it, so could anyone else, including the Chinese. And, besides, that blankety-blank didn’t need to know what was going on on the network for the other guy’s data to be able to get from point A to point B. The two things weren’t even related.
“Tell me your requirements,” I told this guy, “and I’ll be more than happy to ask for the technical details like ports and protocols that you need to get it done.”
“See, now you’re already jumping to ports and protocols. We’re trying to figure out the requirement.”
I see no need to elaborate further. Well, except to say that the one system I’ve seen that specified five-nines uptime and actually delivered it was also built for the government, to government specifications. And it delivered it while running on Windows 2000. Yeah. Impressive. And I know that system delivered five-nines uptime because I was the guy who pulled the data out of the system to prove it was meeting the goal.
Cringely asserted a week or two ago that 50% of IT projects are successful, and 50% of them fail. To me, that 50% figure seems a bit optimistic, but maybe it depends on how you define project.
My successful projects typically have had a few things in common: management that knew when to empower and when to get out of the way, the technical people knew what problem they were trying to solve, and they understood the environment the thing they were building was going to work in.
The larger that project is and the more people who are involved in it, the easier it is for one of those few things to get way out of whack. Toss in some outside vendors who don’t completely understand the requirement and have no idea about the environment, and then you’re lucky if only one of those things gets out of whack. After all, the vendor is probably selling you something (if not a whole stack of somethings) that they built for somebody else.
So let’s look at those three 20-year-old guys working in a basement who built healthsherpa.com, a better healthcare.gov than healthcare.gov.
First, had healthcare.gov looked and worked like healthsherpa.com, people would be calling it a failure. After all, you just punch in some data, and in the end, you get a phone number to call (not necessarily even a toll-free number at that), the name of a product, and a price. Had the government delivered that, it would still be a scandal. Maybe an even bigger scandal. It’s 2013, after all, not 1993. We know how to do e-commerce now.
But there’s definitely a lesson to learn from healthsherpa.com. They saw the problem that the real site wasn’t solving, and they decided to sit down and see what they could do in a few days that would be better. And these three outsiders realized that they weren’t trying to solve a difficult problem.
Think about what the site does. You tell it where you live, a little bit about your family, and how much money you make. Then it spits out a list of health plans that are available to you, along with a price.
Strip away the e-commerce part, and what you really have is a second-year (if not second-semester) computer science problem. Shove a bunch of publicly available information into a database, let people punch in some information about themselves, and it retrieves the relevant health care plan information from the database, and does a little bit of math to adjust the results before presenting them. Three guys beyond their second semester of computer science ought be able to build that pretty quickly. So they didn’t let the part they couldn’t do stand in the way of the piece they could do.
They did the best they could at the piece they could do, and a lot of people are happy with the results.
You can count me as one of them. I punched in some information about my family into it, and it told me about 25 different health plans that are available to me, along with a price. In a matter of seconds, I knew something I hadn’t known before.
Sometimes it’s better to do half the job well than the whole job poorly.
I can only speculate, but, based on the years I spent watching people sit in rooms and argue about what they’re building, I think it’s a pretty sure bet that the team building the real healthcare.gov site long, long ago lost sight of the concept that the heart of their product was a database that shoved out information based on a person’s zip code.
The second must-have is the e-commerce portion to let you buy that plan you chose. That part’s harder, but that’s a problem countless others have solved too. Silicon Valley is full of millionaires and billionaires who got that way by solving the same problem at a young age.
Build those two pieces and bolt them together, and you have something like what the state of Kentucky built: a bare-bones but functional and perfectly usable site that some people are holding up as a model of what the Federal government should have built.
Now, if you want to make it look really snazzy, and you want it to be really fast, things like that are additional pieces of the project. But they’re secondary. If the go-live date is tomorrow and one of those pieces isn’t ready, it’s not a showstopper. You can cancel them or add them later.
A good project manager (or project management team) can juggle these pieces and make sure that the pieces at the project’s core get the resources they need, while good team leads keep the teams focused on the heart of the problem that they’re trying to solve, whether it’s making database queries or sending purchasing information to an insurance company.
What I think really happened was that a mess of contractors and subcontractors lost sight of the idea that they were trying to solve two relatively simple problems, and it turned into a big pile of really big problems and spiraled out of control. It happens.
And this time it happened on a project that’s in the public eye. You’ll never hear of the government projects I worked on, so nobody looks bad if those projects ever get declared a failure. This was a must-win, and it failed so badly it’s destined to be the butt of jokes for years to come.
It looks worse since it happened under the watch of a president with a reputation for being pretty tech-savvy. Obama’s campaign websites worked well, he’s adept at using social media, and he talks a lot about his smartphone. He seemed like a guy who would be capable of putting together a team that could deliver the goods.
Then again, that’s not the only time it’s happened. Microsoft released Windows 8 and Steve Ballmer proclaimed he bet the company on it. Epic fail, as the kids these days say. Sometimes must-wins work out–Windows 7 worked out pretty well for Microsoft–but it’s not a guarantee.
So how does one save face now?
Well, there are a lot of smart people working on the problem now. If they remember that they’re really trying to solve a couple of problems that they’ve solved many times before, and they aren’t afraid to throw away the existing site if rebuilding proves easier than fixing, I think they can solve it pretty quickly. And they might do well to release version 2.0 as a stripped-down, basic, barebones implementation. It sends the message that they focused on solving the problem, rather than wowing you with superficial elements that are nice to have, but don’t really help to get you, the end user, what you came for.
But it won’t happen in three days. Their problem is more difficult to solve, and since they’re a government agency and they’re storing and/or transmitting sensitive consumer information, there’s going to be a certification and accreditation process to go through. That part alone will take longer than three days.
But I think it’s possible for the right team to salvage it. I’ll even be bold and say it’s possible they can have it up and running properly before the end of the year. Difficult maybe, but possible.
Is it too late for that? I don’t really think so. This is technology. Enough projects fail that pretty much everyone can think of a product they saw that didn’t deliver, or a project somewhere they worked that didn’t pan out. I can’t be the only one who thinks Cringely’s estimate of 50% of IT projects working might be generous. People are used to version 1.0 being glitchy.