4

While there's way too much wisdom and anecdotal evidence accumulated over the years that throwing new people into a project to magically close a scope-gap or a schedule-gap is a bad idea, I've noticed that seasoned leaders continue to try this, especially in the software development world (which gestates release babies faster than the typical 9 pregnant women).

Asking if there's a narrow set of conditions where this act of insanity ( adding new lines of communication and enduring the burden of ramp-up, training, having too many chefs in the kitchen, etc.) ACTUALLY ever helps a project succeed?

I can think of try-to-break-the-software usability testing where NOT knowing how a web application even works can possibly invite bug-bounties and having people show up as a mob to test.

Is there any other scenario that could work?

Improve this question

8 Answers 8

Reset to default
3

Different tasks have different degrees of resources elasticity. And a task in itself can have different degrees of elasticity depending on other present variables like the environment.

Imagine ten patients needing surgery with one surgeon. Then, add four more surgeons. Would anyone argue that the duration to complete those surgeries worsened? Hope not. What if there were only two surgery theatres?

Having hard fast rules is for the intellectually lazy. You need to assess each task and the environment and other factors to gauge the elasticity you may observe.

Improve this answer
5

In certain cases it is possible to get more work done if you introduce more people.

The most usual scenario is when teams take time to do detailed scoping and when the project itself allows low coupling among the components.

In my experience this has rarely happened. Communication grows a lot by adding a single member and administrative tasks requiere more time than usual.

Managing the unmanageable explains in more detail how small teams tend to get more work done in less time. Have a look if you're interested :)

Improve this answer
0
2

One way to think about it is to consider if the task would be marked "Effort Driven" if you were creating an MS Project Plan for it. Effort driven tasks are actually expedited by adding people (at least up to a point). The Mythical Man Month idea that adding more people to a late software project will make it later is true for knowledge workers on a project which is adequately staffed - but not for tasks which can benefit from brute force (the bug bounty, in your example), or for tasks which are simply understaffed.

Improve this answer
2

A lot of the other answer, cover the case where there is a lot of independence. But what if there is no space on the team to add anyone, then is it ever possible.

  • Hire a specialist in an area that you are stuck (on critical path).
  • Introduce pair programming, each pair made up of one old-timer, and one newbie. Rotate the pairs each day, so that the newbies get experience in each aria. This takes a while to get up to speed, to don't add to close to end of project. It will probably take at least two weeks for a pair to be as fast as if working separately, so you may expect 4 weeks to pay off (this figures are not researched, just a guess).
  • Use surgical teams. This is a bit like pair programming. But with a team of 10. Also in mythical man month. see https://softwareengineering.stackexchange.com/questions/355203/what-happened-to-the-surgical-team-pattern-from-the-mythical-man-month It will need updating, and is a bit more complex that pair programming.
  • Hire problem solvers: that is for every 2 or 3 workers, give them a manager. The manager works for the workers, if the workers have a problem, the manager finds a solution (the manager must Not out rank the workers).
Improve this answer
1

Is there any other scenario that could work?

I think you are approaching this from an angle of what works functionally. You already know it does not.

Look at it from another angle: as a project manager, who do you want to be? The active, try-your-best guy who pours more manpower into a late project that then fails anyway despite all your best efforts? Or the defeatist guy who tells their boss that this project will fail anyway and then stand by with their hands in their pockets doing nothing while the project fails?

Pouring manpower into a late project is not an effort by an intelligent, educated person trying to save the project. It's the move of somebody who needs to look worthwhile in the eyes of their bosses, who probably know nothing about whether adding manpower is a good move or not. All they know is their PM requested more money when the project was late, which seems the smart thing to do.

Improve this answer
10
  • The bigger challenge is instead convincing one's leadership that we need to plan for damage control and managing the client relationship.
    – shivsky
    Commented Jun 17, 2018 at 12:21
  • 1
    In my personal experience, upper management is the prime reason why projects are late, either because they set the deadline (instead of asking what can be accomplished and in what timeframe) or by insisting an an archaic, legacy project management method (C&C) for a project that was highly volatile and would have required a more agile approach.
    – nvoigt
    Commented Jun 17, 2018 at 12:23
  • Which also requires that your client be Agile as well.... Rarely seen in the circles I move in
    – shivsky
    Commented Jun 17, 2018 at 12:24
  • 2
    I think the premise is fine. But I think an intelligent, educated person knows that the curve that represents diminished returns is exactly that, a curve. It does not drop off a cliff. So if your under staffed and have a decent number of concurrent tasks, adding humans would yield greater productivity. Even if at full task, adding a human may not yield a 1:1 production increase but could still add some increase, thus the word diminished. And finally, not all tasks are the same. Some have very different looking curves.
    – David Espina
    Commented Jun 18, 2018 at 17:33
  • 1
    @DavidEspina The argument is not that it only adds a bit of performance. But according to Brooks in Mythical Man Month, and experience. It will make the project even slower: Each new resource adds overhead, as well as resource. The overhead when first added is usually higher that the resource. See my answer for a few exceptions.
    – ctrl-alt-delor
    Commented Jun 29, 2018 at 11:54
1

Adding extra people to a project can work quite well if you have planned it out in advance. In my team, we have a few external people who are up to date with our systems and can help us out if needed.

One is a former employee who took a year off to go travelling and is available to do some temporary work to fund her travels. She knows the codebase and the people so she can join a project on short notice with minimum overhead. We also have a few contractors we use who are familiar with different parts of our system and can add extra capacity without too much extra co-ordination needed.

Improve this answer
1

I definitely agree on what Roberto Anzaldua posted. From what I observed:

If you give a tightly coupled codebase to someone new to the project, he/she will need to dissect which parts he needs to work on. There might be some higher learning curve, since the new engineer needs to learn how his work will interact with the existing codebase and may need to study the other section of the codebase.

While giving a highly decoupled codebase to someone new to the project, the new person can just think on the interface perspective of the design and he can concentrate on the section that needs to be worked on. The lead software engineer usually takes care of the interaction of that section to the existing codebase using abstractions or interfaces.

While making a software work is expected, I believe a good software lead knows how to write a highly decoupled software which is crucial for any project especially for projects with large codebase. I observed the those who are knowledgeable in design patterns and solid principles have the ability to write highly decoupled software.

Improve this answer
0

Elasticity also depends on size of codebase. If you have a huge product with thousands of LOC, and your project is upgrading it on a new level here and there, then you can have a team with tens of people working effectively. I managed such a project during 2 years and it was very successful.

Also, you can find more in a very similar question here.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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