What a Project Summary Has to Do Before You Can Act on It

This article is about what capital delivery needs from AI-assisted analysis, not about what any platform ships today.

The tests below are worth applying to whatever your current system produces.

Summarisation is the capability every vendor is demonstrating this year, and it demonstrates beautifully. A record opens, a paragraph appears, the paragraph is well written and broadly correct, and the room is impressed.

Then the capability meets a contested programme, and a well-written paragraph turns out to be worth very little.

A summary that cannot withstand the question “on what basis?” is not analysis. It is an opinion delivered in a confident register.

Why fluency is not the test

In capital delivery, a reading of the situation is rarely accepted quietly. It is challenged — by the contractor, by the client's commercial team, by the cost consultant, eventually by whoever is appointed if the matter escalates. A summary that cannot withstand the question "on what basis?" is not analysis. It is an opinion delivered in a confident register.

Four tests separate analysis that survives that question from analysis that does not.

Test one: does it name its sources?

A summary that states a conclusion and a summary that names the fields the conclusion was drawn from look similar on screen and are entirely different instruments. disagreement becomes specific — they are disputing a value in a named field rather than disputing a judgement — and specific disagreements get resolved, while general ones become positions.

Require that any reading points to the data behind it. If it cannot, treat it as a prompt to go and look rather than as a finding.

PMWEB puts this test first on its own buyer checklist for AI, published in September 2026, as a question: can it show the source record behind every number? Its example is the right one. An AI forecast that cites the pay application or schedule revision behind it, which the reviewer can open and check, is analysis. A figure whose only provenance is that the system suggested it is not.

Analysis that names its sources: the PMWEB 2026 AI Assistant states the basis of its answer and lists every cost code behind the

figure. Illustrative data.

Test two: can you interrogate it?

A fixed output is a report. You take it or you leave it. What is needed is the ability to ask the follow-up question and have the reasoning traced back to the record.

The distinction shows up in the moment that actually matters, which is when the summary says something surprising. If the response to a surprising reading is to open the module and start checking manually, the capability has produced a suspicion rather than an answer, and it has cost more than it saved.

Test three: is the threshold explained, not just applied?

Take a change order sitting at sixty-two per cent of the original commitment value. A system that flags it has told you a number crossed a line. A system that explains the threshold, shows the commitment history behind the figure, and lets you see the change orders that accumulated to it has told you something you can act on.

Analysis that surfaces the threshold alongside the exception lets you question whether the threshold is right, which is often the more valuable finding.

Test four: does it rank by drift, or by date?

This is the test most systems fail, and it is the one with the largest practical consequence.

Almost every task list, dashboard and action report in our industry is ordered by deadline. What is due soonest appears first. This is intuitive and it directs attention to the wrong things, because by the time a deadline is close the options have narrowed to whatever can be done in the remaining time.

Ranking by drift asks a different question: what is moving away from where it should be? An item due in four months whose trend has deteriorated across three consecutive updates is more deserving of attention this week than an item due on Friday that is on track. The first is still recoverable cheaply. The second requires nothing but for someone to finish it.

Deadline-ordered lists tell you what is late. Drift-ordered lists tell you what is going to be late, which is the only version you can still do something about.

The two orderings produce genuinely different top-five lists from the same portfolio. That is not a refinement of the same output. It is a different instrument, and organisations running deadline-ordered attention are structurally late.

The same tests apply to reporting

The four tests extend directly to self-service reporting and to analysis of the working grid, which is where a great deal of day-to-day project work actually happens.

Producing a report from a plain-language description is a genuine advance for organisations where every new report is a request to somebody else. But a generated report is subject to exactly the same requirement as a generated summary: it must be traceable to the data underneath it. A report that cannot be reconciled to the records it came from will be reconciled by hand the first time somebody senior disagrees with it, and after that it will not be trusted.

Analysis you cannot trace is decoration. It may be accurate decoration, and it will still be treated as decoration the moment it matters.

Apply the tests where you are

None of this requires waiting for a new release. The four tests apply to the reports, dashboards and exception lists your organisation produces today, most of which were not generated by AI at all.

Take your current portfolio dashboard. Can you trace any number on it back to the records behind it without leaving the screen? Can you ask it why? Does it show you the threshold or only the breach? And is it ordered by what is due, or by what is moving?

Most organisations find that their existing reporting fails at least two of the four. That is worth knowing before adding a capability that will inherit the same weaknesses and express them more fluently.

Most organisations find that their existing reporting fails at least two of the four tests. That is worth knowing before adding a capability that will inherit the same weaknesses and

express them more fluently.

Next week: what it takes for a system to raise its hand rather than wait to be asked, and why the value collapses if the decision point is removed to make it faster.