Hello my friend,

Recently we’ve talked about tracking the project’s performance based on earned value management system, which show real and objective image of you project’s success comparing to its baseline. In this article I will show you one of the two most widely used ways. Let’s go!

Disclaimer

Probably the consequence of the articles isn’t logic but it doesn’t matter. I’m not following PMBOK Knowledge Areas one by one, as it’s stated in the standard. I’m just writing about topics, what I feel I can describe more deeply and interestingly right now.

What does it mean, “scheduling”?

In general scheduling means the process to establish the schedule of the project. The more formal definition for this is “develop schedule”, which is actually one of the seven Processes that form together Project Time Management Knowledge Area of PMBOK. Let’s look in the standard for references:

Develop Schedule is the process of analyzing activity sequences, durations, resource requirements, and schedule constraints to create the project schedule model. The key benefit of this process is that by entering schedule activities, durations, resources, resource availabilities, and logical relationships into the scheduling tool, it generates a schedule model with planned dates for completing project activities.

Sounds great, doesn’t it? This schedule model upon approval creates schedule baseline, which basis for tracking performance (recon what we have discussed in the previous article about earned value management).

Before I show, how critical path method works, I’ll briefly review the types of sequences that we have in project management according to PMBOK Guide.

What influence the type of sequence?

There are four types of relationship between activities, which shows when the successor activity should start based on the finish of predecessor activity. Here they are:

• Finish-to-Start (FS) means that the successor activity starts after the predecessor activity ends. This is usually the most used type of activities’ sequence.
• Finish-to-Finish (FF) means that the successor activity can’t finish until the predecessor activity ends.
• Start-to-Start (SS) means that the successor activity can’t start until the predecessor activity starts.
• Start-to-Finish (SF) means that the successor activity can’t finish until the predecessor activity starts. This is the least used type of sequence.

Formally this staff relates to Precedence Diagram Method, which is tool of Sequence Activities Process that is also part of Project Time Management Knowledge Area of PMBOK. The definition of the process from the standard:

Sequence Activities is the process of identifying and documenting relationships among the project activities. The key benefit of this process is that it defines the logical sequence of work to obtain the greatest efficiency given all project constraints.

For more references take a look into chapter 6.3 of PMBOK.

Stop theory

I have neither goal nor desire to rewrite the PMBOK in my blog. My objective is to provide you good understanding of these things by landing theory to the practical examples. In my opinion, “Learn by hands” is the most useful and efficient way of learning something.

How to map relations between activities?

Let’s return to our project from the previous article, where we’ve already developed the WBS dictionary with list of activities. For your reference I provide it again.

Based on this list we need to find way how to sequence our activities. Obviously the most straightforward way to build our activity diagram (officially called Project Schedule Network Diagram – PSND) is just to sequence all the activities in FS manner

Probably you are already familiar with such representation of activities, which is called “Activity-On-Node” or simply AON. Let’s briefly look into these numbers:

Here are the definitions:

• Activity ID is the number of activity as it’s stated in activity list or WBS dictionary
• Early start – the earliest possible point in time (date), when the activity can start. Usually it’s counted in days, but in our case it’s hours. This remark is also applicable for all other fields described below.
• Duration – the amount of time needed to accomplish activity. In our case it’s provide in WBS dictionary.
• Early finish – the earliest possible point in time (date), when the activity can be finished.
• Late start – the latest possible point in time (date), when the activity can start without delaying the finish date of the whole project.
• Total float – the amount time, which can extend the duration of activity or delay its beginning without delaying the finish date of the whole project.
• Late finish – the latest possible point in time (date), when the activity can end without delaying the finish date of the whole project.

The first four definitions should be clear to you, whereas the last three can be confusing at the moment, I guess. There is no problem, we’ll return to them later.

At this point we’ve already built the PSND for our project and can find critical path. Well, we have only one path across all our activities, and in my opinion we could call it critical path. Let’s take a look at the formal definition of critical path (PMBOK 6.6.2.2):

The critical path is the sequence of activities that represents the longest path through a project, which determines the shortest possible project duration.

So our path is the longest path and it show also the shortest possible time to finish the project as well. On the other hand our project schedule network diagram is linear and doesn’t provide any possibilities for deviation.

Compression and speeding up the project – fast tracking

In reality this linear PSND is simplification, because usually you have different work packages that can be done in parallel. We are considering just one work package in details, but even here we can do some activities in parallel. The first requirement for such parallelism is that different persons accomplish different activities. It’s obvious, but for the sake of consistency I mention it.

The second requirement comes from dependency’s type (PMBOK 6.3.2.2). The two most important types of these types for us now are mandatory and discretionary dependencies. The difference between them is that mandatory one must be met in any case, whereas discretionary one can be relaxed if it’s needed.

In Project Time Management there are several schedule compression techniques, which allows you to shorten the overall timeline of the project. One of them I’ll introduce right now, which is called fast tracking. It’s described in PMBOK in point 6.6.2.7:

Fast tracking. A schedule compression technique in which activities or phases normally done in sequence are performed in parallel for at least a portion of their duration. An example is constructing the foundation for a building before completing all of the architectural drawings. Fast tracking may result in rework and increased risk. Fast tracking only works if activities can be overlapped to shorten the project duration.

This is applicable only if there are discretionary dependencies, which you can remove. For sure you can’t remove mandatory dependencies, because it’s just impossible. In my opinion fast tracking requires the project manager good understand the field, where he manages the project. Such understanding comes either with experience or though consulting the subject matter experts (SME).

Let’s analyze the list of activities from our work package. It looks like that workers can make dismantling activities as well as they can move furniture before you buy the necessary materials, right? But to do it, they must be already hired, what in our current list comes after purchase of materials. Let’s update the list of activities and build new project schedule network diagram considering all the provided ideas.

Now we can explain these green (early start/finish dates) and red (late start/finish dates) numbers, which forms the basis for critical path calculation. The green numbers are calculated by forward path as follow:

• Set the early start value to the first our (1 in activity 1.1.1)
• Add the duration of the activity and get the early finish date (5 in activity 1.1.1)
• Move to the next activity and set the early start date as next hour (day) after finishing previous activity (6 in 1.1.2 and 1.1.13)
• Repeat until the end of the project

Forward path calculates early start/finish date for all activities/work packages in your project. The most important part case is the one, when different parallel paths merge together (1.1.2 and 1.1.4 in 1.1.5). To set early start for 1.1.5 you should chose the biggest early finish value across predecessor activities, what is 23 in this case.

Now it’s “red” turn. Red numbers are calculated via backward path:

• Set the value of the late finish of the last activity to early finish (53 in activity 1.1.8)
• Remove the duration of the activity and get the late finish date (52 in 1.1.18)
• Move to the predecessor activity and set the late finish date as previous hour (day) before starting current activity (51 in 1.1.7)
• Repeat until the beginning of the project

Backward path calculates late start/finish date for all activities/work packages in your project. As well as with forward path, the most important case occurs, when the parallel activities merges:

• After you have calculated late start for 1.1.5 you copy this number (decreased by one) into late finish 1.1.2 and 1.1.5.
• For activity 1.1.2 the amount of late finish is bigger than early start. So here we have float, which is calculated as late finish date decreased by early finish (23 – 15 = 8).
• When we come to the point, when the activities were splitted (1.1.1 into 1.1.2 and 1.1.3) we chose the lowest number of late start across these activities and copy this value into late start of this predecessor activity (6 in 1.1.3 is lower then 13 in 1.1.2, so we take it and place into 1.1.1)

Probably explanation is weird, but I suggest you to fill this chart on your own again using the explanation as references. I’m sure, after spending some time on it, you will fill it good.

Let’s compare the outcome of the first linear project schedule network diagram and newly built one after using fast tracking for compression. The first outcome is that overall project now lasts 10 hours less (or 15,87% less to the initial time period, which looks much more impressive). The second outcome is that we have clearly defined critical path shown by black arrow, where the deviation for all activities is zero. Also we have a non-critical path, where we have 8 hours of deviation, which allows us to do the work either not intensive or postpone it and do some other job, which can be related to other work packages or even not related to the project in general.

Adding another level of project’s compression – crashing

The last tool from the Project Time Management, which I will describe in this article, will be crashing. The formal definition from point 6.6.2.7 of PMBOK states:

Crashing. A technique used to shorten the schedule duration for the least incremental cost by adding resources. Examples of crashing include approving overtime, bringing in additional resources, or paying to expedite delivery to activities on the critical path. Crashing works only for activities on the critical path where additional resources will shorten the activity’s duration. Crashing does not always produce a viable alternative and may result in increased risk and/or cost.

This means that you can pay more in order to expedite the project, if it’s possible. In the previous article about earned value management (https://karneliuk.com/2016/06/how-to-track-real-projects-performance-use-evm-earned-value-management/). I’ve made an assumption that there will be two workers, who will perform the work at out project. Nevertheless this assumption hasn’t been yet reflected in our schedule, and actually this is an example of crashing.

In our WBS dictionary the activities are calculated as the number of hours, which takes one person to accomplish the task. As we are speaking about two workers instead of one, we can roughly in two times decrease the number of hours for activities that are performed by workers. Our new activity durations will be the following:

Based on new durations let’s update our PSND:

Well, the results are even more impressive. The total length of the project is reduced up to 29 hours, comparing to the 53 hours, which we have using fast tracking. And if we compare it to the initial length, the new one is two times less. What is also interesting, is that now the critical path changed and we have deviation on another path.

Lessons learned

This example provides you valuable insight that it’s quite often that the scheduling the project involves all Process from Project Time Management all together, especially on small projects. As an exercise for you try to make the same schedule following the Project Time Management Process one by one. I guess you should take the same result (or even better), but the amount of spent time increases significantly. This brings you to one of the corner stones of management in general:

The more the control, the less the performance.

It is neither bad nor good. It just works so. For certain projects control is essential, especially in financial questions. In other cases probably you can follow Project Management Processes not so strictly, and this will bring you much higher performance that is valuable for your project. Actually PMBOK also tells you that there is no magic receipt for all projects, either the project manager should adopt it each time.

Conclusion

Scheduling of the project is one of the most complex part of the project planning, because the schedule must be realistic. It’s easy to draw something that will have nothing in common with reality. That’s why understanding both of project management tools and techniques as well as the field, where the project is being done, is very important. Such understanding will provide you possibility to choose the right types of sequences build correct dependencies and provide you possibility to apply compressing techniques (crashing and fast tracking) properly. You see, I’m shifting between processes forward and back, what reflects the iterative nature of project management. Many processes can be applied several times to get the great result.

Support us

Support new interop and automation articles at karneliuk.com
EUR

I want to support with:
9.99 EUR4.99 EUR24.99 EUR49.99 EUR99.99 EUR199.99 EUR

BR,
Anton Karneliuk