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.