Playbook_Logo.png
Free Trial
Watch Demo

Eric Graves

Aerospace and mechanical engineer turned NPD systems engineer, Eric spends his time engineering better product develop systems, using PLAYBOOK as his tool of choice!

Search Result

Posts containing:

Project Management Resource Leveling for Hardware Teams - It's Critical!

Eric Graves- 08/30/16 06:05 PM

What is Resorce 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...

Preventing resource conflicts (overloads) in all of the right places has a huge impact on the throughput of the system (and profit). With the right level of visibility into resource conflicts, we gain a lot more power to control our development system and keep product production flowing. But how easy is it to see where all of the right places are?

(I’ll refer you to Don Reinertsen’s books, Managing the Design Factory and The Principles of Product Development Flow: Second Generation Lean Product Development, for a more in depth discussion on Flow!)

 

Screen_Shot_2016-08-30_at_11.41.02_AM.png

 

 

Basic tools offer the ability to see where resources are overbooked on an hourly basis, relative to an assumed availability of 8 hours a day. In most cases, planners in those tools load resources with project tasks up to "full time," for 7 or 8 hours a day, per resource.

The amount of the resource’s time that will be consumed by meetings, interruptions, various production-sustaining activities, CAPAs, and many other activities is often not accounted for, or drastically underestimated. As a result, people are overloaded and project schedules grow much longer.

Effective resource levelling starts with seeing resource conflicts, but doesn’t stop there

As an example, there may be two full-time activities that overlap that are scheduled to be completed by one person, during the same week. In order to resolve this conflict, the project team needs to first be aware of the conflict, then decide what to do about it. For example, they can choose to:

  1. Add an additional person (Cost impact);
  2. Schedule the tasks consecutively (Time impact); or,
  3. Drop the task altogether (Scope impact).

In order for project teams to make these decisions effectively, the project's objectives need to be clear. In addition to this, resource constraints need to be easily visible, to the right level of granularity and continuously monitored by the team.

So what is the right data? Resource loading issues need to be visible far enough into the future to maximize mitigation options.  In terms of data granularity, we believe teams need to be able to see information by type of task and task criticality.

Not all tasks are created equal

To get a clear and accurate measure of people’s true availability and see the overloads accurately, we’ve found it easy and effective to identify these 5 types of tasks.

  1. Time off/vacation/holidays
  2. Ongoing (e.g., misc interruptions, production support, other regular activities)
  3. Meetings
  4. Monitor tasks (e.g., parts procurement)
  5. Work based tasks (e.g., design the subsystem, draft the test protocol, develop structural model)

In terms of resource leveling and highlighting resource loading issues,work based tasks are most important. This picture shows the large impact the resource’s availability has on the duration of a typical work task, especially when that availability is under 50%.

 

Resource_Overload.png

When we are multitasking across multiple work tasks, or our capacity is filled with meetings, interruptions, and other types of tasks, it is the work tasks which grow and extend our project durations. An accurate measure of availability to complete work based tasks is critical to both accurate project schedules, and our ability to manage availability and stay on schedule. This is especially true for those resources which are on the "critical chain." 

Why a tasks criticality is key

Understanding where critical tasks are at play in resource overloading is also, well, critical. For example, Jack may have several tasks to be completed in one week (showing overload in a standard reporting function), but they may be non-critical tasks. Moving one task after the other probably won’t delay either project, so there is no need to cut scope or get more resources to avoid a delay.  On the other hand, it may be the case that Sue is assigned overlapping critical tasks, which indicates an almost certain delay in one project or the other, or both.

In this scenario, it's critical for the team to take action and resolve overloading on Sue's critical tasks. Jack's overloading it not a priority.

In both cases, the team needs to see this situation so they can act on what is critical.

Conclusion

Ultimately, it’s the job of the project team, the project manager and management to keep work flowing so as to not impact time, cost or schedule. They can do their job effectively when they have the right information at their finger-tips, at the right time. This means understanding loading, not just on an hours-per-day basis, but by task type and criticality.

 

Want to know more about PLAYBOOK's resource loading reporting capabilities?  Please get in touch!

 

I have a few more questions. I'd like to request a call.