So you have confirmed that indeed, your organization is in need of a new technology solution. Perhaps it’s a content management system (CMS), a marketing automation platform (MAP), a digital asset management (DAM) tool, or perhaps a combination of solutions. Whatever the technology, the prudent next step is to start talking to others in your organization to understand their needs and use cases for the new system(s).

Why is it important to gather requirements from the organization? Why can’t the project team just create a list?

Letting just the project team drive the bus and navigate and determine the arrival time (to overwork a metaphor) might be the easiest way to go about it, at least for them.  But going directly to the business and IT leads, and the stakeholders that use the technology on a day to day basis, as well as the leaders who drive the organization’s strategy is not only about making sure that the technology can do what it needs to from a features and functionality perspective. Technology implementations take time, money and people to get it right. Reaching out beyond the typical few on the selection team will help build support for the initiative, as well as awareness of what the new technology can enable and support to help meet company goals and objectives.

If done properly, the requirements gathering process can also help:

• Ensure the selected solution meets the primary user and business needs, and fits in well with the overall technology landscape and plan for the organization.
• Drive the change management process. The discovery process should be about more than just collecting a list of features and functionality. It is also about understanding users’ needs, and is also a great opportunity to connect and review the associated processes, skillsets, and governance that support and surround the technology. Implementing a new, killer solution without the right processes and people to support it will severely limit the usefulness of the technology.
• Reduce the risk of over- or under- buying. The outreach can surface and identify gaps in what is being done today, as well as what the teams using the technology would like to be able to do with it in the future. Buying a technology that only meets the needs of the business today will quickly fall short in the eyes of the users and the business. In the case of complex technologies like content management systems, the company may have outgrown the technology before it is even fully implemented.  Buying too little or too much can be a very costly mistake

Ultimately, engaging a broader audience will help build confidence in the selection team when exploring solution alternatives, both from team members and the business as a whole.

What is the best way to gather requirements?

There is no one “right” way to gather requirements. And the best way depends on many things:

• The size of the organization
• If the stakeholders that need to be involved are all in one location or geographically dispersed
• The number of people that need to be included. And this can be tricky. Deciding who is involved in the discovery process involves more than just who owns the technology and who will be using it. Big technology buys, such as a CMS, have the potential of impacting the entire organization.

When working with clients on selection projects Digital Clarity Group uses a medley of discovery methods – interviews, workshops, surveys, focus groups – depending on the number, mix, and location of the stakeholders, as well as the types of information we are looking to collect.

The important thing to remember about gathering requirements is to make sure that the stakeholders that should be included are, and to facilitate the process to ensure they participate.

Prioritizing the long list of requirements

Once the requirements are gathered then they have to be prioritized. That’s not to say that only a few will be considered, but more so that it is a process of sorting through the litany of needs and wants and identifying which of those requirements and requests are critical. Which features, out of possibly hundreds asked for, if they are not robust and complete enough within the solution selected will ultimately mean an implementation failure. At Digital Clarity Group we call these focal needs.

Typically it is these few (5-10) focal needs are what will help narrow down the list of possible technologies that will work. And that is not to say that the other 107 requirements identified will be ignored, or excluded from the process. As is the case with CMS’s and other technologies, there is a core set of features and functionality that is included, to one extent or another, across the majority of options in the market. Therefore, using those to identify a short list of possibilities, is an exercise in futility. Once the technologies that meet your focal needs have been identified, then turn to the other features and functionality requested by stakeholders to narrow the initial list of vendors down to a short-list of three or four vendor options.

Finally, remember to consider the technologies’ future roadmap as well in your evaluation process. Just because a technology vendor doesn’t match up perfectly with your current list of features, just as your organization’s technology landscape will evolve, so will the capabilities of most vendors. Identifying vendors that are forward-thinking and whose roadmap aligns with your own can make for a much smoother journey.

To hear more about requirements gathering, be sure to listen to our Requirements Gathering Podcast. As well, check out our stakeholder evaluation tool to help you identify who in the organization should be included in the requirements gathering process. Also, we’d love to hear about how your selection process is going, as well as some of the lessons learned during your own discovery phase.