The Mythical Man-Month
Hatching a Catastrophe is one of most quoted of essays from The Mythical Man-Month by Fred P. Brooks. In this essay, Brooks makes the point that projects get behind one day at a time. Rarely, if ever, does a project go from being on time to substantially behind schedule overnight; even though we have all seen projects go from green to red at the blink of an eye. The slow erosion of schedule performance is often very hard to recognize even when a catastrophe is in progress. We often use the example of the metaphor of the frog and the pot of water to illustrate this problem. If a frog is placed in a pot of water that is slowly brought to boil, they will not try to hop out because they don’t recognize the problem until it too late. Whether true or not, the metaphor illustrates one of the main points that Brooks makes in this essay. However, as with most catastrophes, there are mechanisms to avoid disaster with a bit of structure and discipline.
Milestones or Millstones: Brooks proposes that big project on a tight schedule require control. I suggest that any project that is important enough to fund (even in blood, sweat or tears) requires control. Milestones are an action or event marking a significant stage or event in development. For example, the completion of testing or acceptance in a demo is a milestone. Milestones, when defined correctly, provide a tool to help evaluate whether a project is drifting off course. The fifty dollar phrase in the last statement is “when defined correctly.” In order to be useful, milestones must be concrete, specific and measurable in order to be crisply defined.
Milestones that are unambiguously defined with a crisp definition of done provide a mechanism for measuring whether a task or a set of tasks are complete. The ability to know that a piece of work is done is empowering. Who does not like to check something off as done? Failing to define a crisp definition of done does a disservice to everyone involved in a project. The most precise definition of done for a milestone is that the tasks that are linked to the milestone are ALL 100% complete (not just really close). The crisper the definition of done is for the milestone, the less chance that we can deceive ourselves or rationalize that not being exactly done is close enough. The process of deception or rationalization is demotivating to the team and the organization.
Milestones are a tool to establish discipline within the team. Without the discipline provided by milestones, it is easy to rationalize slipping the schedule just a little bit (slipping the schedule is the same as not meeting commitments in Agile). One classic rationalization that Brooks points out is using the excuse that another piece of work is late, so we do not need to be on time. While one would not expect this type of behavior amongst professionals, it occurs. I once sat in a meeting where a hardware manufacturer announced they were over a year late, but since another firm was even later, it did not matter. Interestingly the other firm turned out not to be as late as it was perceived, and significant problems ensued.
As noted earlier, projects become late a day at a time. No one gets overly excited about getting behind a few hours or a day. We can easily rationalize that we can make up the time. Software engineers are trained problem solvers who can easily rationalize the slip until it is too late. How often have you seen a task or story that is nearly completed day after day? It is easy to sweep being late under the rug until it can’t be hidden.
Brooks describes several solutions. One example is generating PERT diagrams that identify critical paths and the slack any task might possess. More interestingly, Brooks describes how the team member/manager tension can be defused. For example, not having the leader act on issues that the person having the problem can solve, thus empowering the team member. Concepts in use today that help prevent hatching a catastrophe include servant leadership, self-managing teams, short time box and daily stand-ups. Including techniques that generate early warning signals that illuminate the true status of work and prevent problems from getting larger.
Previous installments of the Re-read of The Mythical Man-Month
The Mythical Man-Month (The Essay)
Aristocracy, Democracy and System Design
Why did the Tower of Babel fall?
Ten Pounds in a Five–Pound Package
Software Process and Measurement 
October 25, 2015 at 4:08 am
Thomas, excellent analogy about frogs in boiling water. Brook’s memorable line “How does a project get to be a year late? … One day at a time.” has been a favorite of my whole career.
This essay should be read by every Project / Program Manager, it is a classic.
On page 161, Brook’s calls what today we would call the Program Management Office an “irritant”, but tells us an A. M. Pietrasanta was able to run an effective PMO. I wish Brook’s would have written details around this remarkable accomplishment.