From the course: Putting ITIL® into Practice: Problem Management Techniques

How to do it: Example - ITIL Tutorial

From the course: Putting ITIL® into Practice: Problem Management Techniques

Start my 1-month free trial

How to do it: Example

“

- [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.

Contents