Whenever someone asks me for a report, my response is usually “Why?  What do you wish to achieve?”

I’m not (just) channeling my inner Mordac, rather I’m trying to make the outcome as beneficial as possible.

Firstly , a report always answers a question, but that question may be unstated or ill-defined.

Secondly, the underlying data is often complex, and understanding the goal will help to frame the best question.

There are two good types of reports, and one poor type.

Purpose

Monitoring

• Where are we?
• Are we on track?
• Is there anything going wrong?

Ideally these would be in the form of exception reporting, highlighting where corrective action is required.  As we’ll see below, there is a risk where exception reporting is replaced with routine monitoring.

Decision Support

• How can we improve?
• Should we change this?
• Was it a success?

These reports are very situational and to-the-point – a decision is pending and evidence is required to support that determination.  Or, in the case of the post-implementation reporting, to feedback into future decision-making.

Question-less Reports

AKA Reports for the sake of reports – reports where no one is asking the question, or needing the answer.  Where a report generates no response, no action, no decision, there is no point!  Routine monitoring reports can slip into this trap, becoming self-perpetuating wallpaper (Paul Wilkinson’s cartoon is less polite!).  Hence exception reports are preferable, explicitly highlighting the need for intervention.

Complexity

Having established the purpose of the report, the data complexity questions should become easier.  For example, do you want to know service requests logged, handled or resolved?  Asking this before understanding the purpose will lead to baffled looks and “what’s the difference?”  Whereas if we’re clear that the goal is to determine appropriate staffing levels for a team, then the work “handled” by the team must be in view, not just the subset of work that was ultimately completed by the team (several teams may handle a request, before the final team completes it).  Of course, a report on the service requests handled by all teams will result in significant double-counting!

Similarly the question of using elapsed time, working hours, etc become straightforward when the purpose of the report is understood.

It is unlikely that the person requesting the report has an awareness of the data possibilities, options or complexity, hence being clear on the purpose is vital.

So, the next time you’re asked to produce a report, ask “Why?” and if you do have to produce a report for the sake of a report, make sure it requires minimal effort – these reports are all cost and no benefit!

(©GamingWorks)

So, you want a new report… Why? / ITIL Tattle by blogadmin is licensed under a Creative Commons Attribution CC BY 3.0