Time scheduling


Time scheduling is a collection of techniques used to develop and present schedules that show when work will be performed.


The choice of tools and techniques used to develop a time schedule depends upon the level of detail available about the work that needs to be done.

Where the work is well defined, modelling techniques can be used to show the sequence of working and logical dependencies between each package of work. The resulting model can be used to predict start and finish times, and identify where there is flexibility in the schedule.

If requirements are clear but the means to achieve them is less so, or where the requirements are subject to significant change as the work proceeds, then modelling techniques are less appropriate.


Network analysis can be used where the work is well defined. The analysis process has four stages:

  • create a logical model of how the work will be performed;
  • estimate activity durations;
  • calculate timings for the activities;
  • present the results.

Each aspect of the process is considered by the team, using subject-matter experts when appropriate. A schedule agreed by the team is more likely to succeed than one imposed from above.

The logical model is known as a network diagram. This can be drawn in different formats. The common format used by scheduling software is activity-on-node, or precedence networking.

Four types of relationship between two activities can be shown in a precedence network. The most common is ‘finish-to-start’. ‘Start-to-start’ and ‘finish-to-finish’ are also common. Occasionally a ‘start-to-finish’ dependency may be appropriate.

Estimating activity durations needs to consider many factors, such as the effort required, the efficiency of resources, physical constraints (e.g. restricted working) etc. Some activities will comprise work that has been done before and is well understood, others will be new or employ innovative methods.

The simplest form of calculation is critical path analysis. This uses one duration estimate that encompasses all the factors. Critical path analysis calculates earliest and latest dates for the performance of each activity and hence the overall duration of the project. It then calculates the amount that individual activities can be delayed without affecting the project finish. This is known as total float. The longest path (or paths) through the network is called the critical path and is made up of activities with the lowest total float.

A refinement of the network diagram is the program evaluation and review technique (PERT). This uses a weighted three-point estimate for each activity’s duration in place of a single-point estimate. This enables confidence limits to be applied to the result of the critical path analysis.

The most realistic form of analysis is Monte Carlo. In its simplest form Monte Carlo analysis uses the three-point estimate for activity durations but then performs multiple critical path analyses (typically many hundreds) using different activity durations each time. This results in a statistical model of project duration that can be used to calculate the probability of achieving a specific completion date, or calculating a date by which there is an x% probability of finishing.

In Monte Carlo analysis the concept of a critical path is replaced by the criticality of activities, i.e. how frequently they appear on the critical path in the multiple calculations.

The results of all these techniques are typically presented as a Gantt chart.

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

Earned value management combines time scheduling with cost scheduling. It measures progress in terms of value delivered rather than elapsed time. This is used to provide more accurate predictions of future progress and completion based upon progress to date.

Network analysis is not always the best time-scheduling method. A variety of time-scheduling methods have been developed to suit various technical environments. For example:

  • line-of-balance is used on projects that deliver repetitive products (such as a housing estate). This technique is suited to show how resource teams move from product to product rather than the detail of individual activities.
  • time is used (typically in IT) on Agile projects. The project is divided into several discrete periods (or ‘timeboxes’) that typically have durations of between two and six weeks. The work scope and priorities are changed in order to meet the fixed timescale.
  • time chainage is used on linear projects such as roads and tunnels. It shows the timing of activities combined with the physical location of the work.

Most project scheduling is performed with the aid of computer software. The many proprietary software packages available enhance the basic scheduling techniques extensively. They also provide considerable choice in the way that schedules are presented and reported. As with all computer software, the quality of information produced is only as good as the quality of the modelling and estimating data input in the first place.


The overall programme time schedule will reflect all the tranches, projects within each tranche and benefits realisation activity. The scale of programmes often makes it simpler to separate the schedule showing project delivery from the schedule showing benefits realisation.

Dependencies at the programme level will be limited to those that exist between the key deliverables of projects and the relationships between project outputs and dependencies.

Maintaining a detailed network at the programme level is impractical and this kind of modelling is usually restricted to projects. Some specialist software packages allow detailed project schedules to be maintained by the project teams whilst also calculating a high-level programme schedule. This degree of integration can lead to projects having their schedules automatically affected by progress elsewhere. The programme team must ensure that any dependencies between projects and their effects are communicated to the relevant project manager.


The logical 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 team should consider whether these should be managed as a single project or as a programme.

Maintaining an overall portfolio schedule can be done using appropriate software. This requires great expertise and the portfolio support function should employ appropriate specialists.

The volume of activity and complexity of interactions between different parts of the portfolio can be difficult to grasp. Automated calculation in these circumstances can lead to a loss of management contact with an ever-changing detailed schedule. Specialist expertise is needed to maintain the integrity of the schedule and to extract and summarise information that supports decisions. These specialists will normally reside within the portfolio support function.

Ideally, these specialists will provide scheduling support to all the component projects and programmes to ensure consistency. They should also provide expert interpretation of the large quantities of information that will be produced.


Join APM

Sign up to the APM Newsletter.