The disaster whose face is the Obamacare website is a familiar sight to many technical managers. It is clear that the failure is one of management, not programming or servers or clouds or Canadians. Now there is a new plan -- clearly born of desperation -- to get "the best and the brightest" and "fix" the application at this point by working "day and night". This is like getting nine women together to have a baby in one month.

The rules of successful management of a technical project lie in common sense. There are a lot of fancy programs that make colorful schedules with triangles and dots and graphs, but they are all secondary to common sense. Any intelligent grownup can see what happened by getting to the common sense basics of project management.

To start, here is an excerpt from my upcoming book The Little Mentor for Managers that looks at the issue from 20,000 feet.

"As a guideline, here is the right order of things for a successful project:

1. Understand the application

2. Come up with a comprehensive, complete design

3. Share that design in a clear fashion with the client

4. Obtain approval of the design from the client

5. Create a detailed schedule with clear and frequent milestones

6. Obtain approval of the schedule from the client including the definition of "finished."

7. Execute the approved design on the created schedule

8. Prove the task has been successfully completed.

A holdup at any stage can undo all the previous stages. It is the job of the manager to make sure these steps are followed. You can bring all sorts of talent to bear, but if the project is poorly managed, it can be spectacular in a very bad way -- a few examples: the new Social Security software, the NSA power setup in the new Utah computer facility, and the ObamaCare registration/enrollment website.

Any member of the team can cause the process to break down by failing to execute their part, either intentionally or otherwise. Computer programmers have a few quirks that are shared by other businesses, but are striking in the software development arena.

Managing computer programmers has always presented a conundrum for supervisors; some of this lies in the different perspectives of the job. A programmer thinks he or she is a craftsman while supervisors think they are mere specialists. Craftsmen leave a little (or a lot) of poetic license for themselves. They think it is their responsibility to give their client the benefit of their latest and greatest idea regardless of the specifications of the task.

Sometimes, a programmer looks someone in the eye and says "trust me" and some people are so intimidated by technology, they say "OK." The business is full of self-professed geniuses that should never be in charge of anyone's fate, but often enough, someone believes in them. Management wants to get the job done, but programmers want to run to the siren call of their latest idea.

A long time ago, computer memory was very limited and very expensive, so accomplishing a task with efficient code was of paramount importance. New development environments have made it easier to craft code ten times faster than once was the case. This can mean that a job gets done much faster, but it can also mean the project can go very far astray very fast.

Clearly, in the case of multiple government fiascoes, all these rules were violated, but let's just look at one, item six on the list: "Obtain approval of the schedule from the client including the definition of "finished". If there were 50 vendors involved in ObamaCare, each of these should have had a project plan and that should have included the proviso that the vendor does not get their final payment until their software is proven to work as part of the final whole. This can help put pressure on flagging efforts because everyone has skin in the overall game and vendors will pressure one another.

If a competent, experienced technical manager were handling the big schedule for the overall effort, he or she would have indicated that a specific period of time without error after going live would be the meaning of "finished". Final payment would be contingent on "finished". That would be part of the contract of every single vendor involved. Of course, if there is no bidding process and you hire an old bundler buddy to do this basically by the hour, you're screwed before you start. It's a good thing there was an October 1 deadline, otherwise we still wouldn't know what happened. CGI, for example, said they won a "competitive bid". Really? I think they meant that someone from another vendor was at the same cocktail party where the decision was made.

The way this is supposed to work for any large project is that the government issues a Request for Proposal (RFP) where they state the application requirements and solicit solutions from eligible vendors. Vendors respond with their plan and a schedule and indicate what they would charge to do this. The lowest bidder doesn't always win -- the vendor that seems to have the best solution wins in a narrowing-down process that considers all factors. Why didn't they work "day and night" to come up with a comprehensive RFP instead of just giving it to a crony? There are some very competent companies that help develop RFPs and guide the subsequent selection process. Defining the entire project in writing first is a lot cheaper than just diving in the middle and coding outwards.

The talent to do this job right was readily available, but if those companies didn't bundle or lobby, they weren't even considered. At this point, I think we should be looking to see if some of the contractors were bonded. If we can "claw back" money from Bernie Madoff investors, we can do the same to get some of our money back from these losers. Instead, companies like CGI are getting new government business hand over fist.