As a web project manager, most times my job title itself is a bit of cocktail party conversation killer.
Despite the fact that we’ve had the world wide web so present in our lives for nearly two decades, most people think of web builds as an activity that one person does – wearing the hats of architect, designer, coder, writer, developer, system administrator and, of course, project manager all at the same time.
And that general lack of understanding of the complex systems and roles involved in making web sites work is reflected in the recent HealthCare.gov debacle.
Fortunately, for me, that means my job title makes people suddenly want to talk to me about my work.
In a nutshell, you can trace the failure to a few different myths often underlying major failures in development projects.
1. The Myth of the Man Month
Everyone wants to think that if you have a big problem to solve, you can just throw more and more bodies at it to reduce the time frame. The reality is exactly the opposite – that the more bodies involved in a complex problem create more problems, beyond simply a diminished return on investment.
This is especially true as projects approach deadlines. Of course, if you have a major contract to deliver and your client wants to throw more money at the problem, it’s difficult to say no.
2. It’s All 1s and 0s
Computer programming is just programming, right? Well, no.
In this case, they had teams of programmers coming at the problem from at least two different worlds. Working in a siloed client-server environment is night and day from working in the web world.
And when you are trying to get those two worlds to unite under one uber-program, the complexity isn’t times 2. It’s more like 2 to the 10th. Think of trying to get bumper cars to run on high-speed rail. With each of those bumper cars (representing the hundreds of different health care insurance providers) themselves having different wheels and engines and power sources.
3. Just One More Thing
Adding just one more item to a crunch-time project is a frequent project killer. In the case of HealthCare.gov, adding the last minute registration requirement is what I suspect played the greatest role in killing the project.
It would be the equivalent of asking the developers “Now that we have the bumper cars getting onto the high-speed rail, and back out, just add a card-driven turnstile system.”
It’s not that easy.
And again, it’s very hard to say no with so much at stake and so much money available. Taxpayer dollars especially.
4. The Greater the Documentation, the Better the Project
While you certainly need some documentation, what we know from modern software development practices is that you’re better off building and testing as early on in the process as possible. If you spend all your time documenting, and hope that the project will somehow come together in the end as your copious notes indicate it will, you’ve lost the opportunity to build smaller elements out along the way to make sure you are on track.
This project worked well in 2010 because it had a more limited feature set. I suspect that had they simply taken the existing functionality and rolled out specific smaller features along the way, they might have kept the project owners at least somewhat satisfied and had a greater opportunity to predict and address road blocks along the way rather than sorting out the pile up at the end.
Of course, the broader issues of how government procurement works, and how challenging it is to properly staff IT positions at all, let alone government IT positions, and the sheer complexity of the project made the success of a full blown, ready to go web site a slim prospect at best from the start, the lessons learned from decades of web development could have given it a better chance of succeeding.
Given how politicized the entire project has become, I suspect successful launch will be well into December rather than November 1st, unless they can keep calm, carry on, and especially avoid mistake #1.