Time scheduling


Time scheduling techniques are used to develop and present schedules that show when work will be performed and products delivered. The goals of time scheduling are to:

  • construct a model for use in numerical analysis;
  • calculate dates for components of work;
  • determine where there is flexibility in the schedule.

The time scheduling procedure has three steps.


Time scheduling procedure

Once the work has been identified a model is built that reflects the sequence of working and the time required to complete each component. This ‘logical model’ must be supplemented by external constraints such as external decisions (e.g. a regulatory approval or delivery of a procured component). Once the model reflects the internal logic of the work and the external constraints, the schedule is calculated.

In reality these steps are by no means sequential. The model will be adjusted, constraints will be reviewed and the calculation repeated in order to arrive at the optimum schedule.

The range of techniques available to model, schedule and report the work involved in a project, programme or portfolio is very broad. The appropriate choice of technique depends upon the context and how much information is available at the point when the scheduling is being done. For example, factors affecting the choice of technique will include whether the:

  • scheduling is taking place in the identification or delivery phase of the life cycle;
  • scope of the work is well defined or flexible (traditional versus agile approaches);
  • schedule represents a summary of other schedules;
  • output is aimed at members of the delivery team or external stakeholders;
  • work is inherently innovative or uncertain.

The use of scheduling methods that are inappropriate to the needs of the project, programme or portfolio can cause significant problems. An overly complex approach is just as bad as a simplistic approach, so care must be taken to ensure techniques are appropriate and correctly applied.

The most common mechanism for building a model is a network diagram which is made up of all the interconnected activities required to achieve the objectives. This is the basis for estimating and scheduling work with increasing sophistication. The simplest form of calculating a schedule is critical path analysis (CPA). CPA calculates start and finish dates for all the activities in the network. Some activities will have flexibility (referred to as float) and others will not. The sequence of activities with no float are referred to as the critical path – hence the name.

CPA has two major shortcomings. Firstly, it takes no account of the effect on the schedule of limited resources. This is addressed by further analysis in resource scheduling. Secondly, it assumes a single estimate of the time required to perform each activity. Estimating is an inexact science and it is far more realistic to use a range of duration estimates rather than a single point estimate. This leads to statistical techniques such as PERT or Monte Carlo.

Whatever the technique used to calculate activity dates, the results are typically represented as a form of bar chart known as a Gantt chart.

The main advantage of the network diagram is that is can be frequently updated with new information and quickly recalculated. This is an ongoing process throughout the life cycle and uses information about actual progress to predict the eventual completion of the work.

Activities in the network diagram may have allocated costs as well as durations. A technique that combined the effect of both time and cost as part of project control is earned value management. This measures progress in terms of value delivered rather than elapsed time and is used to provide more accurate predictions of future progress and completion based upon progress to date.


Projects, programmes and portfolios

Network diagrams are most applicable to projects rather than programmes, but even here they are not always the best approach. Network diagrams are ideally applied in a traditional project where there is a specification for a unique output. Two examples of situations where they are not used are:

  • projects that produce multiple repetitive products, e.g. a project to build a new housing estate. In this case a techniques such as line of balance may be more appropriate;

  • agile projects where the performance of activities is far more fluid and a full specification isn’t available to model in the definition process. Agile projects focus more on techniques such as timeboxes and MoSCoW.

Most time scheduling is performed with the aid of specialist software packages. While these packages provide the ability to build and analyse sophisticated models of a project, they also provide the capacity to build very large models. As projects become larger and more complex there is a great temptation to build ever larger models because the computing power available today means that analysis is almost instantaneous.

However, the art of P3 management involves having an understanding of cause and effect as it applies to the work being managed. The larger and more sophisticated the model, the harder it is for a manager to have a good feel for cause and effect when making decisions. Sensitivity analysis can be useful in assessing the impact of different factors on the schedule.

Creating a single homogenous model for a programme is rarely successful. Programmes and larger projects, need to create multiple schedules that may be linked by a few key milestones or arranged as a hierarchy. Ideally, this series of interconnected schedules will reflect the organisation structure to some degree so that individuals can schedule the work that they are responsible for without their schedule being constantly and automatically changed by updates to someone else’s schedule.

Of course, these schedules do not operate in isolation and the inter-dependencies between them must be accommodated. This is where specialist planning resources come into their own, perhaps as part of a support office. These specialists can assess the impact of one schedule upon another and interpret the implications for the management team.

The logical inter-dependencies between projects and programmes in a portfolio should be minimal. If there are significant dependencies between two or more projects, for example, the portfolio management team should consider whether these would be managed more effectively as a single project or programme.



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