The fundamental project planning of the healthcare exchange doomed it to delivery failure. This isn't just a lesson for the government. This is important for businesses to understand as well.
Big Bang Development goes like this... all the planning goes into one little ball, tightly planned with all sorts of political requirements and packed with lots of money as the "creative" energy and BOOM - the universe is created and delivered in one fell swoop. And Boom went the healthcare exchange but in a blow up way. It's like trying to launch an elephant with a catapult miles away on a tiny target and you only get one shot. Instead you want to fling a bunch of cats a block at a time for miles.
Big Bang application development philosophy killed the federal healthcare exchange project before the effort ever began. It's a throw back to the late 80s, early 90s software development philosophy. Take a huge project, have non-technical people dictate all the project requirements and hit a set of goals exactly. Of course the project requirements are political and not technical in nature. It all gets thrown over to project managers and technical people and told, "make it happen". So a bunch of people get in the room and they say, okay it's all planned out. Lots of money is thrown into the mix since money is considered the eternal balm for any important project and off you go. These projects almost never meet the three goals set to them - hit budget, hit deadline and hit quality standards. In my development experience we'd always say to a fixed scope project, "deadline, budget and quality - pick two".
Unlimited Budget Doesn't Solve All Development Problems
In this case the healthcare exchange project only hit one goal - deadline. It went wildly over budget and it missed on quality. And that gets to another unusual idiom - "you can throw money at a project but nine woman can't make one baby in a month". There are so many dependencies that coders, engineers, testers, database architects, etc. have on each other that more and more of those skill sets just stack up in a queue of project work. More hands don't get the project done on time and meeting quality standards. The process is flawed so it doesn't scale.
Testing Is Sacrificed for Deadline at a Quality Detriment
Product and code testing usually comes at the middle/end of a project. It is a process and it requires time. What happens is delays in code development in the beginning and middle of the project should end up pushing out the overall project timeline - i.e., you deliver late. Testing is sitting idle waiting for the code to test. So with no change in the deliverable date guess whose time gets sacrificed? You bet you, testing. With limited testing you launch with myriad problems. Quality is sacrificed.
Head in the Sand
Denying information and "putting your head in the sand" is not a practice that works. It only makes solutions and remedies more unobtainable. Here's what the White House did.
What's the Alternative? AN ITERATIVE APPROACH
MOST development efforts do two things. One, they break a large project into many smaller pieces that progress both separately and then get tied together. This is the flinging many cats analogy. This is an iterative approach. It allows smaller teams to work on and test many more functions simultaneously. It also allows you to make changes in the middle of the project because business owners (think politicians and bureaucrats in this case) get to actually use some of the system and give feedback. It also allows for a "pressure release valve" as a project that will not meet deadline overall can release part of the promise by launching a smaller product and finishing later.
What Else Can Help? LAUNCHING BETA
Just about every free to use online application states its a BETA product. Even for years and years with millions of users. Why? Because they want to get the product to market for people to benefit as soon as possible but let people know it may not be perfect. They give an easy way for people to report problems to them and this helps test and fix the issues. In effect that's what was launched by the healthcare exchange. They put the "testing" in the hands of the users. The problem is they claimed it was complete AND they gave no online mechanism to collect the issues from the users to help them identify and fix bugs quickly. Bugs in products exist, that is okay. The term "bugs" was used by Edison, Bell and Tesla back in the late 1800's in developing their products - lights, gramophone, telephone, etc. It happens, embrace it and have users help you constructively.
Let's all take big government lessons to heart and insert it into our "small" business efforts. Iterative product development approaches always trump big bang development concepts- every time.