Project Management Primer #4 - The Mythical Man Month

In 1975 during the pioneering days of software development a man named Frederick Brooks penned a number of books and articles on the subject.

His most famous is “No Silver Bullet”, in which Brooks pointed out that software development could expect no thunderbolt solution to its various problems of quality, cost and complexity other than to adopt rigorous methodology.

Only slightly less famous than “No Silver Bullet” is another Brook’s paper, “The Mythical Man Month”. The papers are no less valid today than they were when written, but they receive a lot less attention.

In “The Mythical Man Month” Brooks argues that adding people to a project doesn’t speed it up. While it is true that more resources can speed up the delivery of a software product, the increase in speed is not directly proportional to the amount of resource added. To put it another way, simply adding people to your project will not ensure earlier delivery.

The main reason for this is the increased complexity of communications which results from adding more people. As each person is added to the project team the complexity of communications goes up exponentially. For each project there is a break-even limit where adding more people will in fact slow down the project.

The diagram above demonstrates the principle graphically. Note that you need not consider each of the ‘nodes’ in the graph to be an individual person – they could be a group of people or an organization within the project that has an 'interface'. The more interfaces you add the more complexity you add to communication and the more overhead you add to the project.

If you don’t believe the math, look at it logically. Every additional person brought into a project will need to be trained and briefed on the current status and assigned tasks. As more and more people are added, more of the original team must be devoted to managing the overall structure. This is a truism of all types of management, not just project management.

Yet, while obvious, this mistake is committed time and time again by project managers. The first reaction to any slow-down in the schedule or a threat to the delivery of the project is to throw more people at it. This rarely works in a well-controlled project and never in a badly controlled project.

Mark McLaughlin

Adding more people to a project requires ‘bandwidth’ to manage them and can distract you from more important goals at hand.

There are a few things to learn from Brook's “Mythical Man Month”:

1. Small autonomous teams are more efficient than large bureaucratic ones, so divide your project up into manageable chunks and let each group work within some kind of defined boundary.

2. If you want to add people to a project, you had better plan carefully how those people are introduced into the team, there will be a lag before they become productive and even be a drain on the productivity of other members of the team. Look for ‘flat spots’ in the schedule to introduce these people to the team.

3. One of your options in the “scope triangle” has just been reduced! If the scope of your project expands you know there’s only a limited benefit in adding more people to the project because of the overheads involved. We’re back to those same two options again: ask for more time; or cut functionality!

One particular project I was involved with illustrated to me the truth behind the “mythical man month” more than any other.

I was the consultant test manager representing the client, a major bank. A senior manager in the bank had staked his reputation on the success of this system and now no expense was spared to make the project fly! The developer, one of the world’s largest IT service companies, had flown in a design team from overseas since no local talent was available at short notice. They had also flown in a top notch project manager from the other side of the world to baby-sit their first project with the bank.

As the project progressed the plans became more and more ambitious and more and more people were added to the project. We started off with one design team and ended up with three, none of which ever received the same brief.

The developer started flying in software engineers from a neighboring country and then flying them home for the weekend. Staff was diverted to the project to help the interlopers try and meet their deadlines but they were still reporting to their original line managers.

It was chaos. Developers were sitting around waiting for instructions. Graphic designers were busily designing interfaces for screens whose business logic hadn’t even been finalized. There were at least three different versions of the specifications floating around and no one knew which one was current.

Our role was to vet the quality of the supplied system for the bank, in effect accepting the system on their behalf. We had a field day! Every release was turned back with major bugs because it hadn’t been tested by the developers and was handed over incomplete.

To my knowledge the system was never launched even after our involvement ended. Expenditure on the whole project must have been on the order of tens of millions of dollars and the project ended up on the scrap heap!

More Tutorials:

• 10 Truths for Successful Project Management

• Scope Triangle

• Critical Path

• The Mythical Man Month

• Defining the Project Scope

• Scope, Visions and Goals

• Using Project Goals to Filter Requirements

• Difference between a Business Case and Project Proposal?

• Return on Investment

• Requirements Specifications

Project Management Templates

Here are some Project Management templates you can get on our partner's site.

	The Change Management Kit provides the documentation required to control changes to the scope, deliverables and resources within the project. The Change Request template allows staff to raise a change request within the project.
	The Project Planning Kit provides you with all of the project management templates, documents and forms required to plan a project by helping you to schedule time, cost and resources.
	The Quality Management Kit includes a suite of templates used to assure and control the quality of deliverables within a project.
	Project Initiation Kit Start a new project by documenting a business case, undertaking a feasibility study, defining the project scope, recruiting key staff and locating them within a project office.
	Project Execution Kit Manage time, cost, quality, change, risks and issues during the execution of your project, as well as supplier procurement and customer acceptance.
	Project Closure Kit Helps close your project by handing over deliverables and documentation to the customer, terminating supplier contracts and releasing resources back to the business.