Recently I was at a practitioner session
where we began to talk about the categorization of work. Inevitably the
conversation moved to what to do with a category or subcategory of 'other'. One
of the participants in our group discussion had mentioned (in their words) “the
extreme amount of time determining and vetting the categories and subcategories
chosen.” They went on to say that their organizational culture operates in such
a detailed oriented way that avoiding the use of terms like “other” is
essential and was accounted for in the timeline for this project.
As a stark contrast there was another
participant in the group whose organization categorized a majority of their requests
in a particular bucket, but despite that they still had quite a few “others” to contend with. Since the others were not the main services they lived with the sea of others.
In my opinion finding a balance that matches
with the organizations requirements is important. For the most part being able
to actively report against them to improve in some capacity is necessary. The
purpose of collecting this data in the first place is to use the information
collected to make some assessments about what is happening in daily operations
and then addressing them appropriately.
To achieve this level of balance we need to
commit to those who will be consuming the output of collected data that all
items which are reported on as other will be reviewed each month. After all, it
is possible that our initial requirements gathering had missed something, or
that a particular category might have been overlooked. Additionally as our
organization grows we will have new services as well as services that will be
retired so while the “others” need to be reviewed and added, we should also
consider what to do with categories and sub-categories that are simply not
used.
To accomplish this, a monthly report might
need to be run to outline all the requests and incidents whose category
contains some level of other. While some things may stay designated as other,
others may be collected into a group where we can say definitively that these
should be a particular category.
The reason that this becomes important is
that while the vast majority of metrics are measured properly and being used by
teams to look closely at what they are doing, the smaller stats are not being
shared with the right teams who might be able to find out what they are dealing
with.
In this example I am showing an overly
simplified look at this. While the percentage of “others” in comparison to
Application Support is not that large it is important to address what it is made
of. After we expand this we reveal that there are security and HR escalations
in there. Being able to provide this information to teams who are impacted will
allow them to build their own improvement initiatives with reportable data
rather than the “gut” feeling that they were dealing with in the past. This is
only the beginning….
This sounds like quite a bit of work but if
we want to display data in consumable and useful chunks we need to understand
that these fields in our systems have a lifecycle just as much as the things
they represent.
Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn
If you like
these articles please take a few minutes to share on social media or comment
Labels: Category, CSI, ITIL, ITSM, service desk, Service Management Reporting