Any views expressed within media held on this service are those of the contributors, should not be taken as approved or endorsed by the University, and do not necessarily reflect the views of the University in respect of any particular issue.

ITIL Tattle

ITIL Tattle

Blog posts on ITIL and ITSM news and best practice from the ISG ITIL Team

So, you want a new report… Why?

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.



  • 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.


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!


Leave a reply


Report this page

To report inappropriate content on this page, please use the form below. Upon receiving your report, we will be in touch as per the Take Down Policy of the service.

Please note that personal data collected through this form is used and stored for the purposes of processing this report and communication with you.

If you are unable to report a concern about content via this form please contact the Service Owner.

Please enter an email address you wish to be contacted on. Please describe the unacceptable content in sufficient detail to allow us to locate it, and why you consider it to be unacceptable.
By submitting this report, you accept that it is accurate and that fraudulent or nuisance complaints may result in action by the University.