top of page
  • Writer's pictureEmbedded IT

How to write a good service specification

Updated: Nov 4, 2021

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

93 views0 comments


bottom of page