How to build a board presentation or business review people can use

14 Nov

A reporting deck should make it easy to see where things stand and what to do about it. The structure depends on who's using it. A board might need to make an investment decision. A customer business review might need agreement on priorities. A monthly progress meeting might need help clearing a blocker.

Start there, then decide which evidence belongs in the main deck.

Choose the right reporting question

These formats can share charts and tables, but their emphasis should differ.

Board presentation
Main question to address: What needs a board decision or attention?
Useful supporting material: Options, performance against plan, risks, financial implications
Quarterly business review
Main question to address: What value did a customer receive and what should happen next?
Useful supporting material: Agreed goals, outcomes, adoption, unresolved issues
Progress report
Main question to address: What changed and where is intervention needed?
Useful supporting material: Milestones, forecast changes, blockers, actions

Treat this as a starting point and follow any governance requirements your organization already has. Decide early whether your deck is a pre-read, a presentation, or both, because a pre-read needs enough explanation to be read on its own.

Put requested decisions near the beginning

Make any approval request specific enough to answer. “Discuss resources” leaves people wondering what you need. “Approve temporary analyst support for the next reporting cycle” doesn't.

Explain what you recommend, why, and which alternatives you considered. If you know what happens if the decision is delayed, say so. Keep decisions and updates clearly separate so readers can tell them apart at a glance.

For a board, we'd put all the decisions together near the front, with detailed supporting slides afterward.

Show performance against a meaningful reference

A number on its own needs context. Depending on what it's for, compare it with a target, a budget, a previous period, or an agreed baseline. Keep definitions consistent from one reporting period to the next, and flag any change to how a metric is calculated or what it covers.

Here's a made-up project comparison:

Launch date
Approved plan: September 12
Current forecast: September 26
Explanation: Integration testing needs additional time
Project cost
Approved plan: $240,000
Current forecast: $252,000
Explanation: Additional testing support

A real slide would also show the reporting date and source. This table shows a two-week delay and a $12,000 forecast increase, so the slide should say whether either change needs a decision.

Build a customer review around agreed outcomes

For a quarterly business review, go back to the customer's original goals. If they wanted a shorter reporting process, show evidence about reporting time. Product usage can help explain a result, but it doesn't prove business value on its own.

Keep measured outcomes separate from estimates. If savings depend on an assumed hourly cost, show the assumption. If it's unclear what caused a result, say so. Include unresolved issues and progress on previous commitments, and give the customer a chance to correct your reading of things.

End with agreed priorities, named owners, and dates, and make clear which actions sit with your team and which sit with the customer.

Make progress reports show movement

A recurring progress deck should show what's changed since the last one. For each major workstream, give the current position and any significant change to the forecast. Keep finished activities separate from finished outcomes.

“Held a testing meeting” is an activity. “Testing criteria approved” is an outcome. Use status labels consistently, define what green, amber, and red mean in your process, and add text so the status is clear without color.

When something is blocked, name the owner, the effect, and the next action. A page full of red indicators isn't much help if nobody knows what needs fixing.

Give risks enough explanation

For each important risk, describe what could happen, why it matters, and what's being done about it. Don't reduce uncertainty to a confident date or a single unexplained score. And keep risks, which might happen, separate from issues, which already have.

If you need an executive to step in, say exactly what you need them to do. If the team is managing a risk within an agreed plan, say that too. Keep the main deck to the items that matter and put detailed registers elsewhere.

Design for repeated reading

Use a stable layout for recurring metrics and keep periods, units, and definitions visible, so readers can compare one report with the next without relearning the structure. Use headings that explain significant changes, keep detailed tables legible, and move supporting records into a well-organized appendix.

Before you circulate a pre-read, ask someone who didn't help prepare it to explain the main decision and the evidence for it. If their version differs from yours, fix the relevant slide before adding more detail.