If you know ahead of time that the software is going to be purchased instead of built, how does the requirements process differ from that of a standard development project?
I think a key difference in a supplier selection project comes from the fact that you are buying functionality that already exists. And while you will probably customize and configure the software, it is not necessarily going to be exactly the same end result as if you developed it internally.
Given that difference, it makes sense to gather high-level requirements and select the supplier using that level of detail. Then work with the supplier to specify the detailed requirements necessary to configure and implement the supplier solution, integrate it to existing systems and custom build any missing functionality.
Inherently, you will be forced to really focus on the core requirements and leave design out of the picture while you choose the supplier. Once you have selected a supplier, you will find it very challenging to speak about requirements without talking about the design of the solution you selected.
As you compare supplier software, you will probably have to make some tough decisions. For example let’s say you have 4 features. One supplier may support features 1 through 3. Another supplier supports features 2 through 4. A decision maker on the project has to weigh all of the factors to make a choice including things like: price to buy and implement each solution, price to build the missing feature in each case, cost of not having one of the features, time to implement. But the reality of this situation is that someone may decide that feature 4 wasn’t really a requirement after all!
A proposed approach to selecting a supplier
For the actual requirements process, here is an idea of what we follow to select a supplier:
1. Define the actors that will use the functionality.
2. Define the high-level requirements. This may take the form of named use cases or features.
3. Specify more detailed requirements based on the highest risk areas.
4. Research the marketplace to identify a list of potential suppliers. This can be done by surveying SMEs, doing web research or talking with colleagues.
5. Narrow the list of suppliers down to the top three to five, based on how closely they match the requirements gathered.
6. Have the suppliers do high-level demos of the solution. Eliminate any suppliers that do not seem to be a fit at this point.
7. Create test cases using the requirements gathered to sufficiently demonstrate how each supplier measures against the requirements.
8. Have the suppliers demonstrate how their solution satisfies the detailed requirements, measured by execution of the test cases.
9. Create a comparison matrix with each test case (and all other measurement criteria you care about) to directly compare the suppliers.
10. Gather information from the supplier, beyond just the functional capabilities.
- Gather pricing data – licenses, support, installation, training, etc.
- Ensure the supplier’s business operations are acceptable
- Determine if their support structure is acceptable
- Understand what their development roadmap looks like
- Perform reference checks with colleague
11. Decision maker chooses a supplier.
Once a supplier is selected, the detailed requirements gathering process should continue. Your detailed requirements should be focused on the scope dictated by the supplier you selected. In standard development projects you would expect to go into more detail on most areas of the system, to ensure you understood the requirements to build a complete solution. In supplier selection projects, there will likely be pieces of functionality that they demonstrate to you, and based on the high-level requirements and risk, you realize that their solution is sufficient and do not need to explore it further.
However, if there is an area in which there is a lot of flexibility in the supplier solution, you should specify that in more detail. Obviously If there is a gap between critical requirements and the solution the supplier provides, you should go into greater depth on those requirements. Points of integration should be explored in detail. Also, it is worth noting that typically you will also spend more time on updating existing processes to work with the supplier solution, whereas in standard software development you may build software that fits into existing processes.
At a low level, you can still follow the same requirements techniques on supplier selection projects. However, realistically your approach to the requirements process should be very different to ensure you select a good software solution and that you minimize throwaway work.
