Requirements prioritization is a recognized project management practice. It's a decision-making process that enables project managers to focus on the deliverables that add the most value to a project's outcome.

It is quite rare that projects are conducted without time, scope and budget constraints. Most projects will likely need requirements prioritization.

Sometimes the prioritization process can lead to conflicts between the project beneficiaries. You might have to scope in requirements that address one person's needs, while de-scoping other requirements that address someone else's needs.

This five-step approach can help a project manager master requirements prioritization without getting into conflicting situations:

1. Prioritize as a common practice
Make it clear from the beginning that requirements prioritization is a common and required practice for any project that deals with constraints. Without prioritization, a constrained project could fail to reach its objectives.

2. Involve stakeholders
Not everyone on the project team should be involved in prioritizing requirements, but not involving the right people in this decision-making process could lead to project conflicts or missed project objectives.

The project's beneficiaries -- such as product owners, end-users or business departments -- should prioritize their own requirements. But project sponsors or organizations outside the project, such as legal departments, can be involved in your prioritization process.

3. Qualify requirements    
Identify and apply key qualitative dimensions that support prioritization, such as priority, severity, urgency, complexity or mandatory requirements. Then identify and apply key quantitative dimensions, such as weight or grades.

Use numbers to reflect the possible grades for each qualitative dimension. For example:

• 0.1 = low
• 0.5 = medium
• 0.8 = high
• 1 = critical

Then, depending on the project's nature and context, use factors that weigh the importance of a qualitative dimension as compared to the others. For example:

• Factor 0.2 for complexity
• Factor 0.4 for priority
• Factor 0.7 for urgency
• Factor 1 for severity

4. Use a prioritization formula   
Based on the qualitative and quantitative values, define a formula or matrix to apply when prioritizing requirements.
For example, a requirement with high severity will get a 0.8 rating (0.8 x 1) and will be prioritized ahead of a requirement with a high urgency (0.8 x 0.7= 0.56)

5. Document the approach
Document the prioritization approach in the requirements management plan as part of the project management plan. This leaves no room for interpretations, doubts or subjective biases during the prioritization process.

How do you prioritize requirements on your projects?

In a previous post, I referred to brainstorming as one of the most constructive and fruitful techniques to collect project requirements.

Brainstorming can be similarly effective and efficient when applied to solving challenges in a project. Project managers can gather the project team together and brainstorm for creative ways to address the issues.

In a brainstorming session, the project manager can take on the planner role, as well as the facilitator role.

As a planner, project managers might consider the following guidelines:

1. Clearly outline the problem or the idea to be explored.
2. Define basic ground rules, such as no criticizing, analyzing or judging ideas during the session. Criticism inhibits creativity. The ideas evaluation should be done at the end of the session.
3. Depending on the complexity of the targeted problem or idea, plan the session with no more than five to 10 people. In a larger group, it's challenging for everyone to participate.
4. When looking to develop new ideas or concepts, gather a mixed audience to gain a wider perspective. On the other hand, if looking to solve a problem, gather people from a focused or specialized group.
5. Schedule sufficient time so that people won't feel constrained. Factor in time for breaks so that people can feel refreshed.
6. Have someone capturing the generated ideas and the underlying notes. 
7. Plan the logistics such as use of flip charts, pin boards, snacks, etc.
   

As a facilitator, project managers might consider the following best practices:

1. Create a relaxed atmosphere that stimulates creativity.
2. Start the session with an icebreaker, a warm-up exercise or something funny.
3. Allow open brainstorming but keep the focus on the initial idea or problem.
4. Encourage everyone to participate and ensure a fair participation from each attendee.
5. Accept all ideas positively and appraise them equally.
6. Encourage people to be constructive, as well as to build on people's ideas.
7. Keep the session unstructured and unconstrained.

Do you use brainstorming on your projects? What is your experience and results?

In project management, if basic technical knowledge is lacking, or the basics are ignored or underestimated, a project's success is not guaranteed.

On the contrary, mastering the project management basics is a prerequisite for project success.

PMI's 2012 Pulse of the Profession revealed that organizations that use basic, standardized project management practices have a 71 percent success rate, compared to the average success rate of 64 percent.

One of these basic pillar practices is taking the time to create a realistic implementation plan. But how do we build a comprehensive, yet realistic project implementation plan? Here are a few tips:

1. Start the project plan while keeping the final objective in focus. Write down and highlight why the project is being conducted and what the project objectives are.

2. Make sure that the project's requirements and overall project scope are clearly captured, along with the project deliverables and the given constraints.
 
3. Implement a well-defined change management process, agreed upon by all stakeholders. The Pulse report revealed that of the projects that used change management, 71 percent were successful.

4. Document the estimated project costs, the funding approach, how the actual costs will be monitored and how cost deviations will be handled.

5. Plan how project communication will be managed. Who are the project stakeholders? What are their project roles and responsibilities and how can they influence the project?

6. Do not underestimate the risks the project can encounter. The Pulse also showed that 72 percent of successful projects used risk management. Assess and document risks throughout the project and plan for mitigation and contingency approaches.
 
What role does project management basics and the project plan play on your projects?

To discuss Pulse of the Profession on Twitter, please use #pmipulse.



See more on the Pulse of the Profession.


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.

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?

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:
 

• Project requirements: Business requirements, end-user requirements, functional and non-functional requirements, etc.
• Product requirements: Technical requirements, product features, functional requirements, etc. 
• Indirect requirements: Overhead imposed by organizational or enterprise environment and standards related to security, regulations, infrastructure and industry, etc.
  

Channels: Identify the channels through which requirements will come in, such as business-use cases, focus groups, requirements workshops, surveys, product introspection, reverse engineering or  imposed by the organization.

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.

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:

1. Collect the project requirements
2. Facilitate a requirements workshop
3. Define the project scope
   
4. Break down the work in small work units
   

Collecting requirements is the process of understanding the customer needs, the business use-cases or the required product features and functionality that the project will deliver. It's an elicitation process, a discovery and analysis endeavor, rather than just a gathering effort.

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.

Solid project planning is a prerequisite for project success. Poor planning, meanwhile, can lead to missed deadlines, budget overruns, poor quality deliverables, frustrated project teams and even project failure.

In my previous post, I offered five steps to assist in planning the project-planning phase. One of those steps involved preparing planning documents.

To foster a successful planning phase, here are seven planning documents I believe most project managers will find indispensable. This list certainly might vary depending on the project setup, project size, complexity and organizational planning guidelines.

1. Project management plan -- This is used as a reference index, encompassing all planning and project documents.

2. High-level project schedule plan -- This document captures high-level project phases and key milestones. It is the document most project stakeholders will see or want to see.

3. Project team planning -- This document provides a "who-is-doing-what" view of the project. This document fosters efficient project execution and effective project communication.

4. Scope plan -- The scope plan documents the project requirements, the agreed scope and the Requirements Traceability Matrix (RTM) summary.

5. Detailed project work plan -- This keeps track of the activities, work packages, resources, durations, costs, milestones, project's critical path, etc. It will be an essential document and work guideline for your core project team.

6. Quality assurance planning -- This document tracks the quality standards your project deliverables will have to align to. These may typically include product testing approach and tools, quality policies, quality checklists, deviations definitions, quality metrics, product defect severity grades, acceptance criteria, cost of poor quality, etc.

7. Risk planning -- This document contains the project risks and the related mitigation plans; as well as the project opportunities and the related exploiting plans. The importance of this document is one of the most underestimated in project planning. Be prepared to have a contingency plan in case something goes wrong or to take advantage of opportunities when they arise.

Start with this checklist when you sit down to plan for your next project-planning phase. Depending on your project's needs, fine tune the checklist and tailor it by adding and removing planning assets, determining the planning time frame, the underlying details and rigor.

Revisit this planning exercise, learn from it and enhance it, to continuously improve your project planning skills.

What project planning documents do you find indispensable?

See other posts from Marian.

There is a saying: "Every minute you spend planning will save you 10 minutes in execution." As a project manager, I've learned that along with communication and execution, planning is one of the three key ingredients for project success.

Planning is not just a one-off activity completed in the early stages of a project. Planning is a process (or rather a group of processes), conducted throughout the project. And like every process, planning itself requires a plan and a setup, which defines the planning scope, details and deliverables.

So how do we plan the planning? Here is my five-step approach:

1. Decide on the project management methodology, framework or practice you will use on the project. Depending on the approach, you might require different planning styles, deliverables, details or rigor.

You might have to go ahead with a detailed planning process if you will use a waterfall approach. Conversely, you might have to keep the planning thin if you will use an agile approach, such as scrum. Or, your planning might be predefined and framed if you have to use your organization's proprietary methodology.

2. Plan project time for planning. In average, at least 10 percent of management time should be allocated to project planning.

3. Write down a checklist of all project documents you plan or need to deliver. The list will mostly depend on your project's complexity, organization and methodology. (More on this in my next post.)

4. Start planning early and continue planning throughout the project.
Some of the planning documents, such as the high-level schedule or scoping documents, might have to be kept frozen upon sign-off. Other documents, such as the risk management planning or rollout planning, will typically require updating as the project progresses.

5. Continuously improve your planning.
Improve planning by communicating the planning outcome with your project team and by collecting their feedback regarding your planning performance. You can use this feedback for continuous planning improvement.

As the project progresses, keep a log of your planning issues to track gaps you encounter along the way. This is the "planning lessons-learned" document that you can also use for continuous improvement.

What do you think? How do you plan for project planning?

See more on project planning.