Schedule Analysis Metrics: Crash Cost Per Unit Time

Schedule Analysis Metrics: Crash Cost Per Unit Time

by | 5 Nov, 2025 | Blog

In recent posts, we discussed how scheduling analysis should not be limited by time optimisation and should also include cost and benefits optimisation.

For that, we can go back in history and uncover one well-forgotten metric that remains relevant today: Crash Cost Per Unit Time. This metric originates from the original Critical Path Method (1957), which focuses on balancing project time and cost.

💡 Crash Cost per Unit Time (CCpUT) is a project management metric used in schedule compression (specifically in the crashing technique) to evaluate the cost efficiency of accelerating a project activity.

💡 Crash Cost Per Unit Time = (Crash Cost – Normal Cost) / (Normal Time – Crash Time)

where,
🔹 Crash Cost: The total cost to complete an activity in its shortest possible time
🔹Normal Cost: The total cost to complete an activity in its normal, less expedited time
🔹Normal Time: The time it takes to complete the activity under normal conditions
🔹 Crash Time: The shortest possible time to complete the activity

The metric helps project managers:
📌 Determine which activities are most cost-effective to crash.
📌 Prioritise crashing activities on the critical path.
📌 Optimise project duration vs. cost trade-offs.
📌 Reduce project duration with minimum extra cost.

Combining CCpUT with ‘Activity Drag’ and ‘Activity Spread’ metrics gives an opportunity to understand where crashing or anti-crashing will have the maximum effect on project benefits.

Alex Lyaschenko

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

Project management myths: low success rate

Project management myths: low success rate

by | 21 Oct, 2025 | Blog

Oxford Business School states that only 0.5% of projects are delivered on their forecast cost, time and benefits. However, this metric is not particularly useful, if not outright misleading. It combines factors that are not directly comparable.

💡 A project is likely to be deemed successful if it delivers more benefits than expected, even if it runs over time or budget.

Time and cost are the primary enabling factors of benefits, not the goal of project delivery. However, these elements don’t contribute equally to the overall value delivered. Sometimes, accelerating delivery may be worthwhile even at a higher cost. In other cases, extending the timeline to reduce expenses may result in a better overall outcome.

Projects involve constant trade-offs between time and cost. Focusing on meeting both targets (time and cost) usually come at the expense of realising full benefits. Conversely, focusing on maximising benefits may result in missing schedule or cost targets.

💡 So, while the 0.5% statistic may be technically accurate, it says little about what truly defines project success.

Oxford Business School hasn’t provided details on how this metric was calculated, nor has it released supporting data on the “on-time” and “on-benefits’ aspects. As a result, we’re only seeing part of the story.

 

Additionally, direct comparison of the original project duration and cost with the final results only makes sense if the scope of the project is the same. Scope is the third primary factor that impacts benefits. Increased cost and duration may be beneficial when the scope is increased.

There is nothing wrong with allowing scope adaptability if it increases the project outcomes.  It just requires appropriate methods for planning and control.

The Project management community should be cautious when referencing this research, which was popularised in the bestseller ‘How Big Things Get Done’. It risks reinforcing a potentially false narrative of widespread project failure.

Alex Lyaschenko

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

Primavera P6 Update. Release 24.12. Milestones now support four dependency types.

Primavera P6 Update. Release 24.12. Milestones now support four dependency types.

by | 10 Oct, 2025 | Blog

In Release 24.12, Oracle addressed a critical issue in Primavera P6, allowing any milestone to be linked with four types of dependencies for predecessor and successor activities.

Many believe that the ability to link any activity and milestone with four types of dependencies is a fundamental requirement for the Critical Path Method (CPM). Arguably, for three years (2022 – 2024), Primavera P6 was not a CPM-compatible tool.

💡 For instance, after the changes in Release 21.12, it wasn’t possible (without hacking the tool) to create a scenario with linking a milestone to a predecessor and successor with Finish-to-Start dependencies. Such logic is common in many schedules. Now  Oracle has recognised the problem and addressed it in Release 24.12.

💡 Export / Import will be easier now as all popular scheduling tools support the basic dependencies for activities and milestones.

It is worth noting that whether Primavera P6 is CPM-compatible now remains an open question. There are valid arguments that other network analysis components are necessary for a system to be CPM-compatible: calendars, lags, hammocks, resources, constraints, deadlines, priorities etc. P6 supports some of them, but not all at once. For instance, it still can’t calculate activity duration considering activity and resource calendars. This is a grey area, as the book “CPM knowledge” doesn’t exist. Everyone has their own opinion of it.

Four basic dependency types are fundamental capabilities for project data modelling, and I am glad to see that this issue is finally addressed in Primavera P6.

Alex Lyaschenko

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

Project Delivery Integrated System: Dashboard vs Engine

Project Delivery Integrated System: Dashboard vs Engine

by | 28 Sep, 2025 | Blog

Imagine your car’s dashboard showing lots of metrics from each subsystem but none of them talk to each other. That’s exactly what “integration” often looks like in project portfolios today.

Each component is managed separately, usually in different systems and by different teams:
🔹 Time → scheduling tool
🔹 Resources → Excel
🔹 Costs → ERP or Excel
🔹 Benefits → another Excel sheet
🔹 Risks → risk tool
🔹 Scope → Word document
then BIM, time-location chart, task management boards, material supply spreadsheets…

Components are presented multiple times:

Cost: cost to deliver and contract cost
Resource: demand and supply
Time: target and forecast
Benefits: benefits for the contractor, client, and end users.
Risks: An opportunity for the contractor could the threat the client.

All of this is then stitched together into a polished dashboard.

But here’s the catch 👉 nothing really changes. Data is shared, but no one adjusts their inputs based on what others provide. The result? A static mirror, not a living feedback loop.

Adding GenAI analysis can make dashboards more attractive, but it doesn’t change the way the project is delivered, as the data in the components remains isolated.

Result? Decision makers look at it and wonder:

💭 “What am I supposed to do with this? Everyone’s busy producing data, but I need information to make decisions. No one asked me what information I actually need or whether these fragmented systems can generate insights that matter.”

Proper integration means that when one element changes, the rest of the system responds accordingly. Without that, dashboards are just pretty dynamic pictures.

🔑 The real challenge: How do we move from simply reporting data to actively managing the dependencies between project components?

How do we enable decisions that balance time and cost, evaluate which risk mitigations are worth the effort, and understand how local optimisations affect overall results?

For that, we need:
📌 methods that integrate all components,
📌 systems that support such methods and
📌 consultants who are good at all components, not just one of them.

The most advanced methodology that truly integrates all components is Success Driven Project Management (SDPM) . In this methodology, a change in one component dynamically changes all others, and it is reflected in the system dashboard.

Alex Lyaschenko

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