Which of the following is a viable method for working with resource constraints

By definition, the Critical Path includes the activities with zero Total Float and therefore a delay in any of these activities will cause a delay to the project’s planned completion date.

Total Float is the amount of time that an activity can be delayed from its Early Start without delaying the project finish date. The activities with shorter floats are more critical than those with a longer one.

Early Start is the earliest possible date on which an activity can start, based on the schedule network logic and any Schedule Constraints.

Schedule Constraints include resource constraints, finance and supply constraints, calendar constraints and imposed dates. The word any here makes the difference: the float should be calculated with all schedule constraints, including those deriving from resource usage, and not only with those deriving from the network sequence logic.

Most project management software programs do not calculate true activity floats because they do not consider resource constraints during the backward pass. as the availability of resources is completely ignored.

The resource dependencies is at the core of the Critical Chain Method, a scheduling techniques alternative to the Critical Path. The Critical Chain is the sequence of both precedence- and resource-dependent activities that prevents a project from being completed in a shorter time, given finite resources. If resources are always available in unlimited quantities, then a project's critical chain is identical to its critical path.

The main features that distinguish Critical Chain from Critical Path are:

• Resources are required to be flexible in start times, and be able to quickly switch between tasks and task chains to keep the project on schedule.
• Activities are scheduled using the Late Start dates, and their duration is estimated in an aggressive way, padding is forbidden.
• Use of (often implicit) resource dependencies. Implicit means that they are not included in the project network, but must be identified by looking at the resource requirements.
• Lack of search for an optimum solution. A "good enough" solution is enough because:
• there is no analytical method for finding an absolute optimum
• the inherent uncertainty in estimates is much greater than the difference between the optimum and near-optimum
• Identification and insertion of buffers (project, feeding and resources).
• Monitoring project progress by monitoring the consumption rate of the buffers rather than individual task performance to schedule.

Not all organizations are ready to switch to such a different scheduling approach: in particular, the late dates, the aggressive estimates and the buffers are concepts too hard to be introduced. I therefore believe that the Critical Path Method is still the most viable scheduling approach, but effort must be spent to introduce at least the concept of a Critical Path driven by resources dependencies.

Allow me to introduce the Resource Driven Critical Path: its calculation is similar to the calculation of the traditional Critical Path with the exception that both the early and the late dates are calculated during forward and backward pass only after a resource levelling has been performed. Analogously, floats calculated this way are called Resource Driven Floats.

Let’s start with an example.

We have three activities: A1 and A2 both performed by Ra and with a 5 day duration, and A2 performed by Rc with a 15 day duration. There are no sequence dependencies between the activities, so all start at the same time. It is easy to calculate that both A1 and A2 have a float of 5 days, while A3 has no float and is therefore on the Critical Path. In the Gantt chart below we are also displaying the late start/end dates for A1 and A2 (by definition A3 has late dates equal early dates).

From the picture above it is obvious that there’s a conflict for resource Ra, so leveling is necessary. Among the many leveling options, let’s decide to have A1 executed first:

The situation has considerably changed: now A1 and A2 are on the (Resource Driven) Critical Path, and A3 has a (Resource Driven) Float of 5 days. In addition the end date of the project has slipped of 5 days.

Below we have another example: on the top schedule all activities are on the Critical Path; after solving the conflict on resource Ra the (Resource Driven) Critical Path is formed by A1-A5-A9.

In the above examples I have highlighted also the Late Start/End Dates of the non-critical activities: I believe that, although the Critical Path Method schedules and monitors the activities on the Early Dates, it is still necessary to monitor also the Late Dates of the non-critical, as a warning sign. After all, a non-critical activity can be delayed without consequences as long as it will finish not later than the Late End Date.

To conclude, using and aggressive and optimistic duration estimation for the activities, could be a little risky if buffer are not used: I would advise to estimate using the typical PERT 3-point weighted estimation, to mitigate uncertainties.

UPDATED 1

While discussing the above approach on a LinkedIn thread, I felt the need to further elaborate on the subject, so i will briefly describe how I would normally proceed.

First thing first: we create a WBS down to work package level.

Second, we create a sequence diagram for the work packages. This second step will also help us in understanding if the granularity of the work packages is enough: if we realise that a start-end constraint between two work packages (let's say WPa and WPb) is not between the last activity of WPa and the first activity of WPb, but between two internal activities, than we may want to further split the work package (one of the two or both).

The sequence diagram will give us the critical path but, as explained above, this does not take into account the resources constraints. So the third step would be to create the Gantt chart and do resource leveling: the latter is easier to perform on Gantt chart than on a sequence diagram. Once done with the resource leveling we will get the new critical path, that is what I call Resource Driven Critical Path.

Be careful how you model resource constraints.

In MS Project we have three options

1. put a sequence constraint between the two task where you have the resource constraint
2. force start date of the task to be delayed due to the resource constraint
3. use the Leveling Delay field on the task to be delayed due to the resource constraint

I deprecate, like many, option 2.

Many suggest option 3, as it keeps separate the sequence constraint from the resource constraint. The problem is that this is not reflected back into the sequence diagram as Leveling Delay field is not part of the sequence diagram method, so if we change scheduling tool you may loose the information.

With the price of a little burden, we could use option 1 and add a custom column named "Resource Driven Predecessor" where we repeat the task ID of the predecessors due to the resource constraint only. This way under the standard "Predecessors" column we will see the IDs of all predecessors (sequence driven and resource driven) and under the custom "Resource Driven Predecessor" column we will see which of the previous IDs are due to resource consraints. This is an important distinction to make, as both constraint may change and you need to know which predecessor is what.

UPDATED 2

To clarify the difference between ASAP and ALAP scheduling, and how ALAP scheduling can be mitigated by a buffer, I am adding two very easy examples. I am not going to consider resources here, to focus mainly on ASAP vs ALAP.

Say we have two tasks A and B, to be executed one after the other.

The next figure compares ASAP vs ALAP without buffer usage and shows what happens when activity A has an actual duration less than what originally planned:

It is obvious that in ASAP you have no gain in finishing A earlier, while in ALAP you finish B earlier, given that in CCM tasks duration do not contain padding and therefore last less than in CPM.

Of course people could argue that you could shift starting date of task A a lot earlier. In practice this is what happens when using buffers that are calculated according to a well defined formula. The following figures shows the introduction of the buffer:

Now in CCM if actual duration of task A is less than planned, the gain in time can be added to the buffer, leaving more margin in case B will last longer than planned. If duration of B will last as planned and no buffer is used, the project will indeed finish a lot earlier: see how with usage of the buffer the project in the second figure finishes earlier than in the first figure.