Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.
In my last post, I wrote about the importance of a project schedule plan and the fact that a project schedule is generally constrained by various factors. In this post, I'll take a deeper dive into the three techniques that can be applied to address resource and time constraints.
This technique can be applied to a project's schedule plan when the project is facing resource constraints or when you need to allocate resources consistently and most effectively throughout the life cycle (e.g., all resources utilized at 100 percent capacity by project completion). You'll need to apply this technique when resources are available only for a certain time or when you have resources over-allocated in parallel project activities.
The basic idea behind resource leveling is to recognize tasks, priorities, dependencies and constraints. Tasks with the highest priority will be scheduled first. Others, depending on their dependencies and constraints, will be moved for later or assigned other resources available during this time.
Logically speaking, resource leveling is applied in this order:
Develop the schedule.
Consider work tasks, dependencies and constraints.
Identify the critical path of your project schedule.
Once you have identified resource bottlenecks and over-allocated or under-utilized resources, set task priorities and apply resource leveling. In some cases, resource leveling can lead to critical path changes -- for instance, if you have to extend the duration of a task on the critical path, due to the reduced availability of a critical resource.
This is a schedule compression technique for dealing with time constraints without sacrificing project scope -- for example, when you have to meet a hard deadline for one of your project's deliverables.
This technique focuses on the tasks on the critical path. Shortening them reduces the total duration for meeting a given deadline or milestone. And delivering a project in its entirety, with no scope change, in a reduced time can only be achieved by increasing or improving the resources allocated for that task.
As an example, let's take a software project aimed at creating a new system, and migrating functionality and data from an older system. You could reduce task time by allocating more programmers to develop in parallel the functionality of the new system. Similarly, to shorten the data-migration time, you could replace a regular computing machine with a more powerful one.
Be aware that crashing the schedule will generally increase costs. And sometimes, there will be tasks that will have the same duration, no matter how efficiently they can be performed (e.g., monitoring the stability and reliability of a component for a fixed time).
This is another schedule compression technique that can help reduce project time without changing the scope. The focus of fast-tracking is on expediting certain tasks by overlapping their execution, despite their dependencies.
Let's take the same software project as an example. Chronologically reversed, programming the new functionality (task number one) depends on designing it first (task number two), which depends on a gap analysis task (task number three). By applying fast-tracking to these three tasks, instead of executing the tasks in a sequence, you can overlap them. You can start the design (task number two) in parallel and lagged with the gap analysis (task number three). Similarly the programming (task number one) will start lagged while the design (task number two) is in execution.
Fast-tracking is one of the most-used tactics to deal with time constraints, but it does have a few downsides. By not waiting for the complete results of preceding deliverables, fast-tracking could lead to delivering lower quality or even reworking some tasks, which can result in additional costs and delays. The project environment can get very dynamic with tasks conducted in parallel. This can be a challenge for project managers, who might lose sight of the bigger picture or get overwhelmed with managing overlapping activities.
What is your experience with these techniques? Which do you think is most effective?