Subscribe via RSS

Adding People To A Late Project Makes It Later

Filed Under Human Factors, Software Process

Stones

Hopefully, we have all come to the conclusion that adding people to a late project makes it later; however, I am surprised how many managers and developers still feel this is a good idea. One of my favorite quotable quotes is:

9 women do not make a baby in 1 month

I have talked before about balanced teams, but having correctly sized balanced teams is also important. If a team grows too large the overhead cost of communication, training, and coordination grows exponentially.

So what questions can we ask ourselves before adding additional resources onto a project?

Is this a temporary resource problem?

Many companies accidentally over staff themselves during situations where they legitimately need more people but on a temporary time frame. Adding permanent staff during these feeding frenzies is dangerous because the possible outcomes are never pretty:

  • Projects are overstaffed to “keep people busy”
  • Creates feast and famine experiences in work loads
  • Always in a hire-then-fire state (creates bad company blood)

What is the communication cost?

If we bring extra resources there are a number of questions we can ask about how we will weigh the cost of communication:

  • Will the people physically be in the office or remote?
  • Is our spoken language also their primary language?
  • What modes of communication are we limited to (email only, documents, phone…)?

Can we realign expectations?

In my eyes, this is how 90% of these temporary problems are solved.

Ask yourself, “Is this deadline really a deadline or just a made up one?” Unless your company has been running commercials announcing the deadline, it would be a good guess that this milestone or deadline is really just a fabricated placeholder in someones timeline. Can that expectation be moved slightly instead of asking for forgiveness when your late project become later.

How much time will we lose before we gain?

As the saying goes, “Two steps forward, one step back”, but in many cases ramp up time for additional resources is the first nail in the coffin for you project. There will always be a cost to new employees, so you can not always use it as an excuse not to bring on new blood – but is at the end of a project when you are the busiest the best time?

Be very leery when bringing people into a late project – it might just be the death of your project.

RSS Icon

  Don't miss a drop! Subscribe now via RSS or email.

Comments

5 Responses to “Adding People To A Late Project Makes It Later”

  1. Dew Drop - September 10, 2008 | Alvin Ashcraft's Morning Dew on September 10th, 2008 7:11 am

    […] Adding People to a Late Project Makes It Later (Max Pool) […]

  2. Arjan`s World » LINKBLOG for September 10, 2008 on September 11th, 2008 2:05 am

    […] Adding People To A Late Project Makes It Later – Max Pool ‘ There will always be a cost to new employees, so you can not always use it as an excuse not to bring on new blood – but is at the end of a project when you are the busiest the best time? ‘ […]

  3. Mike on September 12th, 2008 2:31 pm

    I just had an idiot for a client pull a project because “it wasnt moving as fast as they wanted it to” meanwhile 6 solid weeks of work had already been put into this project and no pay had come my way. They breached the contract and now they get no code. Tough sh*t on them. This and your article and all I’ve seen out there goes to prove that there are multitudes more folks out there who do not know whats going on, how to run projects (especially IT projects) and so forth, than there are those folks who “get it”.

    Its really sad.

  4. developer.cl » Archivo del weblog » links for 2008-09-25 on February 5th, 2009 8:39 am

    […] Adding People To A Late Project Makes It Later (tags: management development) […]

  5. Staying motivated during a large project | ian jenkins on March 1st, 2010 12:10 pm

    […] Having a massive project solely on your back is not nice and will only damage the project. By choosing a number of developers to work on the task you instantly remove the pressure of one person having to deliver. This doesn’t mean throw your whole dev team at the problem, but simply share tasks based around spare time in the developers schedule. You should determine the development team for the project at the start of the project and it is important to note that if the project is running late, adding more developers to it is not the answer. […]

Max Pool - © 2024 - {codesqueeze}. Sycorr Banking Solutions