It depends entirely on what you use the data for. Use as many as you need, but be clear on your needs. I aim for no more than two levels of hierarchy but I'm sometimes tempted to add a third.

In my experience, it is primarily used for reporting purposes - to differentiate between jobs. In that case I am concerned about accuracy.

Once we understand the importance of accuracy there are immediately two competing demands:
- More options means more granularity and more specificity.
- Fewer options means an easier time for anybody actually responsible for selecting a correct option.

In most cases organistions are good at adding options and bad at removing or consolidating options. Consider each additional level of hierarchy is essentially another decision you burden staff with for every job.

At the first hierarchical level I aim for five to eight disparate options. This generates a nice spread in reporting and we humans seem reasonably competent at selecting from a list that size. My first level is comprised of broad activities and as much as possible is not a replication of skill groups (because that would be redundant).

At the second level I again aim for five to eight options, but more is ok if they are clearly discrete. These should be of similar depth - apples to apples.

Designing or redesigning the issues hierarchy to achieve that outcome is a complex exercise in simplicity engineering.
- Consolidate terms until the volume of jobs reaches a usable threshold in reporting terms (per reporting period).
- Split overused terms to discover more information.
- Review jobs to see what issues are being selected to make sure they're accurate.
- Discuss with staff actually making the selections what problems they experience.


So I think the current limit of 5 levels is generous and adding more would be a case of providing "enough rope".

Great post Josh!

You're right. The classification hierarchy is used primarily for Classification, Reporting, Filtering and Automation. Having too many levels, or complexity can compromise the efficacy of each of these. Having said that, each organization is different and needs to strike a balance between being able to succinctly identify and classify jobs, and having a cumbersome "too much rope" hierarchy.

When hierarchies get too complex, or too deep, there is a tendency for staff to use generic codes, or the dreaded "Other" classification.

Your design model makes a lot of sense. Sounds like you've done a few miles in the classification business. ;-)

For those running into issue with overly complex classification hierarchies, or seeing lots of duplication or redundancy in the tree, consider using the "Virtual Issues" feature of HelpMaster. See http://www.helpmasterpro....Virtual%20Issues.htm

Thanks Rod,

Yes, I've been a user of two systems with poorly managed classification lists, one was in Helpmaster, the other was a similar product.  In both cases I eventually became responsible for fixing the problem.  It was particularly challenging to make changes to the classification list in a large organisation (350 IT staff) so I really had to have a clear understanding, solid plan and persuasive arguments to build a consensus for change.

Actually I'm a big fan of the "Other" category.  The trick is you need to periodically review how it's being used.  That helps you identify missing categories, opportunities for consolidation or diversification, points of confusion amongst staff (inconsistent usage).  "Other" is also an appropriate house for the truly sundry types of jobs that crop up.  Classification is one of those areas that does evolve over time and you need to devote some administration time to it to ensure it keeps pace with your changing circumstances.  I know a lot of Helpdesk managers would balk at this but it's just a matter of practicality.  Have you ever found yourself at a dead end in a conversation with an IVR?  Your call doesn't match their categorisations and you end up just wanting to talk to a person.  Without an "Other" we end up just forcing round pegs in to square holes.

In terms of automatic assignments based on classification, I have found that to be troublesome.  You end up with one of those tail wagging the dog situations - staff decide who it should be assigned to, then pick a category that triggers that assignment at the expense of matching what the job does to the classification.  You end up with less information - the assignment details tell you the same information as the categorisation.  I prefer the database-purist approach where one field has one meaning: classification as purely a subjective selection that aids reporting, and which section is responsible for carrying out the work is identified in the assignments.  Then you put the smarts in your report, drawing from either assignment details or classification or both, depending on your needs.

Obviously if someone has a set up that's working for them, that's great.  These are just some of my lessons learnt and strategies I would use in a redesign or new implementation.  It's also very IT oriented and I understand that not all Helpmaster installs are for IT customers.