-
Notifications
You must be signed in to change notification settings - Fork 3
J2: Statement of work guidance
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.
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?
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.
State if, and under what circumstances subcontracting of sections of the work might be necessary.
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.
It is usual for a SoW to be peer reviewed by an Analyst, a Designer, an Engineer, a Project Manager and the Director.
Software Development Life Cycle. King's Digital Lab. 2025
-
- A2: Terms of Reference guidance
- B2: Project Approach Questionnaire guidance
- F2: Feasibility guidance
- I2: Product Quote guidance
- J2: Statement of Work guidance
- Data Management Plan guidance and AHRC template
- L2: Project Review Record guidance
- N2: Web Hosting and Infrastructure Service Level Agreement (SLA)
- Q2: Decommissioning Authorisation guidance
-
Monitoring Methods - In progress
- Z1: RSE Team Mission and Activities
- V1: How do we approach analysis when a project is funded
- Meetings
- Peer review
- Task management
- Budgeting and resource planning
-
Scenarios and examples - In progress
-
Other useful documents
- KDL Guidance to project partners questionnaire
- SUP Amenability to archiving assessment
- KDL Checklist for Digital Outputs Assessment in the REF
- DSDM Agile Project Framework Handbook
- FAIR Guiding Principles for scientific data management and stewardship
- KDL HR Roles
- AHRC Data Management Plan (external)
- UK Dataservice Data Management Checklist
- Tips on data collection