Overview
Project Leaders need to have confidence their project timelines can be achieved in the time frame they have allocated and they need to be able to discover potential overloads as early as possible so they can bring them to management’s attention for guidance and resolution to avoid unnecessary delays.
Managers need to ensure morale is high - team members have reasonable expectations and do not feel overwhelmed. Managers also need to have confidence when team members will be available to support other projects.
The Overload Impact Report (OIR) provide exactly this information.
Each row is a team member and each column is a week.
By default the report looks two weeks into the past and eight weeks into the future for tasks with Planned and Active lifecycles (no Completed, Archived or Sandbox tasks). Ideally there should be no Planned tasks planned to start in the past and there should be no Active tasks that end prior to today that are not marked complete, so any "loading" in the past two weeks tells you immediately there are out-of-date tasks in the past two weeks which is a call to action.
The percentages shown represent the team member's loading for the week and are either based on the team member's capacity (typically 8 hrs/day) or availability (typically 4 or 5 hrs/day but varies by role).
In this example, after John Doe's name is the text "NA/8". This means that John's availability has not been set by an administrator therefore the percentages are based on his capacity (8 hrs/day).
When John's availability has been set by an administrator, it is shown after his name and the percentages are based on his availability (4 hrs/day).
To set a team member's availability, an administrator must enter the following in the Resource's IMAddress field... e.g., "Availability=4".
Since availability varies by role (and can vary a lot), it is recommended to set every team member's availability so that the report is more accurate and useful.
Just because a team member's loading for a week is over 100% of their availability, does not necessarily mean it will delay the project. It depends on the criticality of the work, e.g., if John Doe is loaded 150% this week and it is all Normal criticality (yellow), that means that all of his tasks have at least 5 days of slack (probably more), therefore if 50% of the tasks were delayed one week, it is likely that none of his tasks will become critical and there will be no impact on the timeline. So, the goal is to assess how likely projected overloads are to impact the timeline and to then take action where it looks likely and keep an eye on the rest. Because projects are dynamic and complex, team member loading should we reviewed regularly as part of the rolling wave planning process, weekly or bi-weekly.
Overloading Guidelines (% of Availability)
A team member is overloaded and it is likely to impact the timeline if...- For any 1 week, 100% or more Critical (pink) tasks
- For 2 or more consecutive weeks...
- Avg. 90% or more Critical (pink) tasks or...
- Avg. 100% or more Critical (pink) & Near Critical (orange) tasks or...
- Avg. 100% or more Total AND Avg. 30% or more Critical (pink) & Near Critical (orange) tasks
- For 3 or more consecutive weeks...
- Avg. 100% or more Total even if they are all Normal (yellow) tasks
There should be no tasks with unknown slack (brown) in the next eight weeks because there is no way to know how they contribute to this loading criteria therefore no way to know how likely they are to impact the timeline.
If a team member looks overloaded, first review and revise their hours of work estimates with the team member ,especially Monitor and Shared tasks as they often have too many hours of work allocated.
To quickly see a team member's loading by criticality, use the Criticality filter. For example, I can quickly change the percentages to be based on any Time Off and Critical tasks only.
Now, only the loading of Time Off and Critical tasks are shown.
The report can be customized using Report Settings.
