Brooks Law

by Sandrine Favier | Jun 7, 2021 | Project Management

Brooks Law

Stay in the loop

One of the touchiest topics in project management is how to deal with a late project. A few years ago, when meeting a developer of my acquaintance who was then working on an overly complex project (due in part to a very unclear product vision provided by the project manager), I risked asking him about the status of the developments.
The project had already fallen behind schedule, many features had been added at the last moment, but worst of all, my acquaintance explained, he was being swamped with resumes by his project manager, who had decided that the best solution for finishing the project on time was to hire 2 or 3 additional developers. The thought of having to recruit and train new developers in addition to his workload did not make him happy.
Fast forward a few months after we met, I met up with my acquaintance who was working at a new start-up. I asked him how his previous project had ended: “chaotic” was the word he used. The product had been delivered weeks late, and worst of all, did not meet the client’s requirements. The project manager blamed the lack of investment from the developers and moved on to another project because, after all, he had done what he could and “nobody ever got fired for buying IBM. The project manager in question probably didn’t know about Brooks’ Law, or he wouldn’t have focused his strategy on adding new members to an already overworked and pressured team.

The Brooks law statement

« Adding manpower to a late software project makes it later »,according to Fred Brooks,a Software engineer, in his 1975 book« The mythical Man-Month ».

The concept may seem counterintuitive, especially for businesses that estimate the time needed to complete a task in Man-Days or Man-Months. However, if we look a little more closely at the issue, this law can be easily comprehended by those who know a little about project management or software development.

Complexity and line of communication

Software development projects are complex operations and each new member added to the project must first be trained on the project (methods, tools, code base…). This leads to an increase in the number of communication channels, an increase in the amount of information exchanged and a slowdown in the time and quality of the processing of this information.
There is a formula to evaluate the number of communication channels between the members of a team.

(n² – n) / 2

Example: For a team of 6 people, there are 15 communication channels. Sometimes, a picture is easier to understand than a mathematical formula 👇

This moment of taking over has an impact on productivity because not only does the recruit not yet participate positively, but above all because it diverts resources towards training time (the recruit will have to be trained and supervised by a team member who will therefore no longer be able to concentrate on his or her work in progress). It’ s also likely that the recruit, regardless of his or her skills, will introduce bugs that will also slow down productivity.
This is known as the J-curve effect.

To go further

As Fred Brooks stated in his book, this law is a simplification of reality. Nothing is set in stone, but there are ways to avoid falling under Brooks’ law.

Developers are not interchangeable with each other. Nevertheless, with a good analysis of the project’s requirements and a proper assessment of the profile sought, it can be positive for a project to add to the team someone with a strong expertise in a specific field.
A good segmentation of the project can minimize the need for communication between team members.
A matter of timing: it’ s possible to add people to a project earlier in the process. For this to happen, the project manager must quickly review the scope and the evaluation of his planning (perhaps he was too optimistic).

TAGS: