What makes a usable schedule?

 

Ruth Murray-Webster and Peter Simon

cartoonIt has become apparent to us that a disciplined and knowledgeable approach to project scheduling is seriously lacking in many project organisations, resulting in a myriad of effects associated with the project manager not having a clear understanding of scope, quality and dependencies and their effect on estimates and time-plans.

Over five years ago, in one of our earliest Lucid Thoughts entitled ‘Reviving the Ancient Art of Scheduling’, we lamented on how the use of ‘modern computer tools’ had impacted the quality of project schedules. Evidence from projects we are close to suggests that this area remains problematical, with many project managers not possessing the basic skills necessary to control this part of their work.

Before going too far it is important that we understand what a project schedule is and what it should be used for. A project’s schedule must accurately reflect the scope of the project to deliver fit for purpose ‘products’ and the sequence of activities required to deliver the desired outcomes. It should also take into account and document the assumptions it is based on as well as the resources required to achieve it.

When initially created, the schedule will determine how long the project will ideally take; or where there is a pre-determined finish date it will show how this will be achieved (or not). If the prescribed finish date cannot be achieved it will assist in re-strategising the project to work out how it can be. Once agreed, the schedule, with the other parts of the plan, is base-lined and then used to monitor and control the project. Yes, that’s obvious we expect most of you to be saying at this point. However, the key to us is what makes a good and usable schedule i.e. a schedule that accurately refl ects the project’s scope and required sequence of activities to achieve the outcomes and also that can be monitored against and easily updated?

Most project management textbooks will suggest that the starting point to any schedule is the Work Breakdown Structure (WBS), which not only aids the definition of the project’s scope but also assists in breaking it down (decomposing it) to a level where project activities can be defined. It is often said: “if it’s not in the WBS it’s out of scope”.

So how many of you start the scheduling process with a WBS? Or do you skip that part and go straight to the computer and either start typing in the activities from scratch or modify an existing schedule from a similar project? Neither of these methods will facilitate a thorough definition of the project’s scope and can lead to serious omissions.

Too often we see schedules that only contain part of the work necessary to satisfy the client or internal stakeholders – all the work that anyone needs to do to deliver the project needs to be explicitly identified.

Once you know, or think you know the activities involved in delivering the project then what actually determines their sequence? We find that most producers of schedules sequence a project’s activities based only on ‘hard logic’ or mandatory dependencies between activities that have to be adhered (unless you were to risk re-work by ‘fast-tracking’) e.g. you plan not to test something until you’ve built it.

However few schedule producers understand the importance of ‘soft logic’ or discretionary dependencies that are a choice and often relate to preferences or resourcing constraints e.g. Team A will test Item Y after it has finished Item X although logically the two testing activities could be done in parallel. Sensible use of soft logic (with the rationale justified) goes a long way to creating a ‘good’ schedule.

We find that these two points are the tip of the iceberg when it comes to project scheduling with many other relevant points lurking just under the surface of the water waiting to surprise you. For example:

  1. How many of you reading this article can honestly say they understand the meaning and relevance of the terms total float, free float, shared float and negative float?

  2. How many of you understand the importance of identifying and monitoring not only the critical path but near critical paths as well, and taking action to prevent nodal bias influencing your progress. Nodal bias (or merge bias) occurs when two or more (sets of) activities occur in parallel and each has a logical link between its finish date and the following activities. Nodal bias compounds risk, because parallel tasks exaggerate the impact of over-optimistic estimates.

  3. How many of you explicitly refl ect the uncertainty in estimates rather than hiding it away in single point estimates? You can do this simply using PERT in all the software packages, or you can apply a critical chain approach, or use an approach that builds in conditional (what-if) activities and refl ects the schedule based on the probability of those what-ifs occurring.

Why does all this matter? Is it really relevant to every project? Let’s further elaborate on what makes a good and usable schedule.

In the ideal world a normal schedule shouldn’t need to change as it would reflect the defined scope and the preferred and agreed sequence of the project’s activities that should be followed to meet the targets set. The problem with this is that things will inevitably need to change when activities have not gone to plan and the achievement of the end date and interim milestones need to be maintained. If an activity on the critical path slips, or another activity becomes critical, then does that mean the end date consequently moves or does it mean that an alternative sequence or plan will be utilised? The answer is almost certainly the latter.

But to make these changes easily the schedule needs to be understood by all those using it so that when it needs to be changed then familiarity with how the schedule has been derived will assist in making necessary changes. In such cases, understanding the logic used to build the network is critical, as is having sufficient granularity of activity to know how to re-plan. In our experience – too many schedules have incomplete scope, and where the scope is defi ned it is at too high a level with the over-use of fixed dates, or of ‘start/start’ or ‘finish/finish’ dependencies in place – prohibiting easy updating.

So what is the effect on project performance of not having ‘good and usable schedules’? What we see is the production of schedules that are either impossible to achieve, because they don’t reflect the true scope or real activity sequence or real degree of uncertainty in the project, or that in order to achieve them requires extra, unplanned resources and extensive working hours to do so. We also see organisations struggling to revise or update their schedules to reflect project progress and changes because the detailed understanding of the schedule is not there, leading to frustration and excessive re-planning/re-work.

What can be done to overcome these problems? It’s easy to say ‘get back to basics’ but there is an enormous amount that can be learned about project scheduling that software training does not provide. Perhaps it’s about time some of the old textbooks were dusted off and a new generation of scheduling training commenced.

Remember ‘failing to plan is planning to fail’.

 

 

SHARE THIS PAGE

Please consider allowing cookies to be able to share this page on social media sites.

Change cookie settings
No history has been recorded.
Back to top