Know what you want: How to build a business requirements document for software procurement.

The way that businesses purchase SaaS products has fundamentally changed. Ironically, however, despite our ever-increasing access to information, the software procurement process is now more difficult than ever. To simplify the process, and ultimately increase the ROI on a software purchase, borrow a technique used in software development and create a business requirements document. This clear outline of the priorities and requirements of a SaaS purchase gives stakeholders a clear guide.

Pain points in procurement.

A report by Gartner called 5 Ways the Future of B2B Buying Will Rewrite the Rules of Effective Selling took a close look at the factors complicating the B2B procurement process, including:

Organizational complexity. 93% of surveyed buyer stakeholders said their purchasing decisions were part of a larger institutional initiative, with 80% expressing uncertainty that they could manage the desired changes. The resulting uncertainty made them 30% less likely to make a purchase decision at all.

Too many cooks. A decade ago, the average number of stakeholders involved in a B2B purchase was five. Today, the average is 11, and sometimes as many as 20. Each of those people brings their own biases into the process — that’s a lot of competing priorities.

Changing views of the sales process. More members of the millennial generation are making purchasing decisions, and they bring a fresh perspective. Gartner’s research found that they are twice as likely to be wary of salespeople, with 44% saying they prefer no contact at all with sales teams. Instead, millennial purchasers often prefer to turn to other sources of information, including network referrals and customer review sites as the basis for their decisions.

Difficulty looking at the big picture. Software purchases must consider the long-term needs of a company as it grows, as well as considerations like ease of onboarding and implementation. Focusing too narrowly on specific requirements can also limit the discovery of new products that solve multiple problems.

The result? A majority of respondents told Gartner that purchasing is now overwhelming and difficult. The solution? Enter the business requirement document.

Steps in identifying business requirements.

1. Determine what problem the software should solve. Consider the following questions:

• What pain points are you trying to solve?
• In what ways is your current tech stack inadequate?
• Are those problems the result of software problems, process problems — or both?

2. Gather information from end users. Too often, buying decisions are made without consulting the people who will use the product on a regular basis. Companies have better buy-in when end users are involved. Ask them how their jobs could be easier, and dig deep into the processes and systems that could make that happen.

3. Make a clear list of what you want. Drill down deep — this is your chance to really figure out how to improve operations.

4. Take the long view. Invest in new software with an eye to where you want to be, not necessarily where you are right now. You want a solution that will scale with you, not hold you back.

5. Consider the entire offering. Don’t just think about requirements in terms of functionality. Requirements should also consider your needs in terms of:

• Onboarding support.
• Training options.
• Availability of customer support.
• Help center documentation.

6. Don’t think in silos. Make sure any new software integrates well with the rest of your tech stack.

All requirements are not created equal.

In a perfect world, once you have a list of requirements, you will immediately identify a SaaS product that meets every one of them. The reality, of course, is that you may have to compromise on some of them. That can get tricky with a lot of stakeholders, so it’s imperative to rank the priority level of each requirement.