# Tag Archives: CPM Delay

## Critical confusion – when activities on the critical path don’t compute……

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

[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

## Dealing with client delay

Preventing or minimising client induced delay is a common issue from small ‘agile’ IT developments through to multi-\$billion mega projects.  Whilst this type of delay can never be completely eliminated, they can be reduced by applying a pragmatic six stage approach.

Stage 1:  Make sure your needs are known and understood by the client.

The best way to minimise delays is to ensure the client understands not only ‘what’ they are expected to contribute but also ‘why’ it is needed – don’t make the mistake of believing ‘they understand’, just because it is their project. Proactive communications is the key to helping your client better understand their role and the consequences of a delay on their part. Some of the questions you need to answer are:

• Does the client understand the importance of their involvement?
• Does the client really understand the need for timely feedback?
• Do they appreciate the impact to the project if they are late / slow?
• Do they know the dates that they will need to undertake actions so they can plan their work?

You will be surprised how valuable communicating proactively and raising visibility of the potential problems can be; the key is making sure the client develops an understanding of the requirements and the amount of effort needed for them to meet their obligations. This is a form of ‘directed communication’; see: The three types of stakeholder communication.

Stage 2:  Schedule the activity and code it up to make extracting focused reports easy.

A vital tool on the communication lexicon is clearly presented schedule information that is relevant to the client. Make sure their work is defied by activities that can be easily pulled into a focused report. Do not use lags on links to allow time for this work – no one is responsible for the ‘lag’.

Stage 3: Regularly status the schedule and communicate the changes to the client.

Having a plan is only part of the power of scheduling.  Create a baseline and show the slippage between any current ‘client owned’ activities and the plan. Using unbiased data to highlight issues will change behaviours – no one likes to be seen to be causing delays, particularly the project’s beneficiaries.

Stage 4: Raise a risk for anticipated future delays – manage the risk.

When you have a sense that the client is not going to meet their deadlines raise a risk and look for ways to manage the risk. If possible ask the client to help with the risk mitigation plan, which will give them some buy-in to help you be successful. This type of engagement also helps from a communication standpoint to better manage expectations. See more on risk management.

Stage 5: Raise an issue for an actual delay – manage the issue.

If the client ends up not meeting their dates, you have an issue that needs to be effectively managed. Issues management (problem identification and resolution) needs to be performed. Get your team, management, and stakeholders involved. Ask your manager for their input in resolving the problem that is now impacting your completion date. Get more accountability from your managers and the client’s managers to help resolve project deadline concerns. Your managers and sponsors are also the ones in a position to manage priorities to get the work done. If the problem cannot be resolved perfectly, at least you are continuing to manage expectations. See more on issue management.

Stage 6: Deal with contract issues contemporaneously.

If there is a need to make a contractual claim for the delay, make the claim immediately whilst the cause and effect are easily defined and keep the claim factual If the earlier steps in the process have been followed there will be no surprises and resolution of the issue can be achieved with the minimum of fuss or delay. See more on contractual dispute management.

Summary

Client induced delays are best avoided:

• In commercial contracts, the ‘excusable delay’ (EOT) claim will inevitably damage the relationship and cause ill will – the effect of which can outweigh the benefits of the ‘claim’.
• Internal projects don’t have the ‘claims’ option and may appear to be unreasonably held accountable for events and circumstances that are not within their control, but they do have control over the processes used to manage the project.

By utilising disciplined and proactive project management processes, you are more likely to avoid these problems and encourage the client to help you be successful by managing expectations and getting the client to be a part of the solution – not just the problem. It’s really just a case of applied stakeholder management!

## Assessing Delay and Disruption

In preparation for the IAMA National conference later this week I have just finished developing and updating a short series of papers focused on addressing schedule delay and disruption.

• Assessing Delay and Disruption – an overview of the accepted methods of forensic schedule analysis [ view the paper ]
• Prolongation, Disruption and Acceleration Costs – an overview of the options for calculating costs associated with approved delays and acceleration [ view the paper ]
• The complexities around concurrent and parallel delays are discussed on Mosaic’s White Paper WP1064 Concurrent and Parallel Delays

## Cause of Delay

Late last year the British High Court delivered a very interesting judgement on the assessment of delay, disruption and prolongation claims.

A delay to an activity may disrupt the work and it may delay the completion of the project. The two factors are independent (this is the fundamental principle in the UK Delay and Disruption Protocol).

In Costain Ltd v Charles Haswell & Partners Ltd [2009] EWHC B25 (TCC) (24 September 2009), the High Court has determined that for prolongation to occur, the actual delay has to flow through to a delay in the completion of the works. The mere fact the delayed activity was on the then critical path when it occurred is not of itself evidence the delay flowed through to the completion of the works. At paragraph 200(ii) the Justice Richard Fernyhough QC stated I find that it has not been shown by Costain that the critical delay caused to the project by the late provision of piled foundations to the RGF and IW buildings necessarily pushed out the contract completion date by that period or at all.

The fundamental issues relate to the definition of the critical path were canvassed inin my 2006  paper ‘Float is it real’.

At page 7 I argued:

Despite the CPM requirement for a single duration estimate, durations are variable; changing the estimate of a planned (future) duration or differences between the actual duration and planned duration on completed activities may change the critical path.

In the example above, at the ‘Initial Claim’ the critical path was running through the top chain of activities and ‘delay x’ was encountered. As no one can predict the future, at the time of the dealay it would be reasonable for everyone involved in the project to assume this is a critical delay and administer the contract accordingly.

Later, changes in the duration of the activities cause the critical path to move (either reduction in the time needed to complete some activities in the top chain or increases in duration in the lower chain, or both). When ‘delay y’ occurs as a ‘Later Claim’, this is also a critical delay based on the schedule at the time of the delay.

However, given the definition of the ‘Critical Path’ is: Generally, it is the longest path through the project. …that determines the duration of the project. The difficult question to answer is what happens to ‘delay x’, it appeared to be critical based on the best information available at the time the delay occurred. But changes over time (and after the time of the initial delay) have shown ‘delay x’ to actually be non-critical.

Certainly based on the Constain’s case, scheduling experts will need to define far more than simply a delay to an activity on the current critical path. As a minimum it will be necessary to show the delay impacted the overall completion and the extent of the impact. It will also be necessary to show the delay caused a general increase in costs for a prolongation claim to be sustained.