Brook's Law Revisited…
CONTENTS
Introduction
Today’s Software Development Scenario
Project Cost
Written Communication
References
INTRODUCTION
In 1975, Frederick P. Brooks [1] stated that ‘adding manpower to a late project makes it later.’ For centuries this have been considered as one of the most cardinal principle of software project management. In 1995 Brooks [2] wrote the following in the 20th Anniversary Edition of his original book “…There have even been studies evaluating the truth of Brooks’ (intentionally simplistic) Law, that adding manpower to a late software project makes it later.
The best treatment is that of Abdel-Hamid and Madnick…” Hamid and Madnick [3] say that adding more people to a late project always make it more costly, but it does not always cause it be completed later. Brooks have taken into account the additional time taken to train the new people, the work lost due to repartitioning the work among increased project size, the time lost due to the increased complexity of communication, when new people are added to a late project and have stated his law that this addition will only make it later.
All the factors that Brooks considered are there in every project. But in today’s software development environment we cannot ensure that all the members of a project team will remain unchanged from the start to the end of the project as the project have become more complex and large and the size and complexity are increasing. So, today the relevance of Brooks’ law is somewhat limited.
TODAY’S SOFTWARE DEVELOPMENT SCENARIO
With the advent of modern software development tools (like CASE, integrated development environments, program generators, etc.) the training time is limited to learning the functionality of the project. This is because the employees of an organization will be trained in the software development tools and techniques that are being used in the organization.
Management can make sure that the people who are introduced to the project are people who have the necessary training on the tools and are familiar with the organizations standards and practices. So the training required is limited to understanding the functionality of project. In large projects, not all the team members have the full understanding of the system and that is not needed either. All they require is an overview of the system and detailed understanding of their subsystem or module. Imparting this training can be done outside the project and for this one does not have to interrupt the people who are working on the project. Also when the new people are familiar with the standards, conventions and procedures of the organization, the time lost in communication is also greatly reduced.
Another aspect is that, the new people can do the learning on their own; they can make use of the CBTs, project documentation and so on to make them knowledgeable and current in the work allotted to them. So in most cases, if good people (people who are bright, who are familiar with the organization and its working environment, the tools used and who can learn thing quickly) are chosen, then the time its takes for such a person to reach full productivity is negligible compared to the additional work that can be completed by him.
Here the important thing is the organizational culture, practices and policies. All the employees should be familiar with the working practices and standards of the organization, the tools used for software development, and so on so that they are interchangeable. The higher the degree of interchangeability of the employees the less is the difficulty for the management to add new people to a project and still not suffer from time overruns.
PROJECT COST
Another aspect of this scenario is the cost—whether adding manpower to a project will increase the project cost? If we consider the budget or the initial estimate, yes it will increase. But that is only part of the picture. We have to look at the project cost from the organization’s viewpoint. There are indirect costs like the overhead costs, opportunity costs, penalties and other intangible aspects like customer goodwill, company’s reputation and so on.
Today, most of the project contracts have penalty clauses; i.e., if the project is not completed within the specified date, the company has to pay the client penalty for the delay. In one project that the authors have worked, the project was for an international securities clearing agency. The deadline for the project was the 3rdof October. This is because that was the only time during the year that the company had 3 days holiday. So if the project didn’t go live on the 3rdof October, then the only chance to make the system changeover was in the next year. So the contract had a penalty clause—our company will have to pay a sum of $10,000 each day for the next one year, if it missed the October 3rd deadline. Consider a situation where the company misses the deadline. The penalty that the company will have to pay the client is an astounding $3,650,000! This itself was a good motivating factor for us to complete the project on schedule and it is no wonder that we completed the project one month ahead of schedule. Not all projects will have such penalty clauses, but there will be penalty for the number of days delayed or something similar.
Consider another scenario where a company has planned to launch a product on a particular date. If the project is not complete by that date, the company is missing a market opportunity, may be an opportunity to be the first in the market. Also, if the product launch is announced, people have booked for the product and if the product is not available on the promised date, the company’s reputation is at stake. Not all companies can do what Microsoft does and still mange to get away with it! So a delayed project will result in negative press reports, loss of customer good will and tainted company reputation and it will also give the competition an opportunity to grab more market share.
CONCLUSION
So, if we consider all these factors, adding manpower, people who are right for the task (as we have described earlier), need not make a project late. In fact in most of the projects the authors have worked and managed, we were able to meet the deadline or finish ahead of schedule by adding more people. Here the only thing that one should consider is that, just adding new, untrained employees to a project will create the same effect that Brooks had predicted. But if you choose the people who are right for the job, and infuse them into the project and if the organizational environment is conducive for interchangeability, then the project will not be late.
Now regarding cost, yes additional manpower means additional expenditure. But when we consider the total costs (from an organizational viewpoint), the delayed completion will turn out to be more expensive in the case of tangible and intangible costs.
REFERENCES
[1] Brooks, F.P., The Mythical Man Month, Reading, MA: Addison Wesley Publishing Company, Inc., 1975.
[2] Brooks, F.P., The Mythical Man Month: Essays on Software Engineering (Anniversary Edition), Reading, MA: Addison-Wesley, 1995.
[3] Abdel-Hamid, T. and Madnick, S., Software Project Dynamics: An Integrated Approach, Englewood Cliffs, NJ: Prentice Hall, 1991.
