Justifying Resources through the DRED: How to Repeal Brooks’s Law

There is a famous quote from Frederick P. Brooks Jr., author of The Mythical Man-Month, that has come to be known as Brooks’s Law. The quote is: “(A)dding manpower to a late software project makes it later.”

Although Brooks himself called his law an “outrageous simplification,” there is some truth in it. And it is often taken as though it were gospel, on all activities and projects irrespective of the nature of the work: “What do you mean you need more resources? Don’t you know about Brooks’s Law? Adding resources to a project just makes it take longer!”

There certainly are types of work and situations where adding resources will delay completion. In certain situations work such as software coding, writing documentation, and, as I discovered on a consulting gig about ten years ago, doing installation work in the cockpit of a jet fighter can all be subject to such constraints. And there are undoubtedly many other such cases. But I don’t think one should accept it as gospel for even the majority of work situations. Try lifting a refrigerator or a long table up a couple of staircases by yourself and then tell me that employing an additional pair of hands wouldn’t have been more efficient!

The impact of varying resource levels on an activity’s duration is called the activity’s resource elasticity: how much it will contract or expand in response to more or fewer resources. This is a very important consideration when looking to compress a project’s schedule. Some work is very resource elastic, some is a little so, some is not at all and some is negatively so. From a scheduling viewpoint, it can be very valuable to know what the resource elasticity is of each activity, especially those on the critical path with substantial amounts of drag and drag cost.

One of the planning techniques I have used on consulting assignments is to obtain a secondary duration estimate from the SMEs based on the following question: “I have no idea if I can — but if I could get you double the resources you currently have, how long would the activity take?” (Notice: I don’t ask “How resource elastic is your activity?” which would simply beg for the response: “Huh? What the heck’s that?”)

The estimate this question generates is the doubled resource estimated duration, or DRED. It is not intended to trigger some kind of automatic increase in resources and corresponding schedule compression. Rather it is simply to provide, in terms that anyone can understand, an indicator of how resource-elastic the activity might be.

Most project management software packages can store a secondary duration field. Then if it turns out, either upfront or during implementation, that an activity with lots of critical path drag and drag cost is very resource elastic, it may identify a suitable target for efficient increase in resources.

But not without first going back to the SME and re-establishing both that the increased resources would be beneficial AND that we know the right amount of additional resources. (Maybe a 25% increase will give us as much benefit as a 100% increase, so why spend the extra money?)

There is a range of possible DREDs for any activity. For 20-day activities, DREDs might look follows:

5 days: Very rare, but it can occur as a result of not having optimum team size – toting that refrigerator upstairs is one example – I bet two people get it done in 25% or less of the time that one person would take!

10 days: Said to be “perfectly” resource elastic — the number of estimated workhours is unchanged and thus implementing the DRED may cause little or no negative cost impact.

13 days: More common than 10D in my experience. Some negative cost impact, but still usually a good way of reducing drag cost.

17 days: A small improvement. It may be useful if the drag cost is great, but not if it’s small.

20 days: Not at all resource elastic.

30 days: Negatively resource elastic. However, sometimes using entirely different kinds of resources can help.

Once the initial schedule has been generated and the drag and drag cost of each critical path activity have been computed (we are doing those calculations, aren’t we?), the project manager/scheduler should look at the DREDs of those activities, see which might benefit substantially from added resources, and then check back with the activity managers/SMEs who generated the estimates.

“You said you could get this activity done 10 days faster if I got you two more programmers and one more mechanical engineer. I just want to confirm that this is correct?”

“Actually, Steve, I’d really only need another mechanical engineer – that’s the constraining resource. But I don’t think you’re going to be able to get one!”

“Let me see what I can do.”

And then I go and make the case that I can potentially shorten the project by 10 days, at an expected value of $20,000 per day, by getting one additional M.E. for three weeks. If that M.E. is located anywhere in the organization, he’s going to be assigned to my project! (That is, of course, unless the manager of another project where time is even more valuable is using the same techniques and needs that M.E. at the same time.)

Finally, since multitasking has become so much more prevalent in the business world than it was back when Mr. Brooks worked at IBM, it is good practice to periodically examine all activities with critical path drag and drag cost for their level of resourcing. If any such activity has only part time resources, its resource elasticity should be examined. Why would we ever limit a critical path activity with large drag costs and a generous DRED to a 25% or 50% resource assignment? That’s just one more inefficiency that these new techniques for critical path analysis can identify, measure in financial terms and, perhaps, alleviate.

Fraternally in project management,

Steve the Bajan