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

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

Realistic Project Delivery KPI

Realistic Project Delivery KPI

How often have we been told that projects are late and over budget and we need to do something about it?

At the same time, it is an absolute lack of understanding that it could be a sign of project delivery maturity rather than a real issue! The real issue is when ALL projects are on time and budget.

In this post, we will discuss this challenge from different perspectives and try to answer the fundamental question: Do we want all our projects to be on time and budget, or not?

An ideal project delivery

Many portfolio managers, sponsors, and project managers want their projects always to meet committed dates and budgets. An ideal scenario is when ALL projects are delivered on time and within budget, as their performance is often evaluated based on these criteria.

However, what is ideal for individual performance is not necessarily an ideal scenario for a portfolio. Let’s go deeper to a project level to understand why.

Each project ALWAYS has uncertainties and risks. So, it is not possible to predict project duration and cost precisely. It always ranges. A range for project durations and a range for project costs. Something like this famous hat:

Boundaries of these ranges may be unclear for project stakeholders, but they always exist.

In reality, there are rare cases when a range goes to infinity, but it is an exception from the rule and probably another good topic to discuss. The absolute majority of all projects have a distribution of cost and time.

There are many possibilities of how time and cost targets could be combined.

Someone (let’s say a “Sponsor”) decides which of all combinations will define project targets. The committed delivery date defines the target for the duration, and the committed project budget defines the target for the cost.

The probability of meeting both targets is lower than meeting each of the targets.

For example, if a project has agreed on targets and there is 90% chance that the project will be on time and a 90% chance that the project will be on the budget, the probability that both times and budget achieved will be less than 90%.

Different targets that include different types of contingencies may exist, but to keep it simple, assume there is one key set of targets. Delivery beyond these targets is going to be considered a failure.

Some sponsors choose very aggressive targets with low probabilities to meet them; others prefer a conservative approach with a higher probability of success.

When a sponsor doesn’t clearly understand ranges and distribution of possibilities (or are misled by low-quality risk analysis reports), they may assign a target outside the range. Yes, some projects are planned to fail.

Achievable and Realistic

If all projects in a portfolio constantly meet targets, this could mean one of two things:

  • Project managers have magic wands;
  • It was too easy to hit the targets;

Why could not all projects be just managed well and delivered as expected? Because Black Swan events exist.

A Black Swan event:

A Black Swan is an unpredictable event that is beyond what is normally expected of a situation and has potentially severe consequences. Black Swan events are characterised by their extreme rarity, severe impact, and the widespread insistence they were obvious in hindsight.

A Black Swan event is unpredictable (Unknown Unknowns), and you won’t find a related risk in the project risk register. Also, there are predictable (Known Unknowns), unavoidable low-probability / high-impact risks that could significantly impact project delivery. If such risks materialised and the project still meets the targets, it means that this project had a sufficient contingency to cover such risk, which could be the real problem!

From the “Parkinson’s Law”, we know that work expands to fill the time available for its completion. So, projects with significant contingencies (to cover “Black Swan” events) will likely take longer and be more expensive, even if the risks don’t materialise.

Parkinson’s law:

work expands to fill the time available for its completion.

The project delivery paradox

Mature and non-mature portfolios have different approaches to setting up projects and controlling project delivery.

Organisations with a non-mature project delivery don’t plan projects properly or apply deterministic, critical-path-based planning. Executives assign project targets without visibility of possibilities. Their projects take longer and spend more (sometimes substantially more) budgets. However, Portfolio managers rarely understand the actual delivery rate and often have an illusion of good performance.

Once executives of one of my clients decided to increase the project delivery rate from 90% to 95%, their Project Delivery KPI report showed that they were constantly above the 90% threshold. In reality, the actual measures discovered that they were below 40%.

Organisations with the mature project and portfolio management apply probabilistic planning and set the targets based on calculated probabilities. They accurately monitor how the probabilities change during the project’s progress. Their project delivered faster and with less budget, but it is still below the 100% mark. The 80% of on-time & budget projects is usually a good result.

A project portfolio delivery methodology that includes probabilistic methods is SDPM (Success Driven Project Management). SDPM has methods for:

 

  • full integration of scope, time, cost and risks
  • development of probabilistic project delivery plan and schedule
  • set and monitor probabilities of success.

Organisations that implemented SDPM understand how changes in project delivery and a risk profile impact probabilities to meet agreed targets. They control the contingency consumption.

Summary

  • A project with a contingency that covers low-probability / high-impact risks and ‘Black Swan” events is likely to meet planned targets. However, the project is also likely to spend available contingency even if the risks have been avoided (Parkinson low).
  • When all projects in a portfolio always meet targets, it is a sign that project KPIs don’t reflect reality, and the genuine delivery rate could be much lower.
  • SDPM methods focus on building optimised probabilistic project delivery plans, setting up the achievable project and portfolio targets, and controlling probability changes.

Alex Lyaschenko

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

Contract Cost vs Actual Cost

Contract Cost vs Actual Cost

Project-driven companies need to manage several budgets for the same project. Particularly useful to control contract cost (income) and actual cost (expenses) of project.

The actual cost comprises of equipment, materials, resources and other direct and indirect expenses.

Cost Centers
Spider Project unique feature – Cost Centers enable to control several budgets of the same project. Project cost components in Spider Project could be grouped in cost centers to control both: contract and actual costs.

This approach has a number of advantages:

  • To be competitive in tenders, as it is extremely useful to calculate planned profit, taking risks and uncertainties into account;
  • During project execution, project managers can control how their decisions impact profit;
  • Project sponsors can understand the “cost of delay”.

See how Contract Cost and Cost Centers work in Spider Project:

Julia Lyaschenko

PMO | Program Planning & Delivery Specialist | PRINCE2© Practitioner | SAFe© Agilist (SA)