Project Roadmap vs Delivery Schedule

Project Roadmap vs Delivery Schedule

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

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

CPM Challenge: Longest Path vs Total Float

CPM Challenge: Longest Path vs Total Float

Just as programmers are divided between those who start counting from 1 and those who start from 0, planners and schedulers are split between defining the Critical Path via ‘Longest Path’ and ‘Total Float’. But who’s right?

Both methods for defining the Critical Path have their advantage and drawbacks. Let’s explore them.

Longest Path Method

The Longest Path method is beneficial because it includes all activities that directly influence the project’s completion date, even if some of these activities have a Total Float greater than zero. However, this method focuses on the final project end date, which is not always the most critical concern. Project stakeholders are more interested in the delivery of key milestones rather than when the project officially concludes. They need to know the Critical Path in the context of project commitments, typically called deadlines.

The Longest Path method also struggles when a schedule has ‘Start No Earlier Than’ (SNET) constraints that may require to reflect existing limitations. In such cases, the Longest Path can be reduced to a few activities or even one milestone, which may be theoretically correct but practically ineffective.

The Longest Path method has one more critical limitation. Practically, we know that activity duration forecasts are not precisely 100% accurate. This is a risk that an activity formally doesn’t belong to Longest Path but practically drives project completion day. For instance, an activity with just one hour of Total Float may not technically be on the Longest Path, but it must be managed as if it is critical.

Scheduling Fragment N1
In this scheduling fragment, the ‘Go Live’ milestone has the deadline, and there is also an event with SNET constraint. The schedule calculated based on the Longest Path Method shows that only the last milestone is critical but calculated based on the Total Float Method shows all activities and milestones are critical.

Total Float Method

The Total Float method addresses some of the Longest Path method’s limitations, especially when the schedule includes Deadlines and SNET constraints. It can also widen the definition of what is considered critical by including near-critical activities. For example, activities with Total Float of less than 8 hours could be considered critical, allowing for more flexible oversight.

However, this method struggles when multiple calendars are used in the schedule. In such cases, activities on the Longest Path can have a Total Float greater than zero, even though they impact the delivery date. It is essential to identify such activities, as it may be possible to accelerate the delivery date by adjusting the calendar or resource assignments.

Scheduling Fragment N2
In this scheduling fragment, activities 1 & 2 are based on 5d calendar and Activity 3 is based on the 4d calendar (Tue- Fri). As a result, activity 1 & 2 belongs to the Longest Path but have Total Float =1d. The schedule calculated using the Longest Path method shows that all activities are critical. The same fragment calculated using the Total Float method shows that only the last activity is critical.

Which method to choose?

My recommendation: use both, but do it smartly.

The theoretical definition of the critical path with the longest path may be technically correct but impractical for day-to-day project control. The ultimate base should be Total Float.

However, when schedule optimisation is performed, it is useful to know the current longest path as it may be possible to accelerate delivery by shortening an activity with a positive Total Float.

Analysing the project from both the Longest Path and Total Float perspectives gives a better understanding of critical activities and potential risks.

As an option, planners can develop a filter that covers critical activities regardless of applied methods. For that, they can calculate critical path based on Total Float including near-critical activities

and create a filter that shows all activities that are Critical or Longest Path.

Alex Lyaschenko

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