For planning purposes, how many work hours per day should I expect of each staff member?

Question

In my reading on SE, some people say 5-6 hours and this agrees with my experience. In our company, we commonly are "at work" 7.5 hours each day, but from a PM point of view...

How many hours should I plan in a work day for each staff member?

Answer 1

TL;DR

In general, I recommend a "fudge factor" of 0.75 to baseline a new project, absent other data. This would mean 6 hours of project effort in an 8-hour day. I also recommend a more aggressive fudge factor of 0.4 to 0.6 for new teams to account for the overhead of team formation and process development.

In the following sections, I describe some considerations for estimating team capacity and some general advice about scheduling.

Estimating Useful Work

There's no "one size fits all" answer to this question. In my experience, 6 hours a day is a useful planning value when including project overhead like meetings, conference calls, time tracking, and other process overhead, but a great deal depends on:

• The amount of process overhead imposed by your project framework.

  If you follow the math, this figure comes out to roughly 26% in common Scrum implementations. Other frameworks may vary.

• The amount of task-switching overhead imposed on workers due to multitasking, interruptions, or other cognitive disruptions.

  Some studies have pegged this value at an average of 23 minutes and 15 seconds per interruption. Jobs with higher cognitive load suffer more from disruptions to flow, so you may find that IT projects suffer from this more than construction projects, but your mileage will definitely vary.

• The amount of creativity required for tasks.

  Creative work is not an assembly line. You can't turn creativity on and off like a water tap, and projects that involve novelty, idea generation, or creative problem-solving are likely to yield only a couple of productive hours per day on average.

• The process maturity of the team.

  Teams require time and effort to develop processes and learn to work together effectively. Some people refer to this as the "Forming, Norming, and Storming" stages of teaming, and frameworks like Capability Maturity Model Integration (CMMI) attempt to label levels of maturity. New teams and processes can require a substantial amount of overhead to get up to speed, and targeting 40%-60% productivity at the start is often an aggressive but attainable estimate. You can refine this figure over time, but I would personally lack confidence in a schedule that estimated initial productivity any higher.

Schedule Estimation is an Art Form

Your best bet is to find a fudge-factor that gives you at least 80% confidence in your schedule based on a team's projected capacity. Build in enough slack for overhead and contingencies, but don't fall prey to Parkinson's Law by radically underestimating capacity, either.

Finding the balance is somewhat of an art form, rather than a rigorous science, because you have to base your estimates on statistical probabilities within your organization and given your resources. Productivity and efficacy in any problem domain vary widely between groups, so looking for a universal constant will invariably result in disappointment.

An iterative approach to capacity/productivity estimation is often best. Start out with an achievable target, and refine your scheduling estimates over time. This is very much the agile approach used by Scrum and Kanban, but can work with more traditional approaches as well.

Answer 2

80% is the figure I have always heard, although trying to find internet citations that support that figure is surprisingly difficult and, in fact, I wasn't able to find any!

I have flip-flopped in how to manage this within the sphere of project planning and scheduling. If you are using MS-Project then, on the surface, it seems obvious that you would set the working day to the full hours and use Max Units to define the productive percentage. Somehow, for reasons I cannot fully understand, I have never managed to make a plan track reality very well using this method.

These days I ignore it and plan at full days, but use estimates that already take into account daily productivity thresholds (i.e. if we say a task will take 5 days in the plan, that is five days including time lost to non-productive activities). This seems to work well for me, though that is perhaps based on two effects:

• I am very used to working with this method
• The tasks I plan are typically measured in (~ >3) days rather than hours

I have also had some robust and brutal arguments with senior management in my career, about the fact they believe workers should be 100% productive from start of day to end of day. Rather than have those arguments on endless repeat, I found it easier on my sanity to include non-productive time in the task estimates, thereby "hiding" the effect. Since senior management never had any idea how long a task should take, they were just happy I was applying resource at 100%. Win-win. 'Twas ever thus.

Answer 3

The best suggestion I would offer to anyone asking this is to ask each team member individually what they want to sign up for. Check in weekly to see if there are changes they want to make to this going forward as their default or on a "I'm at 0% since I'm on PTO" type of feedback. There are a few reasons for this:

1. Gets the individuals bought into the assumptions that are being made in the plan. It also gives you the opportunity to reinforce that this is a "plan" and we are just looking for the best assumptions we can make.
2. It allows you to get feedback and a discussion going for things that might be able to impact the amount of time they can commit. Maybe it is other projects encroaching (valid or invalid) or maybe it is something you weren't aware of as impacting certain team members.
3. It reflects the reality of different people have different pulls on their time. More Senior folks might have multiple cross department/project responsibilities or participate in strategic planning. More Junior members may in fact be distraction free.
4. Improves the data collection and gives you something to act on. Is 7.5 hours a day "good"? If you see if being more like 5 hours, you have the option to take action.
5. Just about any tool you use can support allocation of this on an individual basis.

All of the above is assuming you are running an active project. For planning purposes without a team I would suggest adding this level of detail is likely an unnecessary step unless you are paying hourly (either to the individual or as part of some department allocation/resource cost tracking system). You pay people for a full day so estimating in the abstract is likely all that is required.

Answer 4

While this is opinion based, I don't find having a parametric around utilization to be valuable in planning and estimate. Everything's probabilistic. Resource utilization will range from something as low as zero to higher than 100% for hyper performers; size of staff will vary; hours for work will range from a min to a max; and duration will range. They play off each other with some correlation but also have a lot of random drivers at play. And in many cases where you have a seller-buyer relationship, it doesn't even matter because the project team member will charge full-time to the work no matter if they are turning wrenches, attending meetings, or talking by the water cooler.

You just need to have the understanding that your team works productively something less than full-time so that you can build in contingency. Using the same parametric may increase your precision but does nothing for accuracy. Sometimes you need more, sometimes less. Base this on your overall risk assessment for that team for that project at that time.