Some Thoughts on "The Mythical Man Month"

"The Mythical Man Month" is a book on software engineering and project management by Fred Brooks. Most of the book is about the pitfalls of large programming projects, but the author's views on scheduling, project complexity, and the importance of communications are relevant to any project. The book's title derives from a fallacy of scheduling that holds that humans and months are interchangeable, meaning that the productive effort that results from adding more people to any project will always reduce the time it takes to finish. This is a central, if unstated, premise of ship construction and overhaul scheduling. Brooks based the book on his experiences at IBM managing the development of OS/360. The things that struck me most clearly from the book were:

“large software management projects suffer problems different in kind from small ones, due to division of labor.”

Chapter 2 The Mythical Man Month

Software projects go late because:
  • We don’t estimate project durations well (“our techniques are poorly developed”) and schedule as if we expect “all will go well” [Soule -perhaps not so, we just don’t have ways to estimate the impact of “unknown unknowns” in an intellectually satisfying way, besides using what are called "base rates" (the average for similar projects), so we choose not to so or act like it is not necessary. Kahneman and Tversky wrote a famous paper about this called "The Planning Fallacy." I can provide copies upon request. Any Engineering Duty Officer that does not understand the Planning Fallacy is seriously uninformed about scheduling complex projects.]
  • Estimating techniques confuse effort with progress, hiding the assumption that men and months are interchangeable (this only works for simple, separable tasks that required no communication, like harvesting wheat by hand). Debugging errors is particularly complex work (probably similar to high level systems testing during overhaul).
  • Unrealistic scheduling to match the customer’s desired date
  • Schedule progress is poorly monitored [Soule - we monitor the heck out of the schedule, we just don't believe what the metrics tell us.]
  • There is a tendency to add people to a project that is falling behind, which only makes the problem worse [Soule - of course this is not always true, but unfortunately Navy senior leaders act like it is NEVER true.]
Brooks’ Law: Adding manpower to a late software project makes it take even longer

Chapter 7 Why Did the Tower of Babel Fall?
* Good communications on complex projects is essential to coordinate efforts and manage the unexpected/inevitable change. “Teams should communicate … in as many ways as possible …”
There are built-in inefficiencies in communications in conventional project hierarchies that communications strategies should try to address.

Chapter 8 Calling the Shot
“Data for building isolated, small systems are not applicable for programming [larger, more complex] projects.” [Soule - this could be construed as an indictment of the rationale for scheduling complex shipbuilding/repair tasks. We presume that we can plan jobs at the micro level and "roll up" the information to produce  a realistic schedule without the ability to understand or predict all the interactions between jobs. The few interactions we understand between jobs at the outset are not those that cause us problems during execution.]

Chapter 9 Ten Pounds in a Five Pound Sack
Small teams tend to sub-optimize to meet their own needs rather than think about the overall impact to the project. This is a major hazard of large projects. [Soule - they also struggle with “Student Syndrome”]

Chapter 10 The Documentary Hypothesis
“The project manager’s chief daily task is communication, not decision-making.”
“Only a small part of a technical project manager’s time - perhaps 20% - is spent on tasks where he needs information from outside his head.” [Soule - I have definitely found this to be true in ship overhaul, construction, and modernization. This is just another way of saying that the project leader's chief job is leadership, not technical decisions.]

Chapter 11 Plan to Throw One Away
Pilot projects are better than trying to develop a big project all at once without prototypes.
Projects must be designed to manage change. [Soule - and learning]

Chapter 13 The Whole and the Parts
A good project plan does not eliminate uncertainties, it just reduces their number (Soule - “the critical path is never the critical path”).

Chapter 14 Hatching a Catastrophe
Day to day schedule slippage is harder to recognize, harder to prevent, and harder to make up than calamities.

Highlights from a Siemens Product Lifecycle Management Conference

Retirement Process Lessons Learned