Project Status Report Example: One Week of an ERP Migration

The example

This is week 14 of a fictional ERP migration at a three-site manufacturer, reported on Friday 11 April for a go-live on 18 May. Currency figures are in thousands and millions of pounds. The report is one page because that is what gets read; the detail behind each line lives in the RAID log, the plan and the budget tracker, and the report points at them rather than reproducing them.

Reading the example

• Item - a fixed set of lines that appears every week in the same order. Readers learn where to look, and a line that is missing becomes conspicuous. Rotating the structure to suit the week's news is how a status report stops being comparable with the one before it.
• RAG - red, amber or green against a stated meaning, not a mood. Here green means no intervention needed, amber means being managed with a named action, red means help is required from outside the project. Milestone lines use complete, on track, at risk or missed instead, because a milestone is not a condition.
• Position this week - two or three sentences with a number in them. Compare the schedule line, which names the new date and the float remaining, with a line that says "some slippage in testing". The first can be argued with; the second cannot, which is exactly why it is useless.
• Change since last report - the movement, not just the level. The budget line moving green to amber is the most important fact in that row, and a reader scanning the report in ninety seconds will see it there rather than by remembering last week's version.
• Owner - who to ask. It also stops the report reading as though the programme manager personally owns every line, which flattens accountability and makes escalation harder.
• Decisions required - the reason the report exists. Two decisions, both stated as a choice with options, both addressed to a body that can actually decide. A report with an empty decisions line week after week is either a project with no obstacles or a project that has stopped asking.
• Decisions taken - a short running record so that nobody relitigates the finance UAT window in June. It also gives the reader the context for the constraint they are looking at.
• Next period - five commitments, not fifteen. Next week's report is read against this line, so it is worth being specific enough to be judged.

What makes the amber lines credible

Three lines are amber and two are red, and the report is more believable for it. The pattern that destroys credibility is the one where a project reports green for eleven weeks and red in week twelve. Anyone who has sat on a steering committee has seen it, and the effect is that green stops meaning anything at all.

The schedule line here does the thing that most reports avoid: it says the milestone moved and the go-live date did not, and it says what was consumed to achieve that. Float dropping from nine days to five is the sentence a reader should react to. Reporting only that the date is unchanged is technically true and materially misleading.

The budget line shows the same discipline. It gives spend to date against plan, then forecast at completion against approval, because those answer different questions. Spend to date says what has happened; forecast at completion says whether there is a problem. A report that shows only the first is describing the past. The reasoning behind that is set out in the project status report guide.

Who this report is for

This one is written for a programme board that meets monthly and reads a weekly email in between. It is deliberately not a steering committee pack: there are no slides, no financial breakdown by workstream and no risk heatmap. Those belong in the monthly pack, structured around the decisions the committee is being asked to take, as described in the steering committee report guide.

The audience also explains the length. Everything a reader needs to act is in the first four lines; the milestone rows are for the person who checks dates; the decisions rows are the call to action. A report that has to be read from top to bottom before anything can be understood has ordered itself for the writer rather than the reader.

What this example leaves out

• The distribution and the cadence. Weekly on Friday afternoon to a fixed list, from the same person. A report that arrives on a different day each week trains people not to look for it.
• Financial detail. One budget line stands in for a cost tracker with committed spend, accruals, purchase orders and forecast by workstream.
• Named risks in full. The risks line summarises; the RAID log carries the entries, the owners and the actions. Keeping both in step means they read from the same source rather than being written twice.
• Workstream reporting. Five workstreams feed this page, each with its own weekly view. The consolidation is where inconvenient facts get smoothed, which is why the underlying reports are worth reading occasionally.
• Trend. A single week shows a position. Most readers want the last six weeks of RAG side by side, which a workbook can produce automatically and a written page cannot.
• What was left unsaid. No status report captures the thing everyone in the room already knows and nobody has written down. That is a limit of the form, not of the template.

The workbook version of this page, with the RAG dashboard and milestone view built in, is the weekly IT project status report. The same content as slides for a senior audience is the IT project status report deck.

Examples · All 36 templates