Project Roadmap vs Delivery Schedule

Project Roadmap vs Delivery Schedule

by | 27 May, 2026 | Blog

Project Roadmap vs Delivery Schedule

We must stop applying critical path analysis to roadmaps.
A project roadmap is a high-level view used to communicate progress or intent. It contains limited detail, simplified logic, and no resource modelling. It is a communication tool.
Roadmaps may be known as Program Roadmap, Integrated Timeline, Summary Schedule, Control Schedule, L3 schedule, etc.

A delivery schedule is an execution model. It answers Who? Do? What? When? and Why? questions and reflects existing constraints.

The fundamentals differences are:
• A roadmap may represent a wish plan or a simplified view of a delivery schedule.
• Roadmaps are drawn. Delivery schedules are calculated.
• A project can function without a roadmap. It can’t operate without a delivery schedule.

Roadmaps and scheduling tools

Roadmaps can be created in many tools: whiteboards, Excel, PowerPoint, Visio, Planner, DevOps, Jira, Primavera P6, Microsoft Project, Spider Project. There are also dedicated tools, such as Office Timeline, and add-ons like SSI Tools for Microsoft Project.

Execution schedules, by contrast, require specialised systems.
In basic planning approaches such as Gantt, Kanban, or Last Planner, all scheduling data is estimated and manually calculated. These approaches can be supported with simple tools like Excel, Planner, Trello, or even Post-it Notes Boards. There is a wide range of solutions available. 

In basic network-based methods, including Critical Path Method (CPM), some parameters are calculated. This requires specialised scheduling systems such as Microsoft Project, Primavera P6, OPC, OnePlan or Asta. The range of solutions is limited by still enough to choose from. 

With advanced methods like Resource Critical Path Method (RCPM), a large number of parameters are calculated. This requires advanced project delivery systems such as Spider Project or Aurora. The limited number of such tools reflects the complexity of solving project optimisation problems. Choice is very limited. 

Use or misuse

Scheduling systems such as Primavera P6, Microsoft Project, or Spider Project can be used in fundamentally different ways:

  • As modelling tools: to build a true network-based delivery schedule as analytical models
  • As spreadsheets: to manually assemble a Gantt-style delivery plan
  • As drawing tools: to produce a roadmap

Too often, analytical systems are used (shall we say misused?) as drawing tools, while the output is treated as a schedule. This creates one of the most persistent misconceptions in project management: applying critical path analysis to roadmaps. Even if some dates or sequences are calculated, a roadmap is still a roadmap. It is a ‘picture’, not a simulation model.

A roadmap never contains the level of detail required for meaningful critical path or resource critical path analysis. Using colours to highlight key elements is entirely appropriate; treating a roadmap as a computational model of execution is not.

In reality, a single roadmap bar can carry different levels of criticality over time. That matters! Treating such activity as critical or non-critical is a dangerous oversimplification. Two linked tasks in the roadmap may have hundreds of dependencies, and some of them are critical or may become critical considering existing uncertainties. It may be enough to demonstrate “logic in principle” in the roadmap, but ignoring other dependencies may lead to a misleading analysis. 

The right approach is to auto-generate high-level views from a detailed execution model, showing which parts of high-level activities are critical. That requires applying CPM or RCPM to a properly structured, data-driven execution schedule, not to the roadmap itself.

A good example of such a capability is the ‘Roadmap’ feature in MS Project or the Multiple WBS in Spider Project.

Planners and forensic analysts should stop applying critical path analysis to roadmaps. Renaming a roadmap as a “control schedule” or “Level 3 schedule” does not change its nature. It remains a high-level communication view, not an execution model.

Alex Lyaschenko

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

Longest path vs critical path — where theory breaks down

Longest path vs critical path — where theory breaks down

by | 7 May, 2026 | Blog

A month ago, I challenged the LinkedIn PM community with a simple scheduling quiz: calculate the duration of two parallel tasks and analyse the critical path.

It was deliberately designed to expose the gap between scheduling theory and real delivery. Surprisingly, no one attempted to model it properly. Most tried to solve it manually or asked GenAI system for a solution. Maybe it looks too simple to bother even trying? 

Let’s revisit it and see where common scheduling thinking falls apart.

The quiz

Two parallel activities each ideally require 3 resources (6 total), but only 5 are available. We must assign resources, calculate durations, Total Float, and identify Critical and Longest paths.  

This is a common scenario for any project. The full quiz conditions are below.
 

A practical (though not optimal!) solution is:
• Start both activities in parallel
• Assign 3 resources to one activity and 2 to the other
• When the first activity finishes, move the freed resource to the second
Outcome:
• Activity 1 finishes in 10 days
• Activity 2 receives a third resource from day 11 and accelerates from 15 days to ~13.3 days

Detailed quiz conditions 

Detailed quiz requirements (for those who want to model it):
• 2 parallel activities
• Each can use 1, 2, or 3 resources
• Resources can move between tasks but can’t multitask

Resource-driven durations:
• 3 resources → 10 days
• 2 resources → 15 days
• 1 resource → 30 days
• All resources share the same calendar and productivity rate
• Total available resources: 5

Tip: It is easier to model the scenario if we assume that the volume for each activity is 240 units, that a day has an 8h calendar, and that each resource has a 1 unit per hour productivity rate.

Where theory fails

1. CPM gives the wrong project duration
Depending on assumptions, CPM-based planning is likely to produce 10-day or 15-day estimation. Neither reflects reality.

2. Critical path vs longest path
Activity 1 is on the critical path, but not on the longest path. Activity 2 is on the longest path, but not on the critical path. 

3. Float tells the real story
Start of Activity 1 (even though it is on the longest path (!)), can be delayed by ~3.3 days without impacting completion but start of shorter Activity 2 can’t be delayed at all.

So, which one is truly critical?

This breaks a core assumption in many scheduling guidelines. The longest path does not necessarily mean the most critical sequence in the schedule.

Key insights

In real projects, once we introduce:
• complex logic
• dynamic assignments
• resource limits
• calendars
• external constraints
• deadlines
• lags/leads
longest path is often meaningless. What matters is whether an activity has float under existing constraints.

When projects apply Resource Critical Path method, the true critical tasks and real acceleration options become visible.

Schedule optimisation

If we analyse the solution, we will see that the assignment is not optimal, as two resources are idle for the last 3.3 days. The optimal solution is to move the 3rd resource from Activity 1 to Activity 2 on day 7. In this case, each activity will be completed in 12 days!

This optimisation opportunity is far from intuitive.

No one in the LinkedIn discussion identified it. Some proposed a theoretical 50/50 allocation but couldn’t explain how such a split would actually be implemented in practice. And this is a very simple scenario. Real projects involve thousands of activities and hundreds of resources. Finding a truly optimal allocation becomes a complex mathematical problem that requires advanced, resource-driven project data modelling approaches.

Projects are delivered more quickly and with less funding when advanced resource-driven planning and optimisation methods are applied. 

Conclusion

Many guidelines claim that activities on longest path can’t be delayed without delaying the project delivery date. This example demonstrates that the assumption doesn’t hold when real-life project complexity is taken into account.

If we want schedules to support project decisions, not just inform reporting, we need to move beyond Critical Path Method and adopt resource-driven scheduling approaches.

Alex Lyaschenko

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

Total Float Challenge: a deadline with positive Float

Total Float Challenge: a deadline with positive Float

by | 30 Oct, 2025 | Blog

The previous Total Float challenge demonstrated that the lack of a clear, unambiguous definition of schedule analysis metrics may lead to poor project decisions. This challenge was initiated to demonstrate that Critical Path Method exist in different, not aligned realities:

  • Theoretical CPM
  • Practical CPM
  • Software(s) CPM

I invited the Planning and Scheduling LinkedIn community to take on the next challenge: find the Total Float for one of the activities in a scheduling fragment.

I took the previous challenge as the base and increased the complexity by adding two pitfalls:

  1. Positive period against the deadline.

There is a 1-day gap between the forecast milestone delivery (13 days) and the contractual deadline (14 days).

  1. Activity continuing past the deadline.

An additional activity occurs after the deadline, which is a common situation in many projects.

Although these nuances appear minor, they fundamentally affect how the Critical Path is identified. The challenge proved difficult; no one could clearly explain why the practically correct answers differ from those produced by CPM software. Let’s explore why this is the case.

Practical CPM Perspective

Many participants gave the “right-looking” answer: start of Activity B can be delayed for one day without missing the deadline. Some went further, noting that its duration could extend to three days without impacting the deadline. Keep these two numbers in mind -we’ll revisit them soon.

However, in the CPM method Total Float metric measures float relative to the forecast finish, not deadlines. This point, already discussed in the first challenge, is highly contentious, as many CPM systems mix all perspectives into a single metric.

Some planners reviewed the challenge from a forecast perspective and concluded that Activity B has zero float (TFs = 0d) and lies on the critical path, since delaying its start extends the project to 18 days. Others added that it could be extended to two days without affecting the project finish (TFf = 2d).

Critical Path in this fragment: ABD(milestone)E

Delaying start of each activity on this path will delay the milestone (13 days) and end project date (18 days). Factor the forecast and deadlines into the calculation, we can conclude that:

Total Float values should be TFs = 0d and TFf = 2d.

Recovery Gap values should be RGs = 1d and RGf = 3d.

Recovery Gap (RG) is a network analysis metric that quantifies the time required to bring activity back on track to meet one or more project targets. A negative RG value indicates that schedule acceleration is needed. A positive value indicates available float.

But here is the catch: popular CPM tools don’t calculate metrics in that way! 

Software(s) CPM Perspective

If we model this scenario in Primavera P6, Microsoft Project or Spider Project results will be different:

RGs = 0 days, not 1 day as practitioners suggested. TFf and RGf can’t be calculated in Primavera P6 and MS Project systems!

As in Primavera P6 and MS Project is impossible to model TF and RG simultaneously I will perform separate computations.  

Scenario with the deadline modelled in Primavera P6.

Scenario without the deadline modelled in Primavera P6.

Scenario with the deadline modelled in MS Project.

Scenario without the deadline modelled in MS Project.

Scenario modelled in Spider Project.

  • Negative Float metric represents RGs
  • Float Super metric represents TFf 

In all scheduling systems RGs is Zero days (not one). None of systems can calculate RGf (3 days).

Based on CPM scheduling systems, Recovery Gap Start for activity B are different from the practically correct answers.

What CPM Tools show different result?

The fragment contains a second, hidden deadline – the project end date at 18 days.

This deadline is generated during the forward and backward pass calculations and serves as the basis on which CPM tools determine Total Float.

In practice, projects rarely treat the last activity’s finish date as equally critical to every other contractual or business-driven deadline. Yet CPM logic assumes it is.

This leads to misleading outputs – activities that appear critical in the model may, in fact, may have positive Recovery Gaps in reality. As a result, project decisions and claims based on such analysis can be flawed.

This is one of the reasons why schedules used for forensic or predictive analysis often fail to represent project reality. Planners and schedulers tend to place full trust in CPM tool outputs without realising that the underlying logic and hidden assumptions in these systems can distort actual project realities.

Summary

The Critical Path Method is often regarded as a well-defined and consistently applied approach. In reality, it exists as a family of related methods – one described in textbooks and guidelines, another implemented in scheduling software, and yet another practised by planners in real projects.

Even a seemingly simple question like “What is the Total Float for a single activity in a small schedule fragment?” can become surprisingly difficult to answer, as the result depends on which version or perspective of CPM we choose to apply.

The pitfall discussed in this article is only one of several reasons why CPM calculations can yield inconsistent results. It has direct practical importance for predictive schedule analysis and for forensic investigations of project delays.

Alex Lyaschenko

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