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

 

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

Schedule Logic Check Metrics

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

Critical Path Drag

Critical Path Drag

Majority of project managers are familiar with the critical path method (CPM) and think that they know how to apply it to manage their projects.

Many scheduling software can compute and visualise Critical Path, so it is a no-brainer to use it. Usually, a project manager accepts the calculation as the schedule. The Critical path method doesn’t take resources, material and financial supply constraints into the consideration. So, the next steps become to assign resources, baseline the schedule and start to manage project progress.

This is because the project managers have forgotten that the “M” in CPM stands for method. The reality is that the first network is only the tentative schedule, giving just the data to implement the method fully. Once the initial CPM schedule has been computed and a logic diagram produced, the project manager is in a position to use the critical path method to save time and money. If, for instance, we want to shorten the project duration, we now know where to start: the current critical path!

There are three ways of trying to shorten the project:

1. Shorten the duration of activity on the critical path by:

  • adding extra resources
  • assigning resources with better productivity
  • ask resources to work more hours
  • change delivery method (a backhoe instead of 10 labours)
  • prune scope (gold planning)

2. Start critical activities earlier by:

  • applying anti-crashing method

3. Change logic and remove activity from the critical path by:

  • applying fast-tracking method

But the question is: Where should we add/remove these resources? Where should we review the scope? What will the effect be of such actions on the schedule and cost?

For the answers, we need CPM metrics.

One of the CPM metrics that could help us find the answers to the above questions was proposed by Stephan A. Devaux and explained in his “Total Project Control” book called Critical Path Drag. In the 1st edition, published in 1999, Stephan used the term DRAG (Devaux’s Removed Activity Guide), but since the 2nd edition, it was written as “Drag”.

In his book, Stephan described the Critical Path Drag metric as:

Critical Path Drag

Critical Path Drag is the quantification of the amount of time each activity is adding to the project.

To some extent this metric could be considered as an opposite to the Total Float metric.

Total Float

Total Float is the amount of time an activity can be delayed before its path becomes the longest path.

By contrast, drag is:

  • only#1 on the critical path; and
  • the amount of time by which an activity duration can be shortened#2 before its drag is reduced to zero.

Further decrease in the duration of the activity would not reduce the duration of the project as another path became critical. In other words, it is the amount of time that could potentially be saved on the project by reducing the duration of the activity (or removing an activity completely).

#1,2 The proposed explanation covers the majority of project scenarios, but not all of them. We will review such scenarios below.

Most of the software that computes Critical Path also could calculate Total Float (TF), but just a few can calculate Critical Path Drag, so this metric is still not well known. However, this computation is very important. Without understanding activity drags, well too often, implemented project optimisation measures don’t give the expected effect.

The formula for computing drag on a simple critical path network schedule is as follows:

  • If an activity is off the critical path, its drag = 0
  • If an activity is on the critical path and has nothing else in parallel#3, its drag = its duration
  • If an activity is on the critical path and has other activities in parallel, its drag is the lowest number between:

– activity duration
– total float of the parallel activity with the least total float

A programming formula may look something like this:
= IF (Critical = “Yes”, Min (duration, min({total float of parallel activities}), 0)

#3 Parallel activities belong to a parallel stream. They are not necessarily planned to be performed at the same time as the analysed activity.

Critical Path Drag Calculation

Let’s review the following simple project:

With all “Finish-to-Start” dependencies, the duration of this project is 18 days. Drag for first and last activities is equal to the duration of activities.
The drag for the second critical activity is only 3 days. This means that if the activity will be reduced by 3 days, the project also will be reduced by 3 days. Any further optimisation would not decrease the duration of the project as this activity would not be on the new critical path anymore.

Let’s assume it is possible to add resources to the 10-days activity and complete this activity twice quicker. The new duration of this activity will be 5 days:

The project has a new Critical Path and as we expected duration decreased to 15 days.

Drag for 2nd and 3rd critical activities is 2 days each. However, it doesn’t mean that if both activities are reduced by 2 days, the project will be 4 days shorter! The drag is not cumulative.

Negative Critical Path Drag

Let’s consider a slightly more complex example: a working typical fragment “1 km of Road Construction”. There are only 20 activities in this fragment, but there are much harder to calculate critical path drag manually. Let’s use a scheduling tool, Spider Project, to calculate CP drag for each activity:

1 km of Road Construction.

There are 10 critical activities and all of them have Critical path drag <>0. In this project fragment, the first and the last critical activities have CP drag equal to the duration of the activity. In other cases, drag is less than the activity duration. Also, there are 3 critical activities where drag is less than zero. Let’s analyse how it is possible.
As it was explained in the “Project Anti-Crashing Method” post, in some cases project duration could be reduced by increasing a critical activity duration:

In this example, the CP drag of the activity “C” will be negative. If the duration of this activity is reduced to zero, the duration of the project will be increased from 42 to 50 days. So, CP drag will be minus 8 days.
At the same time, if it is possible to increase the duration of activity “C” by 14 days, the duration of the project will be decreased from 42 to 28 days (!)

Critical Path Drag on non-critical activities

It is logical to think that project duration could be reduced by optimising activities on a critical path only. However, there are project scenarios when decreasing the duration of the non-critical activity could reduce the overall duration of the project.
In the previous post, we reviewed a project fragment when activities have different calendars.

Activity “A” only could be performed on weekdays and activity “B” only could be performed on weekends.

Activity “A” has 4 days of the total float, so it is not on the critical path. However, if we reduce the duration of this activity to 5 days, the overall duration also will be reduced from 14 days to 7 days.

So, the CP drag of activity “A” will be >0. How much exactly? Well, it depends..
If it is based on the activity “A” 5-days calendar, CP drag is 5 days. If 7-days calendar, CP drag is 7 days.

Summary

  • The Critical Path method gives project teams information to optimise their project plans, not the final schedule. The method has optimisation metrics for that.
  • Activity Drag is an important Critical Path metric that allows prediction of how the applied effort would shorten project duration
  • In some cases Activity Drag could be negative
  • When different calendars are applied non-critical activities may have a positive ‘Activity Drag’. Optimisation of these activities would shorten the project duration.

We are going to review other Critical Path optimisation metrics in future posts.

Alex Lyaschenko

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

Hidden Project Schedule Opportunities

Hidden Project Schedule Opportunities

A few days ago, I had organised a poll on LinkedIn and asked a simple question: Can project duration potentially be reduced by decreasing the duration of non-critical activity (total float >0)?

While the poll is still open, and the final result may still slightly change, it is already clear that half of the responders believe that reducing an activity that is not on the critical path would never change the duration of the project, and another half don’t think so. Most of the project participants believe that they know how the critical path method works, so why is there no agreement on a simple question then?
By organising this poll, I wanted to demonstrate the fact that project management is not as simple as it is presented in project management trainings, and even in global standards or organisational frameworks (PMBOK, NASA, etc.). The courses and standards always simplify reality to make it easier to understand.
Apart from project management, it is hard to find another area where professionals continue to apply simplified methods to solve complex and complicated problems, and real project management is never simple. To pass a project management exam, what you need to know is not the same as what we need to know to manage projects!
A real-life project is not just a list of activities with ‘Finish-to-Start’ type of dependencies, as is shown in almost all books that explain project management methods (incl. critical path method) and techniques.

It also includes:

  • Start-to-Start, Finish-to-Finish and even Start-to-Finish dependencies;
  • Double dependencies;
  • Resource limits;
  • Hard & Soft constraints;
  • Different resource & activity calendars;
  • Lags & leads;
  • Risks & uncertainties.

Even the critical path method may not work as expected when these aspects are taken into account.

Let’s now go back to the question in the poll and find the correct answer. So far, in comments to the poll, there are no examples offered, that would demonstrate how a non-critical activity could potentially reduce the duration of the project. Let’s review a small project fragment:

Example

The fragment contains two linked (Finish-to-Start) activities with different calendars. The predecessor activity “A” has six days of duration and a 5-days (Mon-Fri) calendar. The successor activity has 2 days of duration and a weekend (Sat-Sun) calendar.

The duration of this fragment is 14 days. The activity “A” is not on the critical path as it has four days of the total float. However, if we could reduce this activity to 5 days, the overall duration will be reduced to 7 days:

This simple example demonstrates that in some cases, project duration could be reduced by decreasing the duration of a non-critical activity.
It is just one of the examples of “hidden opportunity” in our schedules. There are many others. Such opportunities often exist, but they are not obvious. Unfortunately, MS Project and Primavera don’t have built-in critical path metrics that could help project teams to identify project opportunities. I am going to explain such metrics in future posts.

Alex Lyaschenko

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