Your planning tools calculate the delay. They should propose the fix.

The problem: a tool that stops at the diagnosis

The cycle is the same in Primavera P6, Microsoft Project and the other major tools. You enter durations, logic links, constraints, resources and calendars. The critical path engine calculates dates. If they don't hold, the planner looks for a fix: add a crew, work Saturdays, order earlier, split a delivery. They change the schedule, rerun the calculation, look at the result, and start again.

This iterative work relies on the intuition of whoever is doing it. It is slow, rarely documented, and it explores a handful of options where hundreds exist.

Why it happens

Stijn Van de Vonder, at Proove, framed this problem with great clarity in an article titled The one thing all project scheduling tools got wrong. His point: tools help you analyze the problem far more than they help you solve it, because none of them treat corrective actions as input data. Recent advances (probabilistic risk analysis, lean, early uses of AI) improve the diagnosis without changing that logic.

I share his analysis, with one nuance drawn from my years as a planner: teams know their options. The site manager knows a second crane is available, that the crew can run two shifts over the summer, that a given purchase can be brought forward at some risk. That knowledge exists; it simply isn't written down anywhere a calculation could use it.

What changes: options become data

The approach is to declare, up front, the list of available levers: additional resources, alternative calendars, possible sequences, ways of splitting work packages. For each one, you specify the activities it affects and its cost. The engine then explores the combinations under the program's real constraints and presents side‑by‑side scenarios: duration, cost, risk, workload.

The planner does not drop out of the loop. They stop searching for the combination by hand and instead review the best ones, challenge them and choose. The program director, for their part, makes a trade‑off between two or three costed options instead of signing off on a single schedule.

This shift has a cultural consequence that is often underestimated: the decision becomes traceable. You know which options were ruled out and why, which is worth a great deal in a program review or a contractual claim.

In the field

This is the logic of multi‑constraint scenario simulation: import the existing schedule, declare the levers and constraints, generate and compare scenarios, then export the selected solution back to the production tool. On this principle, a team's scenario capacity is multiplied by ten, and trade‑offs are made on quantified differences rather than convictions.

Frequently asked questions

Further reading

• –Module: AI EXPERT
• –Use case: Multi‑program scenario planning
• –Glossary: Critical path, What‑if

Sources

• –S. Van de Vonder, "The one thing all project scheduling tools got wrong," Proove, Knowledge Base.