Schedule network model and critical chains

In this article we will continue to consider the difference between the schedule network model and the schedule network schedule and talk about the critical chains of the project. And also about how the critical path method differs from the critical chain method.

Everyone knows that there is a critical path in the schedule, that it is necessary to monitor the work that is on this critical path, but there are a number of nuances that can turn the critical path into an empty formality. In discussing today's topic, I will rely on graphic materials from the company's training courses PM Expert and on copyright materials, which I also use in my courses.

So let's start with the "legends" of the critical path. Which of them immediately come to mind? Well, at least the two most common ones:

1. There can only be one critical path in a project;
2. The critical path does not change as the project progresses.

What can you say? Firstly, there may be more than one critical path in a project. There may be two, three, or more, depending on how many technological chains you have planned in your schedule network model. Secondly, the critical path lives a dynamic life within the project life cycle and can change even daily, provided that you enter actual data on the execution of work in the schedule network model on a daily basis and recalculate the model. Sometimes it is interesting to observe a situation when in the office of one or another project team there is a project schedule printed in color on the wall on the wall, with the critical path highlighted in red, and the project team has been monitoring the progress of its project along this critical path for almost a year. Of course, this is the wrong approach.

What nuances do you need to pay attention to when building a schedule network model and further working with it in order to be sure that the signals that you and I receive from our CCM are really correct? Of course, it is desirable that all tasks in your schedule network model have predecessors and successors. If it is not possible to link them to an explicit task/work, establish a connection with the milestones of the beginning or completion of the project, or other intermediate milestones of results. Try to use as few connections as possible with advance or lag - they interfere with the accuracy of the calculation. And of course, it is considered "bad form" to use strict restrictions on tasks ("nailing them with nails"). If the specified conditions are met, you and I can be sure that the critical path is built correctly and we receive the correct signals from the schedule network model. All this is true if the rules for determining predecessors/successors are observed, that is, if the technological interdependencies between the tasks/work of the project are correctly determined.

Now let's look at the difference between the critical path method and the critical chain method. The key difference corresponds to the difference in the definition of a schedule network schedule and a schedule network model. Remember in previous article? "A network schedule is a tool for planning the timing of a project, which operates only on the start (completion) dates of project tasks and the duration of execution of these tasks. Taking into account technological interdependencies between project tasks. The schedule network model, in addition to the approaches indicated for the schedule network schedule, also uses information on project resources, cost parameters of project tasks/work, uses the critical chain method in its construction and is built using specialized software." We remembered this. And since we're talking about the critical path method or the critical chain method, let's look at their differences with examples...

Figure 1.

From the definition shown in Figure 1, we see that the critical chain method already operates with the concept of resources. What does it mean? Let's go ahead and look at Figure 2.

Figure 2.

Let's imagine that we have a project under management consisting of 10 tasks/works, and we must build a schedule network diagram for this project. Using the method of determining early start and finish dates, as well as late start and finish dates for project tasks/work, as well as understanding technological sequences and having data on work durations, we build a project network diagram. Now we at least already understand that our project has a duration of 13 days. And we can observe that those tasks whose early and late start dates are equal to each other, as well as the early and late finish dates are also equal to each other (that is, these are jobs that do not have a reserve) - these jobs are the jobs of the critical path. It is highlighted in red. Now you and I are simply obliged to pay attention to these works when managing the project, because we understand that increasing the duration of any of the tasks/work on the critical path by at least one day (!) will lead to an increase in the implementation time of the entire project by at least this one day. Great. We looked. They accepted the job. But let me remind you that we are currently working within the framework of creating a schedule network schedule and are only operatingdates, durations and technological relationships. Something is missing here... Maybe we can try to assign the resources we have to work and switch to the mode of working with the schedule network model? We decided - we did it. Let's look at the results of our activities in Figure 3 using the schedule network model.

Figure 3.

We can observe that while assigning resources, we are faced with a problem where two of the jobs that need to be executed in parallel use the same resource. And we are already working using the critical chain method. Let's look at Figure 4.

Figure 4.

Figure 4 shows in detail the hourly load of our resources on project work. Yes, we wanted this work to be completed in two days, but we have limitations on the "Analyst" resource - we only have one. And now we are faced with a dilemma regarding our options for responding to this situation. There are two main options for action: either purchase another "Analyst" resource for this day, or parallelize our work. Let's imagine a hypothetical situation in which there are strict restrictions on the project budget, so we do not have the opportunity to attract another analyst. What to do in this case? Then, in accordance with the proposals shown in Figure 4, we will be forced to parallelize our work and increase the duration of the project. Will there be changes in our critical chain? How will the duration change? Let's look at Figure 5.

Figure 5.

We are observing a situation in which the duration of the entire project has increased by that same one day, and the critical chain has been rebuilt. Now the duration of our project is 14 days. And a new list of project tasks/work appeared that required priority attention from the project manager and the entire project team. What if we didn't assign resources and worked relying on the good old "Maybe"? This is precisely why it is useful to use the schedule network model of the project in your work. Use the critical chain method. It is then that we can be confident in the correctness of the signals that the schedule network model gives us.

It is important to understand that although the schedule network model is exactly the tool that allows us to adequately manage our project and read signals, this is not all the practical benefit of the schedule network model. Let's take a closer look at Figure 5 again. We see a new critical chain, which now passes through different activities than in Figures 2 and 3. We understand that these activities are now the highest priority. Let's imagine a situation where problems arose with resources for timely completion of work on task "C", for example, one of the employees fell ill. Let's look at this in Figure 6.

Figure 6.

Please note: tasks/jobs "C" and "D" are now executed in the same time periods. Only task "C" lies on the critical chain, and any shift in its start date or duration will affect the completion date of the entire project as a whole, and work "D" has a reserve of 2 days. I can start it (at the earliest) on the 4th day, or I can (at the latest) start it on the 6th day, and nothing will happen to the project. The main thing here is not to get carried away and not start on day 7... Then work "D" itself will already enter the critical chain and change the completion date of our project. Thus, having data on the reserve for task "D" of two days and assuming that this work uses the same resources as task "C", I, as a project manager, have every right and opportunity to at least completely stop the execution of work "D" within the early start and finish dates, transfer these resources to work "C", finish it beautifully on the 5th day (according to our model), take resources from it and on the 6th day put them back on work "D" and thus save the project from violation deadlines. But what does it take to be able to navigate like this and really get the right signals? A few keypoints:

1. A well-constructed schedule network model: without "studs", without the absence of "predecessor-successor" connections (that is, without open-ended work), without resource conflicts.
2. Using the critical chain method to determine priorities for project work.

But this is not all the benefit that the project team can get from the schedule network model. And more about this in the following materials.