Is Brook’s Law Hampering Your Company’s Efficiency?

In the workplace prior to the digital age, Murphy’s Law (if something can go wrong, it will) and Parkinson’s Law (work expands to fill the time allotted to it) were often cited as reasons why projects were late or off track.

 

But since the dawn of digital, if a project isn’t delivered on time, the biggest excuse is Brook’s law.

 

Coined in 1975 with the release of Frederick Brook’s bestseller The Mythical Man-Month, Brook’s Law, in an over-simplified version, simply says that “adding manpower to a late software project makes it later.”

 

In this case, a man-month refers to the amount of work that one person can do in one month.

 

Brooks noted that when a software project is late, a common response by companies is simply to add more software engineers to the team and assume that the work will go faster and get done on time.

 

But it doesn’t work that way.

 

That’s because each new engineer brought into the project has to be brought up to speed on it. This takes time and communication, and everyone on the team has to discuss every aspect with the new person for them to fully grasp what is going on.

 

If still another engineer is added a few days later, the whole process has to start again.

 

Conscious of the common excuse of Brook’s Law, some companies try to get around that by keeping their software project teams extremely small, or even just one person, but that doesn’t solve the issue either.

 

When an engineer works alone, it is almost impossible for them to get the continual feedback on design that they need to move to their next step.

 

So what is the solution if management asks human resources professionals to step in and figure out why their team is not going to be done on time?

 

The first thing is to try to figure out why the project is running late in the first place. Was there a delay in getting parts, tools, approval of designs, or was a key player ill? There can be any number of valid excuses and the key is to try to find a way to make up the time lost if at all possible and solve the issue if possible.

 

Perhaps, after a study of the man-hours already workers and what is possible between now and the deadline, it becomes clear that right from the start that the deadline was unrealistic. Sometimes harsh truths have to be accepted and schedules need to be corrected.

 

If you do decide to bring in more team members, look where they fit in the structure and select those who can be brought up to speed the fastest and with the least amount of disruption.

 

For example, good programmers could be added with specific directions to follow without having to have in-depth knowledge of the entire project. Anything that can be free-lanced or handled by another team (such as quality assurance tests) may speed things along.

 

Excellent development practices can also help as well as good managers who can step outside the team and consider calmly what needs to be done to bring the project together.

 

It may be tempting to scour the technology world for a hero or heroine, bring them in and hope that they can work their magic, but that is rarely a good long-term solution for any organization.

 

For starters, it is always possible that their reputation has surpassed their skill level. And as late as the project is, keep in mind that it could be worse. If you bring in someone to do their magic, they may actually halt effective communication between programmers and hinder progress.

 

Karl Wiegers, in his groundbreaking book Creating a Software Engineering Culture, attributed the workplace culture as a key contributor to operating successful software projects.

 

His idea was that you don’t need heroes; you just need ordinary trained people to deliver the best results time and time again in the right environment.

 

Who is right and who is wrong about this?

 

The debate rages on, but there are four factors that clearly support trying to use your own skilled team, give them a clear intent and a reasonable deadline, and realistically expect success.

 

That is because if you narrow projects down to just one person, you reduce their capacity to learn and have their ideas challenged. That does not benefit your organization in the long run.

 

There is also the safety and security factor. What would happen to your project is the one who understood it fully got hit by a bus and never recovered? If there are no team members, who knows where the project was and where it is going.

 

Most importantly, working on a team increases accountability and increases morale, two highly important qualities for long-term success.