Blog Post Image

A Critical Look At Critical Path Analysis

Paul Naybour Paul Naybour

Published: 7th January 2010

I’ve finished so I’ll start

A critical look at critical Path Analysis

John Bolton, Programmes Director, Parallel Project Training

For a large number of years students of project management have been taught to undertake precedence diagramming as a mechanism for determining the end date of a project and as a guide to the optimisation of resource usage. It is probably the most recognisable aspect of modern project management techniques, culminating as it does in the production of the ubiquitous Gantt cart. It is enshrined in the deepest darkest fundamentals of planning software systems and as such has become widespread it its application, albeit often invisible to the person driving the software. This sometimes blind devotion to software as a one stop shop leads the unwary into the production of poor plans, not fit for purpose. Whilst PDM is a perfectly viable technique there are other variations on a theme using other methods and techniques such as agile and critical chain etc. that are dismissed (knowingly or unknowingly) in the belief that PDM is all you need. These other techniques for manipulating plans have a lot to offer as supplementary mechanisms or even as wholesale alternatives to achieving the best result. The need to consider some other form of planning rigour is further substantiated due to the inherent challenges when deploying the PDM. In this article we look at the limitations of it and of critical path analysis with practical tips on how these challenges can be overcome.
The principles
The theory of PDM is well understood by all project managers and requires that an analysis of the lowest level of work package or activity be undertaken and that they become connected together as in Figure 1.

A simple precedence diagram

Figure 1 A simple precedence diagram

The normal relationship between the ‘nodes’ in the network are those of finish to start. This means that any subsequent tasks can only start once the predecessor has finished. The subsequent task does not have to start immediately after the predecessor but merely that it can. Any gap between the predecessor and successor is termed float and can appear either after the predecessor (free float) or before it (independent float). Once the whole network has been analysed the critical path will be determined as the longest path through the network thus determining the end date. The network above has an end date of period 9. The use of this simple approach has a number of limitations and challenges when trying to predict plans for projects. Practitioners need to be aware of these challenges so they do not compromise the plan and so that the project can perform effectively. These challenges are illustrated below.
Challenge number 1 – Inertia
The project manager will spend a significant amount of time creating a plan. After that significant investment the inclination on the part of the project manager is not to change it unless something significant happens. The plan remains fixed and the project manager does their upmost best to resist any contra effects to change it.
Consider this scenario though. Task 1 takes Monday to Friday and Task 2 takes Monday to Friday the following week. Task 2 cannot start until Task 1 has finished. What happens if by some fortuitous set of circumstances Task 1 finishes on the Thursday? Ideally the project manager will raise change requests, alter the plans, call in the staff that were all expecting to turn up on the Monday to get them mobilised to start on the Friday. Does this really happen in real life or does the team take a breather and start on the Monday week 2 anyway? I think we know the answer to that one. This laisez-faire approach will have a significant impact on our ability to meet dates generally?
Take another example; you are running for a train and out of breath, hot and bothered you arrive on the platform only to find that the train left five minutes early. You would probably be somewhat unimpressed. If trains can only leave on time or late they will therefore (on average) be only on time or late. If a project never grasps any opportunity to finish early and capitalise on that they will (like trains) only ever finish on time or late, never recovering the average. Changing the plan to accommodate early finishes is sometimes too much bother and the general inertia present means that the plans are only changed when the need is significant. Critical Chain planning tackles this head on and provides a significant opportunity to build more robust plans and optimise schedules, taking full advantage of early finishes, using a simple system to ensure that resources are in place to take advantage of the time saved.
Challenge number 2 – Assumptions
In preparing a plan, assumptions may often be made about the availability of resources. If these become influential in the design of the logic though, they can significantly reduce the flexibility of the project to take advantages of changes in resource availability later. Consider the example of a 4 walled room and each wall needs a coat of undercoat and top coat paint. The top coat can only be applied after the undercoat has been applied on each wall. Each wall takes a day to paint each layer. Let’s ignore drying time for now. What kind of plan could we end up with? Given only the information above it is incontrovertible that the only true dependencies in our plan are as appear in Figure 2.

Figure 2 Painting a room

With this plan then the project takes two days (if we have 4 painters) There is a strong likelihood that some plans for this project would show wall 1 undercoat, then wall 2, 3 and 4 undercoat with wall 1 top coat starting after the end of wall 1 undercoat yielding a project duration of 5 days. This version assumes we have two painters for three of them.
What about if we drafted a plan with an assumption made of only having one painter hardwired into the logic? The plan might look like the one in Figure 3

Another view of the plan

Figure 3 Another view of the plan

In this version we would end up with a project of 8 days, undercoat 1, 2, 3 & 4 then topcoat 1, 2, 3, & 4. What happens to our plan though if miraculously we find another painter? If you added this resource into most planning software it would make no difference to the duration as you have told the software not to violate the dependencies. Would the project manger utilise the extra resource and start tasks early? Of course they would. Would they change the plan? Probably not… (see challenge 1 above). Also, if the plan does not change, we were measuring these tasks with earned value techniques then we would have actual figures for tasks that should not have started yet, which starts to make a bit of mockery of all planning principles.
A proper understanding of these principles and the potential ramifications of the choices is imperative. If assumptions about the number of resources are embedded into the dependencies then because they cannot be violated these dependencies will force a less than optimised plan.
Challenge number 3 – Lags and leads
Precedence diagramming allows for the introduction of lags and leads into the network. A lag introduces a gap between the end of one task and the start of the next. A lead means a task can start before another finishes for example. These of course can be very useful. Consider our room painting project from above. The paint may take a day to dry meaning the top coat can only be applied after the undercoat has been applied (and dried). The whole plan for one wall can therefore look like Figure 4.

Drying time as a task

Figure 4 Drying time as a task

Using a lag we can dispense with the extra task (Drying time) and merely introduce a gap with a lag such as Figure 5.

Using a lag

Figure 5 Using a lag

In the planning software both of these alternatives are available and readily deployable to generate creative schedules. There are a few words of caution to be considered here though;
By introducing a lag, there will be a gap between two tasks on the resultant Gantt chart that may not be altogether clear as to why they are there. The critical path may have gaps in it.
By not having a task, attention on the period between the two tasks can be lost and assumptions made about the fact that the paint has actually dried.
The paint drying cannot itself be completed when recorded as a lag as only tasks can have acceptance criteria associated with them (is it painted? Is it dry?).
No-one is assigned to the task and so no-one is charged with vouching for the fact the paint has dried, meaning control is lost.
On the other hand having tasks in the schedule that do not in themselves involve work can mean a much larger list of activities than might otherwise be the case.
So the moral of the story is that just because the planning software functionality is available it may not be appropriate to use it – all or any of the time and if it does, make sure it is used sensibly.
Challenge number 4 – More detail is not necessarily better
When a schedule is constructed the estimates of effort (which drive the duration) are considered and need to be incorporated into the plan. These estimates are more often than not put in the simplest form and on a uniformn basis. One days’ work spread over a two week period will result in 1/10th of a day per day. Hang on though, 1/10th of a day is 48 minutes! The person allocated to this task is not a) going to work at this rate and b) will not book their time at that rate if they do. A precedence diagram requires duration for the task and resources assigned. These two things are separate (see above). When durations are driven through a resource loaded plan and this leaves peculiarly low or non uniform resource allocations in the plan, the project manager will be challenged to account for the effort in the way it was planned. Combine with this the way in which software will allow any manner of non standard loadings (front loaded, back loaded, uniform, pro-rated, etc), there is plenty of opportunity to come up with a schedule that is unachievable from the start, not because the overall timescales are unachievable but it is simply too complicated to make much sense.
The relationship between the schedule and the earned value recording also presents problems where non uniform resource loadings are used. Consider the example of someone producing a written document over a period of a week – a report say. The profile of their work might look like
Monday, understand the task and think about how to write the document and what to put in it.
Tuesday, find the template, talk to a few people about work they have done, do a bit of googling and maybe undertake some interviews
Wednesday, write the contents list
Thursday, do some more research, interview some SME’s and begin to make some notes, take a long walk to think about it some more
Friday, produce a first draft in the morning, throw it away and write the document from scratch between 3 and 5 on the Friday afternoon.
Let’s consider what would happen if they did not turn up on the Friday. How much earned value is vested in the four days work. None. This is an extreme example but the principle holds true, particularly where non tangible products are being produced. Some people start early and ‘get things in the bank’. Others leave things to the last minute. This variability in work rate is not for putting into plans but they are material and will need careful consideration in arriving at a properly considered schedule and believable progress reporting.
We write the document. Our schedule has a reviewer tasked to review the document and mark up their comments. The reviewer returns the document to the creator and they in turn apply the comments and re-submit for final comments. It then goes to quality assurance for checking against standards and style. It goes to the customer who then in turn reviews it and marks up comments. These again go back to the author for revisions and finally it gets published.
This is a ten stage process to simply produce a single document. The writing took a day or two of actual work but all the reviewing and comments involved added significantly to the task and will need to be controlled. On our plan then we will have ten tasks all linked and all culminating in the publication of a document. How much detail do you need and do you really need it must be at the forefront of any project manager’s mind when preparing a schedule.
In some circumstances a lot of detail may be required with work packages taking perhaps a day or two. In other circumstances it might be possible to have a task of a month or two. Project managers should not be afraid of having plans at differing levels of detail to accommodate differing levels of exposure to risk. If you need control put detail in the plan, if you do not then keep it simple.
Agile methods have a lot to teach here, especially when it comes to the issue of iteration and apparently unknowable estimates of the time it will take to agree (for example) a document. Time-boxing is a principle that constrains evolution within a fixed timescale focussing on the priorities first then potentially sacrificing detail. Only do work that you are prepared to discard is not a bad mantra for the Agile project manager. PDM does not sit well with agile methods though, PDM assumes that once finished a task will not be revisited. Agile assumes it will. Both probably have a role to play, care is needed not to discount one in favour of the other and lose the advantages of each.
Precedence diagramming is a tried and tested mechanism for providing coherent and cogent plans. It is not a silver bullet though and just because it is supported by software that makes it all seem very easy and simple, the old adage ‘of garbage in means garbage out’ still holds true. Use the technique as it will provide a valuable backbone and ensure rigour is instilled, but quite possibly the thought going into the production of the plan is the important thing rather than the finished product. Expand your thinking and embrace other ideas and do not become blinkered to alternatives.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.