Adding new team members to a late project

Question

According to Brooks' Law, adding more people to a late project will make the project later (or by analogy, nine women cannot have a baby in one month). The increased lateness is due to the fact that productive team members must now invest time in ramping up new team members rather than working, and communication needs grow exponentially.

And yet, some managers still see it as a viable way of finishing a project that is running late (a practice appropriately named crashing).

How to best push back on the proposal to just add people to a late project, or are there times when it is acceptable to do so?

Answer 1

Accept the proposal when -

-- the people coming in are experts(at the task) and would directly add value /expedite the project mission.

Push it back when -

-- the intention is just to throw more bodies at the task , just to bring the resourcing estimates(numbers) in control, to create a perception that the project is now aptly resourced to finish on time

Answer 2

If the project is rather a big, and long, one and from the very beginning you actually planned for scenario like that adding people late (but not too late) might actually help. Consider 1-year long project which has deadline written in the stone, like some software for Olympic Games. You can't really move the deadline, unless we're postponing Olympic Games, and probably dealing with scope is rather hard so we aren't left with much choice.

If you planned software in a way there are separable modules which can be build by independent teams you actually can scale the team up. Of course there are stages of the process, say setting the architecture up, which can't be approached that way but they're usually during the early phase of the project.

Anyway, that isn't a default scenario. By default you prefer to avoid such situations so you should bring good arguments with you. I'd start with some historical data showing (bad) impact of late additions on a project deadline. If there is such data of course.

Also you can try to show the cost of learning - time spent by a newbie on learning a project and time spent by one of existing team members on teaching/coaching.

Then you can move to industry experts, like Fred Brooks, but from my experience such arguments rarely works. I mean if someone blindly believes that more people means faster delivery they probably haven't even bother who the heck Fred Brooks is, let alone reading his writings.

If everything else fails just accept late additions, but make sure you actually measure their impact on a project so in the worst case you will have some ongoing data analysis and maybe you'd be able to act somehow during the project. And even if not, the least you get is some historical data you can use when the same discussion happens in the next project.

Answer 3

There are many examples of tasks whose duration can successfully be compressed by adding additional labor. Brooks Law is hugely valuable but I think a PM needs to assess the uncertainty on a case by case basis. If a task is generally not unique and rather standard for industry, then your risk is reduced and you have decent likelihood that your duration will compress. If the solution/product is quite unique and processes/tools are homegrown, you have some threat here. In either case, the added resources need to have reputation of competence and capability that precede them, where you can have a reasonable level confidence that they can hit the ground running.

Answer 4

The biggest dangers of adding people to the late project seem to come from the additional communications paths, the distraction caused by training the new people, and the team having to go back through storming and norming phases again. As with many things, a bit of advance planning can help with these challenges.

• First and foremost, try to bend scope or date before you try and pile on people.
• Consider low-risk, low-learning pieces of the project that could be broken off wholesale without needing a great deal of input from the existing team. Can you outsource this piece with minimal distraction to the rest of the team? Imagine outsourcing as adding a bunch of people that don't have to distract the existing team.
• If you have the opportunity to mitigate the potential for being late ahead of time, extend the previous point by giving that supplier a bit of work throughout the project so they already have people that understand the context and the domain. Essentially, you're buying the option to disperse the "damage" of adding additional people if the project does become late. This strategy is detailed in Don Reinertsen's book "Principles of Product Development Flow".
• The earlier the better. It's typically far less disruptive to a team to add one person three months before a deadline than three people one month before a deadline. Consider slowing adding capacity if it can be done without overly distracting the team, and the new members can train more easily.
• Cross-train aggressively. If you have external reviewers that work with the team throughout, they are more capable of joining the project without disrupting things. If other teams are frequently involved in brown bags and other demos given by the team at risk of being late, people will already have background to do less damage.

In short, if being late is inevitable, try and adjust scope or date reasonably. If adding people can't be reasonably avoided, strive to mitigate the damage done to the team to where those people are a positive difference rather than negative. Oh, and always set the expectations before taking this drastic action... make sure stakeholders don't expect double speed by doubling people, etc.

Answer 5

Gift-wrap a copy of the Mythical Man Month, and focus on providing alternatives. Cutting scope or extending the deadline are usually appropriate.

There will be some small, fundamental functionality which needs to be delivered. Identifying this vision, and engaging the team in finding quicker alternatives to delivering it, can really help to reduce the need for evening and weekend work. You'll be amazed how creative technical people can be when their quality of life benefits!

Answer 6

Crashing can be successful. I've done it. But most people make several mistakes:

They UnderCrash usually crashing takes 3 to 5 times as much cost to successfully overcome the problems caused by the inertia of brooks law. Most people severely under calculate the amount of resource required to crash a project. A project that is 25% complete at the halfway point will probably take five times as much resource as originally applied to get it back on track.(basic math says 3 times, but the inertia of brooks law has to be overcome)

They MissCrash, due to the massive acceleration of resources, only certain projects can be successfully crashed. If you don't have the workbench space to support all that extra resource required to overcome the inertia, it simply won't work.

They Crash too late. Once you hit a certain point, all the resource in the world, organized perfectly isn't going to move that needle.

They ignore the fact that the project has already failed. If crashing is required, you have totally missed your targets. The project has failed. You have to go back and figure out why you were off. If you still have unclear scope, poor sizing, and lousy communications, you can't successfully apply the resources to solve the problem.

Answer 7

There is definitely a conflict between Brook's Law and a modern project management discipline (where "crashing" technique comes from). The source of this conflict is an assumption being implicitly made by Fred Brooks in his book that a software development team is creating software in a permanent chaos, without any project management at all.

Since 1975 many things have been improved. PMI gave us new knowledge and a new law - law of project management - the PMBOK. If you follow it you will be be able to compress schedule by means of crashing in any moment of time, even on the last day of the project.

So the answer is - Fred Brook is right if your team works in chaos.

Answer 8

I agree with Pawel,

I'd say that no matter the level of expertise, when a new member is added in a team especially in a project that is overdue and deals with pending issues, it will undoubtly cause a slow down. There are indeed factors to take into deep consideration on both sides.

Let's face it, I don't know about you, but I've worked on a fair amount of projects and even if some firms claim to use the same MS technology [even to be the best in the field and give formal training formation to newcomers when it's not always the case...], no one uses the same code logic and architecture in every context. If things were that easy, we could all sit back and take a big break... Reality shows that it's not the case, each new project brings a new challenge.

A lot of factors [both technical and human] can vary and interfer from project to project. I'd say the analogy of nine women who cannot give birth to a baby in one month is perfectly true, still a lot of team or project managers can yet picture the basic concept. Too often their own reputation comes first, they have to deliver a product right on time no matter what upon a client's requests, otherwise their own job might be in jeopardy... right?

I've ended a big project recently. We were a small team of 4 senior developers with few young developers to help us with unit testings tasks. We started the project nearly all from scratch and we managed to deliver the product on time exactly as the client requested. We even brought more extras in bonus. We occasionally had to work overtime on weekend [for free..] but just like with the Olympic, the project just couldn't be postponed and we all knew it was a one big shot deal we couldn't miss, so we didn't want to skip it. Throughout the project, we not only learned to work and communicate together as a team, we sort of all created the architecture and business logic of the project right form the start and I can humbly confirm that if I would have been asked to join the same team at a much later stage in the production, let's say like a year after and in an overdue scenario..., no matter the level of expertise, without any proper training from my fellow team members, I might have been lost in the jungle.

The bottom line... Adding new team members to a late project can often end up in a Catch 22 situation for both parties like I often seen if not handled and managed properly.

Answer 9

How to best push back on the proposal to just add people to a late project, or are there times when it is acceptable to do so?

In corporation world, decisions are made. If decisions are made and there is no influence from your side, the best thing is to i) accept it and ii) write it down because otherwise, it never happened. You basically disagree (find ways of saying 'no') and point out risks of delays, productivity, etc.

I have encountered this a hundred times, adding people (shall I say 'throwing in people') however the decision reasons were of different nature like 'person A is available, s/he can help'. Here the solution was for management to give person A work irrelevant of the project (scope, problems, etc.) person A joining. A line-project scenario (matrix).