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.
Skill Level Intermediate
Transitioning from Waterfall to Agile Project Managementwith Kelley O'Connell1h 32m Appropriate for all
Putting ITIL® Into Practice: Problem Management Techniques
2. Ishikawa Diagram
3. Kepner-Tregoe Root Cause Analysis
4. Fault Tree Analysis
5. Component Failure Impact Analysis
6. Service Outage Analysis
7. Post-Implementation and Major Problem Review
- Mark as unwatched
- Mark all as unwatched
Are you sure you want to mark all the videos in this course as unwatched?
This will not affect your course history, your reports, or your certificates of completion for this course.Cancel
Take notes with your new membership!
Type in the entry box, then click Enter to save your note.
1:30Press on any video thumbnail to jump immediately to the timecode shown.
Notes are saved with you account but can also be exported as plain text, MS Word, PDF, Google Doc, or Evernote.