Showing posts with label brainstorming. Show all posts
Showing posts with label brainstorming. Show all posts

Friday, June 22, 2012

Information Gathering Techniques


In the previous chapter, we saw one of the techniques used to identify project risks namely the “Documentation Review”. As outlined in the chapter on “Overview of Tools & Techniques used in Risk Identification” there are several other tools & techniques that we will utilize in this risk identification step. In this chapter we are going to take a detailed look at “Information Gathering Techniques”

Information Gathering Techniques

The information gathering techniques are involves utilizing techniques that predominantly revolve around interacting with experts and trying to gather as much data as possible about the potential risks that may affect our project. The information gathering techniques we can utilize are:

1. Brainstorming
2. Delphi Technique
3. Interviewing
4. Root Cause Analysis
5. Expert Judgment

Trivia:
Are you wondering why I have added “Expert Judgment” as an entry in the Information Gathering Techniques chapter when it was also part of the superset list of techniques used to identify risks??

The answer is simple. Expert judgment is utilized in almost every management activity we might end up doing on our project. In this case, the techniques like Delphi or interviewing etc. need a certain amount of expert judgment in order to be fully successful. That is why it is added here as a separate entity.

Before we go any further to discuss these techniques in detail, we need to know the participants, the “Who” part of these techniques. If you ask a project manager this question, his answer would most probably be “Everyone” and if so, his answer is almost correct. This is because the list of people who are involved in these information gathering activities include almost everyone that you can possibly think of. It includes:

1. The Project Manager
2. Project Team
3. Risk Management Team (If a separate team exists for risk management)
4. Customers
5. Stakeholders
6. End Users
7. Subject Matter Experts
8. Risk Management Experts
9. Other Project Managers

The people in points 7, 8 & 9 are usually not part of our team. An experienced project manager will identify such key people who can contribute greatly to the projects risk management effort and invite them for these activities to make use of their expertise and experience.

Now let us take a detailed look at each of these techniques…

Brainstorming:

Brainstorming typically involves a large group of people who get together solely for some purpose (Here it is Risk Identification) and share their individual ideas and suggestions under the topic of discussion. In this case, the outcome of a brainstorming session could be a comprehensive list of all possible project risks. Brainstorming sessions are typically led by a facilitator (To ensure focus on the topic & decorum) and may also involve experts from outside the team as required.

There are two ways in which these brainstorming sessions can be held:
1. Large Group Technique – Here a large group gets together and it is a free for all kind of scenario.
2. Nominal Group Technique – Here, smaller sessions are held first at different times and then the outputs are reviewed/discussed in a larger meeting.

An important point about this technique is that, the meeting/gathering should use the Risk Categorization standards as well as the RBS in order to identify risks effectively. As and when risks are identified, the group usually categorizes them as well.

Delphi Technique:

The Delphi Technique is almost similar to the Brainstorming technique but with a few major differences:
1. We will utilize experts instead of the everyone
2. Experts share their feedback/suggestions anonymously to the facilitator
3. The facilitator summarizes the responses and re-distributes it to all the experts
4. This cycle is repeated until a consensus is reached

Trivia:
Are you wondering why do experts have to respond anonymously? Well think of it this way; let’s say you are attending a brainstorming meeting where the Director of your department too is a participant. As the technical architect of your team, you are an expert and your ideas have a lot of weight with the project manager. So, you have an idea and share it with the group but your director thinks that this idea will not work and your project manager agrees instantaneously because he is the “BOSS”. Now, go back and ask yourself the same question “Why do experts need to respond anonymously?”

An important point to note here about this Delphi technique is that, we will be utilizing the expertise of only those people who are experts in Risk Management.

Interviewing:

Well, this is probably the simplest of the information gathering techniques and is probably self-explanatory as well. Anyways, for the sake of completeness, this technique involves interviewing subject matter experts (SMEs), stakeholders and other experienced project participants with the purpose of generating risk related ideas. An important point to note about this technique is that, this is one of the primary sources of risk identification data.

Root Cause Analysis:

As with the interviewing technique, this root cause analysis technique too is straight forward and you might already know about it. This technique involves:
a. Identifying an issue
b. Determining the underlying cause (to figure out why it is happening) and
c. Develop preventive measures (to ensure that it does not happen)

Easy isn’t it? This technique attempts to address the real problem to find “Why” a risk exists. Instead of just responding to the risk, we are trying to figure out the root cause of the risk and address that directly so that, not only this risk but also others that may exist due to this cause are all taken care of in one go.

Expert Judgment:

Expert judgment is an indispensible asset for any good manager and that is why we are talking about it as a separate entity even though it is utilized in almost every risk related activity we do. There is truckloads of knowledge and expertise around us and it is our responsibility to learn all that from those experts and utilize their expertise. So, as a subset of Information gathering, expert judgment involves talking to the experts and getting their opinion/feedback. As a project manager we must invite selected experts who have already participated in similar projects and can be a valuable addition to this exercise. But, the PM must ensure that he considers the experts bias before accepting their views. For ex: some experts may prefer doing certain things the way they are comfortable with, even if there are better/faster ways of doing the same thing. In such cases, the PM (You & Me) must take the judgment call and choose what is best for the project.

Prev: Documentation Reviews

Next: Checklist & Assumptions Analysis

Monday, May 16, 2011

Important Terms & Definitions - Project Scope Planning

Let us wrap up the Project Scope Planning topic by reviewing the important terms and definitions we have learnt as part of this topic.

Alternatives identification - A technique used to apply nonstandard approaches, such as brainstorming and lateral thinking, to perform project work.
Baseline - A reference plan for components, such as schedule, scope, and cost, against which performance deviations are measured. The reference plan can be the original or the modified plan.
Brainstorming - A creative technique generally used in a group environment to gather ideas as candidates for a solution to a problem or an issue without any immediate evaluation of these ideas. The evaluation and analysis of these ideas happens later.
Code of accounts - A numbering system used to uniquely identify each component of a WBS.
Configuration management - Refers to controlling the characteristics of a product, a service, or a result of a project. It includes documenting the features of a product or a service, controlling and documenting changes to the features, and providing support for auditing the products for conformance to requirements.
Control account - A node in the WBS that acts as a management control point where scope, schedule, and actual cost are integrated and compared to the earned value to measure the project performance.
Decomposition - A planning technique to subdivide the project scope, including deliverables, into smaller, manageable tasks called work packages.
Deliverable - A unique and verifiable product, a capability to provide a service, or a result that must be produced to complete a project or a process or phase of the project.
Lateral thinking - Thinking outside the box, beyond the realm of your experience, to search for new solutions and methods, rather than only better uses of the current solutions and methods.
Planning package - A WBS component that is below the control account that has a well-defined work content but does not yet have a detailed schedule.
Product scope - Features and functions that characterize a product, service, or result to be delivered by the project.
Project management plan - An approved document that describes how the project will be executed, monitored and controlled, and closed.
Project scope - The work that must be performed (and only that work) to deliver products, services, or results with specified features that were promised by the project. The project scope draws the boundaries around the project—what is included and what is not.
Project scope statement - A document that defines the scope of a project by stating what needs to be accomplished by the project.
Requirement - A condition, characteristic, or capability that a specific outcome of the project must have.
Rolling wave planning - A case of progressive elaboration in which the deliverables about which full information is available are decomposed to the lowest level, whereas the deliverables for which full information is not available are left at higher levels until the information becomes available.
Scope baseline - The reference scope against which all the scope deviations are measured. It consists of the scope statement, the WBS document, and the WBS dictionary.
Scope definition - The process used to develop the detailed project scope statement.
Scope planning - The process of developing the project scope management plan.
Subprojects - Parts of the main projects that are independent enough that each can be performed by separate project teams.
Work breakdown structure (WBS) - A deliverable-oriented hierarchical structure that displays the decomposition of deliverables into work, which must be performed to accomplish the project objectives and create the project deliverables.
Work package - A deliverable or a task at the lowest level of each branch of the WBS.

Previous: Summary - Project Scope Planning

Next: Introduction to Project Schedule
© 2013 by www.getpmpcertified.blogspot.com. All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.

Followers

Popular Posts