119 lines
6.1 KiB
Markdown
119 lines
6.1 KiB
Markdown
|
||
|
||
**Statement of Work For:** [Client]
|
||
|
||
**Document Created:** [Date]
|
||
|
||
**Author:** [Author]
|
||
|
||
**Distribution:** [Distribution List]
|
||
|
||
**Document Revision History**
|
||
|
||
| Revised By | Date | Comment |
|
||
| -----------------|:--------------:|:---------------------:|
|
||
| Initials or name | Date modified | Reason for revision |
|
||
| Initials or name | Date modified | Reason for revision |
|
||
|
||
|
||
| Start Date | End Date | Project Manager |
|
||
| :---------:|:-----------:| :--------------:|
|
||
|dd-mon-yyyy |dd-mon-yyyy | Initials |
|
||
|
||
## Background
|
||
*[Optional section]*
|
||
|
||
If there is a background to this SOW that is relevant, possibly because it will be distributed to multiple stakeholders that are not aware of the work background then describe it here. For example: *“[client] has been experiencing difficulty identifying sources coming to their website, which makes it difficult to track marketing spend…”* This type of background is often a justification for rapid sign-off of the SOW as it highlights the commercial imperative of the recipient of the work.
|
||
|
||
## Objectives
|
||
State the high-level business objectives and proposed solution so that the two marry up, with the solution an explanation of how the objectives will be met. For example: *“to implement [solution] by [development steps] so that [objectives] can be met in a timely and efficient fashion.*
|
||
|
||
## Project Scope
|
||
### High-Level Requirements
|
||
List the requirements that must be satisfied in order for the project’s goals to be realised.
|
||
|
||
| Requirement | Comment | |
|
||
| ------------- | --------------------------------- | --- |
|
||
| Requirement A | Delivery of A enables B to happen | |
|
||
| Etc. | Etc. | |
|
||
| | | |
|
||
|
||
### Milestones and Deliverables
|
||
*List the major project milestones and the deliverables from them*
|
||
|
||
| Milestone | Deliverable |
|
||
| ------------- |---------------------------------|
|
||
|Milestone A |Deliverable 1 |
|
||
|Milestone B |Deliverable 2 |
|
||
|Milestone C |Deliverable 3 |
|
||
|Etc. |Etc. |
|
||
|
||
### Project Plan
|
||
#### Timeline
|
||
Lay out the timeline for delivery at a high level. It is generally wise not to commit to dates, only to durations in a SOW, as delays in approval often occur with the deadline not shifting accordingly.
|
||
|
||
1. Wk 1
|
||
- a. Kick off session
|
||
- b. GAP Analysis
|
||
2. Wk 2
|
||
- a. Deliver detailed technical spec for sign off
|
||
- b. Deliver database schema
|
||
3. Etc.
|
||
|
||
## Risks and Assumptions
|
||
### Risk Analysis
|
||
If you are creating a sophisticated SOW you may have a separate Risk Register. <u>Do not link to it</u>, instead call out the risks in a table with the column headings below:
|
||
|
||
**Risk Id** – A unique identification number [can be used to identify and track the risk in the risk register if one is in use].
|
||
|
||
**Category** –Is the risk financial (cost and/or revenue), regulatory or compliance, timeline, resource, environment, or some other key category? Categorising risks groups them and aligns them with stakeholders who are best placed to assess/mitigate and stakeholders for whom the risk is greatest.
|
||
|
||
**Description** – Describe the potential risk. For instance: Item A cannot be completed until Item B has been purchased but approval is not yet forthcoming and there is a delivery lead time, or Item A requires resources that have not been identified and the project is currently resource constrained.
|
||
|
||
**Potential Impact** – A quantitative rating of the potential impact on the project if the risk should materialize. Impact in a Risk Register should be scored on a scale of 1 – 10 with 10 being the highest impact.
|
||
|
||
### Assumptions
|
||
List all of the assumptions that are being made. For example: *“to successfully meet its goals in a timely manner with benefits reflected in the current financial year, all parties have signed-off the budget and the project will begin on the scheduled start date.”*
|
||
|
||
## Pricing
|
||
List the price, stating clearly:
|
||
|
||
1. Currency (don’t get paid in Canadian dollars when you meant US dollars!)
|
||
2. Amount
|
||
3. Payment Terms (including any staged/milestone payments)
|
||
4. If price is Fixed or Time and Materials. If the latter, then specify that there is a Rate Card in the Appendix and put it there.
|
||
|
||
## Approval
|
||
*This Statement of Work has been reviewed and accepted by the following people, as indicated by signature below:*
|
||
|
||
[List all individuals whose signature is required, along with their titles and/or roles on the project. As a general rule, try not to put all the text of an Approval section on a page by itself and always place it immediately beneath the pricing information.]
|
||
|
||
**Full Name** ...............................................................................
|
||
|
||
**Title**..........................................................................................
|
||
|
||
**Signature**.................................................................................
|
||
|
||
**Date**..........................................................................................
|
||
|
||
--
|
||
|
||
**Full Name** ...............................................................................
|
||
|
||
**Title**..........................................................................................
|
||
|
||
**Signature**.................................................................................
|
||
|
||
**Date**..........................................................................................
|
||
|
||
*[it is advisable to specify dates in dd-mon-yyyy format, which is the international standard]*
|
||
|
||
## APPENDIX A - REFERENCES
|
||
Include the relevant text of any documents referenced in this SOW (for example a Rate Card if T&M). <u>Do not link to documents outside of the physical SOW</u> as this document forms the basis for a contractual agreement and should therefore be complete in itself.
|
||
|
||
## APPENDIX B - GLOSSARY
|
||
| Term | Definition |
|
||
| ------------------------|----------------------------------|
|
||
|Term used in the document|Its definition in lay terms |
|
||
|Etc. |Etc. |
|