One of the things that is sorely lacking in our industry is an ability to articulate requirements. IT and Telecoms is complex, and usually involves lots of detail, and many buyers do not bother with writing a decent specification before they go to market. This leads directly to a mismatch of expectations, vague service delivery, poor value for money and some sort of dramatic falling out in the post-contract phase. So why not just write down what you want at the outset?
The process of writing a decent specification can be time consuming, and I think this is the main driving factor behind this issue. Clients are busy, they know what they want and they can talk around it, so why bother writing it down? Surely a supplier can just recommend a solution based on what I tell them, and it gives them the flexibility to design something that fits the need. “It makes me Agile”. Well, for many good reasons, sitting down and structurally documenting your requirements is an investment that pays back on a multiple, both in terms of providing consistent direction and a point of reflection should misinterpretation occur.
Clearly this is only relevant for substantial projects. A few hundred quid on a laptop does not justify this effort. However, anything more than £50,000 in value I would say is worth spending a bit of time on.
Embedded’s approach to writing a service specification is standardised and has been commended by both clients and suppliers for providing what they want. We structure a document effectively as a layered story, explaining why something is required, what is in place today at multiple levels, any constraints there are to improving it, and clearly stating how a response should be provided.
Suppliers want something they can send to their solution teams and avoid lots of overhead of questioning and engagement to allow them to qualify an opportunity. To a large extent, this improves their sales efficiency and therefore allows them to potentially reduce price, or time to respond, such that the potential client gets the best deal and service longer term. On a non-commercial basis, the fact that a client has bothered to write an honest specification actually shows that the relationship will be open and detailed, which sets the correct tone for a long term client/supplier relationship.
Clients, or buyers, want something that incorporates all of their needs across an organisation, and makes it easy to compare supplier responses. Many a technical requirement is written by the IT team, but if that fails to account for the needs of the financial team (payment profiles, capitalisation of assets etc), operational teams (user requirements, service hours), legal team (warranties, liabilities, termination provisions) or other groups, the service is likely to fall at a review hurdle, or worse – post contract. Similarly, having a supplier quote for “apples” and “oranges” makes for a difficult decision process, especially if you were ordering a Clericot.
The structure of our standard specification isan attempt to help drive an improvement in specification writing over time. Needless to say we would welcome the opportunity to write this on your behalf – we have many standard questions for different IT and Telecoms scenarios that will hopefully improve the result – but if that’s not appropriate, good luck!
NB this may not be an exhaustive list of points and questions, but it gives a structure within which a requirement can be specified and further points / considerations can be captured.
Service Specification – our standard structure
Introduction (1-2 pages, summary level)
Why does this document exist? Purpose / Objectives etc.
Who are the client? Industry, size, location
What problem is the client trying to fix? Timing, gravity, cost
Who are the key stakeholders and their role? Client, third parties (like consultants)
What is the timeline of process to be followed?
Overview of Requirement
Diagrams of what is in place now
More detail on what problem is trying to be solved
Any things that have been considered and ruled out already, and why
Reasons why timelines need to be hit, and impact of this
Technical Requirements
List of technical components, in as much detail as possible:
Make / model / version / age
Maintenance arrangements in place
Performance / Capacity stats and trends / peak usage drivers
Locations / current management responsibilities
Resilience / methods
Any core technical processes or expectation, such as:
Overnight vs day time processes (End of Day / Start of Day)
Backup / Retention requirements and current methods
Existing processes that will need to be maintained / transferred
Data migration requirements (with volumes), if appropriate
Operational Requirement
A structured assessment of all relevant ITIL processes and any expectations of interfaces between client and supplier
Key service strategy and design considerations, including SLA’s and service hours
Service boundary / demarcation
Security requirements / minimum policy expectations
Regulatory requirements and impact on process / security
Commercial Requirements
Who is the contracting party
Term and termination options expectations including Exit Process commentary
Pricing profile expectations including any indexation or reductions over time
Any contract terms key expectations (insurance, warranties, liabilities)
Commentary on novation or transfer of existing assets / agreements
TUPE implications. If relevant, seek specific HR advice
How pricing should be presented, structurally, to allow a comparison across responses
Service Migration considerations / expectations
What needs to happen by when? What happens if it doesn’t?
What dependencies are in place between resource pools (Client and Supplier)? Ask for any expectations the supplier has on client to ensure these are understood.
Are there any constraints on dates because of key processing times / schedules / resources?
Timeline of activity / implementation
Headline plan for this RFP process – when is the client expecting what from the supplier and vice versa? Document, Clarifications, Presentations, Decision, Contract Award, Project Start. Process Guidance
Any specific instructions regarding the RFP / Selection process the client has e.g.:
Document response format and structure
Communication interfaces
Costs / Expenses for the process
