Earned Schedule Metrics Challenge

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.

🔮 Addressed challenge:
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

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.
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. 


Quiz answers

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

Project Quiz: Uncertainties and Risks

Project Quiz: Uncertainties and Risks

Project Results depend on activity and resource uncertainties and risk events. However, these project components also impact each other. Let’s demonstrate it by a Project Quiz.

A project has two streams: 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:
A: 3-5 days
B: 6-8 days
C: 2-3 days
D: 10-11 days

Resource uncertainty
Activities A and C require the same skill, so two resources are needed to perform them in parallel. However, whether the second resource will be available is unclear.

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.

The goal is to complete the project as soon as possible with the fewest expenses.
Therefore, can you find:

a) Project duration (as a range)?
b) Should the risk be mitigated or not?

In the next posts, we will review and analyse answers.

Alex Lyaschenko

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

Doubled Resource Estimated Duration optimisation metric.

Doubled Resource Estimated Duration optimisation metric.

Stephen Devaux proposed some control and optimisation metrics in the Total Project Control book.

One of them, Critical Path Drag, was explained previously, read more in this post: Critical path drag. CP Drag helps to identify activities that directly contribute to project duration. The metric measures the potential to reduce project duration. However, activities with positive or negative CP Drag are good candidates for optimization, but they do not guarantee that the desired optimization is possible.

Resource elasticity

There are many factors that impact activity duration. Critical path method challenge activity duration estimation. One of them is resource elasticity.

Resource elasticity

The ability to change activity duration by changing resource allocation.

Stephen recommends an additional CPM metric, Doubled Resource Estimated Duration (DRED), to measure resource elasticity. DRED is a second duration estimate for establishing a task’s resource elasticity.

It is established by asking the question:

“If Activity X is estimated to take (20?) days with current resource estimates, how long would it take if we doubled (or could double) the resources?”

Some reasonable answers are:

  • 1D (Rare)
  • 10D (Said to be “perfectly resource elastic” — same total resource use, double the daily resources for half the time)
  • 12D (Very common situation — some “bang for the buck”, but not perfect).
  • 17D (Some value, but not huge — requires rigorous analysis of the true cost to be confident in implementing such a change).
  • 20D (Not resource elastic at all).
  • 30D (Negatively resource elastic — the resources will get in each other’s way, like in working in a cockpit).

Stephen recommends capturing the DREDs for each activity in a secondary Duration field and performing true cost analysis on them. Cost analysis includes CP Drag, Drag Cost and true cost computation.


DRED metric has some advantages and downsides.


The question ‘If we can double resource allocation, what gain can we get?’ is straightforward, and the answer gives a good sense of resource elasticity.

Easy to implement.
Creating an additional field to capture additional activity duration is not difficult and can be done with most planning tools

It helps to identify activities with the highest resource elasticity.



Lost effort
It requires upfront identifying DRED for all activities, but most of them (>90%?) will never be used. It is a lost effort.

Resource quantity
Resource quantity is not the only option to reduce activity duration. Other options may include changing the resource calendar, changing resource calendars, removing a material supply bottleneck, assigning resources with better productivity, reducing activity scope, changing process, etc.

Optimistic duration
DRED may not be the optimistic activity duration, and that is what we actually want to know. Activity duration is usually a spectrum between optimistic and pessimistic durations. DRED is somewhere on the curve but we don’t know where.

Monte Carlo Analysis
It can’t be used for Monte Carlo Simulation Analysis. MCS requires optimistic, expected and pessimistic estimations.

Triple estimation
What if it is possible to triple allocation? Should we also have the TRED metric? What if a resource with half capacity is available? Could such a resource be useful?

Resource availability
DRED is CP Drag’s complementary metric, but both metrics are not sufficient for optimisation. Practical optimisation depends on resource availability.

Freed-up resources
For schedule optimisation, it is important to understand if an activity can be performed with fewer resources, as freed-up resources can be used to accelerate CP Drag activities. DRED doesn’t give us this vital information.

Alternative approach

An alternative to DRED is Optimistic Activity Duration, or Crash Durations (original CPM method) Original critical path method and beyond.
While Activity DREDs is simpler, Optimistic Activity Duration is more accurate and usable.

There are four options to identify Optimistic Activity Duration:

Collect optimistic durations from SMEs.

Use collected statistical data.

Use primary uncertainties
Calculate Optimistic activity Durations based on primary uncertainties (volume of work, resource productivity, calendars) as 3-point estimations and technological constraints (max possible assignment quantity, min required workload, etc.).

Statistical primary uncertainties
The same as above but use statistical primary uncertainties.

Resource Supply limits

Optimistic activity duration has theoretical and practical values. 

It is important to know the theoretical duration, which is based on technological limitations only, and the feasible duration, which also considers resource supply constraints.


The main idea of DRED is to develop a proxy to complement CP Drag by analysing activity durations with double resource assignment. DRED is easy to understand and use but it needs to be applied carefully. An optimistic activity duration may be different from DRED.

An alternative approach is to identify 3-point activity estimate. It requires more effort but gives more accurate data for analysis and optimisation.

Alex Lyaschenko

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

Overlap activities with a positive lag challenge

Overlap activities with a positive lag challenge

I’ve heard from some planning consultants that negative lags (leads) must be prohibited and replaced with positive lags from a predecessor activity. While this workaround has certain benefits it is not the universal way for managing activity overlaps. It’s essential to also consider the downsides as well.

In general, activity overlaps are beneficial as they accelerate project delivery. However, creating and managing overlaps increases the delivery model’s complexity. Projects can be delivered quicker and with less funds if the complexity can be effectively managed.

There are three possible ways to simulate activity overlaps in a project delivery model:

  • FSNL: Use Finish-to-Start dependencies with negative lags (leads)
  • SSPL: Use Start-to-Start dependencies with a positive lag
  • Apply artificial split of the predecessor activity

Each option carries benefits and downsides.

In this post Artificial activity split problem. Resource levelling challenge, we reviewed the downsides of an artificial split. Now, let’s discuss SS dependencies with a positive lag option.

In this example ‘Activity D’ could/should/must start 1 day before the milestone.

Currently, the milestone date is driven by the completion of Activity C. So, replacing the FS-1d dependency with SS+3d lag is possible. Each activity and milestone’s start and end dates will be the same.

The SSPL workaround addresses some problems but also creates other planning simulation issues.


There are reasons why planners may want to use SSPL instead of SSNL.

Benefit 1
For some people, it is easier to imagine a delay than overlap.

Benefit 2
Negative lags can be used to hide project delays, and it is easy to prohibit them completely rather than to identify such cases.

Benefit 3.
Situations when the start of the successor’s activity is before the start of the predecessor’s activity look like anomalies.

The start date of Activity D is before the start date of the Milestone. Practically, there is no anomaly in this example as the milestone is not an activity (just a logical connector), and the start date of Activity D is later than the start dates of all predecessor activities (A, B, and C).

However, the logical anomaly is possible in other scenarios and must be addressed.

Benefit 4.
An overlap may be linked to achieving the volume from the predecessor activity.
For example, when 80% of volume activity C is achieved, the successor can start. In this case, the SS + lag dependency is the correct representation of logic. However, to simulate it correctly, activity and lag need to be volume-based, not duration-based. 80% of duration may not be the same as 80% of volume.

Unfortunately, many popular planning tools don’t support volume lag. Read more in the post: Volume lags


The SSPL approach has downsides.

Problem N1
The duration of positive lag (SS+ 3d) has to be aligned with the predecessor activity duration (4 days). There are MANY reasons why the duration of Activity C may change: change in activity or resource calendars, change in resource assignment, clarified volume of work, etc. Regardless of the change, the duration of the lag must be revised and updated. It may not be easy to identify which schedule changes impact lag duration.

Problem N2
The Milestone has non-driven predecessor activities (A and B). If any of them are delayed and push the milestone, it should also push the start of Activity D. However, as it is linked to Activity C only, the schedule incorrectly shows that Activity D can start as planned. As a workaround Activity D may have SS + lag logic to each predecessor activity but it even further increases complexity due to the problem N1.

Problem N3
If Activity C has a delay after it commences, it will push the milestone but not Activity D.

Problem N4
The SS + lag logic actually doesn’t address Benefit N2. Projects can still hide delays with the SS + lag by not updating the duration of lag correctly.

Problem N5
This workaround only works if the lag calendar is the same as the predecessor calendar. Popular planning tools have limited capability to configure lag calendars. Microsoft Project applies successor calendar. Primavera allows configuring the lag calendar, but configuration can only be done for the whole project, and it could be scenarios when it lag calendar need to be associated with successor duration, not predecessor.

Problem N6
The above problems may impact the result of the Monte Carlo Simulation Analysis. Read more on the post: Artificial activity split problem. Resource levelling challenge.


Activity overlaps are beneficial but must be correctly simulated in the project delivery model.

Application of the ‘SS + lag’ logic is relevant for some scenarios, but it is not a universal way to represent activity overlaps. This approach has downsides that downgrade potential benefits.

Alex Lyaschenko

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