Olive’s Guide to effective requirements gathering for software and technology evaluations
If you had to guess how many software projects fail because of poorly articulated requirements, what would you say? 71%.
Requirement failure is the number one reason why technology and software implementation don’t go to plan. This holds back digital transformation. Here, we discuss requirements gathering for the software selection process.
Book a discovery call to learn more about how Olive can enhance your requirements gathering process.
Getting the Requirements Elicitation Process Right
Most CIOs, digital transformation leaders and IT departments know that gathering requirements is a problem. However, they rarely know just how damaging it is. The problem of not knowing is that you underestimate the risks involved and are more likely to make mistakes, rush or look for shortcuts in a tedious, costly process.
Each step in the requirement gathering phase is vital. Successful and seamless implementation is the result of an effective requirement gathering process so it shouldn’t be skipped over. If you want to get it right, you need to be thorough and go through the process. However, it is possible to accelerate it.
How to capture and gather requirements for software selection
Follow these requirement gathering techniques to set your project up for success
1. Appoint a Lead
Depending on the scale of the requirement gathering process and the stakeholders involved, you may need a project committee. However, at the very least, you need a central source of leadership stewarding the process. This person should understand who the stakeholders are and what constitutes a good, well-written requirement.
If you are the CIO or IT Director making this appointment, don’t forget that your success will ultimately be judged against the success of your implementation. It isn’t a hands off process. Regular check-ins and support are going to be important.
2. Define the Purpose and Goals of the Software
Setting goals and defining the purpose might feel unnecessary, but it is important for everyone to be clear on what success looks like. What problems are you solving? Why is it important? What do you expect to gain by implementing the solution?
Take the time to articulate your objectives so everyone is on the same page. Having defined goals gives you a framework to assess your requirements against and can help steward the process for stakeholders.
3. Define your stakeholders
A stakeholder is anyone inside or outside the company who is impacted by the software. Identify the right stakeholders for requirements gathering.
Direct users may be your employees, customers, partners, vendors or anyone who directly interacts with the software. Secondary users are those who rely on the outputs of the software. Both will need to be heard from because nobody is better suited to offering advice on requirements than those affected by it. As an added bonus, including your stakeholders into the process of gathering and giving feedback on requirements, leads to high user adoption later.
4. Software Requirement Elicitation
Interview Individual Stakeholders
Speak directly to the people who will be impacted. Your aim is to improve their functionality and output so knowing what is important in making things happen is essential. Outline the objectives and discuss what would help them and make their work easier and simpler.
Stakeholder Questions for effective requirements gathering
What do you need the new software to do?
What capabilities are required?
Who else is impacted by this software?
What areas need improvement?
What currently causes headaches?
What would you build into the current system if you had a magic wand?
Which competitors do things best and what makes them better?
What is on your wishlist for software features?
What would make your lives easier?
Shadow Stakeholder Processes
Answering a questionnaire or responding to interview questions won’t always go deep enough for requirements. Employees might forget something or overlook how integral a certain function might be.
Roll up your sleeves and get involved. You may find some important requirements and areas of inefficiencies by shadowing the team members. Many employees might view something as a reasonable cost of the job but to you, it is clearly causing delays.
Host Cross-Functional Meetings
Eliciting requirements typically starts and ends in meetings. You open the discussion around goals and objectives and listen to understand the current process, pain points and desired future state. Assess, discuss and rank the requirements as a team.
Set cross functional meetings between groups of different stakeholders to drive engagement and alignment on requirements. When departments get together, they can see the process through different perspectives and how they can make it better for each other. Gather all the requirements discussed and if you need, ask for further clarification. Clarity is going to be essential.
5. Document Everything
You will be getting requirements from a host of different sources and channels. Meeting minutes, feedback forms, shadow process notes, interview transcripts, email chains and more will be flooding in. Everything should be recorded in a central area. Most often this is Microsoft Excel or Google Sheets.
Document everything in clear language. Where it is required, add annotations to give further clarification because you will forget what the intention was from time to time.
Keeping a central document allows you to codify the information gathered. Make sure your record uses language that can be accessed by all potential stakeholders. If you need a description verified, ask the stakeholder because this is how requirements get mis-translated. Be as specific as possible. Once it comes down to writing functional and non-functional requirements, you’ll be glad you did.
6. Ranking Requirements
Once you have all the requirements gathered, categorized, and formatted, you need to go back to the team for prioritization. Create a feedback form that will uncover the clear ranking order of each requirement. Usually this is done in online forms, can help streamline the usability of the feedback.
The aim of revisiting your stakeholders is to create the list of blockers must-haves. Must-haves are the capabilities that the team can’t do without. What are the non-negotiables? What separates a requirement from being a ‘nice-to-have’ to a ‘must-have’?
7. Re-write Requirements as Vendor Usable Requirements
The information and notes you take from stakeholders is highly unlikely to be in a vendor appropriate format. Requirements must be written correctly. You will need to adjust the wording and break things down with specific, commonly used language. This step alone can be a nightmare because a good requirement is one that expresses a clear need and cannot be interpreted in any other way. It’s more difficult than you think.
Keep requirements short, articulate and unambiguous. Vendors need clear and absolute terminology.
8. Taking Your Requirements to Market – Avoid Bias
Equipped with the requirements, you’re ready to see what is out there. Usually this is done through a self search or an RFP but both come with inherent bias.
Ignorance Bias in Choosing Who You Know Only
A self-search is taking your requirements and finding what vendors are out there to satisfy your needs. You’ll often start with who you know, what is easy, the opinions of trusted sources or even friends. This is problematic because you limit your options to who you know. It’s an ignorance bias. You could be missing out on the perfect vendor because you just don’t know they exist.
Market Comparison Site Dangers
The next step is usually to go to a market evaluator platform. We use them for everything now from Airbnb and Booking.com to medical and car insurance. For software, these platforms appear more helpful than they actually are.
The problem is that vendors on these sites pay to play. The results you get are not entirely based on the requirements you put in. They are based on who in the field has paid to rank higher up the list. This should be a concern because it puts the power in the hands of salespeople as opposed to buyers. Priority is given to making sales rather than improving businesses.
RFP Concerns
The RFP process relies entirely on how well you define requirements and the accuracy of the responses received from vendors.
You will likely see a wide range of responses to the same requirement. 10 different vendors giving you 10 different answers makes it difficult to compare and contrast. Each vendor also has the aim of creating sales so will talk up their ability to satisfy each requirement.
9. Request Demo
Sift through the vendors who respond to you. If you find 3-5 that seem like a good match, ask them for a demo. Often vendors don’t get asked to prove themselves or they treat demos like a sales pitch so draft the questions you need answered and decide on a selection criteria that will be used to rank the vendor demos. Bring a selection of colleagues to represent your stakeholders and have all voices heard.
Selection Criteria Examples
Based on the demo you received, ask stakeholders for feedback on;
– Vendors ability to satisfy requirements
– Usability/UX required
– How well the vendor meets functional and non functional requirements
– Vendor’s partnership potential
– Product scalability and support
– Overall demonstration and professionalism
Your aim is not to be sold to but to find something that meets your needs. If your vendor goes off track, ask them to get to the point or speak to your requirements. After demo’ing your potential vendors, meet with your team to discuss the selection criteria.
Olive is the ultimate tool for gathering requirements.
The Olive Process – avoid RFP templates, spreadsheets and zoom calls
Olive knows the process works and that it is essential for finding the right software. But it’s just too long, flawed and risk prone. Not to mention, cobbling tools together to run the process, results in shady data, and potentially human error and bias within the results. To mitigate this risk, we have created one tool to do it all. We have maintained the process but improved and shortened it by automating redundant functions, removing bias and giving more power to the buyer. Give Olive a try, instead of using multiple excel spreadsheets, to gather requirements, trying to rank them in meetings and trying to manage the entire requirements gathering process across multiple PM tools such as Jira or Jama.
Olive provides clients with libraries of requirements to choose from so you don’t risk omission or misinterpretation from vendors. Our library speaks the language of the stakeholders and vendors so there is no margin for error or disconnect. Once your team has had the chance to collaborate, select and grade the requirements together, Olive puts your opportunity out to the right vendors, through surveys, without revealing your company’s identity.
Each potential vendor can then anonymously assess your requirements and respond with how they meet your needs. For your ease, you are presented with this data through a visual grid of how well the responding vendors satisfy your requirements. This allows you to dig into why each one responds and flag any concerns you have.
We eliminate vendor bias by not charging vendors to feature. We find that the typical platforms lack credibility by putting the power in the hands of the seller. That shouldn’t be the case. You’re the buyer, you take the risk and need a software to serve your business needs. You should only be offered vendors that help you. That is the Olive philosophy.
Streamline Your Requirements Gathering Process with Olive
Gathering requirements is a tricky part of the process. Few understand the potential pitfalls and it leads to a huge possibility of failed implementations. Without clear requirements, you are susceptible to the risks but the process does take quite a bit of time.
Gathering, ranking and satisfying your requirements through Olive’s platform streamlines and shortens the process. You get industry expert advice and vendor appropriate requirements to give you assurance in your procurement. Olive helps you to reduce the margin for error so that your implementation goes exactly as you had visualized in the very beginning.
Book a discovery call to learn more about how Olive can enhance your requirements gathering process.
