Resource Management Solutions : 9 Women can’t make a baby in a month

Resource Management Solutions : 9 Women can’t make a baby in a month

I’ll admit that I stole this title from an excellent article on TechCrunch by Mark Suster. The article explains why over-capitalizing companies too early is a bad idea. But the title got me thinking that it’s actually a good metaphor for explaining why throwing additional resources at a project doesn’t always mean you get things  done any quicker.

If you’re in a hurry to have a baby, adding extra women just doesn’t help. In fact, sometimes adding additional resources can actually slow things down. I can see your eyebrow raising so please excuse this very odd metaphor.

Going off the rails

You’re three quarters of the way through your web project and the deadline is looming. You look at your project plan and your milestones and you realise that there’s no way you’re going to hit the deadline at the pace you’re going. The project is going way off track. Every project manager finds themselves in this situation at some point in their career (sometimes over and over again). Conventional wisdom says that you have the following options:

  • Get agreement from the client to shift the deadline
  • De-scope the project or deliver in phases
  • Get the team to work longer hours (oh no, do I really have to get the whip out again?)
  • Add resources and have parallel workstreams

While this last option might sound good on paper, it’s not always a good solution. Web projects are often very complex and frequently the solutions are completely bespoke for each client. This means that resources that have been working on the project for weeks often have a huge amount of intricate knowledge about the project that only exists in their heads. Sure, you can have lots of documentation but, inevitably, there are things that just don’t find their way into the documentation. And if you’re working on an Agile project, you may not have much documentation at all. This means that any new resources that you add to the project will have to go through an “on-boarding” process – getting up to speed with all the intricate details before they start work. If they don’t get up to speed first, they can end up going down the wrong path, disrupting the team and generally doing more harm than good.

Grey Shopper
Katy Surr

“Resource Guru simplifies the way we work and gives us a holistic view of what’s happening.”

Katy Surr
Resource Manager

Precious time

The trouble with “on-boarding” new resources is that it takes time – the very thing you’re trying to save. Not only does it take up the project manager’s time and divert him from his normal activities, it also takes time away from the other resources who have to explain all the intricacies of the project – all those things that live only in their heads.

Too many chefs

Another problem with adding additional resources is coordinating who does what. Sometimes it’s easy to divide a project into isolated tasks that can be easily distributed between resources. But sometimes this is not quite so easy. I think this is especially true when it comes to programming. It’s just not that simple to throw another programmer into a team and expect him to start making a positive difference. There is so much inter-connectivity in web development and it all needs to be very carefully coordinated with each person knowing exactly which piece of the jigsaw they are working on. Get this wrong and you can end up in one hell of a mess.

Don’t get me wrong, I’m not saying that chucking additional resources at a project never works. I’m just saying that it’s not always that simple and needs careful thought and planning. Sometimes it’s just better to get that whip out ;)

A late update

After writing this post, I came across Brooks’ Law which is apparently where the phrase “nine women can’t make a baby in one month” comes from. Strangely enough, Brooke’s Law relates directly to what I was saying and says that “adding manpower to a late software project makes it later”. Brooks explains that there are 2 main factors that explain this:

  1. It takes some time for the people added to a project to become productive. Brooks calls this the “ramp up” time (what I called “on-boarding” above).
  2. Communication overheads increase as the number of people increases – which relates to my “too many chefs point”.

So, the fact that I came up with a very similar idea independently obviously proves that I’m a genius! ;)

Related articles: