Develop and Analyse Project Schedules for Realism: Part 1 – A Composite Scheduling Process

by Nov 1, 2016

by | Nov 1, 2016

This is the first of a 2-part series of articles covering the development and control of robust, but realistic, project schedules.   The focus of the articles is as follows:

  • Part 1 – A composite scheduling process; and

  • Part 2 – Assessing schedules for realism.

The first part covers a project scheduling process which takes from the best processes available and consolidates it into a composite scheduling process.

Introduction

When presented with a project schedule which shows the correct durations and task dates, we generally assume the schedule is acceptable.  We then establish the project baseline against which the project will be progressed.  Not long after the project kicks off, things start to drift from plan and then it becomes an ongoing exercise to continually replan and rebaseline.  This situation gradually deteriorates and eventually leads to project delays, delay claims and, in some instances, lengthy and expensive court battles.  As is so often the case in life, the devil lies in the detail.

During my career, I have regularly encountered this phenomenon and must attest to many hours of frustration because one, or more, of the following requirements were not adhered to:

  • Basic rules of schedule development and control;
  • Minimum standards for what a quality schedule looks like;
  • Documented backup on how the schedule has been compiled;
  • Proper signoff and communication of the baseline schedule; and
  • A proper change management process.

It became evident that something was amiss in the underlying structure and processes of these schedules.  There appeared to be quality and governance issues at stake which, truth be told, are some of the main drivers of a realistic schedule.  This series of articles will highlight and suggest ways in which this situation can be improved.

Composite Scheduling Process

There have been numerous books written on scheduling; suffice to say that it is very important that a planner / scheduler follows a rigid formal planning process.    Examples of formal planning and scheduling processes can be found in the Project Management Body of Knowledge (PMI, 2013), literature and articles from the American Association of Cost Engineers (Crawford, 2011; Stephenson, 2015), and books such as Project management using earned value, 2nd edition, by Humphreys (2002).

There are certain nuances to each of these high-level processes, which, if selectively stripped out and used to create a composite process, will more fully describe the process for creating a project schedule. Over a period, my personal preference has swung towards using the approach of Humphreys (2002), primarily because of the introduction of the quality assessment sub-process in conjunction with one or two modifications which will address the fundamental frustrations highlighted in the introduction.

The composite schedule development and control process is highlighted in Table 1.  Note that the process described below is not a linear sequential process, but goes through a series of iterations to get to the eventual outcome.

Table 1:   The Schedule Development and Control Process

Process Steps Sub-Process Description
Prepare Schedule Develop the Network List the activities, decide on durations, apply the logic. You now have a network diagram.
Perform Critical Path Analysis Do the forward and backward pass analysis to determine the critical path.
Resource Loading Resource loading ensures that resources are fully loaded for optimum output.  It also prevents overloading of critical resources.
Crash the Network Determine if the schedule can be reduced to get to realistic durations or resolve long durations.
Schedule Quality Assessment Run a schedule quality assessment prior to the Risk Analysis.
Risk Analysis The quality assessment conducted previously will assist in ensuring a more realistic outcome.  Determine schedule contingency.
Benchmark the Schedule This is not an ongoing sub-process but needs to be done especially when developing early project schedules.
Baseline the Schedule Setting a Traceable Schedule Ensure that progress criteria are in place and the baseline has been set.
Prepare & Signoff on Basis Document This is the document detailing the makeup of the schedule and is the communication tool for all project stakeholders.  It validates and confirms the baseline for the project.
Monitor & Control the schedule Update the Schedule Update the schedule to reflect current reality.  This does not change the baseline.
Schedule Change Management Any changes affecting the schedule to go through a formal change management process.  Note the baseline does not change until a formal request is submitted to do this.
Schedule Risk Assessment Ongoing risk assessment and mitigation actions are done.

Let us now discuss each of these in a little more detail.  The focus of the balance of this article will only be on the schedule development and control process.  The second article will address the quality assessment sub-process and the schedule basis document.

The first step in the process is the preparation of the schedule so that we can establish the baseline which the project will be measured against.

Prepare the Schedule

Preparing the schedule comprises the following seven steps:

  • Develop the Network: This sub-process is the start of schedule preparation.  As part of the inputs a set of target dates are required which could be startup related, market related or project completion related.  The list of schedule activities is derived from the scope which should be in the form of a Work Breakdown Structure (WBS), activity durations are determined and the relevant logic applied.  The various project execution strategies will also determine logic and grouping of activities so bear this in mind.

Once this has been completed, one has what is referred to as a network diagram.

  • Perform Critical Path Analysis: To determine a critical path (the longest path through the network) for a project, a series of backward and forward passes of the network are simulated by the planning software.  The resultant critical path is the sequence of activities such that if any one of the activities were to be delayed, it would cause the project to be delayed.
  • Resource Loading: It has been statistically proven that proper attention to resource loading leads to improved project outcomes and more reliable schedules.

Resource loading and critical path analysis are interchangeable, as some planners like to do the critical path analysis after the resource loading exercise has been undertaken.  I am personally not too fussed, so long as both actions occur iteratively until an optimum solution is achieved.

  • Crash the Network: “Crashing” is a technique whereby various strategies related to overtime, additional manpower or sequencing of work are investigated to determine if there are opportunities to reduce the project duration.  This is a lengthy and complex process and usually leads to reduced project durations.  However, the additional costs need to be weighed against the improved outcomes.
  • Schedule Quality Assessment: This is a sub-process that I believe is extremely underutilised, yet assists greatly in enhancing the realism of the schedule.  Until recently, there did not appear to be much research on this aspect of the schedule.  In the absence of anything substantive this set of criteria can be used to analyse a schedule and determine fundamental problems which will need to be corrected.  It is also not a panacea for all schedule issues but can be used as a minimum standard which can be added to over time. More on this in next month’s follow up article.
  • Risk Analysis: This sub-process should not be undertaken until a proper quality assessment has been conducted.  Incorrect use of logic, relationships, constraints, float and long durations could have a detrimental effect on the outcomes of the risk analysis and render the whole exercise invalid if we do not use a realistic schedule.

The object of a schedule risk analysis is to determine the possible impact on project durations should the probability of certain risks materialize or events occur.  After the analysis, a range of probabilistic dates are presented and the team decides on an appropriate level of risk.  This then becomes the schedule contingency (like cost contingency) and should be managed in the same way.

  • Benchmark the Schedule: Benchmarking appears to be an activity that takes place on an ad hoc basis.  When initially establishing the project schedule it is imperative to conduct a benchmarking exercise to determine the realism of the proposed project schedule before it becomes the de facto baseline.  Once the initial baseline has been established it may not be necessary to conduct a benchmarking exercise again unless there has been a significant de-scoping or scope increase.

Baseline the Schedule

  • Setting a Traceable Schedule: On completion of Schedule Preparation sub-processes, it is important to put the baseline in place.  Included in this exercise, all the elements for assessing progress to determine progress objectively should be included.  Without having an established and agreed baseline the team will be flying blind once progress measurement starts.

The exact measures aka Earned Value criteria need to be in the schedule so there is no debate about the percent complete as it should simply be a question of determining whether the activity is complete or not?

  • Prepare and Signoff on Schedule Basis Document: Another area that perplexes me is the lack of preparation and / or upkeep of the schedule basis document.  This document describes the scope, explains the inner constructs of the project schedule, progressing criteria, assumptions, exclusions etc.  Planners apart, not many people can understand the inner workings of the schedule so it is vital that this information is captured in an easy to read and understandable way. It is critical that this document is used to get parties to sign off on the schedule before the baseline is set. A typical schedule basis document should contain the following:
    • The Plan – This should include a list and description of the activities with their planned dates (start and finish). A complete scope of works should also be added;
    • Schedule control baseline – A time phased, logically linked, resource loaded, detailed interpretation of the plan based on an aggregation of a common attribute of all activities to be measured and assessed.
    • Planned schedule – A list of activities with their planned date information usually illustrated as a bar chart;
    • Schedule basis – A description of the activities and resources covered, included methodologies, standards, references and defined deliverables, assumptions, inclusions and exclusions made, key milestones and constraints, calendars and some indication of the level of risk and uncertainty used to establish schedule contingency;
    • Schedule control plan – The progress weighting and measurement approach should be included. It should include a description of how project performance should be measured and assessed in respect of the schedule including rules for earning progress and the procedures for evaluating progress and forecasting remaining durations.  This should all form part of the schedule basis document;
    • Quality Assessment Results – The results of the quality assessment should accompany the schedule which this assessment relates to; and
    • Signoff – Ensure signoff from all parties that this is the accepted schedule and baseline reflecting the scope of work as described earlier.

Monitor and Control the Schedule

  • Update the Schedule: The regular sub-process of updating the schedule now commences with daily, weekly or monthly updates and reports against the baseline.
  • Schedule Change Management: An area that does not get the attention it deserves is in schedule change management.  Too often the focus is on cost without understanding that a slippage on schedule may also have an impact on cost.  In addition, this is the only mechanism through which the project baseline can be changed.  The planner must ensure that he makes no changes to the schedule unless formally agreed to and signed off via a formal change management process.
  • Schedule Risk assessment: Ongoing quarterly or bi-annual risk assessments should be conducted to test for the realism of the schedule in being able to accommodate potential risks.

Concluding remarks

In this article, I’ve highlighted some of the concerns I believe are hindering the development of realistic schedules.  I then identified four key areas (there may be more), which if implemented properly, will lead to significantly improved realism in schedules.  These are:

  • a well though through and consistent schedule development and control process;
  • a schedule quality assessment conducted frequently (GASP);
  • a basis document used for signoff; and
  • benchmarking.

Whist many people will be saying this takes a lot of time the effort is well worth it in the long run.  The effort is only expended in the initial setup and development, but thereafter it is pure maintenance.

References

Crawford, T.X., 2011, Professional Practice Guide #4: Planning and scheduling, 3rd edition, AACE International.

Humphreys, G.C., 2002, Project Management using Earned Value, 2nd Edition, Humphreys and Associates, Inc.

PMI (Project Management Institute), 2013, A guide to the project management body of knowledge (PMBOK® Guide), 5th edition., Project Management Institute, Inc.

Stephenson, H.L., 2015, TCM Framework: An integrated approach to portfolio, program and project management, 2nd edition, AACE International.

Kevin Mattheys

Consulting Partner, Director

Kevin has been in Project Controls and inter-related fields for more than 30 years. He has an Electrical Engineering qualification from Wits Technikon as well as a BCom degree and Project Management Diploma. More...

DOWNLOAD

You might also enjoy:

Project Governance

Project Governance

By Herman van Heerden, Freek van Heerden, Jurie Steyn  Introduction Ed Merrow (2011), in his book Industrial Megaprojects, maintains that much of the pathology we see in megaprojects today reflects the nature and problems of the modern industrial firm and the way in...

read more
Black Swan Risk Management for Projects

Black Swan Risk Management for Projects

By Jurie Steyn.Introduction Decimus Junius Juvenalis, known in English as Juvenal, was a poet active in the period AD 110 to 130. He wrote sixteen satires on the vices, abuses, and follies of Imperial Rome and is regarded by many as one of the greatest satirists of...

read more
Learning from All Projects

Learning from All Projects

Any organisation should strive for continual improvement in the way they execute projects. A good way to do this is to ensure that mistakes of the past are not repeated.

read more