One of the key roles in any project core-team is an expert planner and scheduler.
I was recently called upon to carry out an external review of a project schedule. This was a two year $20m project to deliver a turn-key manufacturing facility to a new customer. The project was two months in, and already two weeks late to schedule. Understandably management was becoming nervous about late delivery penalties.
Although internal peer review (by PMO using subject matter experts from another team) had always been carried out, the company typically found itself unable to deliver on time. In short, what was typically judged to be a reasonable schedule usually turned out to be an underestimate. The schedule had already been reviewed internally before bid, but had been approved on the basis that the schedule was ‘tight but do-able’.
A systematic schedule review involves the use of a standardised schedule review checklist. The detailed contents of this are individual to the organisation, but it’s worth reviewing the items that will always be present, and we applied in this case.
- Schedule Basis
A basic but important consideration is to make sure that the schedule has been set up with the right (and realistic) working and non-working days. In this case, although working days had been mapped, the schedule did not adequately take account of time-zones or the likelihood of customer non-availability during holiday periods.
- Who Created the Schedule?
Has the right person set up the schedule? In this case, the pre-sales engineer had done a reasonable job, but, perhaps due to pressure, had been very optimistic.
Over the years I’ve seen one schedule in which the project relied on concrete achieving full strength in 2 days and another in which full resource efficiency was achieved in the open air in the Middle East in the middle of the summer.
- Critical Path
Of prime importance, has the critical path been properly identified? In this case, although the critical path activities looked realistic, it looked like best case estimates had been used to fit a mandatory delivery time.
(Another useful measure is the percentage of activities on the critical path. If the number is high, then there’s not much room for optimisation.)
- Multiple Critical Paths & Bottlenecks
In this project, multiple critical paths converged towards a bottleneck. Of course, with more critical activities, there’s more to go wrong, but in a bottleneck, only one path has to be delayed to delay the entire project. In this case, commissioning could only begin once three separate systems had been completed and tested, one supplied by a sub-contractor. In practice, delays are more complex than the schedule may suggest as typically there may be waiting time and other expenses for mobilised resources.
- Activities with Low float, or Reducing Float
Activities with low float may become critical and should be assessed as if they were critical. Particular attention should be paid to activities with reducing float not only because they may become critical, but because there may be a problem with them.
Dependencies should be checked for practicality. In the current schedule, two areas of concern were identified. In the first, some activities had been overlapped to fit the schedule. While it is sometimes possible to start work on a successor before the predecessor is complete, in this case, there was a complex dependency between them and a significant risk of rework. The second area of concern involved several activities that were not technically dependent on each other (installation of two service systems), but simply could not be installed at the same time due to the limited space in the installation area.
- External Dependencies
This schedule had three external dependencies, one on the customer, one on a subcontractor, and one on a different part of the supplier organisation. All present risk, however, in this case, the dependency on a customer deliverable (completion of a building structure) was on the critical path. It must be remembered that where the customer causes a delay, they may well grant relief for schedule delay, but typically will not compensate for wasted mobilisation or other resource allocation costs.
- The Basis for Duration and Resource Estimates
You can’t build a practical schedule without reliable estimates. Although in this case a rigorous estimating approach had been taken, one long activity was identified on the critical path where the reliability of the estimate was low (engineering of a component using new technology).
- Long Activities
Longer activities tend to contain more uncertainty, both for practical (there’s more in there) and mathematical (variance is a function of the square of the duration) reasons. In the case of long activities, a useful technique is to break them down into smaller components. In this case, the team managed to find some savings by breaking down two long activities and mapping estimates and dependencies more accurately.
- Activities Beyond Detailed Planning Horizon
You may have seen the joke schedule that looks something like this:
1.3 Miracle Happens
Where rolling wave planning is used, then later phases may initially have only high level and sometimes over-optimistic estimates. In this case, however, the entire two-year schedule had been planned in detail.
- Resource Loading and Critical Resources
It can be complex to resource load the schedule within the software; however if this is not done, then resources cannot be correctly planned, allocated or optimised. In this case, a simple resource loading had been carried out, and the correct number of resources had been allocated and committed. However the resourcing had not been optimised and there were several instances within the schedule where savings could be made (specifically, a team was mobilised twice to customer site, when only one, slightly longer visit was necessary).
Of course, critical path is always considered. However it is also important to consider critical resources. In this case a significant risk was identified: delay of one critical activity by one week meant a delay of one week to project delivery. However, this activity required a critical resource who would only be available at the original scheduled time.
What Not To Do
The team suggested that we could use risk management to solve the problem. This was along the lines of ‘the project is scheduled to take 2 years, but there is a risk that it takes 2.5 years’. I’ve a feeling that the team wanted to park this risk on the risk register and hope for the best. Of course they might as well have stated that ‘pigs can fly’ but there is a risk that they can’t.
What Should be the Approach?
Well if we’re starting at the start:
- Through systematic development and review, create a realistic schedule.
- Optimise the schedule. The steps for this are outside the scope of this article, but it should be remembered that it is not only a case of balancing Scope, Schedule and Cost, but also risk, resource, and other constraints (We can actually deliver more, earlier, and at lower cost, but the risk will be higher).
- Identify and analyse risk.
- Re-optimise until the project is capable of delivery at a price acceptable to customer and supplier, and risk acceptable to all parties.
In the example project, we weren’t starting at the start, however early identification of the delivery risk triggered a ‘concentration of minds’ on the part of both project team and management. Indeed, things turned out well: after a rigorous review and re-planning based on the considerations above, renegotiations with the customer were carried out and a new delivery date accepted (with a lower margin, but also lower potential penalties).
What Does the PMBOK say?
Much the same as above. However the question arises as to what we’ve meant by ‘realistic’ estimates and schedule. Does this mean the p50? p80? p90? The only way to determine this is to carry out probabilistic analyses of our projects using Monte Carlo simulation, and deriving S-Curves representing probabilistic values for project outcome (dates and cost). Not only does this provide significantly richer information, such as sensitivity information telling planners where to focus optimisation efforts, but also gives management a solid basis on which to determine project viability, targets and contingencies.
Comparing this approach with the static ‘deterministic’ approach used in the example described above, it is interesting to note that where Monte Carlo simulations are run, it is quite typical to discover that the initial ‘deterministic’ schedule is realised in less than 5% of simulations when running a probabilistic model.
Monte Carlo analyses should be (and typically are) run within large complex projects, typically starting at pre-bid stage and continuing, but for most projects it is simply not cost-effective to run Monte Carlo analyses. In any case, it probably would not provide much additional information. However, with the simple approach outlined above, and particularly the systematic use of estimating, scheduling and risk management tools.
This is where that expert scheduler comes in!
If you would like to know more about Scheduling and Risk Assessment, you can join our next Scheduling and Cost Control Training Courses on 10-12 July or 4-6 Nov in London.