provided by: 
Originally published at Internet.com The IT Infrastructure Library (ITIL) refers to service or systems outage analysis (SOA) as a method to improve availability. Presented as an availability management process tool or technique, SOA is a powerful management tool to improve quality.
As is quite common since the ITIL is descriptive and not prescriptive, ITIL does not explain how to carry out a SOA. In this article I will explain what an SOA is, its benefits, and give you an easy to follow six-step guide to performing SOA.
The reason to use SOA is to identify the causes of outages and thus reduce the frequency and duration of outages. SOA aims to improve mean-time-to-repair (MTTR).
The result of a SOA is clear understanding of what happened to cause an outage, and exposes the risk of future outages due to the same cause or causes. Finally, an SOA can produce recommendations for improvement to avoid the issue in the future.
With these types of benefits, you might think that performing an SOA is complicated but, in reality, just the opposite is true: You can perform a SOA without any major investment in software, tools, or training.
Performing an SOA is straight forward. Working with problem management and customers, you examine past outages to identify configuration items (CI) (products, people, or process) related to an outage. In effect, you simply review the impact to the organization and infrastructure as reflected by how the organization responded to an outage.
This is different from proactive problem management since availability management has a scope that includes the organization (people, process, training, staffing, etc.)
Getting Started
To get going, collect outage data in the form of incidents, any related closed problems, or known errors. Gather together a team of people familiar with the outages, the infrastructure, processes, procedures, people, and so on. Be sure to include a customer representative and perhaps some users on the team as well (their input will be critical in guiding the team through the SOA process).
Once you have the team empowered, lead them through the six following steps:
Group related outages together by vendor, product, family, application, customer, etc. Then, using customer and user input as appropriate, categorize each outage as "significant" or "less significant." Focus only on those labeled "significant," and monitor the "less significant" for future outages.
For each outage tagged as "significant" review the root cause of the unavailability (this requires closed incidents and problems.) For example, faulty hardware or software. This is probably already known since the outage is resolved.
Perform a simple Pareto analysis to break the significant issues into a smaller group. The Using the Pareto 80/20 rule you can rank the related outages and their causes.
You will find that the majority (80%) of the outages result from a select few causes (20% of the organization or infrastructure.) Of course, you want to focus on the 80% of the outages caused by the 20% of the causes.
For each grouping of similar outages, examine the reasons for the duration of the unavailability. For example, the outage may have occurred because of faulty hardware or software, but the duration of the unavailability might have been extended by lack of tools, little or no training, unavailable spares, etc.
Remember to consider the "3 P's" - people, product and process. Then review:
* All existing procedures and policies used during the outage. * The actions and inactions of staff members, customers and anyone else involved in the outage or its restoration. * The management directives given to all involved during the before and during the outage.
You must determine if anything might have lessened the duration of the outage, or better yet, avoided it altogether. Your examination of the "3 P's" should locate a trend, a related cause, or at something in common with similar outages. This is the smoking gun.
For example, a common cause might extend an outage may be a hierarchical escalation requirement that does not allow staff to proceed without management approval or a special tool is required and could not be found.
The next step is to quantify the avoidable outage time. That is, if one hour of downtime resulted from trying to locate the proper tool, then the avoidable outage time is one hour times the number of outages so affected.
Identifying the most preventable downtime is your goal. This is then the most significant generator of preventable downtime.
End the SOA by creating a report summarizing the number of outages analyzed, timeframe, avoidable outage time, and the suggestions for improving or avoiding the outage. Prepare a request for change (RFC) and pass the entire kit on to change management.
Hank Marquis is a managing partner and CTO at itSM Solutions. You can contact Hank at hank.marquis@itsmsolutions.com.
Author: Hank Marquis
Read article at Internet.com site