3

Prioritizing Requirements

In the previous chapter, we learned about elicitation planning and the different tools and techniques of elicitation. You got the opportunity to transform the business user’s expressed and unexpressed intentions, thoughts, and ideas into formalized requirements. You have a complete list of clear, consistent, complete, and validated requirements. Now, we need to review and sift through this huge list of requirements and work on prioritizing them. We have limited resources and we cannot deliver everything. To enable businesses to realize optimum business value by addressing the most pressing and important requirements, we need some kinds of prioritized requirements. For this, we need to identify the requirements that are valuable and group them.

In this chapter, you will learn about the process of managing requirement prioritization based on urgency and relative importance. You will work with the stakeholder/subject matter experts and rank requirements that are identified during the requirement identification phase. You will learn about the methods to identify important tasks that provide business value. You will also learn about the dependency map between various requirements and how to prioritize dependencies without creating gaps in the requirements flow. We will conclude this chapter by reviewing proven techniques for managing meetings, resolving conflicts, and getting consensus and agreement from stakeholders.

We will be covering the following topics:

• The importance of requirement prioritization
• Reviewing various prioritization techniques
• Creating a dependency map between requirements
• Managing prioritization meetings and getting consensus
• Simple CRM requirement prioritization and roadmap scenario

Requirement prioritization enables you to identify the most important business needs so that the next phase of the project can work on these important requirements. The most challenging task is how, as a business analyst, you manage conflicting priorities based on stakeholders having different goals and priorities. It is highly recommended to initiate ranking or staking requirements from the elicitation phase itself. From my experience, by starting early, you may easily identify about 50% of the top priorities that you think may go into the first release. Prioritization helps you plan the implementation and layout of the roadmap.

The importance of requirement prioritization

Any project has a limited budget, definite duration, and finite resources. Prioritization helps with managing requirements and the allocation and utilization of resources effectively and productively. It helps us focus on putting our efforts into implementing the most critical requirements that matter most. By prioritizing, we are identifying and defining when requirements get addressed and implemented. This helps us improve communications and keep everyone transparent. Many times, I have experienced that the prioritized list keeps changing. When socialized with stakeholders, they rethink and redefine what they need now versus later. This helps us to move requirements around and prioritize them to get the most benefit for everyone.

Prioritization activity should be iterative, at our workplace, we revisit this list every 3 to 6 months and adjust it based on the needs at that point in time. New requirements will be added and they may take higher priority, whereas the existing prioritized ones may be dropped as we found a new way to better address the needs. This list also helps us in creating project/product roadmaps. You can group them into various releases, such as numbers 1 to 10 from the prioritized list go into Release-1, numbers 11 to 20 go into Release-2, and so on. Sales and service team members do not have the patience to wait for years to see the solution, especially with Salesforce implementations. After we get the agreed prioritized list, we create a roadmap for the next 12 to 15 months, spacing releases every 3 to 6 months depending on the complexity of the deliverables. Good prioritization helps us with building these roadmaps and this, in turn, helps us plan project activities and keep stakeholders informed on when they can see the finished working product.

Reviewing prioritization techniques

To enable effective requirement prioritization processes to happen, we need to use objective consensus methods to remove any bias. Let us look at some of the frameworks that we can utilize. Sometimes, you have to use a combination of frameworks to achieve results.

These frameworks will aid you and your stakeholders in better decision-making. None of the techniques can work in isolation and it needs to be a collaborative effort. Understanding the available techniques will help you pick one that provides the most actionable results.

The following are some of the techniques/frameworks. Use the ones that work best for you:

• The MoSCoW method: Used to identify and action important requirements.
• Multivoting: Voting requirements based on an established set of rules/voting ranks that are point-based/cumulative.
• Weighted ranking/staked ranking: Ranking requirements based on established risk factors and weightage.
• SWOT analysis: Prioritizes based on strengths, weaknesses, opportunities, and threats.
• RICE scoring: Prioritizes based on scoring each requirement against these four factors: reach, impact, confidence, and effort.
• Value versus effort: Compares scores based on value, benefit, impact to cost, risk, complexity, and effort.
• Story mapping: Orders requirements on a grid in a logical manner to describe the activities end to end. This offers simplicity and is easy to understand.

You need to employ more than one method to get to the correct prioritizations.

I often use the MoSCoW method, weighted ranking, and story mapping for prioritizing my requirements. This is what I prefer to do:

1. Use a combination of methods to bucket them into three groups: High, Medium, and Low (or you can call them Red, Blue, and Yellow). This task can be achieved fairly quickly in a day or two provided it is done properly with the right set of team members in the session.
2. Get consensus and agreement from everyone that the requirements prioritized are categorized in the right bucket.
3. Next, we go through each one of the High-priority bucket items and use one or more of these prioritization techniques to rank them from 1 to N (with 1 being the highest priority).
4. Review them again after they are ranked collectively and agree on the ranking priorities. Do the same for Medium and Low. See the following diagram for more information:

Figure 3.1 – Prioritized requirements with each priority subprioritized

Next, we lay it on our roadmap. Based on time, budget, and resource availability, we pick X number of prioritized requirements for each release. In practice, some of the High-priority requirements will fall in Release-2. This is when the team needs to work collaboratively and see which ones are needed during Release-1 and which ones can wait until Release-3. Most conflicts arise in this kind of situation, as reality does not meet the perceived expectation. You, as a savvy business analyst, with the help of the project sponsor and project manager, need to show your negotiation skills and get everyone on the same page to agree. It’s not that these techniques or methods produce a well-prioritized list, it is the team that does that collaboratively. You can use one or more of these techniques or your own techniques.

The following figure shows an example of a multi-year roadmap for a sample of prioritized requirements. Adding a roadmap element to your requirement prioritization activity sets expectations with stakeholders and project team members and keeps the overall requirement process transparent:

Figure 3.2 – FY2022/FY2023 Multi-year project roadmap

Let us review some of these techniques. We are not getting into details as that is not the aim of this chapter.

MoSCoW analysis

The MoSCoW analysis categorization (or MSCW excluding vowels) stands for must have, should have, could have, and would have:

• Must haves: These requirements are needed, and without these, the project does not exist. Enabling these needs helps the business unit achieve its goals. These are the core functionality and capabilities of the system. For example, an account management functionality where users can create and edit customer records in a system. Also, if this is security risk-related or compliance mandated, then it will fall under this category.
• Should haves: These requirements are important and valuable and can wait a little longer. You will need them soon but not immediately. Examples are workflow notifications, automating processes, and so on. Users can still utilize the system but may need to rely on manual processes, which is inconvenient but possible. These requirements are also important and need to follow after all the must-haves are completed.
• Could have: These requirements pose a minimal impact on the project at this time. For example, a user would like to see their attributes (such as owner’s region/country/division/department) in account and contact records. Most of the time, these are simple requests and can be clubbed with one of the previous two categories to get synergy by saving time during the design, testing, and deployment. Of course, you still need to develop and do some level of design work.
• Would have: These requirements have no impact for now and do not impact the project. These are more ideas that may eventually morph into more important requirements and move up the chain. Examples are cosmetic changes to the UI or email templates.

Story mapping

In this technique, we arrange user stories for an end-to-end process in a sequence in a specific order of importance. By reviewing the stories along the process from start to finish, both the critical paths and possible alternate paths, we will be able to identify gaps as well as stories in the wrong position or undesired stories along the way. This will help during the prioritizing session in rearranging the stories for a more effective future state. This is like connecting all the dots to make a complete picture. When you see the end-to-end big picture, you can easily see the missing, misplaced, and redundant dots.

This method also lets us map the dependencies, such as the connection between the stories in the sequence of flow. Story mapping helps us find missing or unwanted events, which in turn helps us to refine prioritization. If managed well, story mapping gets the best outcome by complementing each other with other techniques.

A sample story mapping event flow is shown in Figure 3.3:

Figure 3.3 – Story mapping business event flow with missing requirements

For simplification purposes, we added only the story name and depicted this in the process flow format. When discussing with stakeholders, you can write each event on a story card and rearrange the story cards until you have the most optimal story that fits your business needs. You can think of each activity as a story card. This rearrangement will automatically give you the right priority for each of the story cards.

Now you know there are different prioritizing techniques, and you can pick ones that suit your project. In the next section, let us review and see how we can establish dependencies between requirements.

Dependency map between requirements

There exist functional dependencies between requirements, either from the same projects or from other project initiatives, and this will lead to reprioritizing requirements. We need to identify cross-functionality dependencies and prioritize requirements to align them by understanding dependencies between processes, systems, and teams.

You can identify requirements dependencies by reviewing or creating end-to-end process flows, function and system diagrams, and conceptual flows.

In this example, let us assume we have requirements from A to J, as listed in Figure 3.4, with priority values from 1 to 10. We stack-ranked them in our first iteration and in the second iteration, we used the dependency mapping technique and discovered that two specific requirements are linked together and need to be implemented at the same time; if not, neither will work:

Figure 3.4 – Requirement prioritization options

Let us analyze this step by step.

Option 1 is our first draft of prioritized requirements. We discovered that requirements A and F are interdependent. Implementing this option makes A unusable unless F is implemented.

We have multiple ways to address this dependency. For simplicity reasons, let’s say we came up with two other options.

Move F next to A and implement priorities 1 and 2 together as one unit. Now you are knocking others down. This is Option 2.

If feasible, split A into Ax (independent part) and Ay (dependent part with F), so that Ax can be done now, and Ay and F later. This is Option 3.

As an example, look at the following two separate requirements:

• Account management functionality: Sales analysts shall be able to create, update, and transact with the customers (High priority).
• Integrate customer identity verification so that sales analysts can verify customer identity. Sales analysts shall be able to access identifying information from the different systems without the need for a separate login (Medium priority).

On further analysis, we discovered that sales analysts cannot transact with customers without verifying customer identification. There is a dependency between these two requirements.

A possible solution is that we can make it into two parts:

• Enable user-friendly customer identification hyperlinks on the customer page. When the user clicks on the link, it opens up a window requesting them to add their credentials to access the system.
• Enable single sign-on (SSO) functionality shortly after release and make the hyperlink SSO-enabled.

We can identify this kind of dependency issue by using prioritization techniques such as dependency maps and be able to find workarounds. After addressing the dependency, we can reprioritize and adjust requirement priorities to get the most benefit.

Managing prioritization meetings

We reviewed various prioritization techniques and now you are equipped with different prioritization tools. In this section, let us look at how to make the process better by effectively managing the prioritization meetings.

For the requirement prioritization meetings, only key members need to be present in this meeting. Examples include the lead business analyst, technical lead, architect, project manager, cross-functional leads, key SMEs, project sponsors, and stakeholders. The technical team, architects, and project managers will be observers and will need to contribute when their expertise is needed for confirmation and clarification. Usually, the team size should be approximately 10 to 12 people and it’s highly recommended that they are co-located in a conference room. This is not an elicitation session and you do not need to have all team members present.

These are key decision-making events where leads/managers decide what is needed, when it is needed, and how it is needed for the business unit. The management can greatly benefit as this prioritized list will be the input for an implementation roadmap for the next 1, 2, or 3 years.

You can make prioritization meetings meaningful and effective, as follows:

• Engagement rules should be communicated
• Prioritization meetings should be well planned and communicated
• Clear agenda and goals should be communicated
• Ground rules for conflict resolutions should be established
• Educate and give an overview of the tools and techniques the team plan to use
• Define the criteria for prioritizing factors and their weights
• Set up a good conference room with a large wall-to-wall whiteboard, flipcharts, and projector to display previously created process flows, conceptual flows, and so on

Factors you need to take into account while prioritizing are as follows:

• Statutory/regulatory: As an example, if it is mandated by the regulatory authority, these have to be prioritized very highly. For example, data encryption at REST for PII data on account and contact records in Salesforce.
• Policy-related/audit findings: These are required by the company. It may be a policy to restrict emails from going to external users when sending notifications from the Salesforce system. Or it can be related to an audit finding that needs to be remediated at the earliest.
• Cost to implement: This can be any reason such as consulting costs for specific skills being too high. Specific vendor software can be easy to implement and use.
• Time to implement: Can this be implemented quickly in 3- to 4-month windows or does it need a long time?
• Value to users: Does it add value? Can it save users time, help them do things better and faster, or give them a better user experience?
• Benefit to organization/business unit: Does it meet regulatory requirements or get a better ROI?
• Ease of technology use: Can the system be used by end users relatively easily with minimal training or can it be scaled for more users?
• Skills availability: Do we have skilled team members? If we have to customize a specific function, do we have that skill set? For example, to create a complex function, do we have a skill set in Salesforce Apex and knowledge of Tableau CRM?
• Conflicting requirements: Implementing one will prohibit the other from implementing.

Based on your project, you can use combinations of these factors. Also, the relative importance of each factor may vary between projects and between companies. During the elicitation phase, plan and obtain agreements on the prioritization procedure to make decisions on what takes priority. Make every effort to see whether you can move forward constructively and negotiate a compromise with stakeholders with conflicting priorities or requirements. Establish a conflict escalation and resolution mechanism. Justify why a specific requirement is prioritized as High and another one is rejected. Be open, truthful, and transparent, and communicate the decision as early as possible to all stakeholders.

Based on the project, culture, stakeholders, and other parameters, rather than ranking, prioritize them in groups. All requirements that belong to a group will have the same rank and they will be implemented and released together.

Practical tips for success

Let us take a look at a few pointers that might help you with your prioritization activities. They are very useful and important and can potentially save you a lot of pain and time:

• Manage expectations by progressive prioritization and by being transparent.
• Set expectations with stakeholders that not all requirements may be implemented.
• Ask the right question:
  • What problem are we trying to solve?
  • What happens if we implement it?
  • What happens if we do not implement it?
• Involve the right stakeholder who is relevant to a specific session. For example, if you are discussing the account management process, there is no value in inviting all quote/contract management stakeholders.
• Not all stakeholders are the same. Some have a bigger say on what to prioritize because of their rank, knowledge, role, and so on.
• Whenever you reprioritize, make sure you are not breaking something else. You need to re-run whatever technique you used before, plus at least one more technique.
• Some requirements have to be prioritized as High because they may differentiate your product compared to other competitor products for political reasons (such as you want to release the feature for a major conference), and improve adoption/usability (if adoption and usability are already an issue).
• Prioritizing high-risk requirements early will help you mitigate the risk and find alternative options in the event it does not work out.
• You have to implement some requirements that may have a lower priority. We create a minimum viable product (MVP) and implement only the core functionality with minimal effort, which can be enhanced later. This effort will help you gain their trust and create excitement and interest. Do it wisely. Your main opposition will be your project manager.
• Start prioritizing efforts early. Start tagging them as High, Medium, or Low. Keep reviewing them iteratively and keep the document current. Priorities change as the requirements age.

Simple CRM requirement prioritization and roadmap scenario

Here is a real-life scenario that will help you get an idea of how to keep the stakeholder informed and set expectations. I simplified the functions so that it will be easier for you to understand and get a gist of it. The following screenshot is our documented requirements at the end of the elicitation activity. In these scenarios on the left, we have functionality for Account Management, Contact Management, and Opportunity Management in groups:

Figure 3.5 – Prioritizing requirements [before --> after]

Now, we took the documented requirements and color-coded priorities during prioritizing sessions with key stakeholders. We used ranking and story mapping techniques and came up with bucket ranking (Red – Priority 1, Aqua – Priority 2, Gold – Priority 3, and Green – Priority 4) on the right-hand side.

Let’s review the rationale:

• Priority 1:
  • Core functionality such as Account, Contact, and Opportunity Management are our main goals. Without these, we cannot implement anything else.
  • Compliance and regularity requirements such as Know Your Customer (KYC) identifies customer confirmation, and this is a complex process that resides in the external system.
• Priority 2:
  • Workflows (automation, notifications, and approval) are our next business priority to get informed and take timely action. This will enable us to have a better user experience and better adoption.
• Priority 3:
  • Data enrichment tool (for example, D&B Hoovers, Pitchbook, and Demand Tools), sales navigator (for example, LinkedIn sales tool for contact enrichment), and integration. These tools and integrations automate and simplify data creation. Our priority here is to keep the data clean, usable, and relevant.
• Priority 4:
  • After we have the core functions, good data, integrations, and automation, we implemented reports and a dashboard. Our rationale here is to enable a tool that works accurately. So, it made sense for us to have it after data enrichment.

Now we have the prioritized list, nicely colored and agreed upon by all stakeholders, which mapped each of the requirements to their appropriate priority. All is well with everyone so far, as some stakeholders with Priority 2 requirements may expect to get theirs implemented along with Priority 1 during the first release. Even worse, some stakeholders may expect even Priority 3s and 4s to be delivered during the first release. So how do we solve this?

Your next task is to place them in release buckets. Before segregating them into buckets, educate stakeholders about the release timeline, resource capacity, high-level time estimate, effort, and so on. Once everyone agrees, start dropping each requirement into various buckets starting with the highest priority to the lowest. In our simplified example, we moved all Priority 1s into release bucket 1. If you still have the capacity, you can move some of the Priority 2s into this bucket. Finally, you will be able to assign all requirements into various releases after long conversations, agreements, and disagreements. The following figure depicts the roadmaps for your requirements. This gives a glance at when a user can expect to see their requirement implemented:

Figure 3.6 – Requirements roadmap

This analysis is specific to the project. Your priorities may be different from the ones we have, even though we both have similar Salesforce implementations. As a business analyst, you have the knowledge and experience of navigating your organization and getting requirement priorities that fit your requirements.

Business analysis and project management in a true sense go by strict rules and are very stringent on what is in scope and what is not. On paper, this is all well and good, but in real work, this is not the way it works. I have seen many requests prioritized as low and these are requested by influential stakeholders and end users. 80% of these requests take only 20% of the time. Rather than wasting time on negotiations, I would go with re-prioritizing and tagging this 80% with other higher priority items. By logically grouping them, you save time during testing, training, and deployment. At the end of the day, we deliver more with a little bit more effort, but at the same time, gain the trust of stakeholders. This helped me tremendously in my later projects as these stakeholders understand that you do what is best, and since they trust you, the business analysis process gets more impactful and fun.

Note

While some may argue that project managers are responsible for project roadmaps with input from all key players, I would say there is no harm in business analysts initiating and creating one. Later, you can hand this over to your project manager (PM). By creating this during the prioritization phase, you are not only prioritizing requirements but also letting users know when they will get their requirements addressed.

Summary

In this chapter, we covered techniques that you can use to help you prioritize your requirements so that you can accurately capture business needs in the right order of priority, keeping the process transparent for all stakeholders.

You got a good idea of why requirement prioritization is important and how it helps you to identify the most important requirements that the team should address to fulfill the business need and add value. We looked at various prioritization techniques that can be used to enable the team with the prioritization process. We also showed you how to create a dependency roadmap of requirements to help you identify any gaps and opportunities to improve by adding new requirements or re-arranging existing requirements. Finally, we learned about managing prioritization meetings and getting consensus, helping you to manage conflicts, obtain consensus from all participants, and keep stakeholders up to date with the requirement priorities.

In the next chapter, we will cover process flow. We will review how to capture the current state of business and what the gaps and opportunities are, and then develop a process for the desired future state. We will also capture ways to automate processes so that users can have a great user experience.

Questions

1. What are conflicting requirements and can we implement these requirements?
2. What are the advantages and disadvantages of the MoSCoW technique?
3. Why is requirement prioritization important?

Further reading

• Requirements Management: A Practice Guide by PMI: (https://www.pmi.org/pmbok-guide-standards/practice-guides/requirements-management)