Reporting for Major Projects

101: start with the reader and the decision

Use the Data guide first if your team cannot explain where a number came from, what it means or which period it describes. Then define the job this report must do. A contractor progress review, an executive funding decision and an operational handover need different views of the same project.

Write a short reporting brief before opening the dashboard tool: who will read it, what they already know, the question they need answered, when they need the answer and what action is available. Agree the required detail with that audience. Preserve the contractual record while giving decision makers a focused explanation they can use.

• Name the decision owner and the meeting or deadline the report supports.
• State the reporting period, comparison basis and any material information gaps.
• Ask which decision would change if the result were different. Remove measures that serve no defined purpose.

Implementation: build the reporting calendar backward

Begin with the decision meeting and report issue date, then work backward through approval, corrections, reconciliation and source submissions. Agree the reporting boundary and time zone with contractors and internal teams. A calendar that gives the last contributor the same deadline as the report author leaves no room to check the combined story.

Scroll sideways or use the arrow keys to see all columns.

Adapt the dates for actual working calendars, holidays, time zones, contract obligations and available review time. Assign an owner to every handoff and a route for late submissions. The issue date does not change the performance period: a December report published in January is still a December report.

Orion Matthews and Tonya White's harvest process adds a practical rhythm: collect, review the reports, correct the inputs and repeat before the final reporting position is locked. Plan those rounds into the calendar. The Data guide explains the identifiers, ownership and snapshots behind them.

Align the dates before comparing the numbers

Keep the source status date separate from the extraction time, dashboard refresh time, submission deadline, approval date and report issue date. A refresh this morning can still contain a schedule last statused a week ago. State the time zone where it affects the boundary and identify the dates beside the measures that depend on them.

Aim for compatible cost, schedule and physical-progress cutoffs. Where that is not possible, show each source date and explain the gap. An agreed accrual, estimate or reconciliation may help bridge it, but label the adjustment and assign an owner. Changing the date label does not align the underlying information.

• Compare planned value, earned value and actual cost on compatible scope and time bases; disclose unresolved timing differences.
• Distinguish period movement from cumulative values, and a genuine change from a correction to an earlier period.
• Name the baseline and forecast versions used in each comparison. A reporting snapshot does not by itself change the approved baseline.
• When later events materially affect the decision, add a clearly dated subsequent-events note instead of silently rewriting the period position.

Current view or December report? Make the difference visible

Use "current operational view" for information that changes as systems update, and "period-end snapshot" for information measured at a defined cutoff. Once approved and distributed, retain the "as-issued record" of what readers received. Reserve "real-time" for a view whose actual end-to-end delay supports the claim.

Scroll sideways or use the arrow keys to see all columns.

For example, a January dashboard may show a revised delivery forecast after December has closed. That is useful current information. The December as-issued report should still reproduce the forecast and evidence used at its approval. If December itself needs correction, distinguish the corrected edition from the original and explain why.

Carry the view type, cutoff and version into exports, screenshots and meeting packs. Keep current and approved-period filters clearly separate. A live source blended into a supposedly locked report defeats the distinction, even when the headline still says "December".

Implementation: build a story the evidence supports

Start with the important change, explain its consequence, then show the available response. A useful sequence is: what changed, why it matters, what we know, what remains uncertain and what decision is needed. Separate an observed movement from a proposed explanation. A persuasive narrative should make uncertainty easier to see.

In a hypothetical package report, a delivery forecast moving beyond the required installation date calls for more than a red status. Show the affected milestone, evidence behind the forecast and the choices the project can still make. Give each proposed action an owner and a decision date.

Lessons from the field: trust is earned through people

Earn that trust by being able to explain the evidence behind the headline. Know the source, the review performed and the unresolved limitation. Make it easy for someone to challenge a conclusion without having to reconstruct the whole report.

When a number changes after publication, explain the correction and its effect on the earlier conclusion. Keep the previous reporting position identifiable. Credibility grows through consistent, candid reporting, including occasions when the evidence does not yet justify an answer.

Treat a report edit as a controlled change too. If someone adjusts a figure or conclusion after generating the report, reconcile it to the approved dataset or record the explicit adjustment and its approval. On reissue, identify affected recipients, dashboards and exports so the corrected story reaches the people using it.

Implementation: make style serve understanding

Create a short style guide for the reporting team. Agree the vocabulary, chart conventions and visual hierarchy so readers can spend their attention on the project. Consistency should help them interpret the message, while the page structure can adapt to the decision.

• Use a headline that states the finding, followed by its implication and requested action.
• Keep sentences direct; define acronyms and avoid language that hides ownership.
• Show units, dates, scope and the comparison basis next to the measure.
• Label current versus period-end views, provisional inputs and superseded editions in words, including on printed and exported pages.
• Use consistent colours and labels; do not rely on colour alone to communicate status.
• Give the main issue visual priority and keep supporting detail readable.
• Check the report at meeting-room size, on a small screen and in print.

Design for attention, then allow time to understand

A reader may notice a red bar or a widening gap quickly. They still need to understand the scope, comparison, cause, uncertainty and available response. Design the report to guide that work. A page full of visible information does not establish that its audience has understood the decision.

In these studies, bits describe information under a defined task and encoding. They are not a count of thoughts or items on a dashboard. The useful question for a reporting team is what the reader can interpret and act on, not how much information the screen can display.

For reporting, treat attention as a resource to spend deliberately. Make the priority easy to find, reduce unnecessary interpretation and leave time to question the conclusion. Keep the supporting evidence available, including exceptions that could change the decision.

• Give the view a clear job. State the finding in the headline and identify the question the audience needs to resolve.
• Reduce competing signals. Remove decorative elements and redundant measures; retain dates, units, comparison bases and material uncertainty.
• Make the comparison easy to follow. Keep scales and layouts consistent where appropriate, label the relevant values directly and use emphasis selectively. Explain any change of scale.
• Sequence the explanation. Orient readers to the scope and period, show the change, explain its consequence, then discuss the options. Keep earlier comparisons available rather than making people remember a vanished chart.
• Give people time to read. Introduce a new visual, pause and check its meaning before adding another claim. Avoid automatic slide advances or dashboard refreshes that change the evidence during discussion.
• Put detail within reach. Use a stable overview with supporting pages or drill-downs for investigation. Simplification must not conceal a contradictory result or remove the basis for challenge.

For example, an equipment-delivery report could first show the forecast delivery date against the installation need date. Then explain the affected milestone, show the evidence and uncertainty, and compare the available responses. Share the detailed package list for investigation. Do not ask the room to interpret every package while you explain a different problem.

Test the report with someone from its intended audience. Ask them to explain the main change, the period it describes, the uncertainty and the decision needed. Where they struggle, revise the explanation or layout and test again. Set meeting pace from that feedback and the decision's complexity.

Ahmed's billboard analogy makes the point memorable: give the reader a clear visual priority.

Lessons from the field: three designs, three choices

Ahmed's companion episode walks through the decisions behind his dashboard designs. These existing examples use sample project names and figures. Study the communication choice, then adapt it to your own audience and evidence. The written explanations carry the lesson; open each image for its finer detail.

Advanced practice: close the loop after the meeting

Record the decision, its basis, the action owner and the next review point. At the next cycle, explain what happened as a result. A report has more value when the team can follow its findings into a changed plan, a resolved uncertainty or an explicit decision to hold course.

Review the reporting system itself. Which pages changed a discussion? Which questions still required a separate explanation? Which measures encouraged the wrong behaviour? Use that feedback to improve the report while preserving the underlying records and definitions needed for comparison.