Mythical Man Month Summary

Did a website, friend, co-worker or colleague mention the book “The Mythical Man-Month”?

Few books on software project management have been as influential as The Mythical Man-Month.

The same thing happened to me and I wish this book had been available when I wanted the essential teachings of The Mythical Man-Month.  So, I wrote it.

This book is a helpful summary of “The Mythical Man-Month” by Frederick P. Brooks, Jr.

You can consume this guide in one sitting.

Mythical Man-Month Summary
Mythical Man Month Summary

This is the book I wanted. It is a summary of all the things you need to know in a compact, easy to read, low-risk format.

If you do not want to save your time and effort with this summary of The Mythical Man-Month, please buy or borrow or the original. It’s an excellent book. I encourage you to do so. This summary guide saves your time and effort.

This Mythical Man-Month summary guide is ideal for:

1) Developers, engineers, and managers who need The Mythical Man-Month principles summarized.

2) Developers, engineers, and managers who need a refresher on the lessons from The Mythical Man-Month.

Key Benefits:

  • A compact summary of the principles of The Mythical Man-Month in a fast, convenient format.
  • Written by a developer and manager with 20 years of experience in software development who wants to help you.
  • Saves your time. Everything has been organized for you.


People experienced with software development and project management of software products can have negative experiences.  They miss deadlines, they miss budget forecasts, the deliverables are not well received, etc.  This is not to say all software projects are negative.  Good software projects can happen.  Your chances of success can increase when you are aware of the following signals.

The following is an excerpt from The Mythical Man Summary

Why do software projects go awry?

There are five common elements to the answer of this question:

  1. Techniques for estimating are poorly developed.
  2. Effort does not always equal progress.
  3. Our estimates are not stubborn enough. 
  4. The overall progress of the schedule is often poorly monitored.
  5. The traditional response of adding more manpower to late projects is flawed.

Sample Chapter from The Mythical Man Month Summary book


All programmers are optimists, but this can lead to thoughts such as “all will go well” and “each task will take only as long as it ought to.”  This is not only untrue, but it’s also reckless.  This is exemplified during the implementation phase of software development, where design ideas are shown to have flaws such as bugs or incomplete requirements.  The presence of bugs alone shows overly optimistic thoughts are unjustified.  Bugs happen.

The Man-Month

Cost varies by the number of developers and number of months; progress does not.  Men and months are interchangeable commodities only when a task can be delegated which requires no communication amongst one another.  A possible example of a task which requires no communication is reaping wheat.  Software development is not reaping wheat.

When a task cannot be partitioned because of sequential constraints, more effort does not affect the schedule because the amount of communication required increases.  The extra communication is found in training and intercommunication amongst team members.

Because communication effort is great, adding more men lengthens, not shortens, the schedule.

Systems Test

Sequential constraints in the schedule are predominant in debugging and system testing portions of the project.  This is often the mis-scheduled portion of the overall deliverables.

Gutless Estimating

While the project sponsor may govern the urgency, it cannot govern the actual completion.  However, false scheduling to match the sponsor’s desired date is more common in software than any other engineering discipline.  Individual managers will need to “stiffen their backbones” and defend their estimates.

Regenerative Schedule Disaster

What happens when a software project is behind schedule?  There are four possible approaches:

  1. Assume that only the first part of the task was estimated incorrectly and add more manpower to make up the difference for the first portion misstep.
  2. Assume the entire project estimate is off and add more manpower for all phases of the project.
  3. Carefully reschedule.
  4. Trim the tasks.

The first two cases are disastrous.  For example, adding two new men, no matter how competent, will require training by the existing experience project member for a month.  Thus, three man-months (two new, plus one existing member) is invested without any progress on the project itself.

The bottom line is adding manpower to a late software project makes it later.  One cannot conform to a previously estimated project schedule by using more men and fewer months.