Shopping for almost anything, including software, is as easy as a Google search today. With a few phrases and clicks, we can quickly see what’s available in any category from phone apps for meditation or financial planning to enterprise software for product lifecycle or quality management. Amazing and convenient, right? We also can quickly go down rabbit holes of possible solutions without the guidance of requirements. We do cover the research and evaluation stage later in this guide, but before you start Googling or checking out G2 reviews, you need to articulate and prioritize your requirements.
You may be familiar with product requirements, which range from market, customer/user, and business to functional, technical, operational, quality, and more. While you won’t be doing full requirements management activities as you do with your own products, you need to identify requirements for the solution that will meet your business needs.
Solution requirements are capabilities or conditions the software you select must have to meet the business needs and provide confidence in continued success.
You can name and sort requirements into categories. This will help you as you work through requirements prioritization or weighting discussions as well as provide some organization to your list. You may also further group requirements into areas under the main categories.
Explanation:
The specific information, behaviors, rules, and operations a solution should have to ensure desired outcomes and meet the business needs.
Possible Requirements Areas:
Business-need requirement areas will map to the processes that support your business needs—so this will vary.
Get a PLM/QMS requirements template in the project plan template for examples of areas for product companies shopping for PLM and QMS solutions.
Explanation:
The manner or environment in which the solution needs to operate, including additional expectations you have for the solution or qualities it should include across all business need(s).
Possible Requirements Areas:
Explanation:
The attributes of the solution as well as the vendor’s strength (financial, historical, customer success, customer support) to support your projected growth and future needs.
Possible Requirements Areas:
Creating a full requirements list from scratch is work and can be challenging if you have not defined solution requirements before. Instead, upcycle! Gather a few templates for requirements in the solution space you need and use them as the basis of your own.
Where to find templates?
“The perfect is the enemy of the good.”
– Voltaire
There is no perfect solution. You won’t meet all stakeholder needs and you can’t make all users happy. You can find the best solution—the solution that best:
To get to the best solution, you will need to prioritize requirements. You can use a simple prioritization, such as 1=must have, 2=nice to have, and 3=do not need. As you evaluate solutions, you’ll use this prioritization value to determine weighted final scores, so use numbers.
Don’t overcomplicate the priorities. The simpler the scheme, the more valuable your conversations about what is needed, preferred, or just technology-induced dreams.
As you engage with vendors and see the functionality they offer, you may realize that what the vendors are providing differs in scope more than you expected. Indeed, sometimes no vendor does all you need in one package. In these cases, you want to talk with vendors (and some of their customers) about how they help with your business needs and how they don’t. With structured data and standards, many companies use data flows and integrations across systems as needed. This removes the pressure to settle for a cumbersome, expensive, or unfriendly “all-in-one” solution.
✓ Find one or more solid requirements templates to jump-start your identification efforts—we provide a PLM/QMS requirements template for you in our master software search project template
✓ Get the team together (virtually or F2F) and work on completing requirements identification and prioritization
✓ Put the requirements document somewhere accessible to the team, preferably attached to the project plan (this project plan template includes the requirements template and more)