Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Viewing Posts by Marian Haus
Group Creativity Techniques to Collect Requirements
| In my previous post, I discussed gathering requirements through a facilitated requirements workshop, conducted as part of the scoping phase. A few creative group techniques allow a project manager to get the most out of a requirements workshop. They include mind mapping, brainstorming, affinity diagram, nominal group technique and Delphi technique. (A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Chapter 5.1.) The rigor, the number of applied techniques and the sequence in which these techniques are applied depend on the project's complexity, the workshop audience and the available time for gathering and prioritizing requirements. Nevertheless, the following approach can be constructive and fruitful for collecting project requirements in a facilitated workshop: 1. Start gathering requirements by using the mind mapping technique. Start with a topic, an issue or an area that you want to collect requirements for and develop ideas around it. Group the ideas visually, as a mind map, by writing down each idea and drawing how it relates to the initial topic. Ideally, you let anyone in the workshop create his or her own mind map. 2. Continue the process with a brainstorming session. Allow anyone in the workshop to generate an unstructured requirements list for each idea captured on the mind map. To ensure that the brainstorming remains focused on the initial topic, lay basic ground rules and let anyone freely generate fresh ideas and requirements on the topic. 3. Use the list of unstructured ideas and requirements to build an affinity diagram, where your ideas are organized into groups based on their natural relationship. Let anyone in the workshop participate in organizing the items in the most natural group they can. 4. Identify the most important requirements by applying the nominal group technique. Allow each member or group in the workshop to identify which requirements are the most important for him or her. Rank each requirement on the affinity diagram with a priority: low, medium, high or from one to five. To avoid conflicts, facilitate an anonymous priority appraisal and ranking. Finally, tally the results and identify the most important requirements. 5. Close the process by running several rounds of independent feedback through the Delphi technique. Let any individual or group revise the list of requirements. Share an anonymous outcome from each review round and continue with further rounds, keeping in mind the objective to reach consensus and convergence. Which of the group techniques are you using for collecting requirements? How do you apply them on your projects? PMI Members: Learn more about mind mapping in our Knowledge Center. |
Plan and Facilitate a Requirements Workshop
Categories:
Project Planning
Categories: Project Planning
| Every project manager knows that there is no single best way to collect project requirements. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Fourth Edition identifies several tools and approaches for collecting requirements. They include interviews and focus groups, facilitated workshops, group creativity and group decision-making techniques. Combining some of these tools and techniques with a requirements workshop can be the most efficient and effective requirements elicitation approach. But only if the workshop is planned and facilitated well. Planning a requirements workshop is no different than planning any meeting or event. Some simple steps to follow: 1. Define the scope and establish an agenda The scope and agenda should make it clear to all participants the reasons why they are attending the workshop. 2. Invite the right people Generally, you want to keep the guest list short, but make sure to invite key stakeholders. These include representatives from teams or user groups that will benefit from the project's outcome, project sponsors, product or system owners, and business and technical consultants. 3. Plan the logistics To facilitate an open and constructive working session, make sure that the workshop's location and environment has sufficient capacity and appropriate equipment for hosting the workshop. Now that we have a good plan, how do we facilitate the workshop? 1. Lay ground rules Establish basic ground rules. For example, start on time, stay in scope, and respect and build on other people's ideas. 2. Gather requirements Get everyone involved through questioning and individual interviewing. Apply group creativity techniques, such as brainstorming and mind mapping. And for topics that require in-depth and focused discussions, organize dedicated breakout sessions. 3. Record the workshop Make sure that someone attends the workshop solely to write the protocol during the workshop. He or she should capture all requirements, ideas, assumptions, risks and open items. 4. Pre-qualify and pre-prioritize requirements To facilitate the scoping process at a later stage, try to leave a requirements workshop with pre-qualified and pre-prioritized requirements. 5. Review the protocol and develop a follow-up plan At the end of the workshop, plan sufficient time to review the written protocol and the derived action items. Develop a follow-up plan to address the open items. Identify the owner of each item, and establish deadlines and next-steps. Do you hold requirements workshops? If so, how do you plan and facilitate them? |
Craft "High-Quality" Requirements
Categories:
Project Planning
Categories: Project Planning
| Project requirements derive from concrete business needs or business-use cases and constitute the foundation for the project work. Without requirements, projects cannot exist. Incomplete and unclear requirements may result in project failure. Moreover a significant part of project rework is attributable to problems with the project requirements. On the other hand, requirements that are clear, complete and understood by all the parties are of "high quality." They build a solid foundation for the project work. Collecting high quality requirements can be a challenging endeavor for several reasons: • Stakeholders often don't speak the same language (business vs. technical) • Stakeholders have different understandings and views of the product • Stakeholders have different backgrounds and expertise on the matter It may not be the project manager's role to collect, qualify and write requirements. But he or she is often the one planning the framework and determining or approving the guidelines by which requirements are elicited, qualified and accepted. The following guidelines should help in collecting high-quality project requirements: 1. No requirements without a use case Usually, requirements can be linked to concrete business cases, which are generally task- and user-centric. Use cases help understanding the requirements' context and purpose. 2. Requirements language Pay attention to the wording. Avoid ambiguous words. Use words and terms consistently. You might consider using a glossary of terms to ensure common understanding. Avoid words that have subjective meaning (nice, substantial, safe, simple) and that enforce direction weakly or that undermine commitment (often, always, partially, usually). Use "shall" or "must" instead of "should" or "might." Remove any room for interpretation. Avoid the usage of "and/or" together or "including but not limited to." 3. Requirements characteristics checklist Build a checklist of requirements characteristics that are relevant to your project's quality standards. Evaluate each requirement against the checklist. Here are 10 characteristics that I successfully use to evaluate the quality of requirements: Atomic: Is this a single requirement or multiple requirements in one? Complete: Is this comprehensive enough to start working on it? Traceable: Is this related to a use-case or need? Logical and Clear: Does it make sense? Does it leave no room for interpretation? Consistent: Is this consistent with the project objectives and other related requirements? Measurable: Is this measurable once a solution is delivered? Compliant: Is this aligned to the current product features, system architecture and legal framework? Feasible: Is this realistic and doable given the complexity and the project context and constraints? Necessary: Is this really required given the project objectives and constraints? Or is it more of a want than a need? Prioritized: What are its criticality, urgency and priority? What best practices do you use to ensure that project requirements are of high quality? |
Use a Framework to Plan Project Requirements
Categories:
Project Planning
Categories: Project Planning
| Project requirements are rarely collected and made available in a final form to a project team. Instead, requirements are often collected through an elicitation process, which involves a discovery, analysis, understanding and validation endeavor. Usually, a business or requirements analyst carries out the requirements elicitation process. The project manager is typically responsible for planning and setting up the requirements elicitation and management framework. Well-planned and well-managed project requirements are common characteristics of successful projects. This simplified framework can be a guiding requirements checklist for project managers: Organizational assets: Identify the available organizational process assets for planning and managing project requirements. The organization or project management office might already have standards, guidelines and templates that can or should be used as a starting point. Stakeholders: Use the stakeholder register to identify the stakeholders who will help provide, collect, analyze and document the project requirements. Categories: Identify and categorize the requirements types that are to be elicited, such as:
Documentation: Identify how requirements will be documented, whether it's textual form, graphically or using a formal requirements language. Identify the way requirements will be tracked -- through requirement tools, Word documents or spreadsheets. Maturity Index: Establish the criteria by which requirements are validated and qualified. Is it clear? Does it make sense? Is the criteria aligned to the project vision and goals? Prioritization: Identify the criteria on how requirements will be prioritized and scoped. For instance, list the must-haves first. Then come the "quick wins," requirements based on the owner prioritization, complexity and costs, the project phase, etc. Risks: One of the main inputs for the project risk management plan are the scoped requirements. Identify the requirements posing a risk to the project. Develop risk mitigation, response and tracking plans. Change management: Establish the criteria for detecting scope creep and basic rules for handling requirements changes for applying the change management process. How are you planning and managing your project requirements? See more posts from Marian. See more on project planning. |
Building Blocks of Project Work Planning
Categories:
Project Planning
Categories: Project Planning
| In my previous posts, I laid out the basics, the framework and the key documents for planning a project end-to-end. Now it's time to dive deeper. One of the most essential project planning stages is to establish the grounds for the project work. Planning and defining the project work starts with defining the "what" of the project. Before you can begin, you must understand the business needs and identify the project deliverables and its characteristics. You must set the boundaries of the project by establishing what the project will and will not deliver, and break down the project work into smaller and more manageable work units. The building blocks of project work planning have four main steps:
The requirements elicitation process should be facilitated and not done by yourself. Therefore, do this. Get the appropriate project stakeholders together. Organize focused requirements workshops. Interview, brainstorm and job shadow to glean information. Defining the project scope involves prioritizing the collected requirements, and deciding what's in and out of scope based on such factors as criticality, priority, urgency, constraints, complexity, risks and costs. The scope covers the project deliverables and all project requirements, along with their detailed descriptions and the related constraints and assumptions. The scope illustrates the entire work that the project will carry out, as well as the project boundaries. The part of the work planning that generates action is the Work Breakdown Structure (WBS). The WBS enhances the project scope understanding by decomposing the project work and deliverables into smaller and more manageable work units, also called work packages. The WBS defines granularly the "whats" of the project. Do you agree with these steps? How many steps do you use for project work planning? Read more posts from Marian Haus. |