Reporting isn't communication

I’ve worked with some very talented data professionals, and learnt many things from them. And I’ve worked in a lot of different organisations, and learnt one thing - the data will never be complete. It will rarely be accurate, or available in a timely manner. Human beings will enter it, and if you give them a free text field, they’ll put things in there that shouldn’t be in there.

The dream of PowerBI for many data professionals was that finally, reporting would be real time, on-demand, and move away from spreadsheets and PowerPoints written at the last minute. But it relies on the slow and unglamorous work of data governance, and we need reports now, not in ten years time.

And when I speak to reporting analysts, they share their frustrations that the reports they generate aren’t getting the traction they deserve with executives and decision-makers. They feel that if only they could get time with these busy people, they could build something that would meet their needs. Or they complain that the decision-makers don’t seem to be able to articulate what they want from reporting.

The uncomfortable truth is that busy people are busy, and reporting isn’t about communicating all the information you can generate with the data you’ve stitched together. Sadly, it’s about providing timely and clear information to decision-makers. The PowerPoint will live for some time yet.

And you can still generate executive dashboards and automate reporting effectively if you understand what reporting is really about.

(Or put together an effective deck at the last minute.)

It isn’t about slicers and drill-downs.

It’s about providing the information that decision-makers need to make the decision you’re asking, and no more. And being clear about what that decision is.

This same advice applies for governance papers, and presentations in general, but let’s focus on project reporting, and risks, issues, actions and decisions (RAID, for those in the know).

Risks & Issues

A great way to describe risks is to remember the Cause (or hazard, or threat) > Event > Consequence model. And what you are proposed to do about it (the ‘Mitigation’ or ‘Control’.

Bowtie analysis takes this to the next level, but here’s a simple example.

Unclear instructions (Cause) lead to failure to buy the right item at the shops (Event), leading to an inability to cook dinner.

You mitigations might be to prevent the event from occuring (clearer instructions) or reduce the consequence (have multiple plans for different dinners).

In my mind, issues are simply risks that have eventuated, so the mitigation becomes an action that you’re already prepared to take. N..B. You can get into many interesting discussions with risk and project management professionals about this topic with people - have fun.

Actions

In reporting, generally you are not communicating every single activity you’re undertaking so that your bosses boss knows you’re busy. You’re reporting the key next steps, and doing it simply. Even busy people are still people, and suffer cognitive overload from having to read long paragraphs.

Decisions

Be clear about the decision you’re asking for. This is a good practice as it can help clarify your own thinking. Generally, a decision is what you’re asking the SteerCo, project board, or governance committe to do. Some organisations like options - and the rule of three applies. 1 - do nothing, 2 - do the thing you’re not recommending, and 3 - do the thing you are recommending.

This demonstrates that you’ve thought through the risk (or issue) that is outside of your control, and have come up with a solution that you need endorsement or approval of.

A final note

Report by exception. If youre report has Red, Amber and Green statuses, as is common, a paragraph about how well things are going helps no-one. Focus on the ambers (risks that you are doing something about, and what you are doing) and reds (what has gone south, and you need help with).

And remember - reporting is not communicating. This means that you shouldn’t wait until the end of the month to raise problems - these should already have been discussed informally before you lodge a report.