Lamont Granquist wrote: > just noticed this... > > On Thu, 28 May 2009, Tom Limoncelli wrote: > >> 1. 90% of all tickets will be closed in 3 days (measure the number of >> tickets that are older than 3 days) >> > > ticketing metrics and team metrics in general produce teams that are good > at meeting those metrics. most operational teams define their metrics in > terms of things like closing tickets quickly and as a result they tend to > not fix underlying problems (a difficult and time consuming thing to do, > but which pays off much better than simply closing the same tickets over > and over again every month/week/day/hour ad infinitum). > > i've been thinking that having scrum meetings once a month where projects > for the month are assigned storypoints and those are burned down and the > rate of storypoint burndown could be tracked would give more incentive to > getting projects completed as compared to just closing tickets all the > time... i'm not sure that all of scrum maps well on system > administration, but that part might help... > >
Requiring RCA/LTF (Root Cause Analysis/Long Term Fix definition) for at least the serious or recurring tickets is another way to ensure that the need to close tickets does not drive down quality. (and the RCA/LTF work should be allowed after a ticket is resolved, so that this doesn't shorten the 3 days). It should also be possible to put a ticket into a 'pending' status (pending client, pending equipment arrival, etc.) so that there can be valid (and auditable) reasons for a ticket to stay open. For the team that I work on, our SLA states that we must respond to a ticket within a given number of days working days depending on the type of request and the priority (to raise the priority, a user must go through a defined process, they can't just call everything 'P1'). Many of the issues that our team services involve data centre freezes (for month/quarter/year end), provisioning (which may involve acquiring hardware) and such, so a fixed resolution SLA is not practical. You can't resolve a case in three days if the underlying environment is frozen for the next two weeks! Don't try to create an unreasonable SLA - this will only reduce quality and irritate both users and your team. We work with some groups (*cough*HR*cough*) that have established impractical SLAs, and this results in most cases getting closed without true resolution - which results in more cases getting opened, and more cases getting closed without true resolution. This means that their case metrics look excellent - lots of cases, all closed within SLA - but with no RCA/LTF process to ensure that issues are actually resolved, so there is huge case churn without real effect. Be careful what you wish for - if you ask for the world, you're likely to get it, and the genie will ensure that you don't like the result. :-) - Richard _______________________________________________ Discuss mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
