Skip to main content

Effective Brainstorming Session

There are several problem analysis techniques which are discussed in the V3 Service Operation book, including brainstorming. I have used brainstorming sessions often in my career. Brainstorming is used throughout the problem solving process whenever the team needs to generate ideas quickly and effectively. Some sessions have been very valuable, others not so much. What was the difference? Basically, we need some structure around the sessions and some rules of engagement.

Let’s begin by defining brainstorming. This is a technique used to quickly generate a list of ideas by a team to solve problems or issues. The relevant people must be gathered together either physically and/or electronically to increase creativity and idea generation in a very short amount of time.

Here are 3 different types of brainstorming methods: 
  • Free Wheeling Brainstorming
    • Participants call out their ideas when they occur to them and in no particular order. A recorder posts all ideas for everyone to see as they are presented.
  • Round Robin Brainstorming
    • Each team member is asked, in turn, for an idea. Members may pass on any round as the session continues until all members have passed during the current round.
  • Slip Method of Brainstorming
    • Each individual writes down their ideas on small slips of paper or index cards. The slips are then collected and organized by the group

 The typical brainstorming session consists of three phases:  
  • Idea Generation
    • Team Leader presents the problem. It should be stated in specific, precise terms and known to all participants. Leader makes sure all understand the problem, the session objective and the brainstorming method. All ideas are recorded on a flip chart, only one person talks at a time to ensure that all ideas are recorded. Team begins generating ideas using the method selected for the session. Do not stop until all ideas are exhausted.
  • Idea Clarification
    • Review the list for understanding and duplication. Do not discuss the ideas now. Testing and evaluation will occur later. Clarification and/or modification of an idea is only done with the approval of the idea originator.
  • Idea Evaluation
    • Review the list to eliminate irrelevancies or issues that are not related to the predetermined purpose of the session. Idea evaluation is often performed in conjunction with other analytical tools. It may take place outside the team meeting itself.

 Here are some Brainstorming Rules to guide your session: 
  • Clearly state the purpose of the brainstorming session.
  • Record ideas where they are visible to the whole group. Recorder writes down the words of the idea presenter unless the presenter agrees on an acceptable paraphrase of their idea.
  • Build on the ideas of others (leapfrog).
  • Strive for quantity (not quality) of ideas.
  • Do not evaluate ideas; there is no right or wrong idea.
  • Encourage presentation of wild or even impossible ideas.
  • Never criticize ideas. Remember the goal is quantity not quality.
  • Everyone contributes.
Brainstorming sessions can be very innovative and constructive. It is crucial that the Problem Manager documents the outcome and any agreed resulting actions. The Problem Manager needs to control the session using the above guidelines. Best of luck, with these simple tips, the effectiveness of your next session should improve!

 

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…