I’ve been thinking for a while about writing on how best to go about selecting a vendor for an out-of-the-box, or at least partial vendor solution. Sometimes it just makes better sense to go with a tried and true vendor package that performs specialized functionality that your shop doesn’t have the time or expertise to custom code.
As it turns out, Joy over at Requirements Defined has just done a masterful job of just that. The Requirements Defined blog over at Seilevel.com is one of my favorite reads. The topics are timely, and the writing is great.
In this particular post, Requirements in Supplier Selection Projects, the author has outlined a clear approach to requirements for a project for which outside vendors will be leveraged as all or part of the solution.
Highlights include the following:
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.
I’ve been party to vendor selection on couple occasions, and can vouch fully for the approach outlined in the post. The items I haven’t seen done in my experience with the vendor selection process are 7 and 8. I think it’s a great idea to go the test case route and get vendors to prove that they can meet your test cases through test case execution.
In the environments where I’ve worked, that would probably be work that fell on the Business Analyst, though, as QA is typically neck deep in in-flight release work, and often doesn’t have the bandwidth to provide those types of deliverables that – at this early stage – have not even been fully scoped.
Anyway, aside from the bullets I’ve excerpted, there is lots of other great information in the original post. Do take a look!
To keep up with the latest on Practical Analyst, you can subscribe to the RSS feed, follow Jonathan on Twitter, or view his profile on Linked In.
Latest posts by JB (see all)
- Jim Rohn – February 20, 2014
- Elicitation Tip: When the Stakeholder Asks for a Specific Implementation – February 19, 2014
- Paul Oldfield – February 11, 2014