Man Months is one of the most commonly used words in the software projects. It’s used to refer to the effort required to execute a software project. Simply speaking, a man month refers to the effort of one developer working for a month. However, the concept goes beyond this simplicity.
So what is mythical about Man months?
Frederick Brooks’s The Mythical Man-Month: Essays on Software Engineering, published in 1975, is one of the most influential books on software engineering.
Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects.
Man month is not a mathematical concept. So, if we have estimated that a project is going to take 35 man months to complete, does not mean that putting 35 people on the project, will finish the project in 1 month. As you know, the software project has phases and unless all the phases are completed, the project does not get completed.
This book has made the term “Mythical man months” extremely famous term though relevant. The basic premise of the book, also referred to as Brooks’ law:
“Adding manpower to a late software project makes it later.”
Let’s understand Brooke’s law.
A project is estimated to be 30 man months of effort. The project got started with 5 members and was supposed to get finished in 5 months. After 3 months of work, only 15 man months of effort is spent. As per the estimates, 15 man months of of work is pending to be finished in 1 calendar month. The team has 7 members.
Simple calculation suggests:
Calendar months required to finish the project = 15/7 ~ 2
This is a series schedule slippage. How to correct it?
Can we put 8 more people and finish it in 1 month and avoid project delay? The answer is NO, as per Brooke’s law.
Adding manpower to a late software project makes it later.
Why Brooke’s law is valid?
Sue Kim, in the blog post Mythical Man Month – The Cliff Notes mentions that:
“Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.”
But software development is a highly collaborative process and communication is important. How does this affect the project:
More people open up more channels of communication (for collaboration) leading to errors and delays. Any business communication text will explain that 15 members in a team, will have 15 *(15-1)/2 = 135 possible ways of conversations amongst them.
A popular games amongst children is chinese whispers game, where multiple channels of communication leads to original message getting garbled along the way. This is what happens in software projects, if too many people are added.
Another reason for this is the lack of decomposition of certain tasks. If tasks can be decomposed into smaller parts of almost equal size, it can be easily allocated to multiple people. But that is also not possible always. Some of the tasks can only be done by one person, limiting the ability to divided the work.
About Techcanvass
Techcanvass offers IT certification courses for professionals. We are an IIBA endorsed education provider (EEP), iSQI ATP (for Certified Agile Business Analyst Training) as well as Agile Testing alliance partner for CP-SAT certification training in Selenium.
We have a Business analyst training course with domain training in-built into it. This training program offers you the opportunity to get certified with ECBA certification as well as have banking domain understanding.
Cheers
