Get Clear on Priorities
This phase will feel quite familiar to lots of us: we are understanding and synthesizing what we truly need in a new solution. The challenge at this point is to avoid simply saying that we need everything our current system (or spreadsheet, or manual process) does, plus addressing a few pain points.
Yes, in large part we need to satisfy the features and functions of a solution we’re replacing. But we’re well served by shifting our perspective from feature parity to process and people enablement. What do we want to be able to accomplish with a new tool? Which end-to-end processes are we supporting, and how? What do the impacted teams need to be able to satisfy current and emerging business needs?
This Phase at a Glance
In the Prioritized Requirements phase, our goal is to be able to describe the system capabilities we need to enable business outcomes.
We’re aiming to create an intuitive artifact that we can use in multiple ways throughout the vendor selection effort. We’ll share a version of the prioritized requirements with vendors in our Request for Information (RFI). We’ll create a vendor evaluation scorecard to use in demos and discussions, marking down to what degree each option can fulfill what we need going forward. And we’ll make sure that all high-priority requirements are addressed in proposals and implementation plans.
More than the artifact we’re creating, we want to align the selection team on what’s truly important from a new solution. We often have different ideas of priority levels for specific items across teams, and part of this phase is working out what’s truly important overall.
Here are facilitator activities at a glance:
Conduct requirements gathering sessions with key stakeholders and SMEs
Document and prioritize business and technology requirements
Here are selection team activities at a glance:
Describe business and technology needs
Discuss priorities and constraints shaping requirements
At this point in the project, our vendor count is unknown, but we may have a few “probably yes” and a couple “probably no” options after synthesizing vendor input surfaced during kickoff with the facilitator’s initial thoughts.
Key Activities
Let’s walk through each of the activities in this phase, with what success looks like and considerations to work through.
Conduct requirements gathering sessions with key stakeholders and SMEs
Have you ever been handed a spreadsheet with a bunch of tabs and formulas (maybe even macros) and just been told to figure it out? The person who created it knows where to start and how to make sense of it all, but it can be incredibly difficult to decipher what’s important just from looking at the mechanics of a tool.
We don’t want to hand our version of the cryptic spreadsheet to vendors or to an implementation team. Solution requirements are the bridge between what we have today and what we want to adopt tomorrow. In them, we share what we need to accomplish the responsibilities related to the technology at hand.
To compile and prioritize requirements, the facilitator will need to conduct requirements gathering sessions with key stakeholders and subject matter experts from the selection team. These are most effective when they’re centered around end-to-end processes, cross-functional (and cross-technical) areas, and what an internal or external customer needs to be able to accomplish.
For instance, we could go through the various departments that use the current solution and jot down the activities, insights, and handoffs they are seeking to address with a new tool. We’ll also consider technical teams (security requirements are typically among the highest-priority requirements on the list) and any legal or compliance needs.
A note of caution around legal and compliance requirements: these can have a dramatic impact on your option set. If you’re in a highly regulated industry, make sure to get very clear on what is needed around data protections, reporting expectations, location-based requirements, and more. In some cases, technology providers have a separate solution to satisfy regulations.
And be sure to clarify required and desired integration points. Often, the solution we’re replacing is so old that it doesn’t connect nicely to anything else or it’s the heart of a “spaghetti mess” of interfaces. Make dedicated time to discuss which tools or processes it would be helpful for our new solution to receive information from or send information to in a future state less encumbered by technical debt. (You may find yourself adding desired integrations in the Future State Vision phase, next, as you envision using technology to enable these handoffs even more effectively.)
The best requirements gathering sessions have stakeholders and SMEs describing business and technology needs clearly without jumping to solutioning. (It’s so tempting to take that leap from what we need to how it should be designed, but work hard to focus on what we actually need first.)
Beyond getting a functional or technical need surfaced, I recommend getting to the heart of why we need specific requirements. It may turn out that we’ve done some unintended solutioning and need to go back to basics.
For example, I once helped a customer service team move from a mainframe- and terminal-based system to a more modern app. The terminal had a menu of options, and the user pressed a function key (like “F8”) to navigate to a specific area, then used a combination of tabs, function keys, and typing to get work done on the activity screen. Many of the customer service reps didn’t even use their mouse, and they knew those prompts by heart, so they could fly through the legacy system’s workflow.
The selection team wanted to include requirements like “the new system shall require minimal mouse clicks” and “the new system must be able to be navigated easily with keyboard prompts.” But this was too solution centered. As we talked through it, what they actually needed was for customer service representatives to quickly navigate to an activity area, get information and take a best next action, and include the relevant details to execute the transaction.
Whether they clicked or tabbed or F8-ed wasn’t the issue: speed and intuition for non-technical people was.
This was long enough ago that the idea of an AI agent just doing the task for them based on information at hand wasn’t even a thought. It was more in the era of wanting to have the call-routing system pass the phone number to the transactional system, to avoid jotting it down on a scratch pad. How far we’ve come!
One of most seductive and dangerous pitfalls of migrating to a new solution is simply replicating what we had before, often customizing the new system heavily to fit the old processes. Then we’re left with a new system – which probably had some workflow upgrades end users could’ve benefited from – that’s difficult for the support team to maintain. Often end-users are still frustrated with the new system (despite our efforts to minimize impacts to them) because change is hard and we’ve fit a square peg into a round hole in the new tool, so there are typically some weird user experience moments.
Rather than mimicking an old technology, we’re aiming to understand what people and processes truly need to be successful, finding a tool that can accomplish that, and using the best-practice workflows inherent in that tool (with minimal customization) going forward.
Of course, we’re in the early stages of being able to spin up and spin down new technology solutions with some well-designed prompts. Through this shift, we’ll still need to be able to share what we need and why; we may just use the information differently.
Document and prioritize business and technology requirements
To use these requirements going forward, we need to document them. Most of the time, my requirements end up in a spreadsheet, where it’s easy to enrich the requirement itself with a category, priority level, examples, etc. (And then it’s easy to reuse in the various formats I need going forward.)
But your requirements don’t have to start out in a spreadsheet! One reason to branch out from a tool perspective is that it can be difficult to get meaningful feedback from the selection team by reviewing a long, thorough list. We can make it easier by including vivid and descriptive categories, so team members can focus their review time on the areas that they have the most expertise around.
Beyond categories, we can also tie requirements to end-to-end processes and steps, which helps provide something for people to connect back to (particularly if dry technical requirements are putting them to sleep).
If you’re interested in starting somewhere other than a static list or table, I recommend using an interactive tool that allows selection team members to upvote or comment on specific categories or requirements.
With this, you could facilitate a prioritization session where you ask each team member to vote on the top five or ten most important requirements to them (potentially dividing the group and the requirements list into subsets, then having everyone review the other groups’ recommendations). And you can have people annotate anything that’s not clear or not adequately covered while they’re looking through requirements.
Whatever way you generate feedback on their completeness and importance, iteratively refine your list of requirements until further review is generating very few updates.
(We can continue to refine the requirements list during future state visioning, so it’s not set in stone. But at this point, we want a pretty good understanding of what’s needed going forward.)
Advanced Class
Beyond the spreadsheets and interactive lists mentioned above, we’ve tried several generative AI tools that aim to make the requirements compilation and prioritization process richer and easier. Some of these have a built-in requirements bank that you can customize to your team’s needs. Some have sent these to vendors and gotten their take on requirements fulfilment (buyer beware), so you get an initial sense of which requirements are fulfilled by which options.
We recommend using AI tools at each stage of the vendor selection journey to get additional perspective, speed up tedious tasks, and test your thinking.
Just make sure you’re pressure testing ideas, no matter who or what generated them.
Tools & Artifacts
A list of prioritized requirements is the key output of this phase. Aim to enrich each requirement with a category and description, and tie requirements to an end-to-end process if at all possible.
You may also include some helpful metadata that helps your future efforts but doesn’t get shared with vendors: this could be the name of the main SME for the requirement (to ask follow-up questions) or the team you expect to test whether this requirement has been fulfilled (as an input into implementation planning later).
