One of the important schedule quality metrics is ‘out-of-sequence activities’.

“Out of Sequence Activities” (OOS) – a result of executing the works without following the logic as planned.

There are many very good posts that explain what is “Out-of-sequence activity”, “How to identify them” and even “How to remove them from the schedule”. I am not going to repeat that. You can find links to these posts below.

The questions that I wanted to discuss in this post are:

  • Why do projects have out-of-sequence activities?
  • Is it good or bad to have them?

Why do projects have ‘out of sequence’ activities?

The short answer to this question: the plan was wrong. However, there are GOOD and BAD reasons why the plan was wrong:

GOOD reason: The project team is agile.

A project may have OOS activities if teams working on site find a better way of doing things and the project manager/planner didn’t think of it first. Planning guru Rafael Davila from Puerto Rico once said: “If you have out-of-sequence working it does not necessarily mean it is a planning error, it is common when you plan to avoid too many people working at the same time in the same place and then during the course of the job you find out it is convenient to reduce the waiting time. Life and construction works are complicated, pretending to model such with only FS relationships is a utopia.”
Any project has stable technical (business process) and not stable non-technical dependencies to address resource, material, financial and space constraints. If a project delivery team is agile (yes, even construction projects could be agile!) they are constantly looking for an opportunity to remove non-technical dependencies and commence work earlier.

BAD reason: Schedules don’t apply correct logic.

Most project managers and schedulers are aware that there are 4 primary types of schedule dependencies: Finish-to-Start (FS), Start-to-Start (SS), Finish-to-finish (FF) and Start-to-finish (SF). Recognised project management and scheduling standards (PMBoK, APM Body of Knowledge, Praxis Framework, etc) explain each type but somehow miss one critical point:

Four types of project dependencies are mutually exclusive. It is not possible to create a simulation of one type by applying another type correctly.

If a business process requires the application of, for example, SF dependency the scheduling fragment could not be correctly simulated by replacing the SF dependency with FF, SS or SF types.

Next time when you notice that project (or portfolio) scheduling guidelines recommend to minimise the application of SS and FF dependencies and prohibiting the application of the SF type be sure:

  • A Schedule is not going to be used to drive project delivery. Maybe only for reporting.
  • It is going to be many ‘out of sequence’ activities when the progress is collected.

The quantity of SS, FF and SF dependencies depends on the nature of the project. Some projects are going to have more parallel and overlapping activities than others.

It is not possible to define strict percentage targets and claim that the schedule doesn’t have the decent quality only because there are more than 1X% of other than FS dependencies.

DCMA-14 points Schedule Health Assessment

DCMA-14 points metric N4: ‘Finish-to-Start relations’ often get misinterpreted. This is one of many examples (
“The finish-to-start relationship provides the most explicit presentation of the project schedule activities. The other types of relationships, which can be identified in a schedule, are finish-to-finish (FF), start-to-start (SS), and start-to-finish (SF). However, it is not recommendable for these to be used since they are harder to monitor and control.” 

What this metric is actually showing is that a schedule with a high percentage of other FS dependencies requires higher attention. It doesn’t mean that schedules don’t have low quality. There could be valid reasons why there are more than usual SS, FF and SF dependencies or maybe the project is applying SS instead of FS to hide project progress. The reasons must be discovered and accepted.
Also, if a schedule has a very high percentage (some have 100%) of FS dependencies, it is a great candidate for a deep schedule review. It is likely that the project doesn’t have an experienced planner, or the planner is forced to follow low-maturity portfolio standards.
If a schedule has 100% of FS dependencies ‘DCMA 14-points’ incorrectly shows that this metric is ‘Green’, when it should be flashing red.

The quantity of SS, FF and SF dependencies depends on the nature of the project. Some projects are going to have more parallel and overlapping activities than others.

It is a misleading metric and should not be applied blindly.

BAD reason: level of details

Some schedules don’t have the right level of detail. Planned sequenced activities are actually overlapped. In this case, the project may consider completing decomposition or adding lags and leads.


Another reason why projects may have out-of-sequence activities is fast-tracking.

Fast Tracking [Technique]. A specific project schedule compression technique that changes network logic to overlap phases that would normally be done in a sequence, such as the design phase and construction phase, or to perform schedule activities in parallel. (Practice Standards for Scheduling, PMI)

Fast-tracking is always associated with risk. If a project team took this risk and started the successor activity earlier by breaking the technological process, the question that needs to be asked is: “Has this risk been analysed, and if yes, why is the schedule not updated?”. If the analysis was completed without schedule-based what-if analysis, it indicates that the project doesn’t have schedule and risk management integrated.

Scheduling Tools

Projects managed in Primavera and Microsoft Project are likely to have more out-of-sequence activities for the bad reasons. There is still no front-end access to the dependency table, only via the back-end and it is not possible to differentiate a type of dependency in these tools. So, for planners, it is much harder to change logic as they don’t know which dependencies are technical dependencies and should not be touched (unless it is approved fast-tracking), or if it is a dynamic resource dependency.

Primavera recently added a ‘dependency note’ feature, but for large organisations, it would take years to update for the planners to have access to this feature.
Also in Primavera, it’s not easy for P6 planners to change future logic, they focus more on progress updates.

Schedules managed in Spider Project typically have fewer OOS activities as broken dependencies could be easily identified within the tool. Spider Project has front-end access to the dependency table and a powerful filtering mechanism. 

OOS Types

As there are four types of dependencies, there are also four basic examples of how the activity could be OOS. However, as an activity may have lags and leads there are other, more complex scenarios of OOS logic.

It is important to identify all OOS cases, not only broken FS dependencies.


  • Out-of-sequence activities represent broken logic.
  • There are good and bad reasons why projects may have OOS activities.
  • OOS logic has to be identified and fixed including other than FS broken dependencies.
  • It is very important not just to fix already broken logic, but also to analyse why the project has broken activities and, if required, apply changes to the outstanding activities and mature schedule management processes.

Useful links:

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma