If you are ITIL® certified then you remember Major Problem Reviews (MPR). You may still remember that Problem Management performs a MPR after resolving a 'major problem' to identify:
The benefits of MPR are many, including reduced staff workload and higher quality operations. However, aside from the above, the ITIL offers no specifics on how to perform a MPR.
Luckily, under the name After Action Review (AAR), the US Army has refined a functionally identical process. Peter Senge says the US Army AAR is "...arguably one of the most successful organizational learning methods yet devised..."
Following I show how to perform an ITIL MPR using tips and techniques from the Army AAR.
The ITIL indicates that Problem Management (PM) should perform a MPR after the solving a 'major problem.' A major problem is any Problem where the severity or impact was such that management decides to review the entire series of activities. The scope of an MPR includes process, actions of staff as well as tools, and the environment.
The US Army Training Circular (TC) 25-20 'A Leader's Guide to After Action Reviews' provides good detail into exactly how to plan and deliver After Action Reviews. Of course, it needs some translating for the non-military. Donald Clark, retired Sergeant First Class (E-7) in the US Army worked as an instructor and then a training developer. Later, working at Starbucks in corporate IT, he defined AAR:
The AAR is a professional discussion that includes the participants and focuses directly on the tasks and goals. It is not a critique. In fact, it has several advantages over a critique:
- It does not judge success or failure.
- It attempts to discover why things happened.
- It focuses directly on the tasks and goals that were to be accomplished.
- It encourages employees to surface important lessons in the discussion.
- More employees participate so that more of the project or activity can be recalled and more lessons can be learned and shared.
This is important -- the MPR (and the AAR) are learning activities, not punitive or troubleshooting activities. The goal of the MPR is a discussion surrounding the major problem that allows all involved to learn what happened, why it happened, what went well, what needs improvement and what lessons can be learned from the experience. The spirit of the MPR is open and learning. It is not about problem fixing or allocating blame. Problem Management explicitly documents and shares the results with all who need to know.
The MPR collects, organizes, evaluates, and distributes data relating the objective of the MPR. Ideally, Problem Management documents the types of information to collect before the major problem as part of the process planning activity. Key data includes:
Problem Management defines what a major problem is, and how to respond to one. The planning of how to respond is outside the scope of this article, and specific to every organization. However, there are four key steps to effective Major Problem Reviews:
The focus of the rest of this article is on Step 3 'Conducting' a Major Problem Review.
The basic steps for conducting an MPR are as follows:
1. Assign responsibility for the review. Problem Management should appoint a person to assume responsibility for the review as soon as possible. ITIL says to begin the MPR after resolving the Problem. The Army says to begin the process as soon the leader knows the review is required -- this includes during the response phase of a major problem. Ideally, the person assigned will have a background in Problem Management and a familiarity with the processes, systems, tools, and staff involved.
It might not exactly follow on what ITIL says, but assigning a person to this duty during a major problem, staff resources permitting, delivers several key benefits:
2. Start Documenting. Documentation begins as soon as possible. While it will be tempting to skip the documentation during the major problem, it is critical to document that what actually happens. Benefits of this include:
3. Gather data. Aside from the documentation developed during response to a major problem (step #2), the MPR leader must collect additional information during or after the resolution of the problem. Exactly what to gather is a function of the MPR plan, but some important data gathering methods and opportunities include:
Some key points to consider regarding the collection, structure, and organization of the data and team meetings/workshops are:
4. Initial Meeting. As soon as possible after the major problem closes, an initial meeting of all involved is important -- this includes customers and vendors. Remember, impartiality and unbiased review with the goal of organizational learning is the key here. This meeting (and the MPR process) is not to define blame, assign guilt, or to single out individual failures.
Before any group meetings collate all data and develop an initial timeline of events and actions. Provide this initial timeline to all attendees prior to any meetings. A good agenda might include:
Prepare and deliver your initial meeting findings to all participants as soon as possible after the meeting.
5. Report Preparation. A four-step process provides a nice method to prepare the MPR report:
6. Share the learning. Be sure to distribute the report to anyone who else could benefit from it. For example, you may know about another team using similar tools, hardware, or software. Make the report available as a document, available to anyone who might benefit from it, perhaps the IT portal, library, or in the Configuration Management Database (CMDB).
Major Problem Reviews must focus on response. It is worth repeating is that MPRs are learning events, not performance review or critiques. It is therefore vital that they seek no blame. The quality of an MPR depends totally on the open and honest discussion of events by participants. If they know punishment awaits it is very unlikely that any value will come of the MPR. Management commitment and endorsement of the process is critical.
A Major Problem Review is a Knowledge Management System. It uncovers and shares knowledge. And it's not just for Problems -- call it an After Action Review (AAR) and use the same techniques to assess any training, project, or activity. MPR and AAR both allows employees and leaders to learn what happened and why. Examples include when introducing new products, performing upgrades, after a training session, a change of process or procedure, and any time a significant event occurs and you want to capture organizational learning.
Try using MPR's and AAR's. Use the AAR for non-problems to tune your process and get the organization familiar with the benefits. Then, when you do have a major problem, the entire team will know exactly how to respond.