That imbalance should be fixed because the programme is the document heavily tied to the commercial outcome. Flyvbjerg and Gardner, in How Big Things Get Done, put 91.5% of 16,000 projects over budget, over programme, or both. The model rarely ends up in a dispute. The programme frequently does.
Where Analysis Tools Sit Alongside P6 and Microsoft Project
Primavera P6, Microsoft Project, and Asta Powerproject build programmes. They also report on them, but they report from the inside: the tool tells you what the file says, using the same assumptions the planner used when they built it.
Analysis tools read a finished programme from the outside and interrogate its structure. They run quality checks against published thresholds, compare two versions of the same programme to work out what actually changed, trace the critical path, and quantify how much of a completion-date movement each change accounts for. The practical test of whether your organisation needs one: can anyone on the project team answer "what changed between the April and July updates, and which of those changes moved the completion date?" without spending a day on it.
For teams already carrying a BIM and CDE stack, this is a small addition rather than a new platform. It sits at the review point, applied to a file that already exists.
Five Things to Check Before You Buy
1. File format coverage. This is the constraint that decides most shortlists and should be confirmed before any demo.
| Format | Produced by | Common gap |
|---|---|---|
| .xer | Primavera P6 | Widely supported |
| .xml (P6) | Primavera P6 | Widely supported |
| .mpp / .xml | Microsoft Project | Usually supported |
| .pp | Asta Powerproject | Frequently unsupported, and common on Australian and UK projects |
Where a tool cannot read Asta files natively, the workaround is an export to P6 format, which asks the party you are reviewing to hand you a converted file. Conversions lose information and add a step controlled by someone with an interest in the answer.
2. Deterministic calculation, clearly separated from any AI layer. Critical path, float, and delay quantification are arithmetic performed on a network. If a vendor is vague about which numbers are computed and which are generated, that vagueness will follow you into the first commercial conversation where the figures are challenged. Reasonable products compute the numbers deterministically and use a language model, where they use one at all, to write up findings that already exist.
3. Version comparison, not just single-file scoring. A one-off quality score on a baseline is useful once. Most of the value sits in comparing successive updates of the same programme, because that is where scope changes, resequencing, and duration cuts become visible. Comparing versions is where construction schedule analysis software earns its cost on a live project rather than in a post-mortem.
4. Published thresholds you can adjust. The Defence Contract Management Agency's 14-Point Assessment is the common reference set: no more than 5% of activities missing logic, no more than 5% carrying hard constraints, 0% negative float, at least 90% finish-to-start relationships. A tool should show the thresholds it applies and let you change them, because a 400-activity fit-out and a 12,000-activity infrastructure programme do not warrant the same tolerances.
5. Output your commercial team can use. The audience for this analysis is rarely the planner. It's the contract administrator, the project director, and eventually a lawyer. A report that requires scheduling expertise to interpret will sit unread.
Run the evaluation on a real file from a live project rather than the vendor's sample. Sample data is built to demonstrate well. Your own programme, with its inherited calendars, its half-finished resequencing, and the constraints somebody added in 2024, is the only fair test of whether the tool copes with what your teams actually produce.
The Question Your IT Team Should Ask
Project programmes carry commercially sensitive information: rates of progress, resource loading, subcontractor sequences, and the client's own exposure. Before a file leaves your environment, get three answers in writing. Where is the file stored, and for how long? Is it used for model training or product improvement? What happens to it when the analysis finishes?
Vendors that delete source files after processing will say so plainly. Vendors that retain them indefinitely tend to describe the practice in general terms. For an organisation working under confidentiality obligations to a client, this is a procurement question rather than a technical preference. Include it in the same review that covers your CDE.
What the Standards Say
The Society of Construction Law Delay and Disruption Protocol treats the regularly updated programme as the primary tool for managing time (§4.7), which sets an expectation that updates are maintained properly rather than produced for the monthly report. AACE International Recommended Practice 29R-03 covers forensic schedule analysis methods and, more usefully for a buyer, the integrity preconditions a programme has to meet before analysis based on it means anything. Any tool worth evaluating should be able to tell you which of those preconditions the programme fails to meet.
Where to Start
Programme quality checking is the cheapest assurance available on a construction project, and the least practised. The file already exists, the checks take minutes once tooled, and the thresholds are published by organisations with no product to sell. Start with format coverage, insist on version comparison, ask the data-handling question early, and pick something the commercial team can read without a planner sitting next to them.
