This article is an excerpt from the Shortform book guide to "The Mythical Man-Month" by Frederick Brooks. Shortform has the world's best summaries and analyses of books you should be reading.
Like this article? Sign up for a free trial here.
Why do projects fail in business management? What is the most common reason? How can you avoid failure?
In The Mythical Man-Month, Frederick P. Brooks offers a guide to completing complicated projects on schedule. The book covers strategies for streamlining your process so that you can keep your staff working together smoothly and finish your most daunting projects on time.
Read on for some of Brooks’s examples of why projects fail and his solutions for avoiding failure.
Why Do Projects Fail? Brooks’s Response
Frederick P. Brooks, the author of The Mythical Man-Month, led the division of IBM that programmed computer operating systems in the 1960s. He managed over 100 employees to create cutting-edge programs that required an intense degree of coordination: High complexity, and the errors that came with it, caused his projects to fail and fall behind schedule. Brooks sought to answer the question, “why do projects fail?” In response, he developed a variety of strategies for reducing complexity while coordinating large teams, keeping lengthy projects on schedule, and managing the errors that inevitably occur in detail-oriented work.
One of Brooks’s most daunting challenges in overseeing complex projects is completing them on schedule. Even with teams optimized to reduce miscommunication, any long-term project can fall behind schedule and inevitably fail.
Why Managers Create Inaccurate Estimates
Sometimes projects fail and go off schedule because the schedule itself is a poor estimate of how long they will take. Brooks identifies two reasons why managers create inaccurate estimates.
Reason #1: Desire to Please the Client
When clients ask for a specific deadline, managers may be tempted to fit timing estimates to their clients’ goals instead of their team’s capacities. Managers may be even more tempted to overpromise when they’re pressured by a competitor promising an even faster time—whether the competitor can meet those promises or not.
Brooks offers two solutions to the temptation of overpromising. First, managers must be honest with their clients, and estimate projects with integrity. As a manager, you need to stick to your professional opinion, even when it disappoints a client. Second, he argues companies should publicly release data on their productivity—including things like past project completion times. This will give clients an accurate understanding of project times and therefore, they will make fewer unrealistic demands. This, in turn, will lower managers’ temptation to make unrealistic promises.
(Shortform note: While overpromising to please a client may offer short-term gains, studies show this can lead to disappointment, conflict, and loss of long-term gains. Research on customer conflict with companies shows that companies that promise more than they can deliver face greater backlash and have to spend more time managing conflicts with customers than companies that make realistic promises. Furthermore, companies that foster personalized relationships with their customers face even greater backlash than those that keep things strictly business, as this increases customer expectations, heightening their sense of betrayal in response to broken promises.)
Reason #2: Underestimating the Time to Repair Errors
Brooks argues that projects can fail when managers make poor scheduling estimates because they are too optimistic. He considers computer programmers to be particularly optimistic by nature—as he notes, people drawn to the cutting edge of technology often like imagining a better future. This optimism often leads them to underestimate the time they will spend testing, repairing, and correcting errors.
Brooks advises programmers to take a more realistic view and plan for errors. He offers his own estimates as a guideline for allotting time to each stage of the process.
- 1/3 for designing
- 1/6 for programming
- 1/4 for testing and repairing components individually
- 1/4 for testing and repairing the system as a whole
Notice that testing and repairing take up half the schedule, while programming itself takes up the least amount of time.
| The Planning Fallacy Brooks’s scheduling advice focuses heavily on the field of software development. However, the problem of underestimating project times is much more widespread. In fact, this tendency afflicts so many people that psychologists have given it a name: “the planning fallacy.” Some believe this is a self-serving tendency in which we overestimate our productivity to maintain a favorable self-impression. Others attribute it to wishful thinking: You want to accomplish something quickly, so you imagine you will. Psychologists have found three proven strategies for overcoming the planning fallacy: 1. Take the outside view. One of the most useful tools in creating accurate estimates is knowing how long others spent on similar tasks, or how long these tasks have taken in the past. This will ground how much time you imagine it will take for you. 2. Break up your goal into smaller tasks. You may underestimate how long your project will take because you simply haven’t considered all the required steps. Breaking down your project into smaller goals can lead to more accurate estimates. 3. Take a more pessimistic view. By expecting things to go wrong, you may be able to counterbalance your optimistic underestimation. Try brainstorming a list of problems that will delay your project, and make these delays part of your estimate. |
The Consequences of Poor Scheduling Estimates
Brooks identifies three ways poorly estimated schedules can cause your project to fail:
1. Inaccurate scheduling ensures your project comes in late.
(Shortform note: While Brooks doesn’t explicitly spell this out, finishing a project behind deadline damages your company’s relationships with your clients. If they were counting on your project by a certain deadline, delay interrupts their operations too, guaranteeing strain on your relationship.)
2. Missed deadlines demoralize your employees, who feel like they’re failing even when they’re working productively.
(Shortform note: Business experts note that chronically missing deadlines can also lower productivity by leaving your employees with the impression that their deadlines don’t actually matter. As a result, even if you start creating realistic deadlines, they might not be motivated to hit them.)
3. Inaccurate schedules lower efficiency. Because many projects require your teams to complete steps sequentially, inaccurate scheduling can create bottlenecks in your workflow.
(Shortform note: Project management experts shed further light on how inaccurate scheduling creates bottlenecks. A bottleneck results when input exceeds capacity. In other words, tasks are assigned to a worker, team, or machine at a faster rate than they can be completed. This is where inaccurate scheduling comes in. If you underestimate the amount of time a step will take, then you will overestimate the amount of work you can send to your worker, team, or machine—leading to the imbalance of capacity and input that produces bottlenecks.)
How to Stick to Your Estimates
Projects can fail despite good scheduling. Even the best schedule is no guarantee of timely project completion. In this section, we’ll explore Brooks’s insights on the factors that delay projects and his strategies for keeping a project on track.
Why Projects Fall Behind
Before we can understand how to keep projects moving on schedule, we first need to understand why they fall behind in the first place. Brooks found that projects typically fall behind schedule because of accumulated small delays rather than unexpected crises or catastrophes. In a major crisis, most employees will recognize the gravity of the situation and increase their efforts accordingly. However, smaller delays are often overlooked and allowed to accumulate unaddressed.
This problem is compounded because lower managers often underreport small delays. Brooks suggests that this doesn’t necessarily mean you have deceptive lower managers. They may see themselves as taking responsibility to handle the problem themselves instead of bothering supervisors with minor details. Nonetheless, this results in higher managers not knowing when a project is starting to fall behind schedule.
| The Three Stages of Potential Delays In his discussion of projects falling behind schedule, Brooks primarily focuses on delays in perceiving information: You don’t know that a project is falling behind, because you haven’t noticed all the small delays adding up. However, In Thinking in Systems, Donella H. Meadows explains this is only one stage of the process where delays can slow down a project. Managers also have to consider delays in reacting to information, and delays in the consequences of those reactions. To use Brooks’s example, let’s say a manager finally takes stock of the team’s progress and realizes they’ve fallen behind. Now they must decide when to react: Do they immediately try to address the problem, or do they sit on it and hope the team catches up? This is an opportunity to cause a delay in reaction. Once the manager reacts by implementing a new efficiency solution, how will they know when it is working? The results may take time to come into effect. This is Meadows’s third delay: a delay in the consequences of the reaction. She argues that these delays are especially challenging because they force a manager to make decisions with incomplete information. |
How to Avoid Delays
In discussing why projects fail, Brooks offers two pieces of advice for cutting back on small delays to your project:
1. Set measurable, binary benchmarks. You can track progress much more accurately by setting measurable, binary benchmarks. A measurable benchmark is one whose progress you can easily track and quantify. A binary benchmark is a benchmark that has only two states: complete or incomplete. The opposite of a measurable, binary benchmark is one that is open to interpretation as to whether it has been reached. For example, if you’re building a house and your benchmark is that “most of the roof” will be done by Tuesday, “most of the roof” could mean a lot of things. Conversely, the benchmark of, “nail in 250 shingles by 5 p.m.” isn’t open to interpretation—it’s either met or it’s not.
| The Difference Between Outcome Goals and Process Goals To avoid project failure, Brooks highlights the importance of using measurable and binary benchmarks to assess your progress toward a goal. However, he doesn’t cover what kind of goal best lends itself to success. Scheduling experts argue you can track progress even more clearly by distinguishing between outcome-oriented goals and process-oriented goals. Outcome goals are focused on what you want to achieve, or the end result. Meanwhile, process goals are focused on how you will achieve it—the individual steps along the way. Scheduling experts advise that process goals are often more achievable and realistic. This is because you have more control over a process than you do over its outcome. For example, if your goal is to fix all the errors in a software program by Thursday, this may be unreachable because you don’t know how many errors are left in a program. On the other hand, if your goal is to fix five errors a day until they’re all eliminated, this is within your control, and will therefore provide a clearer measurement of actual progress. |
2. Track the completion of all these specific benchmarks. The more aware you are of small delays, the more you can prevent them from accumulating unnoticed. Once you have measurable, binary goals, record when each is completed. Brooks had an entire team whose job was to record when each goal was met.
(Shortform note: Detailed progress tracking may feel overbearing or invasive to some of your employees. However, it doesn’t have to be, so long as you focus on small achievements alongside the small delays. Some management experts argue that recognizing and celebrating small wins will even boost employee morale and productivity. Because larger achievements are rare, focusing on small achievements can sustain the everyday motivation employees need to keep your project on track.)
Brooks’s Law: Don’t Add More Employees to a Late Project
Brooks argues that once a project becomes late, it’s a mistake to add more employees in the hopes of speeding it up. Many managers are tempted by this pitfall, hoping that extra labor will speed up the project and keep it from failing. Brooks asserts this will only add further delays. In fact, he calls this principle “Brooks’s Law”: Adding more workers to a late project will make it even later. He provides two reasons why.
Reason #1: New Workers Add New Complexity and Opportunities for Poor Coordination
All of those new employees need to be onboarded and incorporated into the existing workflow, which will add time and effort. Furthermore, the additional employees will add more complexity. Recall that as you increase the number of employees working together, the opportunities for miscommunication increase exponentially. This complexity increases the likelihood of errors, meaning more time spent testing, debugging, and correcting.
(Shortform note: Brooks focuses on how new employees will require training and add complexity to a project. However, adding a significant number of new employees can also slow down a project because your team will have to take time building relationships. Management experts have found that teams do their best work when their members trust and rely on each other. These relationships take time to cultivate. Therefore, a team with a significant number of new workers needs time—and perhaps some intentional team-building—before it functions effectively.)
Reason #2: Programming Often Requires Sequential Steps
Sometimes, you can’t move from one stage of the project to another without completing an important step. If you’re stuck on one step, you may be tempted to add more workers to the subsequent steps to speed up the process moving forward. This will simply reduce your efficiency because they won’t have anything to do until that previous step is complete. For example, if you’re building a house and waiting for the cement foundation to dry, you can’t speed up the process by adding more roofers. They will all just stand around costing money without anything to contribute.
(Shortform note: Project management experts distinguish between sequential and parallel workflows. In a sequential workflow, each step is completed before moving on to the next. Whereas in a parallel workflow, certain steps are completed simultaneously to cut down on work time. For example, let’s say you are making a stir fry. Working sequentially, you would chop every ingredient before you began cooking. In a parallel workflow, you would identify the ingredients that had the longest cooking times, chop those first, and then let them cook while you chopped the rest of the ingredients, saving you time. However, parallel workflows often require more planning and management, and only work on certain projects.)
| How Ironclad Is Brooks’s Law? Since the publication of The Mythical Man-Month, several researchers have put Brooks’s law to the test. Brooks himself reviews this research in one of the later editions of the book. While the rule holds up in general, researchers have found two mitigating circumstances. 1. Adding more workers to a project doesn’t necessarily make it later if they are added very early in the process. This will give them more time to onboard and acclimate to the project. 2. Adding more workers to a late project doesn’t make it as late if the workers are team players: people who naturally accommodate others and find ways of contributing, but are very open to taking instruction and changing course as directed. That said, Brooks stands by his law as a rule of thumb. He argues that many managers still make the mistake of thoughtlessly throwing extra staff at a late project to speed it up in the hopes of avoiding failure, and that his law cautions them against this tactic. |
———End of Preview———
Like what you just read? Read the rest of the world's best book summary and analysis of Frederick Brooks's "The Mythical Man-Month" at Shortform.
Here's what you'll find in our full The Mythical Man-Month summary:
- A guide to managing large teams and completing complicated projects
- How to keep your staff working together smoothly
- Strategies for keeping long-term projects on schedule
