## Monte Carlo Simulation Challenges: Third Probability Axiom.

The standard probability axioms are the foundations of probability theory introduced by Soviet Union mathematician Andrey Kolmogorov almost a century ago. These axioms remain central and have direct contributions to mathematics, the physical sciences, and real-world probability cases, except project management.

How does it happen that some of the fundamental principles of risk analysis are ignored in project management, and how does it impact the result of the Monte Carlo Simulation analysis?

## Probability axioms

We assign a probability measure P(A) to an event A. This is a value between 0 and 1 that shows how likely the event is. If P(A) is close to 0, it is very unlikely that the event A occurs. On the other hand, if P(A) is close to 1, A is very likely to occur. The main subject of probability theory is to develop tools and techniques to calculate probabilities of different events. Probability theory is based on probability axioms that act as the foundation for the theory.

Axiom 1: For any event A, P(A)≥0.
Axiom 2: Probability of the sample space S is P(S)=1.
Axiom 3: If A1,A2,A3,⋯ are disjoint events, then P(A1∪A2∪A3⋯)=P(A1)+P(A2)+P(A3)+⋯

Translating Kolmogorov’s probability axioms in plain language we can say that:
• Probability of risk event is nonnegative.
• Probability of all possible risk outcomes is 100%.
• For every collection of mutually exclusive risk outcomes, the probability of their union is the sum of the individual probabilities.

Project risk management practices and popular risk simulation tools ignore the third probability axiom, making the Monte Carlo Simulation results unreliable.

There are two main reasons:
• the way project delivery models are created;
• the way risk events are analysed, probability and consequences are estimated.

## Risk Analysis Challenge

According to the third axiom, a risk event may have multiple mutually exclusive outcomes. Each has a probability of occurring, and together, they have 100% likelihood.

Traditionally, in project management, risk events are analysed with only two outcomes: the planned scenario vs all other possibilities. If a risk event has multiple scenarios, the impact of one of them (usually the worst case) is analysed. However, the probability of the analysed scenario is not sum of all ‘other scenarios’.

Example:
You can win or lose by throwing a dice. If it is 1 or 2, you win 100\$. If it is 6, you lose 150\$. Otherwise, draw.

In project management, such a risk event is likely to be estimated with 67% probability with a consequence minus 150\$ (as the worst scenario).

• 33% +100\$
• 50% no impact
• 16% -150\$

Widely applied two-dimensional risk registers don’t allow to store of multiple probabilities outcomes in the one risk record. Such thinking creates problems with Risk Matrix and other risk management methods, not just Monte Carlo Simulation analysis.

## Critical Path Method (CPM) challenge

Even if a project can evaluate probabilities correctly and find a way to store risk data, they may not be able to apply it to Monte Carlo Simulation Analysis.

The uniqueness of project risk management as it exists today is in the typical approach of creating a deterministic project delivery model and using it as the base for planning, analysis, and control. It simplifies (or oversimplifies?) project complexity and opens an opportunity to calculate planning and delivery metrics. A few to mention: Total Float, Earned Value, Team velocity, etc.

Implementing the third axiom requires ‘AND’ & ‘OR’ conditions, but applied deterministic models are based on ‘AND’ logic only. There is no way to implement ‘it depends on’ scenarios in CPM, CCPM or Scrum delivery models.

Why is this a problem?
Let’s review the following use case:

A project requires testing. It is impossible accurately predict how many testing cycles are needed. It could be one, two or three test cycles with the following probabilities:

One testing cycle: 30%
Two testing cycles: 60%
Three testing cycles: 10%

In deterministic CPM-based modelling, one of the scenarios must be used as the base, and other options are considered to be a risk event. Depending on which scenario is chosen as the base, the risk could be a threat, opportunity, or both:

• If the base scenario is ‘one testing cycle,’ it can only get worse. So, the risk event is a THREAT.

• If ‘three testing cycles’ is the base, it can only be better. The event is an OPPORTUNITY.

• However, if ‘two testing cycles’ is the base, it can be better or worse, so the event is threat and opportunity. It is a THROPPOTUNITY.

It is quite possible that the project team chose ‘two testing cycles’ be the base scenario for the CPM modelling. In that case, correct risk modelling may not be possible, as risk modelling tools only classify risk events as threats or opportunities.

I believe such tools don’t comply with ISO 31073:2022 Risk Management. ISO 31073:2022 does not recommend a term to describe a risk with positive and negative outcomes, but it states that such an event is possible.

Risk – effect of uncertainty on objectives.

Note 1 to entry: An effect is a deviation from the expected. It can be positive, negative or both, and can address, create or result opportunities and threats.

The result of the Monte Carlo Simulation analysis should not depend on which scenario is chosen as the base.

However, the fact that a base is required impacts how a dynamic delivery model is developed.

Let’s review possible options.

Option 1: ‘One testing cycle’ is the base.

In this case, the risk event has 70% (60% + 10%) probability with two possible outcomes:
2 cycles: 86%
3 cycles: 14%

Scenario probabilities:
1 cycle = 30%
2 cycles = 86% * 70% = 60%
3 cycles = 14% * 70% = 10%

Option 2: ‘Two testing cycles’ is the base.

In this case, the risk event has 40% probability with two possible outcomes:
1 cycle: 75%
3 cycles: 25%

Scenario probabilities:
1 cycle = 75% * 40% = 30%
2 cycles = 60%
3 cycles = 25% * 40% = 10%

Option 3: ‘Three testing cycles’ is the base.

In this case, the risk event has 90% probability with two possible outcomes:
1 cycle: 33%
2 cycles: 67%

Scenario probabilities:
1 cycle = 33% * 90% = 30%
2 cycles = 67% * 90% = 60%
3 cycles = 10%

Theoretically, if a project delivery model is developed correctly, the Monte Carlo Simulation analysis result will be the same regardless of which scenario was chosen as the base. Practically, such analysis is impossible as popular planning and risk management tools have two gaps:
• Planning tools don’t support ‘OR’ logic.
• Risk events have ONE outcome only.

## Solutions

To be able to fully extend probability analysis to project management changes in project management methods, trainings and delivery tools are essential.

People: Theory of probability analysis need to be included in project risk management standards and trainings.

Processes: GERT (Graphical Evaluation and Review Technique) model based on conditional scheduling has to replace CPM models.

Tools: It is essential that project risks are fully embedded in project delivery model. For that risk registers and Monte Carlo Simulation Analysis must part of planning and delivery tools, not to be performed in standalone risk management systems.

Let’s back to the above use case and review possible solution.

There are multiple ways how dynamic delivery model  can be developed. This is one of them: delivery schedule includes all three scenarios and depending of team preference any of them could be the base. It may impact CPM metrics but it would not impact result of Monte Carlo Simulation.

One Test Cycle

Two Test Cycles

Three Test Cycles

#### Alex Lyaschenko

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

## Earned Schedule Metrics Challenge

It sounds like EVM is the topic of the week on LinkedIn 😊 It prompts me to
raise awareness of one popular myth that pops up whenever EVM challenges are discussed.

👺 Myth: “Earned Schedule addresses EVM methodological time management problems”.

One of LI’s comments: “A good alternative to SPI is the Earned Schedule created by Walter Lipke, while SPI makes measurements the schedule deadline in money, earned schedule makes in time (i.e. days) much more reliable and understandable.”

No, it doesn’t! Earned Schedule addresses one problem, but others are so big that time forecast is still unreliable.

The original EVM method is based on the assumption that the remaining part of the project will be performed as it was planned on time of baseline. Walter pointed out that current progress is a better proxy and offered a set of metrics to apply the new ‘TPI – Time Performance Index ‘ proxy.

It is the right idea that the performance factor has to be considered, so Earned Schedule is an excellent addition to EVM and is a better alternative to SPI. However, it does make forecasts reliable! It doesn’t show when the project is likely to be delivered!

There are other challenges that should not be ignored.

💣 Critical path.
We can’t apply the same principle to forecasting cost and time!

A dollar spent on a project will be added to the overall cost regardless of where it was spent. However, a day of delay may or may not impact the delivery date, depending on whether the delay was on a critical path.

The completion date depends on critical path activities, not all activities.
Both EVM and ES ignore this fact.

💣 Risk profile.
Let’s assume a project progressed ideally; all works performed as per the original plan but the probability of one risk is changed from low to high. It means that if the risk impacts activities that are likely to be on a critical path, the expected completion date is changed, but both SPI and TPI can’t show that.

💣 Project stages
Projects progress through different stages, meaning different activity types drive critical paths. Each stage has its unique uncertainties, challenges, and opportunities.

💡 There are no reasons to assume that previously materialised risks will materialise again for the same project!

Even worse, a project may accelerate delivery, pushing risks to later stages of the project. Rush (to initiate/design/develop/etc.) compromising maturity & quality may help with good performance but will likely cause delays during testing.

Due to the unique nature of projects, it is impossible to predict completion dates just by analysing past performance. It must be done by analysing the remaining work and risks. Performance is a complementary factor, not the base for such analysis.

#### Alex Lyaschenko

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

## Project Resource Levelling and Risk Analysis

The results of Project Risk Analysis performed without considering resource limitations are not reliable.

Project practitioners are usually aware that a risk may impact cost, completion date, and resource demand. However, that there is an opposite correlation between resources and risks.

Resource limitations may impact risk consequences.

Let’s review the following scheduling quiz:

## Project with resource constraints and a risk

A project has two streams of work: A->B and C->D and will be completed when both streams are completed.
The project has activity uncertainties, resource uncertainty and one risk.
Activity uncertainties
The duration of each activity is estimated as a range. Let’s consider 2-point estimations to keep it simple.
Resource uncertainty
Activities A and C require the same skill. So, two resources are needed to perform these activities in parallel. However, it is unclear if the second resource is going to be available or not.
Risk
The project has a risk associated with Activity D. Activity D will take one day longer if the risk materialises. There is an opportunity to fully mitigate the risk, but it requires additional expenses.
Project priorities and goal

The goal is to complete the project as soon as possible with the fewest expenses.
The project team needs to determine the overall duration (as a range) and decide whether it is worth mitigating the risk.

## Optimistic project plan

Let’s review an optimistic scenario: each activity takes the least possible time, there are two resources ‘Resoucre 1’, and the risk is mitigated. This project takes 12 days.

## Optimistic plan with the resource constraint

How could the plan be optimised if only one resource is available (to perform Activities A and C)? There are only two possible options: to either delay Activity A or Activity C.

Option 1a: delay Activity A

Option 1b: delay Activity C

It seems obvious to choose Option 1a, mitigate the risk, and complete the project in 12 days.

## Pessimistic project plan

The project plan without resoucre constraints based on pessimistic durations doesn’t look dramatically different.
The critical path is the same as it was in the optimistic scenario. It still makes sense to mitigate the risk and complete the project in 14 days.

## Pessimistic plan with the resource constraints

Let’s add the resource constraint to the pessimistic scenarion. There are still only two possible options: delay Activity A or Activity C:

Option 2a: Delay Activity A

Option 2b: Delay Activity C

It still makes sense to complete Activity C before Activity A. However, please pay attention to Activity D. This activity is no longer on the resource critical path, so incurring extra expenses for risk mitigation doesn’t make sense. If Activity D takes one day longer, it will not delay the project completion date. The consequence of the risk has changed!

Conclusion N1: A change in resource allocation in one part of the schedule may change risk consequences in another part.

This is a very simple example, and we can track the impact of each uncertainty on all project attributes and the overall result. Real-life projects are more complex. Even small projects have uncertainties, resource limitations and risk events. As a result, the Resource Critical Path is volatile. Without a dynamic delivery model, it is usually impossible to understand how a change in one project parameter impacts other project parameters and project objectives.

If the consequences of evaluated risks may change after resource levelling, risk evaluation needs to be repeated after each levelling cycle. However, risk re-evaluation is a time-consuming task, and it would be beneficial if a project delivery system could automatically identify changes in the risk profile after re-levelling is performed.

How long does it take to deliver this project?

If the delivery plan is optimised and used to drive project decisions, it takes 12-16 days, depending on uncertainties. However, wrong decisions can extend the project to 20 days (25%).

Should the risk be mitigated?

This question is not as simple as it may sound and has no YES/NO answer.

Depending on uncertainties, the risk may impact the overall project duration and need to be mitigated, or in some circumstances, the mitigation would not bring any benefits but rather would cause extra expenses.

We found two answers based on edge-case scenarios:

– The optimistic scenario: definitely mitigate risk.

– The pessimistic scenario: definitely not mitigate risk.

These two extremes give an an opposite answer. Optimistic and Pessimistic scenarios have a nearly zero chance of occurring. The actual progress will be somewhere in between these two extremes.

Additional information is required to enable a data-driven decision .

Risk Period

The quiz specified that if the risk is materialised, it takes one day longer to complete Activity D but it doesn’t explain the risk period. A potential period could be:

• Before Activity D start date;
• Any time during Activity D period;
• Specific day during Activity D.

Mitigation decision date

When is the latest date to decide on a risk mitigation strategy? It would be good if we could postpone our decision as we may be better informed by that time.

For example, the above analysis shows that if two resources are available, the risk has to be mitigated regardless of other uncertainties. So, when project commenced we may have some addional information that is not directly related to the project risk but couls help us to choose the best mitigation strategy.

Conclusion N2: Risk mitigation strategy is a variable parameter, not a stable risk characteristic.

Probabilistic approach
An alternative approach is to make a probabilistic decision. The project can calculate the chance the risk impacts the completion date by clarifying risk probabilities and building a probabilistic project delivery model. This approach can provide some vital information for project decisions. However, projects need to be extremely careful with this approach, as a low-quality model may show measling results and drive wrong project decisions.

Data-driven decisions require development of Dynamic Deliery Model that correctly shows how primary uncertenites and risks may impact project objectives (time, cost and benefits).

Could different project teams be using exactly the same initial information to develop a model that gives accurate and consistent outcomes? Could it be an another quiz?

#### Alex Lyaschenko

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

## Schedule Health Metrics: Activity Constraints

In this article, we continue to review metrics for schedule health analysis. The first part, “Missing Dependencies” was covered here. Now let’s talk about activity constraints.

There are some project situations that require the use of constraints:

## Delayed Start

Sometimes a project has a situation when it is impossible to start the activity even if all prerequisite work is completed.

Example: Project is ready to start testing but the test environment is only available from next week.

If a Project has committed dates, we need to understand how the project is performing against these commitments, also known as project deadlines.

Example: Based on the business case project committed to delivering three Outputs by 1st October, 1st January and 1st of April.

## Locked Dates

Some projects have locked dates when there is no flexibility to move the start and finish dates.

Example: The Olympic opening ceremony in Brisbane is locked to 23 July 2032.

## As Timely As Possible

If there is flexibility when activity could be performed without impacting key delivery dates there are three options to specify the start and finish date:

• As Soon As Possible (ASAP)
• As Late As Possible (ALAP)
• As Timely As possible (ATAP)

Starting an activity ASAP is usually considered the best approach. In practice, however, starting the activity as soon as it can or leaving it ALAP can both have problems associated with them. ATAP could be achieved with constraints, lags or calendars. Constraints are more visible and often are the best approach.

Examples:

• If the project might require delivery through the Caribbean in September, they might want to put in a constraint to delay the trip until October 15, after the height of the Atlantic hurricane season.
• A union contract may expire on June 3, with the potential for a strike. In that case, the project might want to make sure that certain work gets performed before then.

How many constraint types are required to simulate these scenarios?

All possible scenarios in projects could be specified with only two types of constraints:

• Start No Earlier Than (SNET)
• Finish No Later Than (FNLT)

No Earlier Than (NET):  Prevent an activity from being scheduled to start before a specific calendar date.

No Later Than (NLT): Specify that an activity needs to be finished before a specific calendar date.

‘Deadline’ and ‘Locked dates’ events are presented with a milestone. As a milestone always has the same start and end dates there is no need to have additional Finish No Earlier Than (FNET) and Start No Later Than (SNLT) constraints. It just adds complexity to the schedule.

‘Locked dates’ and ‘As Timely As Possible’ scenarios could be represented by applying SNET and FNLT constraints simultaneously.

ASAP and ALAP are actually not constraints, even though they are listed in constraint types in Primavera and Microsoft Project. ASAP and ALAP could be presented as a switch as it is done in Spider Project.

Activity constraints are essential to represent real-life project scenarios in schedules correctly. At the same time, incorrect application of constraints may have a negative impact on the management of project reserves or even the project delivery dates. Activity constraints may impact Free Float, Total Float and even Project Critical Path. This impact has to be analysed and accepted. So, we need Schedule Health Metrics to identify the incorrect application of activity constraints. There are some nuances that have to be discussed first.

## Constraint Terminology

Scheduling tools use different terms to describe types of constraints.

As explained above only ‘Finish No Later Than’ and ‘Start No Earlier Than’ are true types of constraints.

Primavera has 4 types of Start and 4 types of Finish constraints. Not all planners understand the difference between ‘Finish On’ vs ‘Mandatory Finish’ and ‘Start On’ vs ‘Mandatory Start’. The key difference is that ‘Mandatory’ constraints allow violation of schedule logic and ‘On’ constraints are complementary. As the result, it impacts the calculation of Total Float.

Microsoft Project offers users to decide whether the conflict is allowed:

Also scheduling tools have totally different approaches to managing ‘Deadline’ scenarios.

• Primavera has separate constraints types to simulate ‘Locked Dates’ and ‘Deadlines’ scenarios.
• Spider Project always calculates Total Float with and without the deadline (NLT) It has additional column fields to present and compare both results.

These differences have to be reflected in the Constraints Health Check metrics.

## Hard and Soft Constraints

Some portfolios use ‘Hard’ and ‘Soft’ terms to divide constraints by softness.

There is no common agreement on what ‘Hard’ and ‘Soft’ actually mean.

Some Project Managers assume that ‘Soft’ constraints are ‘nice to have’ constraints and could be deleted if a fast-tracking is required. Others mean that ‘Soft’ constraints refer to resource (not technical) constraints. Arguably, the most popular differential amongst planners is based on a logical priority. ‘Soft’ constraints never violate network logic (but still may generate negative total float) and ‘Hard’ constraints take priority over network logic dependency relationships.

‘Hard’ constraints:

Delay of activity ‘A’ doesn’t push Activity ‘B’. The ‘No Later Than’ constraint followed. Relationship A->B is broken. The project is not logically driven anymore.

‘Soft’ constraints:

Delay of activity ‘A’ push Activity ‘B’. The ‘No Later Than’ constraint is ignored. Relationship A->B is followed. The project is logically driven.

However, some Primavera planners define ‘Hard’ constraints as ‘Mandatory Finish’ and ‘Mandatory Start’ constraints only and others also add ‘Start On’ and ‘Finish On’ constraints to the definition. Recently, I have seen scheduling standards that in one part of the document define ‘Hard’ as Mandatory Start and Finish only, and in another part of the document it also includes ‘Start on’ and ‘Finish On’. This could be driven by different definitions in international scheduling standards.

Planning & Scheduling Excellence Guide (PASEG) published by National Defence Industrial Association (NDIA) defines ‘Hard’ constraints based on Primavera terms (or did Primavera developers apply NDIA term?) and the definition includes 2 types only: ‘Must Finish On’ and ‘Must Start On’.

GAO Schedule Assessment Guide uses Microsoft Project terms (or did Microsoft developers apply GAO terms?) and the definition of the ‘Hard’ constraint includes 4 types: ‘Start No Later Than’, ‘Finish No Later Than’, ‘Must Start On’, and ‘Must Finish On’.

‘Start No Later Than’ and ‘Finish No Later Than’ constraints don’t violate the logic but are somehow still defined as ‘Hard’.

DCMA 14 Points Schedule Assessment

DCMA 14 Points Schedule AssessmentDCMA 14 Points Schedule Assessment includes a metric to control the percentage of Hard constraints: “Number of activities with hard or two-way constraints should not exceed 5%”.

If a scheduled health check includes the terms ‘Hard’ & ‘Soft’, to avoid misunderstanding of the terms there need to be clear definitions established.

## Points to Consider

• All constraints must be explained. Ideally, the clarification has to be in the schedule but if a scheduling tool doesn’t have a feature to document and export this information a separate register should be created.
• As each project is different by nature, criticality and management style it is not possible to define one metric that could clarify that the schedule has too many constraints. At the same time, a number of constraints in a schedule is a very good indicator that the schedule could be not logically driven.
• Some Planners and Master Schedulers fail to appreciate the nuances of constraints and instead restrict their use altogether. Constraints are essential to represent the project work correctly. If constraints are prohibited the schedules could not be used to drive project delivery, only to satisfy someone’s need to say that the project has a schedule.
• What type of schedule health metric to use depends on scheduling tools. Constraints in Spider Project never violate network logic, so metric is not required to control the quality of schedules. In Primavera and Microsoft Project, incorrect application of constraints may impact the calculation of Critical Path and Total Float, so users of these systems have to learn how the constraints work and decide which types of constraints have to be limited or restricted. They need a schedule quality metric to identify constraints.
• If an activity already started it doesn’t matter if the start was constrained or not. Also, if an activity is completed it doesn’t matter if the start or finish of the activity was constrained. Such activities should be excluded from metrics.
• Level of Effort, Hammock and WBS Summary activities should be without constraints. A separate metric should be developed to control that.
• Primavera and Spider Project allow the setting of two constraints to the same activity while Microsoft Project allows only one. It limits Microsoft Project users to simulate all ATAP scenarios. As a workaround, all constraints (presented by milestones) could be stored under the same WBS. Then related activities are linked with the corresponding milestones.
• ‘Locked Dates’ and ‘ATAP’ are actually calendar constraints, not characteristics of activities and ideally have to be realised in the schedule via calendars and not via activity constraint dates. Unfortunately, Primavera is not able to calculate the schedule correctly taking both activity AND resource calendar constraints into account. Planners have to choose between activity OR resource calendars. Microsoft Project and Spider Project don’t have this problem. We will review this challenge in detail in a future post.

It also simplifies the control of constraints as all constraints outside of the WBS are considered as schedule quality issues.

• If an activity is left as late as possible, unforeseeable events can occur that make the activity take longer than anticipated, resulting in missed deadlines. So, it is strongly recommended to use pessimistic estimation as a base for all ALAP activities to have sufficient contingency and not delay the project.

## Schedule Health Metrics: Constraints

Taking all these nuances into the consideration the following Schedule Health Metrics are useful:

Constrained Activities

A number and percentage of activities with constraints is a good indicator that could show that the schedule is not logically driven.

It is possible to develop filters to identify Hard and Soft constraints.

Primavera Hard Constraints Filter

Primavera Soft Constraints Filter

Unexplained constraints

Another Metric could help to identify constraints without an explanation. The method to identify them depends on the way the information is captured.

ALAP activities

Special attention has to be to all ALAP activities.

Technical and Resource Constraints

Apart from DATES constraints, there are other types of activity constraints that also must be taken into the consideration:

• Could an activity be split?
• Does the activity need to be performed on the same date (or shift)?
• How many minimum resources are required to complete the activity?
• Is it technically possible to add more resources?
• Would additional resources increase or decrease overall productivity?

We are going to discuss these types of activity constraints in a future post.

#### Alex Lyaschenko

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

## Schedule Logic Check Metrics

One of the fundamental questions for any schedule health assessment is “Is the schedule logically driven?” There are some scheduling metrics that could help planners and schedulers to find the answer to this question. In this post, we will review some of them, that are related to missing dependencies.

## Missing Dependencies Metrics

Missing logic metrics is a group of metrics known as:

• missing dependencies,
• missing predecessors and successors,
• open start & finish,
• dangling activities.

This check is not as simple as many project managers and schedulers might think. In fact, it is actually very hard to answer the question: Are there any missing or incorrect dependencies in the schedule?

A very popular DCMA-14 Points schedule assessment includes a check of logic (metric N1). Schedulers who are familiar with a scheduling tool (usually Primavera or Microsoft Project) but lacking scheduling knowledge very often apply DCMA-14 “blindly”. Their schedule may have critical logical issues but is reported as a schedule with sufficient quality. I have seen this issue in small business projects and also in large construction programs. So, let’s review what needs to be considered for a comprehensive schedule logic analysis.

Missing Dependencies?

There is no metric that could confirm that a schedule has no dependencies missing.

The fact that each activity (except first and last) has a predecessor and successor doesn’t mean that another successor from/to this activity is not missing. The only way to guarantee that a schedule has correct logic is to implement correct schedule development and maintenance processes and apply control to ensure these processes are followed.

Each reporting period logic changes have to be analysed, documented and explained.

While scheduling metrics can’t guarantee that dependencies are not missing, some of them are good indicators that logic has to be checked and, if required, fixed. There are four primary schedule quality metrics used to indicate that a schedule may have a missing dependency:

♣   Missing Predecessor

All ‘Not Completed’ activities except 1st activity and external incoming activities must have a predecessor(s).

♣   Missing Successor

All ‘In Progress’ or ‘Not Started’ activities except the last activity and external outcoming activities must-have a successor(s).

♣   Open Start

Activities where only the predecessor(s) are either ‘Finish-to-Finish’ or Start-to-Finish resulting in an open start to the activity. All ‘Not Completed’ activities except 1st activity and external incoming activities must have at least one ‘Finish-to Start’ or ‘Start-to-Start’ predecessor.

♣   Open Finish

Activities where the only successor(s) are either ‘Start-to-Finish’ or ‘Start-to-Start’ resulting in an open finish to the activity. All ‘In Progress’ or ‘Not Started’ activities except the last activity and external outcoming activities must have at least one ‘Finish-to-Start’ or ‘Finish-to-Finish’ successor.

There is a number of points that have to be taken into consideration when these metrics are applied:

• A project may have external dependencies and it is not always possible, and in some cases, not recommended to link schedules from different projects. Milestones representing such dependencies do not have predecessors or successors.
• A Project may have Level of Effort (LoE), Hammock and WBS activities. Different scheduling tools implement these types of activities differently and this impacts the “missing logic” analysis.

–   Hummocks in MS Project are shown without a predecessor and a successor but there is no way to identify “Hammock” type of activities in the system.

–   “WBS summary” activities in Primavera don’t need a predecessor or a successor. So they have to be excluded from the analysis. Another metric is required to check that “WBS summary” activities don’t have logic as Primavera permits linking activity to “WBS summary” activity.

–  In Primavera, if all activity successors are linked to LoE or “WBS summary” activities, the activity is actually missing a valid successor. Otherwise, based on the logic, there are no requirements to complete this activity. The same is applicable to predecessors. Such cases could only be identified via a specially developed project report, not via filters.

• If a milestone has “Open Start” or “Open Finish” it actually doesn’t create any issues with logic. Milestones could be excluded from these metrics.
• Microsoft Project has a unique feature to link activities with summary tasks. If this technique is applied it is very hard to analyse logic, as some of the activities are driven by logic from activities and some from summary tasks, so it is not recommended. An additional metric is required to identify summary tasks with processors and successors.

## Filters

Missing logic metrics could be developed via filters in Primavera and Microsoft Project but, as described above, specifics of each tool have to be taken into account. Spider Project already has all these metrics build-in and also allows developing comprehensive additional filters as required.

Primavera filters to identify activities with missing logic:

♣  No Predecessors

♣  No Successors

♣  Open Finish

♣  Open Start

## External Schedule Analysis Tools

When an external schedule analysis tool is used each metric has to be configured to address explained challenges. For example, Acumen Fuse has a pre-developed “Missing predecessors” metric. However, the metric includes ALL activities with missing predecessors. If an activity already started (or completed) it doesn’t matter if it has a predecessor or not. It is recommended to configure this metric to exclude these activities. Otherwise, the Acumen Fuse Report creates “noise” and may incorrectly show that the schedule has predecessors issues when it actually doesn’t.

#### Alex Lyaschenko

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