This blog post is one in a series of 10 based on a presentation I developed, “Top 10 problems new (and not so new) Project users have, and what you can do to ease the pain.” I first gave this talk at a Puget Sound PMI chapter meeting. I later gave an updated version of the talk to my local chapter of the MPUG Project User Group. As you might expect, at the PMI meeting the discussion tended more towards the broader project management issues, while at the MPUG meeting more towards specific features in Project. In fact at the MPUG meeting I had my computer projecting and we played around with Project features that related to some of the issues I brought up.
Top Ten List
In the process of writing the Project Step by Step books (starting with the 2000 edition and continuing through the current edition) with my co-author Tim Johnson, I observed first-hand some of the problems Project users encounter. Some of these problems are straight-forward gotchas in the software, but many common problems were really about how people define, understand and practice project management. In this and the other posts in this series, I’ll guide you through each of the top ten problems new or inexperienced project managers encounter, and what you can do to help identify and address these problems.
Problem #6: Don't reign in effort-driven scheduling when it shouldn't apply
Some things make perfect sense in one context but perfect nonsense in a different context. Effort-driven scheduling is one such thing. It's a powerful feature in Project that you should know well.
The basic idea of effort-driven scheduling (or EDS to its friends) is simple enough: if one person working full-time on one task should take, say, 20 days to complete that task, could two equally able resources complete the same task in 10 days? Depending on the nature of the task the correct answer could range from "Sure!" to "No way!"
In Project 2007 and 2003 at least, EDS is on by default. Project has a task-level setting that you can use to apply EDS or not. That setting is on the Advanced tab of the Project menu/Task Information dialog box, and is the Effort-driven check box. EDS is user-adjustable only for Fixed Units or Fixed Duration tasks, but not for Fixed Work tasks.
TIP Click the screenshot image to see a larger view.
There are two hurdles to managing EDS effectively: one conceptual and the other mechanical. Let's consider both in turn.
The recipe says to cook it at 200 degrees for 4 hours, but I went for 800 degrees and 1 hour. Hey what's that smoke?!?
As a project manager, you really have to understand the nature of the work required to complete a task to determine if EDS should be enabled or not. Consider the following:
Task: Neatly stack up a pile of bricks currently strewn on the ground. One stacker resource would require about four hours to complete this task. Could two stackers get-er-done in about two hours? Most likely yes. How about four stackers in one hour? Well, maybe but there are some issues to consider. Will four workers bump into each other in their mad rush to complete the task in one hour? Is the workspace large enough for four stackers? Clearly, there's some time advantage to having more people work in parallel on this task, but it scales only so far. Ten eager stacker resources, for example, almost certainly could not complete this task in 0.4 hours (although mathematically that is the correct duration with EDS enabled and 10 resources assigned).
Or how about this one?
Task: Perform a liver transplant on a single patient. One surgical team can accomplish this task in, say, eight tense hours. Could two surgical teams working in parallel accomplish this task in four hours? No way. The nature of the task doesn't accommodate additional resources.
Project is binary about EDS-it's either on or off per task. You as a project manager need to apply your judgment to answer the question: For a given task does EDS make sense, and if so to what scale? If the answer is not clear to you, by all means ask the resources who will do the work.
Trust me, Project always does the math correctly (but you may not like the answer)
Next let's consider the mechanical issue of using EDS. Before I assign any resources to a task, the task has duration but no work. Lets' say I do intend to assign two resources named Screenwriter and Artist to the task Develop production boards, for which I have left the default EDS enabled.
There are two ways I could accomplish this that will produce dramatically different results:
Assign both resources simultaneously. Result? EDS doesn't apply!
Assign the Screenwriter to the task, and then assign the Artist to the task. Result? EDS applies.
If you've been paying attention to my previous blog posts like this one you may recall the scheduling formula: Duration x Units = Work. Let's examine the scheduling formula variables in both cases.
Here's the split view with the venerable Task Form for the case of the two resources assigned simultaneously:
Duration = 2w = 10d
Units = 100% + 100% = 200%
Work = 80h + 80h = 160h = 20d
Putting it all together:
10d Duration x 200% Units = 20d Work
Now let's do the math for the resources assigned sequentially case:
Duration =1w = 5d
Units = 100% + 100% = 200%
Work = 40h + 40h = 80h = 10d
Putting it all together:
5d Duration x 200% Units = 10d Work
Aha. It turns out that in both cases the scheduling formula is true. In the first case Project did not apply EDS because the resources were assigned simultaneously. If I had turned off EDS for the task, I'd of gotten the same result even if I'd assigned the resources sequentially. In the second case Project did apply EDS because the Effort-driven check box was checked and the resources were assigned sequentially. Same initial duration, same number of resources assigned, but dramatically different results.
I guess now we'd say person-month
I'm in the camp that believes that for most projects for which Project users build schedules, most of the time, EDS should not apply. I'd prefer it was off by default, but that's not the case. EDS is a mild but managable software manifestation of what Frederick Brooks famously called The Mythical Man-Month. The essential idea here is that all other things being equal, increasing resources does not necessarily reduce duration on a task or project. In many situations, especially those populated by knowledge workers (like the software engineers Brooks focused on), adding more resources can actually increase duration because now there are more "cooks in the kitchen," meaning there are more people to ramp up on complex work, more channels of communication to manage, and in general more complexity than we started with.
Hands-on with Project Step by Step
To read more about this blog entry's subjects in the two most recent editions of Tim Johnson's and my Project Step by Step books, see the following cross-references.
Effort-driven scheduling
- Project 2007 Step by Step: "Assigning Additional Resources to a Task," pg. 83.
- Project 2003 Step by Step: "Assigning Additional Resources to a Task," pg. 76.
Task Form view
- Project 2007 Step by Step: "Exploring Views," pg. 23.
- Project 2003 Step by Step: "Exploring Views," pg. 15.
###

IN the middle of reading #4 FROM this site:
http://blogs.msdn.com/b/microsoft_press/archive/2010/02/22/carl-chatfield-top-10-problems-4-track-by-percent-complete.aspx
I was redirected to finish reading on your blog. But, I can't find where #4 is posted--discussing % complete. Please send proper link to the entire Top 10 list. Thanks!
Posted by: peggy | 01/11/2012 at 04:54 PM