In 1975, computer architect Fred Brooks published a series of essays on software engineering and project management called “The Mythical Man-Month”.

These cautionary tales and inevitable realities not only stand the test of time, but also can crossover to many applications.



In this first article on the subject,  I'll talk about his essay (also called) “The Mythical Man-Month”. The basic theme of it is that the time it takes to finish a project is not linearly proportional to how much manpower that you throw at it.

In some cases, adding additional manpower can make a project take longer to complete.

The first issue is that most project managers do a poor job of estimating the time it takes to finish a project.

Experience tells us that unplanned things always happen, but there is often a lot of pressure to make project deadlines. And most project managers feel that if they did estimate the project accurately they would probably lose their jobs.

On top of that, progress is often not measured accurately or in a realistic way since partitioning the project is not always easy.

To try to expedite the progress, additional manpower will often be thrown at a project.

The reality is that manpower and time are only interchangeable commodities when a project (1) can be partitioned, and (2) the project doesn’t require that the individual participants communicate with each other.

A task such as garbage pickup at a stadium would fit the bill here: It would take one person a month to pick up all the garbage, or 30 people one day if each had their own section.

For the control system projects that we do, partitioning the work is not as easy.


Sure, different programmers can tackle different sections of the program, and they can even test their sections thoroughly to ensure they do what they are supposed to do.

The issues develop when it is time to combine all of these parts into a complete program.

A lot of programming time must be redirected into coordination meetings throughout the process. And more time is spent reworking the logic as the sections are stitched together.

Sometimes there is a sequence that must be adhered to, and time is lost waiting for someone else to finish their work. And some tasks simply won’t be able to be accelerated.

An example that everyone understands is a pregnant woman: No matter how many doctors, doulas or midwives that are thrown at the “project”, that baby isn’t coming until around nine months pass.

Simply put, projects that have a lot of debugging, testing or other post-production requirements may not be able to be completed any faster even with additional manpower.

In summary, when it comes to the effect adding manpower has to the time it takes to complete, the results can be broken down into the following four categories:


 

Figure 1 – Image by Carlo Zaskorski

Category 1: Time Directly Proportional To Manpower

While the thought is that “adding manpower will result in a perfect slope relationship between time and manpower,” this is rarely the case.

This can only work when a task is very basic and does not require communication between those involved, as in the previously mentioned “stadium cleaning” example.

 

Figure 2 – Image by Carlo Zaskorski

Category 2: Diminishing Returns

If the task requires some communication between the workers, the graph becomes logarithmic.

There is a point in these projects where adding more manpower does very little to affect how long the project will take.

 

Figure 3 – Image by Carlo Zaskorski

Category 3: Complexity Limits Effective Team Size

If the task requires a lot of communication and is complex, there is an optimal amount of manpower that should not be exceeded.

When it is, adding more manpower will actually cause the project to take longer.

 

Figure 4 – Image by Carlo Zaskorski

Category 4: More Manpower Won't Accelerate All Tasks

Some tasks are simply not able to be partitioned.

In these cases, the amount of manpower added will never significantly affect the time.

 


 

Written by Carlo Zaskorski
Controls Design Engineer and Freelance Blogger

Have a news tip? Share it with us here.
Have a question on this topic? Click here to scroll down to the comment link
Enjoy the benifits of membership! Insider news, rewards, & more: Patreon.com/automation

Carlo Zaskorski

Carlo Zaskorski is a freelance writer for The Automation Blog who spends his days as a principal design engineer in the boiler/burner industry, his nights as an adjunct professor teaching PLC programming at College of DuPage.
Carlo Zaskorski


Click HERE to scroll down to view or leave comments


Leave A Blog Reply Here

Please enter your blog comment!
Please enter your name here