A saying is (at least here in Germany): Adding new people to a late project makes it even later. That is true, because the additional work to introduce the newbies to the project destroys productivity of the established team members for some time. But we all know that more staff from the beginning would conclude the project faster (at least most of the time). So adding people at the beginning would help the project, adding them late would hurt the deadline. At what point in the project is it too late to add new members where you will not jeopardize the deadline further?
When is the latest opportunity to add new team members to improve schedule performance?
2Take a look at this recent blog post by Martin Fowler: PrematureRampUp, maybe will be helpful...– yegor256Nov 13, 2011 at 8:24
I agree that adding people can slow the project, and this is especially true if they are the wrong people. Adding the right people can speed the project up, especially if they have specific domain expertise that is missing or weak in the original team,and they are being brought in to support the team rather than taking over and destroying morale.
I would suggest that the time to bring in any new blood is at the start of new phases of the project, based on either the introduction of a new technology, a move from one stage (e.g. design) to another (e.g. development), or as soon as you identify that something has gone horribly wrong and you don't have the right resources to fix it. If you have already identified the root cause of a problem and are working on the resolution, then unless it is clear that the resource level is a major contributory factor, trying to beef up the team to speed up delivery is very unlikely to work.
An interesting book that illustrates some aspects of this is "Show Stopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft" which is a bit out of date now, but illustrates how a project can grow massively and change shape to an incredible level. Definitely worth a read, though!
I think it would be a mistake to look for some arbitrary % complete where adding to the team would, with absolute certainty, exacerbate the delay. Brooks Law is compelling, but it is not a true physical law. Crashing your schedule at any time in your progress could help, could hurt, or do nothing at all. It requires analysis and risk assessments and the answer would be different for each project.
I thought more in the lines of a general rule of thumb instead of a very concrete number.– MnementhNov 10, 2011 at 18:13
1Rules of thumb are hugely useful. However, I cannot see how you can arrive at a heuristic for this. All projects are quite different, too many variables that affect results. Even the heuristics developed for EV are now being questioned and ignored. Nov 10, 2011 at 19:01
I think you can get close by estimating lost productivity from "spin up" time. Based on these assumptions:
- New people will need some time to get familiar with the project before they are productive
- Existing team members will have lower productivity whey the new person get's familiar with the project
Now, estimate the amount of time one person will take to get up to speed, estimate the amount of time other team members will less productive, then you will have a cost-benefit estimate that you can apply. If the "cost" of lower productivity makes a set of task run longer than than the "benefit" of having more people to do the work, then you shouldn't add people.
However, @Iain9688 advice of adding people and major phase breaks is a better answer. Since, in theory, everyone is at the same level of productivity when there is a major change in tasks.
It all depends on the your project. Look at the network diagram of the tasks and see where adding resources or running tasks in the parallel can make a difference.