Writing a board technology report that earns a decision

Before adding another chart to a board report, write the sentence that explains why the board needs to read it. If the sentence is difficult to finish, the chart may belong in an operational review instead.

Technology activity is not hard to report. Tickets close, projects move and invoices arrive. The harder task is explaining whether the organisation's position has changed and whether directors need to make a choice within their authority.

I prefer a short main report with enough supporting evidence to withstand questions. Brevity should come from choosing the right information, not from removing uncertainty.

State the purpose of each item

Mark an item as a decision, a discussion or information. Then make the content match that label.

A decision item should name the proposed resolution, alternatives and the consequence of waiting. A discussion item should explain what guidance management needs and when a decision will follow. An information item should say why the development matters without quietly asking the board to approve it by silence.

Check the organisation's delegations before putting an operational decision in front of directors. The board should not become a substitute project team. Equally, management should not treat a material exception as routine simply because the technical work is familiar.

Place the requested decision near the beginning. Directors should not have to infer it from an amber status or discover it on the last page of an appendix. If the paper contains several decisions, make each separable so one unresolved issue does not block unrelated work.

Explain movement rather than displaying colours

A status colour is a compressed judgement. It becomes useful only when the reader understands what changed and what the organisation is doing about it.

Describe the exposure, the evidence and the response. If confidence has reduced because a recovery test failed, say which service outcome was not achieved and what temporary arrangements exist. If confidence has improved, explain what was tested rather than merely saying the remediation project is complete.

Keep operational measures where they help answer a business question. A service availability figure may be relevant, but it can conceal a short outage at a particularly damaging time. Add the impact and explain whether the measure covers the whole service or only one supplier's component.

Avoid treating a steady risk score as proof that nothing changed. The impact estimate may be stable while a planned control is late or a compensating arrangement is about to expire. That movement belongs in the narrative.

Use a decision example that exposes the trade-off

Consider this fictional reporting item. It is an illustration, not an account of an organisation's performance.

A business relies on an older integration service. Its current support agreement ends before the planned replacement can be safely delivered. Management recommends a limited extension while completing the replacement, rather than accelerating the cutover without adequate testing.

The main report should explain that recommendation in service terms: the integration supports daily transaction processing, a rushed change could interrupt that processing, and the extension buys time for testing without removing the underlying dependency.

The decision request should identify the extension cost using the actual supplier quote, the scope being purchased and the authority required. It should also state that the replacement remains necessary. An extension is not evidence that the underlying issue has been resolved.

Offer the credible alternatives. Accelerate with a clearly described increase in delivery risk, reduce the first release's scope if technically workable, or fund the extension. Do not include a deliberately absurd option merely to make the preferred one look sensible.

Put uncertainty where readers can see it

Separate known costs from estimates. Name assumptions about timing, supplier availability and business participation. Explain what could move the estimate and what management will do if that happens.

For the fictional integration decision, perhaps the supplier has priced the extension but the cutover effort remains a range. The report should not merge those into a single apparently firm number. It can ask for the known commitment and an explicitly controlled allowance, with conditions for further approval.

This is also where ownership matters. Name who will monitor the replacement and who can accept any remaining exposure. A project manager can track actions without having authority to accept the business consequence of failure. Risk ownership needs to be visible beyond the action list.

Where evidence is missing, include the plan to obtain it. "Recovery capability has not yet been demonstrated; a witnessed test is scheduled" is more honest than describing the service as resilient because a policy says it should be.

Make the next report accountable to this one

Keep a compact decision and commitment log. The next report should show what happened to the previous resolution, including conditions attached to approval. If the board asked for a narrower scope, the next paper should not quietly return to the original proposal.

Report overdue commitments with their consequences. A revised date alone does not explain whether the delay is acceptable. Say what is exposed in the meantime and whether further authority is needed.

The supporting material should be traceable without swamping the main paper. Keep definitions stable, identify the period covered and explain changes to measures. Directors who ask a detailed question should find evidence rather than another summary of the summary.

A well-written report cannot compensate for a decision that management has not worked through. Do that work first. Then give the board a paper that makes the choice clear enough to approve, reject or amend without having to reconstruct the argument in the meeting.