Join David Pultorak for an in-depth discussion in this video How to do it: Example, part of Putting ITIL® into Practice: Problem Management Techniques.
- [Voiceover] Now that you've seen the steps to brainstorming, let's look at a real world example to help drive home what you've learned. We'll use the same scenario here, and when we go through examples with other techniques. The scenario is a SharePoint collaboration service. In this instance, we're going to brainstorm its components and dependencies as part of proactive problem management. A big part of problem management is to put things in place to prevent problems in the first or to recover faster should a problem occur. In this example the team wants to recover faster from SharePoint collaboration service outages, so they'll work on putting a map of the components of the SharePoint collaboration service, and their dependencies together.
They start by formulating the brainstorming question. What are the components that the SharePoint collaboration service depends on? Then gather a group of subject matter experts to brainstorm around it. The facilitator posts the brainstorming question in the room, and the subject matter experts that have been assembled, begin contributing ideas in turn. As ideas are contributed, the facilitator writes each down. People call out components like storage, server roles, servers, and applications, in no particular order. When the team runs out of ideas or energies, it's time to more on the editing phase.
Now the team works to clarify and group ideas, and eliminate duplicates. In this case technology services was moved under a new heading, services, along with support services, which had been under software. The people category was replaced with a customer category, and only business units and user classes was kept under these. Some in the room needed clarification from others on the nature of some of the components, for example that server roles, are services servers can run, like DNS, or AD, or DHCP, and so on.
The main objective of all this brainstorming is to produce a list of action items, who will do what, by when. In this case there were a number of open questions, on standard setting for network routers, the terms of support agreements, for suppliers supporting the service, and the particulars around a new class of storage device. Action items were assigned to get answers. Another action chosen, but not noted here, was to clean up the service component drawing, and include it in the high level onboarding documentation for new starters responsible for supporting the service.
- Ishikawa diagrams
- Kepner-Tregoe root cause analysis
- Fault tree analysis
- Component failure impact analysis
- Service outage analysis
- Post-implementation and major problem review
ITIL trainer David Pultorak outlines the what, why, where, and how of each technique, and provide examples so you can practice with the goal of placing each technique into "muscle memory." He examines the 4 Ps that can contribute to or help resolve every problem—people, processes, products, and partners—and provides tips on where to go next.
- Identify what brainstorming is, as well as where and when to utilize it.
- Define what an Ishikawa diagram is.
- Determine the definition of the Kepner Tregue analysis in addition to what it can be used for.
- Examine the components of fault tree analysis.
- Recognize what a component failure impact analysis is and how to use it.
- Explore what service outage analysis is along with where and when to use it.
- Review what post-implementation and major problem review is and how to utilize it.