Resource loading is a critical project metric. Get it wrong and you could inadvertently commit to a seriously unrealistic project launch date. Overloading people with work can quickly double or even triple your project timeline.
The good news is that with the right tools it's relatively simple to understand the load on project resources within and across projects...
Setting realistic loads on people's time makes for a much more productive, efficient and positive work environment.
What is resource loading?
Resource loading is your total assigned hours of work divided by the number of hours you have to do the work. Resource loading is looked at on a per day, per week, per month, or per the duration of the project basis.
Resource loading = hours of work per time period / hours of capacity per time period
For example, as project managers we expect a resource loaded to 75% to complete 30 hours of planned work each week (40 hours of capacity), or 6 hours a day. The other 10 hours that week is expected to be spent doing other stuff that isn’t in the plan, or isn’t related to the project (e.g., training, department meetings, etc.).
Resource loading vs. resource leveling
Resource leveling in and across projects is traditionally defined as:
“The process of using a company's resources in the most efficient way possible.”
However, high efficiency is the same as high utilization, which generally results in low throughput, and throughput is where the profit is...
To be at all useful, project plans must first be based on realistic estimates for both the work (effort) to be done and duration. The most effective teams plan together in an appropriate amount of detail to ensure they’ve accounted for all the foreseeable work that needs to be done, the unplanned work that regularly materializes in the ever-changing world of product development, and which resources are needed to do all of this work.
Visibility of issues before they occur is critical — certainly where people’s workloads are concerned.
How to calculate resource loading
There are two options
- estimate all the work needed (each day) and divide by the resource’s full capacity (8 hrs per day).
- Alternatively, estimate the work needed on the project tasks and divide by the resource’s availability to do those project tasks (usually much less than 8 hrs per day).
Either way, you must account for time that isn’t available for completing the project tasks in your plan including:
- project-related meetings and ad-hoc discussions (which aren’t included in the plan)
- regularly scheduled staff meetings
- work that the person is assigned to on other projects
- time spent supporting products that have already launched
- vacation time
- even bathroom breaks, and a lot more.
In fact, the more diverse a person's activities are, the more time is added in the form of switching costs which are also quite significant. These other activities are largely unavoidable, and often take priority over project tasks. The time left for our planned project tasks is almost always a lot less than we planned for.
Interested in understanding more Lean-Agile Principles? Check out our free Lean-Agile training on Playbook Academy such as Rolling-Wave Planning, Applying Agile to Hardware and Critical Chain Project Management.
Some examples to demonstrate the negative impact of overloading resources
The length of time it takes someone to complete a task is a function of the total work required to complete it divided by their availability to perform that task.
Duration (days) = Total work (hours) / Availability (hours per day)
For example, if you have a 12 hr task and 4 hrs/day to work on it, the task takes 3 days.
And if you are looking across a whole project team, simply put, your project duration is the sum of everyone’s work divided by the sum of everyone’s availability. However most activities require specialized resources, so project duration is often determined by those people who have the most work to do, relative to their availability (the critical resources).
How much should you load a resource?
How much you load a resource depends on two very important factors:
- First, how much you may have underestimated the number of hours needed for project tasks; and second
- how much you may have over-estimated the resource’s availability to work on those tasks. Let’s start with the latter.
Let's look at what can happen by using an example scenario. Let's say you have the work estimated correctly, and are expecting a person will be available to do the estimated work for 6 hours a day.You've planned for 6 hours of work to take one day, and every 30 hours to take 1 week.In this scenario you are starting with a resource load of 75%.
But then something happens (insert usual fire to put out!) which impacts the person's availability to work on the project. The project timeline is impacted -- but the impact may be more than you think.
For example, when the person's availability to work on the project work is reduced to 4 hours a day (50%) for the work week, the person will only be able to complete 20 of the 30 hours that had been planned for them. If the following week the resource's availability is still reduced to 4 hours, that week of work will take 8 days. The result is a 60% delay due to a 25% overestimate of a person's availability. And to make matters worse, even if a resource gets back to their usual 6 hours a day the following week, they are still 2 days (10 hours) behind.
If we keep playing this out, the resource would need to complete the entire next week’s worth of project work (30 hours) and the remaining 10 hours of the previous week’s work. And don't forget they may still have 10 hours of unavoidable ‘other stuff’ to do each week for a total of 50 hours that week. 2 extra days of work.
The result... Bye-bye weekend. See you later family? In reality, the project gets delayed, because weekends and evenings with family and friends are important too.
Why is resource availability important?
If the impact on the project was just one week, that may be ok, but when we chronically under-estimate people’s availability it ultimately impacts our timeline. For every day the resource spends a couple of extra hours in meetings or firefighting production issues, etc. they must spend one full 8 hour day only on the planned project tasks to keep the project on track. But we end up losing a couple of hours more than we expect quite often, and almost never get the chance to make it up.
Underestimating resource loads impacts the timeline
Compounding the delays from underestimated availability, the actual hours spent on the project will almost always be more than what we have planned, because some of those planned tasks will be more work than we thought, and because there will be some surprise tasks we can’t really see coming which aren’t in our plan.
Inaccurate resource loading increases risk
When there is a time-crunch on a project due to any of these factors, people take more risks, which just ends up being more work and more delay later (not to mention extra stress).
The resulting ‘work growth factor’ is usually between 20% and 60% but it is very often a lot more. So, if there is a 33% work growth rate, you must reduce the resource’s expected loading an additional 33% (of what you think it is to begin with) or you create the time-crunch and probably still delay the project.
We recommend resource loading at 50% to 60% of availability
In summary, it's far better to plan for resources to have less availability -- and more work than you think. Where most companies assume 75% availability is about right, from our experience, 75% is much too high. On the order of 50% or 60% availability is a better place to start – until you get real work-growth data and can start incorporating that expected growth in the ‘planned’ work that is part of your planned loading.
And if it turns out you are under-estimating people’s availability, or over-estimating the work-growth, you can always get the project done early!
Conclusion
In conclusion, you can compare loading to a running race. If you expect a person running a race to go faster than they can, they end up burning out and/or faltering along the way and getting done later than they would if you expected them to run it at a reasonable pace.
When you consider that the road of product development is really an obstacle course and you don't get to see all of the obstacles beforehand, the only way to run this race effectively is to reduce people’s loading – plain and simple. Finding the right pace isn’t difficult, with the right tools. Without them, it is a bit of a guessing game, and we usually guess wrong.
Plan well and ensure people have realistic workloads. In the end the team will be happier and the project will run on time -- or launch early.
Related Posts
Resource LevelingResource Management
Daily stand up meetings - and free meeting agenda
Critical Chain project management
Task Management
Pull vs. push task management
