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.
———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
