Now that we know the importance of this “priority” field, in my last blog entry, let’s take a look at how companies use it. Here are some classification factors I came across during my FP implementation experience with my projects:
Now that we know the importance of this “priority” field, in my last blog entry, let’s take a look at how companies use it. Here are some classification factors I came across during my FP implementation experience with my projects:
1. Appointment of the person who reports the case.
This will never go wrong as you will always please the top management. A CD-ROM stuck incident can trigger an onsite engineer to be at the CEO’s desk within 5mins; dropping all other work he has on hand. Although this improves high ranking/VIP customer service, a real IT monthly system backup failure might become de-prioritised and any disaster that happens before the next backup will be as its name suggests: disastrous.
2. Number of users impacted
The more people affected, the bigger the problem must be! Straight forward thinking, 1-10 users=P1, 11-100users=P2. Although true as it is, but we might need to look at the nature of the incident itself and determine the operational impact. If someone cuts a ticket saying 500users are not able to apply leave due to the e-leave system down, vs. a sales department of 10 people unable to access the quotation system, I believe the CEO will prefer the quotation system to be fixed first. This area is covered in ITIL, which is why they stated Urgency + Impact=Priority. But then again, “urgency” is really too generic and need to defined based on the company nature.
3. Classify the equipment
Some companies classify all their servers to different categories and set a rule that any incident reported on a Cat1 server will be considered a Sev1 priority ticket. End user PC issues will then be considered Sev7 priority ticket. This method definitely doesn’t put customer satisfaction on top of the list, but does come closer to setting a good rule based on the business impact such equipment might cause. A cat1 building network core switch is definitely more important compared to a meeting room cat5 wireless router outage. Please take note that in this method of classifying, having a CMDB is utmost critical. Helpdesk agents will need to struggle to find the equipment related to the incident reported by the users before they can actually prioritize it.
4. Classify the services
I have only seen this done once in a SI outsourcing department for the customer’s incident management workflow. Very customer-oriented, accurate prioritising of work, but you will need a tedious amount of effort to come up with this list. This will require a very mature and complete CMDB with CIs of every service defined. For example, a consumer web portal movie ticket booking might compromise of a webserver, switches, middleware, DB, etc. When an incident is reported on switch00234, the agent will need to check the CMDB to find out which web portal service is impacted, thus giving it a priority classification. Doing a 1 time exercise to define all services and the respective priority is not enough, this process need to be tied in to project management before any new systems go live, and work closely with the business owners to do monthly review on the services list. Frankly, I have only seen defined written processes of the “priority” field usually on an IT Outsourcing level due, to the demand of their paying customers. Internal IT departments usually just have a “high, medium, low” priority field and when Helpdesk managers are challenged which scenarios to determine the selection…..
“Let the helpdesk agent decide, if he think it’s important, then he will set it to high.”
Although a simple statement, I personally agree that nothing beats the human brain. We can never set such defined rules to cover everything under the IT sky! Out of the “People, Process and Tool”, I will say “people” is the most important thing in making a successful Incident Management.
Thinking of writing a defined list of Priority classification? Try a mix of all and generalise them, providing as a guideline to the agents. Here’s an example:
Priority 1 – Any system impact that might cause in direct business loss; incidents that impact more than half the company; any incident on core network switches/network equipment (refer to xxx list); any incidents logged by the CEO.