On Mon, 15 Jun 2009, Tom Perrine wrote: > Agreed. That's why it is critical to choose metrics that are meaningful and > correspond to what you're trying to > accomplish :-) *Simplistic* ticket closing metrics will lead to exactly what > you're describing. Simple metrics are > often chosen because they are simple to implement and simple to understand, > not because they will lead to the desired > result. > > A better metric would be more complex, perhaps something like this: > > 1. 90% of Service Request* tickets will be closed within three days. > 2. All remaining tickets will be referred to Engineering as "System > Enhancement" tickets within 3 days. > 3. At least 90% of referred tickets will be acceptable to Engineering as > System Enhancements. > > This ensures that simple tickets are handled quickly, -or- are recognized as > non-simple tickets and referred to > engineering. It also has a check in that you don't have too many tickets > "kicked to engineering" that shouldn't have > been, just to meet the other metrics. > > More complex, time consuming and expensive to measure, but more likely closer > to what you're trying to accomplish.
Maybe if you just closed every ticket with either a "this is a total one-off" or "here's the ticket number of the engineering ticket that addresses it". Need to have a drop-down with all the engineering tickets and useful descriptions and defaults, and ideally predictive behavior so the system would try to guess the engineering ticket that went with the problem ticket based on prior ticket classification. That would ensure that at least there's an attempt made to connection the daily churn 7-day SLA service request kinds of tickets were associated with engineering efforts to reduce them. I found it particularly amusing to be doing engineering in an opertional organization where the trend was towards 7-day SLA on tickets. It typically takes me 3 weeks to get a quick engineering change designed, implemented, tested, and deployed. It can take 6-12 months for something nasty like upgrading all the ssh daemons in a company for the first time or various other tasks relating to standardization an existing huge mess (often involving weeks of simply just thinking about it and mulling it over until I get comfortable enough to start pushing something out). >> 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... > > What's a "storypoint"? I'm intrigued. Is this a milestone-like thing? Or > an agile thing I haven't seen before? It seems to be an agile/scrum thing. One of the SDE teams have been inviting us to their monthly sessions where they go through their storypointing and burndown sessions and its been interesting. It takes a lot of time to go through it all, but they seem to be getting a good idea of what they're going to do in the next month, how much they *can* do in the next month, and tracking progress against getting it all done. It also seems like it would be useful to stack up all the projects, storypoint them and then compare to past burndown rates and actually assign a metric to how understaffed you are (project tracking really only tracks what you've been able to get done, it doesn't report very usefully on everything you haven't been able to get done and i've never seen it be very successful at getting more heads assigned). I don't have enough experience with it to know all the weaknesses. I do know that one of the weaknesses of the whole scrum thing is that most system admins don't work on a single project day after day and burn it down constantly so daily scrum sessions often have 'didnt get shit done yesterday' status updates. We get interrupted to often and spend a day or three fighting some fire which derails everything else. We also usually have so much going on in different little projects that if you added a 20 minute daily scrum session for all of them, that would add up to 60 hours a week of time spent in scrum meetings. The monthly storypointing and burndown tracking excersize does seem it might have some application to tracking systems engineering projects, however. At least it isn't an obviously bad idea. _______________________________________________ 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/
