AI for Progress Reporting

A monthly progress report is read by people who will not read it. That is the design problem. The site team knows everything in it already. The client's project manager will read the first page and skim for anything about money or dates. The board will read five lines. Your report has to work at all three levels at once, and most reports are written at one level, usually the wrong one. Reporting is also where an uncomfortable habit lives. The month you first suspect the job is slipping is the month it is easiest to write "on programme, monitoring closely". It is almost never a lie when it is written. It becomes one over about three months. WORKED EXAMPLE: ONE MONTH, THREE ALTITUDES Month 9 of 16, mixed-use scheme. The month's facts, as they come off site: Structure complete to level 6. Curtain walling started, one week behind. Two RFIs outstanding on the plant room layout, both over 20 days. Valuation 9 certified in full. Two variations pending totalling £310k, one with the client since April. One RIDDOR-reportable incident, a fall from a step-up, three days lost. Fire strategy sign-off outstanding from Building Control. Programme shows completion holding at 12 February. For the board, five lines: "Weston Quay, month 9 of 16. Completion holding at 12 February. Curtain walling one week behind, absorbed within float, no impact on completion. Fire strategy sign-off outstanding with Building Control. This is now the principal programme risk; it constrains fit-out from week 44. £310k of variations pending, £180k of which has been with the client since April. Cashflow impact if unresolved by valuation 11. One RIDDOR incident this period, three days lost, investigation closed with actions." Nothing there they cannot act on. The fire strategy is called out as the principal risk, in one line, with the date it starts to bite. For the client, the same month expands to explain and to ask. Curtain walling gets its cause and its float position. The fire strategy gets a specific request naming what is needed and by when. The two overdue RFIs get listed with their ages, because that is the client's team holding them. The variations get itemised with dates of submission, because a report that says "variations pending" without dates lets a four-month-old submission look like this month's. For the site team, none of the above is the point. They need the two-week lookahead, the delivery dates, the outstanding RAMS approvals and who is chasing what. It is a different document with a different purpose, and stapling it onto the client report just buries the things the client needed to see. The mistake almost every report makes is writing one document at the middle altitude and hoping. It gives the board too much and the site team too little. THE RAG STATUS PROBLEM Most reports carry a red, amber, green status. Most of them are green. The pattern to watch for is a project that reports green for months and then goes straight to red. That almost never means it deteriorated suddenly. It means amber was avoided because amber invites questions. Two things make RAG honest. Define the thresholds in advance, so amber means a stated condition rather than a feeling. And make amber cheap: if flagging amber triggers a difficult meeting every time, nobody will ever flag it, and your reporting will keep telling you everything is fine right up until it is not. WHERE AI HELPS Compressing. Give it the full month of detail and ask for the five-line board summary. This is genuinely the best use, because compression is a skill and most people are bad at it under time pressure. Layering. Same facts, three audiences, one prompt each. Consistency between the three matters, and doing it by hand is where inconsistencies creep in. Consistency of format month to month, which is what makes a trend readable. Interrogating your own draft. Ask what a sceptical client PM would question. It finds the soft statements: "progressing well", "minor delays", "being monitored". WHERE IT DOES NOT It cannot decide what matters. Given the month above, AI will report all of it evenly. Knowing that the fire strategy sign-off is the thing that will hurt you, and that the curtain walling is noise, is judgement built from having watched jobs go wrong. It cannot set the RAG status, and it should not be asked to. It does not know the politics. Whether to name the client's own team as the cause of the overdue RFIs, and how to word it, is a relationship decision. FREQUENTLY ASKED QUESTIONS What should be in a monthly progress report? At minimum: progress against programme with the completion position, commercial position including variations and their ages, health and safety, quality, key risks with owners, and the specific decisions or information you need from the client. The commonest omission is the last one. A report that describes the month without asking for anything wastes the one moment each month when senior people on the client side are definitely reading. How do I stop the report being ignored? Put the ask at the top, not the end. Most reports build to their conclusion like an essay, so the request for the decision you actually need sits on page nine. Invert it: completion position, principal risk, what you need from the reader, then the detail behind it for anyone who wants it. If a reader stops after four lines, they should still have received the thing you most needed them to know. Should bad news go in the report or be raised separately? Both, in that order. Raise it directly with the person who needs to know first, then record it in the report. Bad news that appears in a report without warning damages trust even when the report is accurate, because the reader learns it in front of other people. Bad news that is discussed and then recorded reads as management. What must not happen is bad news that gets raised in a corridor and never written down, because then there is no record that anyone was told. Can AI write the whole report from site data? It can write a competent draft from good input, and the quality of the input is the whole story. Feed it a complete set of site records and it produces something usable. Feed it a thin week of notes and it produces confident prose that fills the gaps with generalities, which is worse than a short honest report. The judgement about what leads, what is buried and what the RAG status is stays with you. How honest should the risk section be? More honest than feels comfortable, and specific enough to be actionable. A risk section listing "programme risk" and "cost risk" with amber against both is decoration. A risk section that says fire strategy sign-off is outstanding, that it constrains fit-out from week 44, and that the mitigation is a meeting requested for the 20th, is a working document. Risks with no owner and no date are not being managed, they are being noted.