Preface
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 #8: Overestimate Resource Capacity
For many projects, the capacity of work resources is a critical factor in the success or failure of the project. Work capacity is something you should be able to accurately estimate, quantify, and manage throughout the planning and execution of any complex project. This is especially true for projects that are deadline-driven and requires highly specialized people to complete the work--many projects involving knowledge workers fall into this category.
Just what is work capacity? One way to think of it is as the ability of a person to complete tasks in a project plan, and quantified in working hours. So simplistically speaking one person working a normal full-time schedule for one week would have 40 hours of work capacity. 10 people would have 400 hours work capacity for the week.
I say this is simplistic thinking because when dealing with knowledge workers, it's rare that any one person is really able to spend all of their working capacity on known tasks within a single project plan. Think about your own work life. Let's say you do work a more or less predictable 40 hours per week. Do you ever take vacation days? Are you ever out sick? Take the occasional long lunch with a friend or extended daytime workout at a health club? All of these chip away at your work capacity. Of whatever time you really do have left, is that time booked against tasks in a single schedule? Multiple schedules? You can see how difficult it can be to accurately represent just one person's true work capacity. Now imagine doing so for your entire resource pool.
Smart People and Dumb Math
Here's an exercise I've seen some smart people who should know better go through, typically at the early planning stages of a project and while standing at a whiteboard. I paraphrase:
1. "Let's see, we have ten weeks to complete this project." (Carl wonders silently--really? Is the project driven by some external deadline?)
2. "And we've got five people to get this project done." (Again, really? Do these five people all know their work lives are to be dedicated to this project for the next ten weeks, or longer?)
3. "OK, 40 working hours per week times five people" (Ack! Any holidays coming up? Anyone going to be out sick or on vacation?)
4. "Gives us, tada! 2,000 hours of resource capacity for this project." (Ho boy, that is the best of the best-case scenarios of capacity planning.)
Here's what gets captured on the whiteboard:
10 weeks, 5 resources, 40 hours per week
10 x 5 x 40 = 2,000
2,000 hours resource capacity
Happily, accurately measuring resource capacity is one project management challenge where Project can really help you. Starting from broadest to most specific features, let's see what we can do to improve our calculations. Let's start with this simple project plan:
TIP Click the screenshot image to see a larger view.
Happy Holidays! Really, Go Home.
First, start with the project calendar. Every Project plan uses a project calendar, even if you never see it. The project calendar sets the default working times for the entire project plan. Unless you specify otherwise, Project uses what's called the Standard base calendar as its project calendar. The Standard calendar defines working times as Monday through Friday, 8:00 AM to 12:00 noon, then 1:00 to 5:00 PM. This is probably close to the normal working hours of your organization, but hopefully you close up shop for some holidays. You can modify the project calendar to make holidays nonworking days--you do so in the Change Working Time dialog box (Tools menu):
Select the holidays or other days you want treated as nonworking time, enter a description, and click OK. Project will not schedule work on those days. Note in our simple plan that since I've recorded some nonworking days in the project calendar, Project has rescheduled the work and extended the finish date for the plan. Note that May 31 is now formatted as nonworking time, as are the weekends:
Now I've accounted for my organization's general working time for the time period relevant to this plan, but not for any individual resources' working time exceptions. For this I'll modify resource calendars.
What You Need, My Friend, is a Vacation
You modify a resource calendar in the same Change Working Time dialog box, but you pick the resource you want in the For calendar field:
Whenever you work in this dialog box, be careful about what you have selected in the For calendar field. More than once I intended to edit a resource calendar but ended up editing the project calendar.
For our simple project, let's say our Production Manager has informed you that he plans to be away from work the entire week of May 23. You mark this as nonworking time in her resource calendar:
Now see the result in the project plan:
The production manager's scheduled work is interrupted, and in this case the project finish date is extended. You as the project manager can now decide how to respond: can another resource fill in for the vacationing production manager? Should the whole task sequence be restructured so you don't need the production manager while she's away? Other options?
Enthusiasm Does Not Equal Effort
There are several other features in Project that help you control when work should or should not occur. These include the task calendar and editing individual assignments. Let's stay on this post's subject though: resource capacity. So far we've looked at just controlling when a resource might do work, but there's more to the issue. The next level of detail is setting a resource's appropriate level of work for a specific project. In Project that value is called the resource's maximum units value, and is recorded in the Max. Units field per resource (one place you can see this field is on the Resource Sheet (View menu).
The default Max. Units value is 100%, but you can change this per resource. There are two directions to go:
- Use a lower Max. Units value to indicate that a resource is available for this project for less than full-time.
- Use a higher Max. Units value to indicate that a resource is not a single person, but in fact multiple people with comparable skills who you can basically treat as interchangeable (fungible) on your project. If you want to assign work to a resource named "Set Designer" for example, and you have access to a crew of up to four set designers, you'd set the Max. Units value for this resource to 400%.
The effect of the Max. Units value is two-fold: when you assign a resource to a task, the assignment uses the resource's Max. Units value as that assignment's units value. For example if I have a resource with a 50% Max. Units value and assign him to a task, the assignment will be at 50%. The other effect of the resource's Max. Units value is that it sets the threshold beyond which the resource is considered overallocated. If I assign my 50% Max. Units resource to two tasks that overlap in time, I've overallocated him--I've exceeded his stated capacity to do work. Project won't prevent me from doing this, but it will alert me when it happens.
A cautionary note: So far we've just talked about the Project settings that help me control when work can occur, and for any given resource, how much work can occur. This tells me nothing about the quality of the work though, and that is an area of focus where Project can't really help me. I as the project manager need to evaluate the quality of the work as well as plan the timing of the work.
Everything I Made Up About What I Would Have Learned Had I Gone To Business School Is Wrong
So far our discussion about working time has been rather mechanical. There is of course a human element to how people define their own working times, prioritize their tasks, and communicate their status. These issues are as varied as are people themselves. One of the best books I've read on the subject of how one might approach the time management of knowledge workers and teams is the book Slack by Tom DeMarco. DeMarco is a prolific writer in the field of project management, and Slack is a very readable and concise explanation of a key concept I'll sum up this way:
100% organizational efficiency = 0% organizational flexibility
We've seen that Project makes no assumptions about less than full resource capacity with regard to the project calendar, resource calendars and resource Max. Units values. These are all important considerations we as project managers must explore. We do so often in a faster/smarter/cheaper organizational culture that regards maximum efficiency as a lauded goal, and in some respects it is. DeMarco's book though is a great argument that with knowledge workers at least, we should pause to consider how individual people really manage their time, and how organizations can suffer with wrong-headed campaigns to shave off apparent inefficiencies.
My final thought for this post: Another area that project managers have been known to get wrong is estimating scope of work within a given project. Sadly, we often tend to underestimate how much work is required to complete a given task or entire project, for a variety of reasons. We might be optimistic, betting on the "best case scenario" to become reality. We might like to be perceived as "can-do" overachievers in our organizations. The net is most people I've observed estimating scope of work tend to underestimate, and they often don't mitigate with buffer in their plans. This leads the classic double-whammy of overestimating resource capacity and underestimating scope of work. Chances of gracefully recovering from such a planning mishap are low.
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.
Adjusting the project calendar
- Project 2007 Step by Step: "Setting Nonworking Days," pg. 30.
- Project 2003 Step by Step: "Setting Nonworking Days," pg. 26.
Adjusting resource calendars
- Project 2007 Step by Step: "Adjusting Working Time for Individual Resource," pg. 70.
- Project 2003 Step by Step: "Adjusting Working Time for Individual Resource," pg. 66.
Resource Max. Units values
- Project 2007 Step by Step: "Setting Up People Resources," pg. 60.
- Project 2003 Step by Step: "Setting Up People Resources," pg. 55.
###

http://www.cheapniketn.com/Air-TN.htm
http://www.cheapniketn.com/Nike-TN-2010.htm
Posted by: nike air max tn 2011 | 07/09/2011 at 12:49 AM
The net is most people I've observed estimating scope of work tend to underestimate, and they often don't mitigate with buffer in their plans
Posted by: nike air max tn 2011 | 07/21/2011 at 01:15 AM