Security
Requirements for Buying Off the Shelf
We’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.
We’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: in-house software or service development.
Whilst many Business Analysts 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.
Using the Membership Management System as an example, I’ve written this article to outline the approach I took to creating a document that would be fit for purpose and kick off a successful procurement and implementation.
Why COTS?
Our team helped our client identify that their needs were not exotic and that buying was far more sensible than building. Coupled with a desire to move to a cloud-only architecture, we chose a COTS Software as a Service approach for the whole IT estate.
This approach is common across many modern service businesses. For example, companies providing property management services rely on integrated technology for areas such as bookings, guest communications, availability and property operations rather than developing every underlying system from scratch.
The UK Government’s Cloud First guidance also recommends considering cloud solutions before other options when assessing technology requirements.
What Do You Want the Specification to Do?
Initially, I wanted to tell the market what the client wanted whilst giving suppliers the opportunity to demonstrate what their products could do and how the marketplace had developed.
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 selecting appropriate technology and a 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.
These objectives broadly align with the principles in the Technology Code of Practice, which encourages organisations to understand user needs, make informed technology choices and consider whole-life costs when buying technology.
Organise Some Demonstrations
To get my stakeholders as familiar with the marketplace as possible, we organised demonstrations of products and suppliers from different parts of the market.
I wanted to inspire our stakeholders and, if possible, get them thinking outside the constraints of their current solution. The aim was to start thinking about what they wanted rather than simply listing what they disliked about their existing system.
The GOV.UK guidance on using COTS products and services similarly recommends understanding the problem first and evaluating different options rather than committing to a specific technology prematurely.
Open a Dialogue
The first thing I did was get everybody, both business and commercial stakeholders, comfortable with the concept that our specification was not going to be overly 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 focused manner in those areas of the solution that need to be populated, configured or customised.”
If potential vendors had questions after reading the specification, they were free to raise them as part of the procurement process. We wanted to actively engage with the market and capitalise on supplier expertise.
Breadth vs 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 so that suppliers could provide an informed quote and proposal.
I also wanted suppliers to find the opportunity authentic and compelling enough to justify investing time and resources in responding. This second point is often forgotten. Organisations cannot simply assume that every supplier wants their business.
Given the nature of the product we were looking for, I felt it was sufficient to describe the existing context, how we envisaged the product improving it and what we already knew about our requirements.
The idea was to paint a picture of the business through as many lenses as possible, including data, technology, processes and people.
- Membership volumes, membership types and membership groups.
- Organisational structure and size.
- As-is solution and IT architecture.
- As-is technological issues.
- As-is key data entities and attributes.
- As-is business processes.
- Expected benefits of the new solution.
- To-be data entities and attributes.
- To-be integrations.
- To-be IT architecture.
- Functional requirements.
- Non-functional requirements.
The GOV.UK guidance on choosing technology also recommends considering existing systems, data sources, integrations, cloud technologies and the wider technical environment rather than evaluating technology in isolation.
What About the Requirements?
I couldn’t completely ignore the functional or non-functional requirements that the client had, but set within the wider vision, they became less dominant and put less pressure on the client to know the unknowable.
I catalogued the lower-level requirements users told us they needed, but the overall vision was more about automation, efficiency, freeing up skilled resources and allowing the market to demonstrate the art of the possible.
The process of replacing a long-established system with a COTS product introduces some important differences from a traditional development requirements process.
1. The Business Analyst as Subject Matter Expert
There is a strong likelihood that the Business Analyst will need to suggest a significant number of candidate requirements.
This goes further than simply applying domain knowledge to ask a stakeholder whether they have considered a particular feature. It may require an understanding of industry-standard performance, security, interoperability, IT service management, training, consultancy and available product capabilities.
In this case, I suggested a large number of candidate requirements and validated them throughout the specification development and review process.
2. Prioritisation
Rather than immediately locking the client into a granular MoSCoW assessment, another approach is to present the requirements to the market and ask each supplier how they can satisfy them.
For each requirement, suppliers can indicate whether it is:
- Available out of the box.
- Available through configuration.
- Available through custom development.
- Available through a third-party integration or plug-in.
- Not currently available.
This enables the organisation to assess each supplier’s overall proposition rather than becoming fixated on a small number of individual features.
What Else Is the Specification For?
A good specification can do much more than simply allow suppliers to provide a quote.
Depending on the procurement process and commercial approach being followed, the requirements can also be used to:
- Structure the scoring and weighting of supplier responses.
- Derive shortlisting questions.
- Identify areas that suppliers should demonstrate.
- Highlight functionality gaps that may need to be addressed after supplier selection.
- Support commercial discussions and implementation planning.
For organisations buying cloud services through public-sector frameworks, the G-Cloud Buyers’ Guide provides additional guidance on evaluating and purchasing cloud services.
Outcome
The specification did its job well. It engaged both the market and the client, and the client successfully procured a product that moved into implementation.
The selected vendor also commented positively on the document because it gave them enough information to understand the organisation while leaving sufficient room for their expertise to be applied during discovery workshops.
In Summary: What Should You Take Home From This?
- Get actively involved. Do not expect the business to know everything available in the market or exactly how to express what it needs. Be prepared to offer candidate requirements and research the marketplace.
- Educate yourself on the domain. Background reading, industry guidance and supplier research can help you frame better conversations with stakeholders.
- Aim for sufficient rather than perfect. You are unlikely to create a perfect specification for a product your stakeholders may only procure once every decade.
- Be authentic about the current situation. Explain how much configuration, consultation, migration, training and implementation support is likely to be required.
- Prioritise breadth. Give suppliers multiple views of the existing organisation, processes, technology, data and desired outcomes.
- Consider the complete product offering. Assess overall requirements coverage rather than focusing exclusively on an inflexible feature-by-feature scoring exercise.