If you ask managers and employees on different levels many would agree that they spend too much of their time on reporting. This includes report preparation, generation, compilation, reading and presentation.
And yet, if you ask which reports could be banned you always get the same kind of advices. The own defined reports are important and required. But "the other ones” could be integrated, shortened or abandoned. This view of course makes a debate about reporting reductions very tricky. Let’s look at it a bit closer...
Usually in larger corporations weekly or monthly reports get designed to show how an organisation is performing. Whether you look at financials, operations, workforce, risk
items or your project portfolio to just mention a few, the sheer number of reports show all kind of views on progress and performance. Many teams only exist to generate these
bulletins. And many employees spend up to 50% of their time pulling data, consolidating information, feeding into dashboards or painting power point reports. When things go bad, very
soon new statements get designed to regularly supervise exactly this particular process or focus area. And these statements then remain even if the process challenge is solved
meanwhile.
During a reorganisation reporting sees a super hype. While the old views can’t be stopped (yet), new statements get created to show the target state. And if an organisation does not pay attention it might create an over-reported environment which loses productivity big time.
Here are five challenges:
-
Report generation binds a lot of resources not available for other important jobs or key tasks. It’s a fact that every hour spend on a report is an hour not spend
on your core business
-
Too many different statements based on the same underlying data will create inconsistency in the story these statements tell. This is often caused by data taken from
different moments in time. Or information pivoted along different dimensions. Or graphical representations which provide different pictures. And these inconsistencies often lead to more
reports trying to explain how you get from statement one to statement two
-
Many statements try to show a good rather than a critical picture to avoid more reports on that topic. This does not help steering the real issues behind
-
Too many reports do not measure against a pre-defined target value which then leaves the reader with the question “is this a good, acceptable or a bad value I see
here?”. A value not measured against a predefined baseline is not of great help and often just leaves the audience with a nodding feeling
-
Only what you measure you can manage it is said. But what if you manage the wrong things or follow too many measurement points?
In one organisation I had worked for, a consulting company measured for us how productive our programmers and software developers were. It was done by counting how many lines of code each programmer delivered each day. The report found that many developers delivered less than half of their daily capacity. And some programmers did not deliver any lines of code at all. The conclusion first was to get rid of the low-performers and save money by delivering the same with fewer people. But unfortunately we measured the wrong things as it turned out.
While it might sound obvious, it took a while until somebody asked WHY. Looking into the details we then realised that our developers were suffering from admin burden. Writing reports, taking over work from teams that were reduced in the past, too many status report meetings they had to attend were only a few examples why little time was left performing their core tasks (->writing software). Reducing the team further would have lead into a disaster.
How corporations could improve:
-
Before any report gets demanded, ask why it is needed and what will be done with it. If the report does not allow to steer actions or trigger corrections you might
not need it
-
Reports should be stored in a central repository visible for anybody (sensitive exceptions exist). Whenever a new report is demanded, the repository should be consulted.
If an existing report is available (even if not exactly the same) that existing report should be used or adapted
-
To avoid having too many statements after a while, a new report should demand an old one to go. This creates discipline and makes every report a victim from being
abandoned for the good
-
Think of report generation as an external service you had to pay for each time. It’s very easy to ask internal teams for new bulletins. Because these teams are
already here an paid for, it feels like as if those tasks were for free. But what if you had to pay an external vendor? Would you still be willing to pay for these reports? If not,
they might be not important enough and should be stopped
- Whenever you can, define the optimal value against wich you measure (Key Performance Indicator). Then define the deviation which is still acceptable for your case (for example +/- 5%). This gives you a clear range upon which you need to take action if exceeded. If the value you measure is just a nice-to-know figure, why bother?
Many might argue that it is difficult to push back if your boss asks for new dashboards, reports or status views. But try to bring some of above improvement points to the conversation. And while they might not eliminate all reporting needs, you would be surprised how well they usually foster a great discussion.
Chris Frey @chrisfrey.com
