Get in touch
with Primaned Academy!

+31 10 44 25 177


Call directly to one of our staff members.

Claudia Dieleman

+31 6 23 18 81 29

Stefan Hollak

+31 6 13 52 69 64


Schedule Quality: Technical Requirements

by Gert Truyens| In Blog - EN|

As consultants, we frequently come across schedules of substandard quality. You’ve probably seen our top-picks of mistakes as well: overuse of SF-relationships, too many constraints or even the absence of links between the activities. We receive requests to perform a schedule quality analysis more often these days, so it seems that the market starts understanding the importance of quality standards.

We as Primaned can indeed help with assessing the quality of the schedule beyond the standard tests: did you also think of checking your network’s flexibility, robustness and relationship-redundancy? Did you think of the appropriate level of detail? Make use of our wide experience in analysing schedule quality and writing schedule guidelines fitting your or your employer’s requirements. We go that step further to ensure the best possible circumstances to start, execute and close a project.

This blogpost deals with the technical quality of schedules. Schedules should meet certain criteria and in the following paragraphs we describe why this is relevant, what the required standards depend on and what aspects there are to quality. All elements we discuss are part of the industry’s best practices.

Why do you need quality?

Of course, there are commercial benefits in producing high-quality schedules: it can make the difference in winning a tender over a less project controls-savvy contractor or your company might be considered as a more reliable partner to team-up with for future projects.

Depending on what the schedule is to be used for, quality is required to achieve:

  • Reliable outcomes of risk analyses, delay analyses, critical path analyses and what-if or scenario analyses
  • Verifiable robustness
  • Effective management of interfaces
  • Accurate reporting on progress, completion dates, resources and costs
  • An appropriate level of detail
  • Realistic and manageable amounts of contingency, buffers and float

What determines the appropriate standard?

The required quality standards might differ depending on:

1.    Purpose of schedule
What is the schedule used for? The initial, internal assessment of the time required for completion requires different criteria than an in-depth delay analysis during arbitration.

2.    The project phase
During the tendering process, a less strict approach towards best schedule practices might be tolerated whereas during execution, interfaces with other contractors can increase the need for a top-quality schedule.

3.    Strategic importance of the project
Projects with high strategic significance for the Contractor or Owner require higher standards.

4.    Size of the project
Either in time, money or otherwise, large projects might require higher standards than small projects.

5.    Owners and lenders requirements
An owner of a project can have a set of standards within its own company that they impose on all contractors. Lenders can attach conditions or quality criteria to making the funds available.

6.    Industry standards and practices
IT environments and electronics are often seen as industries that lead the market with high standards, some other industries have a less advanced level of maturity.

What defines quality?

In this paragraph we discuss how quality can be measured and which aspects of the schedule are taken into account.

An important “industry standard” is the DCMA 14-point schedule assessment. Come back to our blog soon for our dedicated blogpost with more details on this subject. Although the test has flaws, it is widely known and exists since 2005. This makes it easier to demand complying with the criteria to be tested.

There are different aspects to the quality of a schedule. At least the following 8 points are checked by Primaned when we perform a schedule quality check:

1.    Logic
A schedule needs sound logic. In theory, only the project start and finish milestones can omit a predecessor or successor. All other activities need at least one predecessor and one successor to ensure that there is no broken logic. Also, the right type of relationships have to be used: mostly Finish-Start relationships, limited use of the SS- and FF- type, and the avoidance of the SF-type. If this quality aspect is of substandard level, the outcome of e.g. risk- or scenario analyses can be useless. Finally, redundant relationships should be avoided as they complicate the schedule needlessly.

2.    Robustness
Put in simple terms: the less sensitive a schedule is for changes, the higher the robustness of that schedule is. Robustness can be analysed by executing a risk analysis. One of the results of such analyses is a probability distribution curve that allows to determine the probability of finishing the project before a certain date.

One can talk about Delivery (or Risk), Execution, Critical path or Claim robustness, but the details of these four different types are outside the scope of this post.

3.    Flexibility
A schedule in which all activities can be executed parallel to each other has a flexibility of 100% and if all activities have to be executed sequentially, the flexibility is 0% and of course you want something in between. Constraints and phase-gates (or hubs) restrict the flexibility and are to be used with moderation. Phase-gates are activities with many predecessors and many successors. Please come back to our blog soon for a dedicated blog post on this topic!

4.    Level of detail
One needs to develop a schedule of suitable level of detail. The desired level depends on many factors: purpose of the schedule, size, reporting requirements, etc. There are no strict definitions of the levels of detail available, but some consensus exists for the levels 0 to 3:

Level 0: the start and finish milestones of the project

Level 1: the distinct phases of the project (e.g. design, fabrication, construction, etc.)

Level 2: the different phases are detailed into e.g. disciplines (e.g. concrete works, electrical works, carpentry, etc.). Often these first levels are not suitable for critical path method calculations and don’t require specialized software.

Level 3: the disciplines are split up into individual activities for which the critical path method can be used. This is the level that is usually suitable for integrating in an integral planning.

5.    Integrality and structure
The schedule should cover the complete scope of the project. One should also pay attention to the WBS to be developed and the phasing of the project.

6.    Realism
On the one hand, all the preconditions and assumptions that support the schedule need to be realistic. Attention is required to calendars and holidays, stakeholders and environment, logic, estimations of durations, phasing, etc.

On the other hand, sufficient buffers and float have to be present in the schedule so that the schedule spans a realistic amount of time for executing the works. A realistic buffer should be based on a correctly executed risk analysis and the total float is the spare time between the end of the buffer and the contractual delivery date.

7.    Consistency
Throughout the entire schedule, one should guard consistency between time, budget, scope and risks.

8.    Transparency
The schedule should give the employer insight in the project. This is largely reduced by ignoring risks, hiding total float or lack of substantiation for applied buffers.


There are many reasons why a schedule has to meet certain quality standards. Most of them relate to creating insight in the project. There are some factors that determine how strict the requirements should be e.g. the intended use of the schedule or the size of the project.

Complying with some of the best practices and keeping a couple of simple rules in mind, brings you a long way. For profound analyses of the schedule quality, Primaned as a partner is your best option. We hope that the increasing understanding of the importance of schedule quality doesn’t slack so we can better focus on creating project insight and increase the project success rate!

This blog has been originally posted on on 11 October 2017.