Posted: Sat Apr 03, 2010 4:27 am Post subject: How to apply a prioritisation metric to Issues?
Hi guys I would be very grateful if you could help me with a problem I am having. I am responsible for developing a process that will allow PM's to apply an assessment criteria in prioritising Live Issues. So far I have thought of impact analysis, consequences etc... But I am looking for a more effctive model that uses some sort of rating or mathematical approach.
I would be very grateful for any input anyone may be able to provide on this.
Mandeep Are you talking about priorities for incidents? or for changes? problems? there is no such thing as issues in ITIL. Can you please clarify what you want so we can help you further? also did you try searching google _________________ Ali Makahleh
Configuration Management(Blue Badge),
ITILV2 Service Manager(Red Badge),
ITILV3 Expert(Lilac Badge) Certified.
“If you can't describe what you are doing as a process, you don't know what you're doing." W. Edwards Deming.
Posted: Sun Apr 04, 2010 10:25 pm Post subject: Incident prioritisation
I am referring to Incidents that relate to software faults. We currently have a list of incidents that is added to with every software release. Currently we are using a RAG status to prioritise the incidents but we require something that actually measures an incident's priority for a resolution based on a more mathematical approach. Giving an incident a Red, Amber, Green does not provide the scientific approcah we require. We are looking to set up a system whereby we can apply some sort of formula to every incident that gives it a priority number. Has anybody tried some mic of Severity / Impact etc....
Any help on this matter would be greatly appreciated.
Joined: Mar 04, 2008 Posts: 1889 Location: Helensburgh
Posted: Wed Apr 07, 2010 7:03 am Post subject:
notwithstanding your statement, I get the impression that you are actually referring to problems (underlying causes) that need resolved by software amendments rather than incidents that require service restoration as soon as practicable.
Irrespective, priority is best established by quantifying, the costs and risks (impact) associated with the fault and establishing the time-frame (urgency) that affects those costs and risks. Basically, the sooner and the higher the ongoing costs and risks, then the higher the priority.
In the case of a software fault, the costs will certainly include any circumvention actions and workarounds (even if this is merely reloading the app with some loss of time for the service) and the risks may be that there are additional, as yet unidentified, effects of the fault.
If you measure in estimates or approximations of time and money you can be as finely grained as you need to be. But remember that the purpose of priority is to direct over-subscribed resource to the most effective actions and you only need to finely measure to the extent that you may have over-subscribed resource.
The engine for calculating this priority is likely to be more closely related to your service management function (incident and problem management, service level management and service catalogue) working/consulting with the customer than to your applications development and maintenance function. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum