TAPUniversity's Blog » Collect Requirements

Focus Groups

lhilkemann — Wed, 22 Apr 2009 09:36:29 +0000

The Focus Group is common across many disciplines, including project management. They are a tool of the PMBOK®’s Collect Requirements process. The desired type of group should be determined. A homogenous group will have similar people who likely have similar perspectives. A heterogeneous group will contain a variety of people who have varying perspectives. A homogenous group will likely feel more comfortable voicing their opinions and will more likely come to a group consensus. A heterogeneous group will display the interaction of different perspectives. There should be at least several people in the focus group, but beware of allowing the group to so large that people become reluctant to speak. It’s common that not everybody who is invited will come, so more people can be invited than are needed. About an hour is a good length of time for a focus group session—they shouldn’t be so long that people lose interest. The moderator of the focus group should have questions prepared beforehand, and encourage participation from everyone. The focus group should be recorded for later analysis and summary. For more on this topic, see the earlier posting of Collect Requirements Process (posted February 24, 2009).

Prototypes

lhilkemann — Mon, 13 Apr 2009 12:48:44 +0000

One of the tools and techniques of the Collect Requirements process described in the fourth edition PMBOK® is Prototypes. They are a working model of a product that allows for feedback before producing the final product. Feedback cycles may be utilized in which people (such as stakeholders) can provide input, and then a revised model can be presented for further input and revisions. For example, Katy is trying to bake a batch of chocolate chip cookies to be entered in an upcoming cookie contest. She bakes an experimental batch and asks her family for feedback. They tell her that she needs more chocolate chips in the cookies, and that they need to be chewier. Katy revises her recipe and bakes another batch for her family. This time they suggest that she make the cookies larger and a little less sweet. After a few more iterations, Katy believes she has the recipe for a winning chocolate chip cookie.

Group Decision Making Techniques

lhilkemann — Fri, 10 Apr 2009 13:10:07 +0000

How can direction be set for a group? Group Decision Making Techniques is listed as a technique of the Collect Requirements process described in the fourth edition PMBOK®. However, these can be used at any time a group decision must be made—not only decisions regarding requirements or project management. Four methods of reaching a decision are: unanimity, majority, plurality, and dictatorship. Katy and her husband have three children. The family is trying to decide what type of cookies they should bake. Here are examples of each of the decision making methods.

Unanimity: everyone in the group agrees to the same thing. Everyone in the family has to come into agreement. After discussing their options and hearing a passionate speech from the youngest child about how good great-grandma’s recipe for oatmeal raisin cookies is, each person decides that they could have oatmeal raisin cookies.

Majority: more than fifty percent of the group decides. There are five people in Katy’s family. Her husband and two of the children want sugar cookies, and since three of five people is sixty percent (which is more than the necessary fifty percent), the family has sugar cookies.

Plurality: the largest block of people in the group decides. The parents are a block of two people and the children are a block of three people, so the children are permitted to decide that the family will have peanut butter cookies.

Dictatorship: one person makes the decision for the group. Katy states that she’s the one that will be baking, and she alone decides that the family will be having chocolate chip cookies.

Observations

lhilkemann — Tue, 17 Mar 2009 13:12:15 +0000

Observation (also called Job Shadowing) is a tool and technique of the PMBOK’s Collect Requirements process. The Collect Requirements process defines and documents the needs of the stakeholders as they relate to meeting the project objectives. This method consists of watching people perform their work. It can be useful in understanding how the work is actually done (which may be different than how it should be done, or how a manual states that it should be done, or how managers think it is being done). Also, some work processes may not be written anywhere and only the workers themselves may know how the work is actually done. At times, people are unable to clearly communicate how work is performed, so observing them is the best method.

There are two approaches to observation: Passive (invisible) and Active (visible). In Passive observation, the observer does not interfere by asking questions or participating in the work—they simply observe and take notes (afterwards they may ask questions). In Active observation, the observer is free to ask questions and may even perform some of the work. In some cases, the observer may act as an apprentice. There are advantages to both methods. Passive observation provides a more accurate representation of how the work is performed because the observer interferes less. However, Active observation allows the observer to have a better understanding of the work by asking questions while the work is being performed and perhaps even gaining first-hand experience of performing the work.

Collect Requirements Process

lhilkemann — Tue, 24 Feb 2009 14:20:55 +0000

Collect Requirements is one of the 42 project management processes outlined in the fourth edition PMBOK®. It’s new to the fourth edition. Collect Requirements is categorized as one of the five Scope knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to define and document the needs of the stakeholders as they relate to meeting the project objectives. This process describes the responsibilities of the business analyst—if one is part of the team. This alone is an indicator that specialized knowledge and experience is especially useful for performing this particular process. Also, Collect Requirements has numerous tools and techniques in addition to three unique outputs. The tools and techniques represent different methods of learning the details of what stakeholders want—interviews, focus groups, facilitated workshops, group creativity techniques, group decision making techniques, questionnaires and surveys, observations, and prototypes. The outputs are: requirements documentation (stakeholders’ needs), the requirements management plan (how the requirements will be analyzed and documents), and the requirements traceability matrix (tracking of requirements throughout the project). This process requires more knowledge and a greater time commitment than does many of the other processes.