Specification Writing

What is a specification?

A specification can be defined as "a statement of needs to be satisfied by the procurement of external resources". It is also known as an operational requirement, statement of requirement, statement of service requirement and output-based specification

Its purpose is to present prospective suppliers with a clear, accurate and full description of the organisation's needs, and so enable them to propose a solution to meet those needs. The supplier's response to the requirement is evaluated to arrive at, depending upon the procurement strategy, either the supplier to be awarded the contract, or those suppliers invited to take part in negotiations.

The requirements in the specification subsequently become incorporated in the contract with the successful supplier.

When is it produced?

For simple procurements the specification is drafted before the OJEU notice is placed. For more complex procurements the specification develops from a statement of the business requirements developed during the preparation of the business case.

The requirement may be refined in consultation with suppliers as part of market sounding or after the supplier selection stage (see market sounding guidance). This can be particularly useful where innovative solutions are being considered. This should be handled with care and integrity to maintain a level playing field.

The specification needs to be finalised before it is issued to suppliers with, depending on the procurement strategy, an ITT or an invitation to submit a proposal.

Who is involved

Depending upon its complexity the specification can be drafted by an individual or team within the organisation or by external consultants. Those involved in its production are:

• SRO - signoff

• Project team - drafting or support to drafters

• Stakeholders (including users) - contributing to requirement development and may also review the specification

• Advisors such as technical and procurement specialists
  

Consider who is most appropriate to review the specification to ensure it is complete and accurate, and who should be involved in evaluating responses to it.

Process

Establish information sources

Except in the simplest of cases, those drafting the specification will need to draw information together from a number of sources and the first step is to identify these sources. They may be individuals, organisations or documents.

People include:

• Business owners

• Users

• Other stakeholders

• Technical specialists

In cross-cutting projects and those involving the e-delivery of services the users of the system can be very wide, including other government departments, organisations, businesses and the citizen. Where the service is provided to the public, or businesses there may be a need to consult with representative organisations such as trade associations. The stakeholder map will identify stakeholders and their areas of interest and the communications strategy will set out the methods for contacting them.

Documents include:

• Business strategies and plans.

• Business requirements

• Specifications or contracts for similar goods or services

• Contract(s) to be replaced by the procurement (the contract strategy should help identify these)

• Process manuals

• Service Level Agreements

• Metrics such as volumes etc
  

The high-level requirement as set out in the business requirements are progressively refined to a level where they provide the necessary detail for suppliers to understand what is required and develop a solution to meet it.

In all but the simplest requirement, this will involve interaction with the people identified as information sources. The degree of interaction will depend on their involvement in and knowledge of the requirement. In some cases it will take the form of interviews, in other cases the review of draft documents. When being interviewed people may describe the current process and it is necessary to extract from this the outputs and key element of process that need to be retained.

When reviewing metrics, be aware they represent historical information and consider what changes are likely to occur over the duration of the contract. Periodic reviews should be used to help shape the requirement. Developing the requirement will raise issues and risks that must be recorded and addressed in accordance with the risk and issue management strategies.

Once the requirement is refined it can be documented in the Specification that will be sent to suppliers. An example framework for a specification can be found at Annex A, and a checklist to help with drafting and review can be found at Annex B. In complex procurements it can be useful to have suppliers' views on the developing requirement. In these cases a draft high-level version of the specification is issued to suppliers after the supplier selection stage for comment. This is not usually part of the evaluation process, and is just used to seek input. This can result in a longer procurement timetable and will incur additional costs from suppliers, so before embarking on it be sure:

• what it is intended to achieve;

• what sort of input is required from suppliers (and make them aware of it).

When considering supplier input be aware of material that, if adopted, could directly or indirectly favour a particular supplier, or a particular supplier or third party solution or technology. The Specification also contains background material to help the suppliers understand the requirement in context and provide supporting material. In large outsourcing projects the volume of background material can be considerable and the practicalities of copying it and issuing it to all prospective suppliers are difficult. If the material is available in electronic form, a CD can be used as a convenient mechanism for distributing it. If the majority of it is on paper, some projects have set up a project library, and allowed suppliers to book time to review it.

The requirement will elicit a response from suppliers. This will be evaluated to assess the extent to which it meets or exceeds the requirements in the specification. The evaluation plan sets out how this will be achieved, and the model provides a framework for capturing and assessing findings. They should be developed in parallel with the specification to ensure:

• all information needed for evaluation is requested from suppliers;

• all requirements and information requests in the specification are covered by the evaluation;

• supplier responses will be provided in a form that matches the evaluation model.

The evaluation strategy sets out the approach to evaluation, and Bid evaluation stage describes the process in more detail.

The specification is a key procurement document. It forms the basis against which the successful supplier will be chosen and will become incorporated into the contract setting out what the supplier will deliver. Its final review and signoff is therefore a key decision point in the procurement process, and it is important that those undertaking it have the necessary knowledge, authority and experience.

The key criteria for the review are:

• the requirements are complete and accurate;

• for IT projects, that COTS software is preferred over bespoke development

• stakeholder needs have been taken into account;

• future developments have been taken into account;

• the requirement is deliverable (i.e. a market exists or can be created);

• requirements are compatible with the scope set out in the OJEU notice

• issues and risks raised in its development have been addressed;

• business implications associated with the requirement have been identified and addressed;

• consistent with :

  • Business case

  • Business requirements

  • OJEU advertisement

  • Procurement and contract strategies

  • Evaluation strategy.

Annex A - Framework for a Specification
Other criteria are in the Specification checklist at Annex B