A timely LinkedIn post by Kul Bhushan Uppal, served as a reminder on the purpose of schedule levels and issues around the use of these.

What are Schedule Levels?

AACEi Recommended Practice (RP) 27R-03 – Schedule Classification System, provides a useful definition: “Schedule levels establish the breakdown and amount of detail required for communication and reporting


Terms you may already have heard on projects such as “level 4 detail” or “Roll-up summary” are all methods of defining such breakdowns. AACEi provides further guidance in this respect with RP 37R-06 – Schedule Levels of Detail.

Regardless of the method or terminology adopted, schedules and how they are detailed should ultimately provide the right information for the right audience, or to paraphrase Murray Woolf “develop schedules they’ll actually want to use”.

Typically a project will operate on multiple levels of schedules, summarised low levels of detail may be used initially while the degree of project definition remains low, enabling strategic decision making. As the degree of definition increases, detailed level 4 or 5 schedules will be developed to the work package control level. Level 1 and 2 schedules then serve the purpose of summarising the more detailed level schedules.

The relationship between schedule levels and project definition might look a little like the diagram below:


Thankfully there are several references that offer much more guidance than the above diagram:

  • The AACEi provide this in RP 27R-03- Schedule Classification System mentioned earlier.
  • The UK’s Association for Project Management (APM) in their recent publication Planning, Scheduling Monitoring and Control adopt the CIOB’s Guide to Good Practice in the Effective Management of Time in Complex Construction Projects concept of Schedule Density (see the white paper WP1016 on Schedule density by Mosaic Projects here)

The key consideration when dealing with varying schedule levels is the alignment between them. Do the high levels of detail align with the lower level details, is the same scope being captured across all schedules?

Schedule Silos

The degree of project definition is rarely a single value across all elements of a project. Any particular element may be relatively more defined than others. The diagram below is illustrative of how a typical project WBS may contain varying degrees of definition:LOD03_sm

As a result of these varying degrees of definition, the planning and scheduling of these elements may occur in elemental “Silos”. If the project is contained within a single schedule a basic inspection can identify which elements of the WBS tend to be better defined, and/or have greater schedule detail produced.

By “Silo”, I refer to those responsible for managing their elements, developing schedules with the information available to them. No doubt this level of ownership leads to schedules they will want to use (after all they developed them!), however Planning and Scheduling managers have an overall responsibility to ensure that alignment of scheduling information occurs across the entire project regardless of definition or level of detail.

I use the term Vertical Silo Schedules when each project element generates schedules without referencing other elements: consider handover or interface milestones not being aligned between elements. Horizontal Silo Schedules occur when one element of a project uses schedules that do align across the varying levels: consider when a detailed level 5 schedule does not align to corresponding element for that work at level 3 or level 2.


Dealing with Schedule Silos

Taking a pragmatic approach to Schedule Silos, here are some tips:

  1. Understand and acknowledge that just as a project has varying degrees of definition, so will the project schedule
  2. This may result in multiple schedules being developed and used by the project, by element, by level etc.
  3. Encourage planning and scheduling by those who will be responsible for the work, but ensure alignment with all other project schedules
If your Organisation or Project requires further assistance on Project Planning, please view the Project Planning, Programming and Controls Page, or Contact Page