The definition of a schedule ‘critical path’ varies (see Defining the Critical Path), but the essence of all of the valid definitions is the ‘critical path’ determines the minimum time needed to complete the project and either by implication or overtly the definitions state that delaying an activity on the critical path will cause a delay to the completion of the project and accelerating an activity will (subject to float on other paths[1]) accelerate the completion of the project.
A series of blog posts by Miklos Hajdu, Research Fellow at Budapest University of Technology and Economics, published earlier this year highlights the error in this assumption and significantly enhances the basic information contained in my materials on ‘Links, Lags and Ladders’ and our current PMI-SP course notes. The purpose of this post is to consolidate all these concepts into a single publication.
The best definition of a critical path is Critical Path: sequence of activities that determine the earliest possible completion date for the project or phase[2]. This definition is always correct. Furthermore, in simple Precedence networks (PDM) that only use Finish-to-Start links, and traditional Activity-on-Arrow (ADM) networks the general assumption that increasing the duration of an activity on the critical path delays the completion of the schedule and reducing the duration of an activity on the critical path accelerates the completion of the schedule holds true. The problems occur in PDM schedules using more sophisticated link types. Miklos has defined five constructs using standard PDM links in which the normal assumption outlined above fails. These constructs, starting with the ‘normal critical’ that behaves as expected are shown diagrammatically below[3].
Normal Critical
The overall project duration responds as expected to a change in the activity duration.
A one day reduction of the duration of an activity on the critical path will shorten the project duration by one day, a one day increase will lengthen the project duration by one day.
Reverse Critical
The change in the overall project duration is the opposite of any change in the activity duration.
A one day reduction of the duration of Activity B will lengthen the project duration by one day, a one day increase will reduce the project duration by one day.
Neutral Critical
Either a day decrease or a day increase leaves the project duration unaffected. There are two variants, SS and FF:
In both cases it does not matter what change you make to Activity B, there is no change in the overall duration of the project. This is one of the primary reasons almost every scheduling standard requires a link from a predecessor into the start of every activity and a link from the end of the activity to a successor.
Bi-critical Activities
Any change in the duration of Activity B will cause the project duration to increase.
A one day reduction of the duration of Activity B will lengthen the project duration by one day, a one day increase will lengthen the project duration by one day. Bi-critical activities depend on having a balanced ladder where all of the links and activities are critical in the baseline schedule. Increasing the duration of B pushes the completion of C through the FF link. Reducing the duration of B ‘pulls’ the SS link back to a later time and therefore delays the start of C. The same effect will occur if the ladder is unbalanced or there is some float across the whole ladder, it is just not as obvious and may not flow through to a delay depending on the float values and the extent of the change.
Increasing Normal Decreasing Neutral
An increase in Activity B will delay completion, but a reduction has no effect! There are two variations on this type of construct.
A one day increase in the duration of Activity B will increase the project duration by one day, however, reducing the length of Activity B has no effect on the project’s duration.
Increasing Neutral Decreasing Reverse
An increase in Activity B has no effect, but a reduction will delay completion! Again, there are two variations on this type of construct.
A one day increase in the duration of Activity B has no effect on the project’s duration, however, reducing the length of Activity B by one day will increase the project duration by one day.
Why does this matter?
The concept of the schedule model accurately reflecting the work of the project to support decision making during the course of the work and for the forensic assessment of claims after the project has completed, is central to the concepts of modern project management. Apart from the ‘normal critical’ construct, all of the other constructs outlined above will produce wrong information or allow a claim to be dismissed based on the nuances of the model rather than the real effect.
Using most contemporary tools, all the planner can do is be aware of the issues and avoid creating the constructs that cause issues. Medium term, there is a need to revisit the whole function of overlapping activities in a PDM network to allow overlapping and progressive feed to function efficiently. This problem was solved in some of the old ADM scheduling tools, ICL VME PERT had a sophisticated ‘ladder’ construct[4]. Similar capabilities are available in some modern scheduling tools that have the capability to model a ‘Continuous precedence relationship[5]’ or implement RD-CPM[6].
[1] For more on the effect of ‘float’ see: http://www.mosaicprojects.com.au/PDF/Schedule_Float.pdf
[2] From ISO 21500 Guide to Project Management,
[3] The calculations for these constructs are on Miklos’s blog at: https://www.linkedin.com/in/miklos-hajdu-a1418862
[4] For more on ‘Links, Lags and Ladders’ see: http://www.mosaicprojects.com.au/PDF/Links_Lags_Ladders.pdf
[5] For more on continuous relationships see: http://www.sciencedirect.com/science/article/pii/S1877705815031811
[6] For more on RD-CPM see: http://www.mosaicprojects.com.au/WhitePapers/WP1035_RD-CPM.pdf
Mosaicproject's Blog 
Good article, Pat. And, of course, I like the quoting of Miklos Hadju’s papers — Miklos is definitely one of the world’s experts on critical path.
I would ask that you think about a slightly different definition for the critical path — instead of “sequence of activities that determine the earliest possible completion date for the project or phase”, how about “sequence of activities, sprints, constraints and delays that determines the actual completion date for every project or phase”?
By this definition, the actual (or as-built) critical path becomes even more important, as it determines not just the minimum but the actual duration of EVERY project or phase (or, indeed, program), even ones which have not used critical techniques to generate the schedule. And any activity, sprint, constraint (logical or resource) or delay (i.e., “dropped baton”) can have critical path drag. This makes it clear that in the examples of reverse critical path, the drag is actually on the FF or SF logical constraint and to shorten the project, the schedule modification must be made on that constraint.
This approach, I’d suggest, also makes it clear that critical path (and drag) analysis is appropriate and beneficial whether the schedule was generated using CPM, PDM, resource leveling, CCPM, agile, or darts at a dartboard.
I really am interested in your thoughts.
Steve D.
Hi Steve,
Your proposed definition is illogical for several reasons:
1. The ISO 21500 definition applies equally to as-built, in progress or prospective project work
2. The Critical Path can only exist in a CPM network, CPM networks have milestones, activities (or tasks) and links. How the activities are organised (eg into a ‘sprint’) does not change the definition.
3. Constraints are only relevant if they affect an activity that affects the completion – the ISO definition applies.
4. Delays are only relevant if they affect an activity that affects the completion – the ISO definition applies.
Definitions are not case descriptions.
Pat.
Hi, Pat.
You wrote: “Your proposed definition is illogical for several reasons:”
Okay. Obviously, I don’t agree. I thought perhaps you’d be interested in looking at things from a different viewpoint. But we’ll have to agree to disagree.
“The ISO 21500 definition applies equally to as-built, in progress or prospective project work”
The as-built CP is the only one that determines what the ACTUAL duration was. The other two obviously don’t, as they are based on estimates and expectations. As valuable as they are, they are attempts to compute the PLANNED duration, based on assumptions and estimates. And in that regard, they don’t always even predict the minimum duration — a good project team should always be seeking opportunities that may arise to increase the project’s expected value-above-cost by compressing the remaining duration.
“How the activities are organised (eg into a ‘sprint’) does not change the definition.”
There we completely agree. Unfortunately, many agile projects overlook this and fail to do adequate critical path analysis.
“The Critical Path can only exist in a CPM network, CPM networks have milestones, activities (or tasks) and links.”
There we disagree. A longest path of activities, constraints and delays exists on every project, no matter how the schedule was developed (CCPM, resource-leveled, unlinked, etc.), and that path will always determine the project’s duration — whether or not we can predict what that path is (i.e., develop a planned critical path schedule) or have even attempted to.
As examples of what I mean by this:
A. If you have an unlinked schedule consisting of five activities, starting simultaneously, of durations 4D, 5D, 6D, 10D and 15D and there are no constraints or delays, the 15D activity will be a single-activity “path” that determines the project duration. As such, it is the as-built critical path.
B. If you have a path of 20 activities, all linked, whose total duration is 60D, and you have another single and unlinked activity of duration 10D, but with a start-no-earlier-than constraint of Day 56, the critical path will be the constraint and the 10D activity (each of which will have critical path drag of 5D). Such analysis shows the project manager how much time each entity is adding to the project duration. And if that analysis is done during the planning phase, where to target to compress the schedule.
“Constraints are only relevant if they affect an activity that affects the completion – the ISO definition applies.”
In other words, if it’s on the as-built critical path. Again, we completely agree. And then they have drag, as in the case of the calendar-based constraint I mentioned above.
“Delays are only relevant if they affect an activity that affects the completion – the ISO definition applies.”
Again, I completely agree — as it would then be on the as-built critical path.
To be honest, Pat, I don’t feel that we disagree much. I do feel that viewing the CP from the perspective I describe (and to the quantification of drag) lends both importance and benefit to the practice of critical path analysis.
But I guess we’ll have to disagree.
Fraternally in project management,
Steve the Bajan
In all of your situations above:
1. constraints, etc are attributes of an activity – the ISO definition applies.
2. All of the Standards require all activities to be properly linked to the start and the finish – this is elementary good practice.
3. The fundamental point of planning is to predict an uncertain future.
Pat.
I find it really funny that CPM followers have taken the name of a Critical Path as if it belonged only to them. The thoght that Critical Path should be calculated only based in a CPM network is outdated and those that insist on that will never find the benefits of building realistic resource leveled schedules.
CPM is useful and necessary for finding effective critical paths, but that is only part of the job. Understanding how constraints of all types and resource leveling affect the true path from day one to final day of a project is what will give us more reliable scheduling models.
I have a project of two tasks… Task A and B of 10 days each and they are not dependant of each other. If they are performed by anyone in the team and I have enough resources, I will take 10 days and both parallel tasks represent two equal critical paths, determining the first and last day of the project and any changes in those durations will delay the project. This means I actually have a critical path with no CPM at all.
If my team is reduced to PAT alone, the same project will now take 20 days and again I have no need of CPM to determine the critical path. Both tasks resource leveled will determine the path from day one to final day of the project.
While a good network is still necessary for complex projects and detailed scheduling modeling, that is one of many other requirements for a good project and we must go beyond CPM path for realistic scheduling.
Peter Mello
Peter, You clearly have absolutely no knowledge of the history of scheduling or project management. The Term Critical Path was developed as part of the 1957 efforts to create the PERT scheduling system, Kelley and Walker were developing the Activity-on-Arrow scheduling system at the same time, their original name for what became known as the ‘Critical Path’ was the ‘main chain of activities’ – this was changed very early (around 1958) to ‘Critical Path’ to have the same name as PERT used for effectively the same logical construct. The Kelley and Walker scheduling process subsequently became known as the Critical Path Method. The fact there are other processes for determining what is important does not change this historical fact. On simple little projects such as the one you describe, formal scheduling is not essential – run a complex major project such as ‘Universal Credit’ in the UK using Agile, without proper controls, and you waste £500 million out of a total budget closer to £1 billion (report of the UK National Audit Office). But please DO NOT pretend what you are doing is Critical Path Analysis – it is not, and it never has been.
If you want to learn a little bit about the actual origin of terms you are misusing see: http://www.mosaicprojects.com.au/PM-History.html
Pat