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

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.