Skip to content

J2: Statement of work guidance

simonastoyanova edited this page Nov 13, 2019 · 4 revisions

1. Purpose of the Statement of Work document

The Statement of Work (SoW) represents an alternative way of commissioning work from the RSE team. A SoW may be suitable when a Feasibility study is not normally needed, though the items on the SoW should be subject to reasonable judgements about their feasibility.

Typically a SoW is more appropriate than a Product Quote when, for example:

  • The RSE team has been asked to perform a limited amount of work on a pre-existing resource
  • A resource is being migrated from one hosting institution to another
  • A legacy project requires significant work to ensure it continues to function properly, does not present any security threats, and can thus be the subject of a new Service Level Agreement

The SoW will usually be prepared by a dedicated RSE Analyst, though input will be sought from all team specialisms involved in the work.


2. Completing the Statement of Work

2.1. OVERVIEW section

This section provides an opportunity to summarise the purpose of the resource and its value in the community. Detail should be included on the technology stack being used to deliver the resource and a plain English explanation of the SoW goals should be included. e.g. in order to ensure the continued availability of the resource ...

What concerns are there about the resource in its current form that effect its sustainability?

2.2. OBLIGATIONS section

It should be made clear that as well as the RSE team committing to producing a Minimum Viable Product (MVP), the research team are accepting the processes and procedures that are necessary to complete the work. The RSE team should reasonably expect that their requests for feedback and testing are responded to in a timely fashion. For the avoidance of doubt, it may be helpful to specify fixed timeframes for reponses.

2.3. SUBCONTRACTING section

State if, and under what circumstances subcontracting of sections of the work might be necessary.

2.4. REQUIREMENTS section

The requirements section is completed in the same manner as for the Feasibility assessment, with itemised, prioritised (MoSCoW) tasks and an estimate of the time needed to complete the work for each task.

2.5. APPROVAL section

It is usual for a SoW to be peer reviewed by an Analyst, a Designer, an Engineer, a Project Manager and the Director.

Clone this wiki locally