13

When an essential software project is behind schedule we might naturally add manpower. The new developer, however competent and however quickly recruited, needs additional training from an experienced developer.

Taking into account the training and intercommunication time, the tasks which the new developer should implement, cannot remain unaltered, instead they should be revised so that they include also the 'adaptation period' of the new developer.

Is adding manpower to late projects the right decision to meet the deadlines?

Improve this question
1
  • "When an essential software project is behind schedule we should naturally add manpower." Perhaps this would be better worded: "When an essential software project is behind schedule we MIGHT naturally add manpower." – Jeremy Feb 17 '14 at 2:14
18

According to Fred Brooks, author of "The Mythical Man-Month", the practice of adding more people to a project at the last minute may not yield the results you want. From Wikipedia, this is known as Brooks's Law:

"adding manpower to a late software project makes it later"

Software isn't like manufacturing. When I was a lumber stacker, it took me a little under a week to form the mental connections to know which direction to twist to find the right stack for the boards that were coming down the conveyor system, and it took me about 3 weeks to where I wasn't in physical pain at the end of each day. :) The company had a lot of turnover, but we were also pretty interchangeable at that level.

With software, it can take good programmers a lot longer than a few weeks to really gain a solid understanding of the systems. Software is more complex, and requires an almost strategical, high-level understanding of how everything connects together. The longer someone has worked in the code, the more they know about where certain bugs, system flaws, and interfaces can be found, and this allows these developers to more quickly get work done and with higher quality.

In my experience, adding people to a project means those people aren't productive for at least a month. Sure, they might take a small bug or two that isn't mission critical, but until they gain a better understanding of how everything connects together, the only impact they really have is in reducing the productivity of the people who have been on the project longer.

If you know a project is going to be late, you have two options that are almost always better than adding people late:

  1. Meet with the stakeholders and discuss cutting non-mission-critical features.

  2. Push back the project deadline to account for the extra time needed.

By adding people late, you increase the chances not only of quality suffering but of the project being even later.

Improve this answer
3
  • 1
    What about a situation, when 1 or 2 core developers leave the project? We will try to replace them, but as you said ''adding people to a project means those people aren't productive for at least a month''. Does it mean that we should try to keep the team as constant as possible until the end of project? – saakian Feb 17 '14 at 7:25
  • 2
    Then that's a different situation altogether. That's "Bob had a family emergency and Sally went to work for a competitor." That's different than, "Oops, we messed up our estimate and didn't consider that the database we chose wouldn't scale for X". If core devs leave, you have no choice but to replace them. That's not really the same as increasing the overall number of developers on the team. Hope this helps. – jmort253 Feb 17 '14 at 7:31
  • When I started my new job as a programmer my supervisor was expecting a period of half a year to be able to make significant contributions. It did not take that long, but it easily could have. – kleineg Feb 26 '14 at 17:16
7

I agree completely with jmort253's answer. However, I would add one caveat.

If your project has extremely isolate-able components (say some batch jobs, etc.) you might be able to add someone and cut some of the remaining time. However, one should be extremely careful before concluding that more resources will speed up a late software project. Those new resources will never be as productive as the existing team because they will always have less experience on the project.

There is an additional concern and that is those new resources are going to be taking time and attention away from the existing team members. That is, in my experience, why adding staff to a late software project makes it later - because it makes the existing, productive team much less productive.

Improve this answer
2
  • I disagree that the new people will never be as productive. They will have less experience on that project, true. But quality programmers will have their own skillsets that might be exactly what you needed. And existing programmers might be blind to problems in the code they have been working on. I would say that new resources are often less productive, at least until they adjust. – kleineg Feb 26 '14 at 17:21
  • And it's exactly that adjustment period that takes time, and requires followup/assistance from the rest of the team ... slowing down the rest of the project – Joris Van Regemortel May 30 '20 at 14:33
5

No, you should prioritise the remaining work and ensure the most important work is done first. Then the stakeholders can decide if they continue to fund the work on the less-important remaining features with additional time, or if they discard them.

Ideally, any project should already be prioritising the work to be done. (If not, why not?)

This question illustrates why the software world is turning away from large-scale projects with a single deliverable deadline date, towards agile multiple-deliverable projects prioritising work items. This ensure that by the time you are getting towards the end of the project's duration or funding (i.e. you're getting "late" in the project) the project has already delivered many iterations demonstrating real customer value.

Improve this answer
1
  • 4
    +1 for the mention of agile and how, even if late, the project has already delivered value. Contrast that with a partially built bridge, which is a useless bridge. – jmort253 Feb 17 '14 at 7:34
3

I think the answers need to be qualified a bit further. I think Brooks findings have a lot of validity. In other words, as Jmort expertly drafted, adding resources can threaten your schedule further.

However, I am loathe to adopt this as law, despite Brooks Law being seemingly adopted in the IT industry, meaning adding resources ALWAYS increases your schedule for ALL projects ALL the time. Not many things in our world operate with this high degree of certainty, like gravity.

Crashing your schedule is a legitimate intervention for compressing your durations, which must mean, despite what Brooks opines, it has some efficacy. Therefore, you need to analyze your situation carefully. The risk is real; however, it is not certain and in some cases you can successfully bring your project back in line.

Improve this answer
8
  • If a software project is being managed in such a way that it is seen to be going to deliver late, then under certain and very specific situations crash the schedule might work - but I would argue that such a project is demonstrating characteristics of a death march project and mismanagement that will see the project fail, even if you toss many of the world's best programmers at it. It's almost never the programmers who are failing the project, it is the garbage they are given in terms of changing priorities, changing requirements, and lack of accountability at the top. – Jeremy Feb 17 '14 at 23:03
  • 1
    There are always a host of both aleatory and epistemic variables that drive unfavorable results. Part of the game. Garbage notwithstanding, as a PM, you gotta do something to intervene. You can't just cite lousy leadership, Brooke's Law, and then sit there with your arms crossed, right? – David Espina Feb 17 '14 at 23:44
  • So instead of attacking a symptom (the project is running late, therefore crash the schedule) attack the causes: prioritise the remaining work items and ensure that the most important are properly described. Direct the work to focus on the most important items. Defend the team from all other demands from stakeholders and external parties that are at variance with the clear direction given. Ensure there is a single go-to authority to get information for any queries that come up and immediate decisions when alternative options are available. In other words, manage the project, not the team. – Jeremy Feb 18 '14 at 0:05
  • 1
    Yes, all of those things. You push and pull where you can, but some things in a project environment can remain frozen and less than ideal despite best efforts. And, some of the "cause" could be optimistic planning from a resource standpoint, where crashing, i.e., bringing more staff, is the right cure. My point is, the situation needs a comprehensive analysis and to avoid the adoption of a "law" wholesale as the answers implied. – David Espina Feb 18 '14 at 0:16
  • 3
    I have to share my two cents: In the extreme case of a lean time of 2, if we have 20 onboarding, at least 2 more are likely to be smart enough to be productive quite fast. In the real (IT) world, however, I'd be more pessimistic and say David was lucky. :) – Tiago Cardoso♦ Feb 25 '14 at 21:02
0

I think yes, Because Manpower planning is likewise referred to as human assets planning, and it is the manner that management makes use of to decide the manner wherein a company needs to circulate from factor A to factor B, in terms of manpower. This happens through making plans and development and enables management to have the right sorts of personnel in the right number within the right place at the right time.

Improve this answer
1
  • Welcome to the site! I'm not sure the OP is asking during the planning stage, but during the execution stage. – Danny Schoemann Dec 11 '19 at 10:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.