How many reports do you receive during a week / month? 1, 5, 10, more? How many of these do you actually read or use? How many of these reports answer the questions you have?
I am sharing a how to guide + example that works very well for me, tried and tested many times.
The key question to build great reports is “What questions does the report need to answer?”
I create a lot of reports for others and I receive a lot of reports. I’d say that 90% of reports in circulation are not useful. Why? Because the person who creates the report did not ask the end user enough questions. The result? A lot of wasted time and a lot of frustration.
I did not know I use a specific report creation method until I explained it to a colleague who asked me “how do you create reports?” (I externalized my intrinsic knowledge so to speak). We used a specific example to talk through how I would create it. I asked tons of questions and started scribbling and drawing on a whiteboard. Afterwards we realized that we had created a how-to guide to creating reports.
The secret to creating a great report is asking questions.
Here it is
Step 1: What questions does the report need to answer?
Step 2: What data do you need / have to create the report?
Step 3: What are drivers and what are outcomes? (e.g. cost is an outcome; it is driven by workload or volume multiplied by cost per h or per unit…)
- Examples for drivers: Activities, sub-projects, tasks, workload, space, volume, shipments, meetings, errors, changes…. etc
- Examples for outcomes: total cost, cost per activity, inventory level, customer satisfaction, profit….
Step 4: Create the report, preferably diagrams only
Step 5: build a rapid prototype of the report and validate it with the end user; then build it
Here a specific example:
- Step 1: How does the cost of this project develop and why did it go up / down / sideways compared to last month?
- Step 2 and 3 combined: we have
- Drivers: chargeable hours, number of hours spent, cost per hour, complaints volume, product changes, time used for product changes …
- Outcomes: total cost, cost for error handling, cost for product changes….
- Step 4: my rapid prototype would be a report with diagrams showing
- Outcome diagrams for the total and its sub-categories
- Driver diagrams
- How drivers relate to outcomes
This might tell you that the overall cost of the project stayed the same although the number of errors that needed to be handled increased by 50% (worrying!) as did the time spent to fix those errors. The only reason this did not result in a cost increase was because you negotiated a much cheaper hourly rate for fixing errors: error volume up, hour volume up, cost per hour down = project cost the same….
I would call that a useful report that allows to take action.