And what would you like with that mythical man-month?

From Chapter 2: The Mythical Man-Month

Excerpt
....because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine's chef. (page 14)

Brooks has grabbed the colors of uncompromising-quality from the chef at Antoine's, the famous restaurant in New Orleans. Brooks argues that software, like Oysters Rockefeller, Pompano en Papillote, Eggs Sardou or Pigeonneaux Paradis, can't be rushed. He conjectures that if software managers had reliable estimation methods, they, too, could argue that quality is worth the wait and confidently admonish the customers to cool their heels.

If he worked for NASA, Brooks would learn that even a 100%-certain estimate could not buy him schedule--even if he was as stubborn as a tabasco stain on a white tablecloth. If he tried, he'd soon be in the scullery watching Ronald McDonald's apprentice running the kitchen. Why? The sponsors (i.e. customers) are using someone else's money to buy stuff whose quality is difficult to measure. What's more, both buyers and sellers operate in a bureaucratic context under the failure-is-not-an-option mandate.

Of course quality matters, but it is not the primary concern; especially at the beginning of the project when the plans are set. An experienced and dispassionately-rational software manager in NASA knows that there will be a magic moment in the project when the management flinches and the credit card comes out. If we need Moet Chandon Dom Perignon , bring it on! Until that time, you'd better stick to even the most fantastic schedules and budgets or it'll soon be time to pass the toque.

There's hardly a better recipe for cooking up the mythical man-month. However, if you consider the NASA business model, these unrealistic schedule and budget plans make sense.
For example, the following factors might weigh on the mind of a NASA program or project manager:

• Launch windows are based on physics. Missing a launch window is really expensive. For example, the 2-year slip of MSL cost hundreds of millions of dollars.
• Government funding is fickle. What's provided today will be taken away tomorrow and restored the day after.
• In the culture of consensus, missing a deadline or overrunning a budget will rarely cost a management job. Responsibility is shared.
• Total cost of ownership is never a factor. There is always more money for software development after the spacecraft is launched.
• Success in NASA is ostensibly determined by meeting science goals. However, as the government's most visible investment in the country's future, NASA provides an administration (arguably NASA's real customer) with one of the best sources of positive PR. Stage a good space drama with a happy ending, the customer is happy and the cost will be forgotten.

From a project management perspective, what's needed is the right estimate--the one that gets the job. If you get the job, the extra money will come. No amount of courteous politeness or better estimation will convince a project manager to accept a plan that kills a job--especially when the funding can be captured in the later stages of the project. Besides, NASA will always have money. If the budget balloons, the consequence is just the delay or cancellation of other projects. Life goes on.

As for being the chef, the most senior NASA software managers might be likened to a kitchen assistant. Until or unless the sponsor choses a different objective, NASA will remain a science-focused, hardware-centric organization. Meanwhile, the chef is king in the kitchen; software does not control the menu.

And what, sir, would you like with that mythical man-month?