Because all projects are different and because some projects have many stakeholders, the PMP Certification Exam will expect you to know that there are several ways you can collect requirements. The most obvious one is interviewing people, but you can also use focus groups, workshops, surveys, brainstorming, and other group techniques.

In addition to the inputs, the exam assumes you have knowledge of requirement-gathering techniques. To perform these activities well, you’re expected to have skills in negotiating, active listening, brainstorming, and facilitating.

Interviews

Interviews can be informal or formal, done one-on-one or conducted in groups. Many times, an interview is the first step in identifying requirements.

Using an example of a childcare center, you might meet with the facilities manager, several parents, and the legal department to discover their product and project requirements.

Focus groups

Focus groups are a more formal method of gathering requirements. A group of prequalified or preselected stakeholders is brought together with a facilitator who asks questions about the stakeholder’s expectations for the end product. When selecting members for a focus group, make sure to get a diverse group.

You don’t want the information you collect to be skewed or represent only one viewpoint. Focus groups can have an established set of questions, or they can be more of a dialog with which you generate and capture ideas, feelings, and reactions.

For the childcare center, you could bring together a group of 5 to 10 parents and discuss their needs and expectations for the center.

Facilitated workshops

For larger projects — especially IT, high-tech, or new product development projects — facilitated workshops can be highly productive. Key stakeholders are brought together to identify their requirements and work through any conflicting requirements.

The IT sector often has joint application development (JAD) sessions. In these sessions, system engineers, end users, developers, and business analysts can all work together to identify product features and functions.

Group decision-making techniques

Some of the preceding techniques can help you make decisions, such as the Delphi technique and the nominal group technique. These decisions are based on the group coming to a unanimous decision, or at least having a majority in consensus. Sometimes, though, the project manager has to establish a structure for making decisions to finalize the requirements. For those times, many decision-making techniques are available.

The PMBOK Guide identifies four methods of reaching group decisions:

  • Unanimity: Everyone agrees.

  • Majority: More than one-half the people agree to a course of action.

  • Plurality: The largest group of people supports a decision, even if they’re not the majority.

  • Dictatorship: One person makes the decision.

There really isn’t one best way to make a decision. It would be nice if every decision had unanimous approval, but that isn’t realistic. Therefore, you have to apply the technique that makes the most sense in any given situation. This can sometimes require a trade-off on getting complete group buy-in and, for the sake of time, making a decision and moving on.

Questionnaires and surveys

Questionnaires and surveys are a good way to gather information from large groups of stakeholders. You can automate the process by asking people to answer a set of questions online and then collating the results. This makes completing and submitting the information fast and easy. If you give people multiple-choice questions or ask them to rate information quantitatively, you can easily total and tabulate your results.

For the childcare center example, you could use this technique to prioritize playground equipment choices, hours of operation, food options, and the like.

Observations

Observation is useful when you want to see how end users interact in a scenario or with a product. Observation can also help you understand unconscious or unspoken requirements.

If you were looking at options for designing the floor plan for the example childcare center, you might observe several similar sites and watch the traffic flow for dropping off children, how the children migrate from activity to activity, what the process is for picking up children, and so on. Then you could design the site to best accommodate those processes.

Prototypes

Prototypes are used to create a model or a mock-up of an end product. They might have limited or no functionality, but they give stakeholders an opportunity to visualize the end product and make changes or additions to the requirements early in the process. For the childcare center example, the architect might create a model and discuss the various features and processes that would be used in the center.

Prototyping is often used in new product development, agile software development, and construction.

Benchmarking

Benchmarking involves identifying best practices in an industry or organization and comparing the existing practices against best practices as a means to improve performance. Test scores and customer satisfaction scores are examples of measurements that can be benchmarked.

Context diagrams

Context diagrams show a business system or model and depict how people or other systems interact with it. Oftentimes in context diagrams, people providing inputs or receiving outputs are referred to as actors. The benefit of a context diagram is that it shows a visual display of a process and the interactions associated with the process.

Document Analysis

Document analysis consists of analyzing documentation that can help in identifying requirements. Examples of documentation you might analyze to elicit requirements include the following:

  • Process flows

  • Data flow diagrams

  • Interface documentation

  • Use cases

  • Issue and defect logs

  • Policies, procedures, forms, regulations, and information from previous similar projects

About This Article

This article can be found in the category: