Requirements for buying off the shelf
I’ve recently come out of the other side of a prolonged shopping spree. The client I’m working for has been spending their hard-earned on their first Learning Management System, a new modern Finance system, a replacement Membership Management system, and a new Intranet solution.
These are all Commercial off-the-shelf (COTS) products, and I’ve written the specification documents for all of them.
I’ve been reflecting on how eliciting and engineering requirements for purchasing COTS products differs from what I (and probably most Business Analysts) have the most experience and comfort with ie. in-house software or service development.
Whilst many Business Analysts (BAs) enjoy the variety that the job can bring, the pivot from low-level prescriptive requirements to high-level informative requirements can be difficult to process (please pardon the BA pun).
Using the Membership Management System as an example, I’ve written this article to outline the approach I took to come up with a document that would be fit for purpose, and kick-off a successful procurement and implementation.
Why COTS ?
My team had helped our client identify that their needs were not exotic, and that ‘Buy’ was a lot more sensible than ‘Build’. Coupled with a desire to move to a cloud-only architecture, a COTS SaaS approach was chosen for the whole IT estate.
What do you want the spec to do?
Initially, I wanted to tell the market what the client wanted, whilst giving the market the opportunity to do what they’re good at, and allow them to show us how much things have progressed since the last time the client went shopping.
I gave the following as the purposes of the document:
“Articulate the overall vision that the client has for administering its membership in the future”. “Provide the foundation for the selection of appropriate technology and vendor”. “Provide the basis for the selected vendor to make a firm pricing proposal”. “Reduce the risk of unforeseen additional requirements extending the implementation and configuration phase”. “Provide the platform for a rapid, high quality implementation of the system”.
So, how do you go to market when you want to buy something that has already been built? How do you ask for features that you don’t know exist? How do you get your stakeholders to think more adventurously than “ it’s got to have spell-check “? How do you know when you’ve told the market enough?
Organise some demonstrations
To get my stakeholders as up to speed with the marketplace as possible, we organised some demos of products and suppliers from different extremes of the market. I wanted to inspire our stakeholders, and if possible, get them thinking outside of the constraints of their current solution — start thinking about what they want, rather than what they don’t want.
Open a dialogue
The first thing I did was to get everybody (business and commercial) happy with the concept that our Spec was not going to be prescriptive. I stated within the document that:
“As a COTS product is being sought, the requirements presented in this document are intended to be informative rather than prescriptive”. “The requirements provided are not to be used to design or develop a system, but to provide a high-level understanding of the capabilities required of a COTS product, and to allow potential vendors to speak of the capabilities of their products”. “It is envisaged that once a vendor and product has been chosen, the client will collaborate with the vendor to document the more detailed requirements in a focussed manner in those areas of the solution system that need to be populated, configured, or customised”.
If after reading the spec any potential vendors had any questions, they were, of course, free to ask these as part of the procurement process. We wanted to actively engage with the market and capitalise on their expertise.
Breadth v Depth
I’d made the decision that I was not preparing a development specification, but I still needed to tell the market enough about my client, that i) they could provide a quote and a proposal, and ii) also find us authentic and compelling enough to invest time and resource in pursuing. This second point is often forgotten — we can’t just assume that the market wants our business.
Given the nature of the product we were after, I felt that it would be enough to describe the existing context, how we envisaged the product improving this, and what we do know about our requirements.
The idea was to paint a picture of the business, by seeing it through as many lenses as possible — data, technical, process, people etc, so using all of the classic BA techniques, I developed the following content:
Everything was kept at a high-level to avoid spending time chasing detail that would never be available from the client, and to ensure that we had a consistent depth across the whole spec.
What about the Requirements?
I couldn’t completely ignore the functional or non-functional requirements that the client had, but set in the wider context of the vision that we tried to paint, they became less important, and put less of an onus on the client to ‘know the unknowable’.
I catalogued and engineered all of those low-level things that users told us they must have (“ it really does have pay to have spell-check”), but the overall vision was more about automation, efficiency, freeing up skilled resource, and allowing the market to show us (and apologies for this) “the art of the possible”.
The ‘knowing the unknowable’ aspect of buying a COTS product to replace a venerable incumbent introduces some key differences to the classic waterfall requirements process
1) BA as SME — There is a strong likelihood that the BA will have to ‘invent’ a large number of requirements. This goes a lot further than the usual practice of a BA applying their domain knowledge to ask the client “ have you thought about…..”, and maybe alien to some BAs used to specifying a build on behalf of a knowledgeable and engaged business, but it is absolutely essential.
At the very least, you are likely to have to suggest industry-standard performance or security NFRs for SaaS products, but you may also have to wield some domain expertise, knowledge of topics such as interoperability, IT Service Management, training and consultancy, or even available functionality.
In this case, I suggested a large number of ‘candidate’ requirements, and these were validated during the specification development and review process. I found that even if the detail of the requirement was inappropriate the subject of the requirement itself was always useful, and always started a productive conversation with the client.
2) Prioritisation — rather than paint the client into a corner with a MoSCoW assessment of their requirements, that they’ve had to rack their brains to even come up with, just present all of them to the market. For each requirement, ask the market whether it is available out-of-the-box, as a custom development, via a third-party plug-in, or unavailable. This allows the business to look at each supplier response in their entirety, and choose which overall offering suits them best, rather than fixating on particular features.
Where our stakeholders were aware of genuine must-have requirements, or areas of real concern, we made these topics for supplier demos either before the formal procurement process, or as part of it.
What else is the specification for?
OK, you’ve got a load of quality content that is good enough to sit within a raft of ITT documents, but before you work out how to structure and present it. What else does it have to do?
Depending on the procurement process you are following, and the commercial expert leading the process, the specification could be used beyond just getting a quote from a supplier.
In my case, my requirements were used to:
- Structure (and execute) the scoring and weighting of ITT responses
- Derive shortlisting questions that the business wanted to apply to the ITT
- Identify those topics that the business would like to be demonstrated to them
- Identify any functionality gaps that would still need to be addressed after a supplier has been selected
Outcome?
The spec did its job well — it engaged both the market and the client, and our client has procured a great product, that is currently being implemented. The vendor has made a point of telling us how well the document went down with them, and gave them the space to apply their expertise through the discovery workshops.
In summary; what should you take home from this?
1) Get actively involved — don’t expect the business to know what’s out there, nor how to express what they want. Be prepared to offer ‘candidate requirements’. Research the market, and know what space you are working within.
2) There is nothing wrong with buying a “……For Dummies” book, to help you to frame conversations with your stakeholders, to offer up potential requirements, and to educate yourself on the domain.
3) Go for ‘sufficient’ rather ‘perfect’ — you’re never going to get perfection, especially if your stakeholders are buying a ‘once in a generation’ product or system.
4) Be authentic and honest about your current situation and about how much consultation, training, and other help your client is likely to need.
5) Go for as much breadth as possible — provide as many alternative views of the ‘as-is’ as possible to maximise the opportunities to provide the market with useful information.
6) Consider the whole basket of functionality that a product offers, rather than focussing on a granular MoSCoW view of things — look at maximising coverage of all your requirements.
Written by Kirk Bedford — Difrent Business Analyst
LinkedIn: https://www.linkedin.com/in/kirkbedford/
Originally published at https://difrent.co.uk.
