Go to previous topic
Go to next topic
Last Post 7/13/2015 10:13 AM by  Josh B
How many levels deep should the Issue Viewer go?
 7 Replies
AddThis - Bookmarking and Sharing Button
Author Messages
Rod Weir
HelpMaster development team
Helpdesk Hall of Fame
Helpdesk Hall of Fame
Posts:555
Points:1017


--
10/29/2012 12:08 AM
    How many levels for the Issue hierarchy?
    5 levels - the way it's always been. (1)
     20%
    10 levels - we need more granularity (1)
     20%
    Less that 5. Our hierarchy is already out of control (0)
     0%
    Other? - Post comment (3)
     60%

    Currently the issue viewer in HelpMaster is limited to 5 levels deep.  This allows for some detailed hierarchies to be built, and gives the reports some fine granularity.

    However....it has been requested that we expand the depth out to 10 levels deep!

    What do you think? 

    Would 10 levels deep be a good thing, or a bad thing?

    HelpMaster development team
    Check out the HelpMaster roadmap
    Dennis Odri
    HelpMaster tech support
    Helpdesk leader
    Helpdesk leader
    Posts:45
    Points:81


    --
    10/30/2012 9:23 PM

    I think that 10 might be a bit too much. I do find myself always looking for at least 1 more level and possibly 2. So my vote is for at least 7, and 8 levels deep would be more than enough in my opinion.

    Rod Weir
    HelpMaster development team
    Helpdesk Hall of Fame
    Helpdesk Hall of Fame
    Posts:555
    Points:1017


    --
    10/30/2012 10:34 PM
    How about a system option that lets the HelpMaster admin decide?
    HelpMaster development team
    Check out the HelpMaster roadmap
    Scott McRae
    HelpMaster sales
    Helpdesker
    Helpdesker
    Posts:30
    Points:44


    --
    10/31/2012 6:02 PM

    I would love to see an admin option for this one. By default, I think 5 levels is great, as it forces you to think about your heirarchy when you are building it. After you grow into your HelpMaster shoes, though, you may want to expand this. At this point an administrator could decide to open it up further to (x) levels. 

    With that in mind, I personally wouldn't like to work with more than 6 or 7 levels at most. It would get so fastidious. It might be great for reporting, but it would be unworkable in the real world.

    Also, it would have to be treated with care, as increasing levels would be simple enough, but decreasing would be a different can of worms if, down the track, it was decided that 5 levels were enough after all.

    Scott

    brian dodds
    New Member
    New Member
    Posts:1
    Points:1


    --
    11/21/2012 8:15 PM
    Hi Rod

    I think it would be great if the Helpmaster Admin could be set at how many levels you want.

    Darren
    AHSA
    Josh B
    Helpdesker
    Helpdesker
    Posts:15
    Points:21


    --
    7/10/2015 3:50 PM
    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".
    Rod Weir
    HelpMaster development team
    Helpdesk Hall of Fame
    Helpdesk Hall of Fame
    Posts:555
    Points:1017


    --
    7/12/2015 3:52 PM
    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





    HelpMaster development team
    Check out the HelpMaster roadmap
    Josh B
    Helpdesker
    Helpdesker
    Posts:15
    Points:21


    --
    7/13/2015 10:13 AM

    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.



    ---