Thus your immediate problem is how to develop your purchase requirements. To help describe this requirements development process, I'm going to frame this article around a cloud service purchase. Specifically I'm thinking of software that will be used internally, as opposed to software that will be used by your organization's customers. Examples of this type of internal software are systems for accounting, ERP, a help desk, project management, etc. Note that this requirements development process could just as easily apply to purchasing in-house software, hardware, other services, or any combination of those. A phone system is a good example of a purchase that combines hardware, software, and services.
There are potentially many products on the market that could work, but the question on your mind is this: Which product most closely matches my requirements? How do I find that product? Bear in mind the first order needs for users of these products are often very similar; it is the second order needs that vary significantly between organizations, and they can make or break the purchase.
To answer that question of which product most closely matches your requirements, you need to effectively develop or gather your purchase requirements. But before we get into gathering the requirements themselves, we need a "requirements framework". A list of requirements by itself is of limited use. You also need to know information behind each requirement, basically why it exists, and who it matters to.
Typically you can manage this information on a spreadsheet, and I have found the following columns to be useful:
- Requirement Name - a short, descriptive name for the requirement. Used to refer to the requirement in other documentation.
- Requirement Description - This expands on the requirement name, and is a detailed description of what the requirement is. Write it in such a manner that a potential product vendor would understand exactly what you wanted when reading the description.
- Who wants the requirement - This is a list of those people who want the requirement. It should also include their title or job function.
- Requirement Reason - This is an extremely important field, and explains why the people above want the requirement.
- Requirement Importance - See below for more details on the Requirements Importance column.
Requirements Importance
This is a measure of how important the requirement is to the people who want that requirement. Usually it is best to have words that describe requirement importance, along with an explanation of what those words mean. You can also attach a numerical rating to each importance, e.g. the numbers 0 - 6 in the example below (more on using these numbers in a future post).
Requirement Groups
It is useful to group related requirements in your list, e.g. all security requirements can go in a group called “Security”, reporting requirements can be collected under “Reporting and Analysis” etc. See below for an example of requirement groups from a help desk evaluation.
This sums up a useful framework for managing the purchase requirements you are about to collect before making a significant IT purchase decision. In my next blog article I will discuss a technique for creating a list of requirements that includes finding those requirements you don’t even know you need.
