Measuring Performance and Progress in a team?
hi guys,
I'm currently managing an IT Operations team. I've been asked by our new head to come up with a way for me/us to measure in some shape or form their progress on a weekly basis.
We use Zendesk for our ticketing system which is very comprehensive. He wants us to find a way of knowing, how many particular jobs were started, closed, including things such as 'what got in the way?'. Along with that, he wants to know a way of measuring project progress in a similar way.
Do you guys have any measuring methods that you use at your work places? Or advised others on how to better do something similar?
Thanks for helping
Yashy
I'm currently managing an IT Operations team. I've been asked by our new head to come up with a way for me/us to measure in some shape or form their progress on a weekly basis.
We use Zendesk for our ticketing system which is very comprehensive. He wants us to find a way of knowing, how many particular jobs were started, closed, including things such as 'what got in the way?'. Along with that, he wants to know a way of measuring project progress in a similar way.
Do you guys have any measuring methods that you use at your work places? Or advised others on how to better do something similar?
Thanks for helping
Yashy
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Hi Yashy,
We use many metrics that signify value. Here are a couple that come to mind:
Remember don't get so focused on engineers time that root cause remediation falls by the way side. I'd always much rather have an engineer fail to meet a time quota and solve the root-cause then meet the quota time but not solve for the root. The latter is how most, L1 & some L2 are handled today. It makes for a poor functioning IT department because things are not actually getting solved, which will innately adds more repetitious behavior modeling resulting in more aggregate time spent. It also provides a false floor if management is not savvy because judging by the metrics alone everything looks great in terms of a time/ticket basis. Systematic performance & kinetic functionality is rarely monitored in a granular manner but rather in a binary (up/down).
In terms of 'what got in the way?' I'm not sure of your business so it is hard to determine what could be impedances for your team. For us we don't have impedance per se, because we have a well defined acquisition process that is handled at the inception of an engagement so that we collect all necessary info needed upfront before work is commenced. Then that is stored in our KB vault for all incidents/problems that arise in an ongoing manner. Maybe if you provide some examples of things that could get in the way that would help me understand what you are looking for. Irrespectively, you can build an impedance field for each ticket and start collating them and start to see patterns I suppose.
Hope this helps! Let me know if you have any other questions!
We use many metrics that signify value. Here are a couple that come to mind:
Ticketing; compare M2D, Q2D & Y2D for the following:
• Top 5/10 repeat issue - strategic to determine why/how to alleviate repeats: is root-cause analysis/remediation properly being performed
• Top 5/10 issues - strategic to determine how/why focal points for more efficiencies/automation; you can break this down categorically if that helps with your strategy
• Tickets opened-to-closed ratio - gauges how many tickets we are leaving unresolved each week ultimately our efficiency/effectiveness
• Average ticket response time - to make sure we are in line with expectations & SLA
• Average ticket resolution time - to make sure we are in line with expectations & SLA
• Average ticket time (in aggregate) - more strategic to determine how to be more efficient/automate
• User Ticket Volume - this depending on circumstances should trend downward if the environment is architected correctly.
• Top 5/10 issues - strategic to determine how/why focal points for more efficiencies/automation; you can break this down categorically if that helps with your strategy
• Tickets opened-to-closed ratio - gauges how many tickets we are leaving unresolved each week ultimately our efficiency/effectiveness
• Average ticket response time - to make sure we are in line with expectations & SLA
• Average ticket resolution time - to make sure we are in line with expectations & SLA
• Average ticket time (in aggregate) - more strategic to determine how to be more efficient/automate
• User Ticket Volume - this depending on circumstances should trend downward if the environment is architected correctly.
Security; compare M2D, Q2D & Y2D for the following:
• Cost Saving for Thwarting Threats/Security Incidents - this put security efforts inline with all other departments - how are you stacked in terms of what you are doing for the bottom-line.
• Number of Security Incidents - this, together with Complexity metric, signifies value in terms of cost saving, effort & time spent
• Complexity of Security Incidents- this, together with Number of Incidents metric, signifies value in terms of cost saving, effort & time spent
• Number of Security Incidents - this, together with Complexity metric, signifies value in terms of cost saving, effort & time spent
• Complexity of Security Incidents- this, together with Number of Incidents metric, signifies value in terms of cost saving, effort & time spent
Remember don't get so focused on engineers time that root cause remediation falls by the way side. I'd always much rather have an engineer fail to meet a time quota and solve the root-cause then meet the quota time but not solve for the root. The latter is how most, L1 & some L2 are handled today. It makes for a poor functioning IT department because things are not actually getting solved, which will innately adds more repetitious behavior modeling resulting in more aggregate time spent. It also provides a false floor if management is not savvy because judging by the metrics alone everything looks great in terms of a time/ticket basis. Systematic performance & kinetic functionality is rarely monitored in a granular manner but rather in a binary (up/down).
In terms of 'what got in the way?' I'm not sure of your business so it is hard to determine what could be impedances for your team. For us we don't have impedance per se, because we have a well defined acquisition process that is handled at the inception of an engagement so that we collect all necessary info needed upfront before work is commenced. Then that is stored in our KB vault for all incidents/problems that arise in an ongoing manner. Maybe if you provide some examples of things that could get in the way that would help me understand what you are looking for. Irrespectively, you can build an impedance field for each ticket and start collating them and start to see patterns I suppose.
Hope this helps! Let me know if you have any other questions!
Premium Content
You need an Expert Office subscription to comment.Start Free Trial