Statement Of Work
The Statement Of Work (SOW) document defines the goal, overall deliverable, and timeline of a project. In most countries, it is a binding contract between the vendor and the client. The purpose of the SOW is to clearly define what the vendor will supply when it will be supplied and at which expected quality.
The project statement of work document usually specifies the payment schedule, and It may also include any industry-specific NFR (Non-Functional Requirements). For example: adhering to the country or federal regulations.
Best Practices When Drafting a SOW
- Use clear and concise language that isn’t open to interpretations.
- Clarify obligations (on both sides) carefully, do not count on them being inferred in any way by the client.
- Spell out KPI’s (Key Performance Indicators) and measurements standards which will be used to determine the quality of the deliverable.
- Agree on the methodology that will be used, this will help when reaching bridges.
- Be consistent when using terminology, no need to use a thesaurus while putting together an SOW.
- Not everyone is familiar with the acronyms that are used in a specific industry, be sure to explain them all.
- Signatures of key stakeholders and officials of both companies need to be on the document.
Now let's look at the key content of the Statement of Work Template : -
1. Background and Current Project:
This chapter should be used to give a short summary of the clients’ company, it's standing in the business community and the current situation which it faces.
Example: Company X is a leading software company that is ranked among the top 20 insurance software providers worldwide, and is committed to providing insurance companies with high-quality software which will help them better serve their customers.
2. Goals and Objectives:
This chapter should clearly spell out what the business goals of the project are, and how achieving these goals will help the company grow in their desired direction.
Example: Company X has established the following business objectives for the software project –
-
Risk management:
Replacing obsolete systems -
Efficiency:
Implement changes to automate and simplify processes -
Compliance:
Increase compliance to adhere to the insurance regulations in each specific country -
Global integration:
Create a standard method of software that will be used by all the business units worldwide. -
Growth:
Provide a flexible platform to support integrating existing business with new technologies and models.
3. Proposed Solution:
This chapter explains how the business goals (stated in the “Goals and Objectives” chapter) will come to fruition, and should focus on the following areas –
- The scope of the project (timeline and milestones, budget, quality, etc.)
- The physical location of the project and where the software will be implemented
- OBS (Organizational Breakdown Structure): How the teams will be split up
- The methodology, templates and WBS that will be used.
4. Services Included:
This chapter clearly states what the vendor will provide in terms of services, when usually they will be split into two categories: Mandatory and Optional. It also needs to state what the company will provide to the vendor, so that they will be able to complete the project on time.
5. Functional Requirements:
This chapter spells out what each module of the software needs to include, and which processes it will support. It also states what the expected performance is in regards to user quantity, response times and up time. If there are any needed interfaces to external systems, this chapter will include them as well.
6. Non-Functional Requirements:
This chapter explains what the regulations, compliance and validations that the software needs to support. This usually differs between countries and industries.
Example: The software needs to adhere to the insurance regulations that are defined by each country that Company X works in. Company X will provide the vendor with these regulations 10 months before the system go-live.
This chapter spells out what each module of the software needs to include, and which processes it will support. It also states what the expected performance is in regards to user quantity, response times and up time. If there are any needed interfaces to external systems, this chapter will include them as well.
6. Non-Functional Requirements:
This chapter explains what the regulations, compliance and validations that the software needs to support. This usually differs between countries and industries.
Example: The software needs to adhere to the insurance regulations that are defined by each country that Company X works in. Company X will provide the vendor with these regulations 10 months before the system go-live.
7. R & R (Roles and Responsibilities):
This chapter defines who does what, and the recommended method to accomplish this is using the RASCI matrix –
- Responsible: who owns the activity
- Accountable: who signs off that it is completed
- Support: who provides resources or information
- Consult: the SME (Subject Matter Expert) with whom there will be a two-way communication
- Inform: who will be informed of the progress of the task
Explanation: The task is under the responsibility of the PMO (Project Management Officer), and they are supposed to put it together.
Throughout the process the VP for planning and resourcing should be consulted, and at the end of the process the COO (Chief Operations Officer who the PMO report to) will approve and sign off on the deliverable.
The business leads will provide the information needed to understand what the scope of the project is, and the predecessors for each process is. Communication with the IT team leads (who will use the HLP as a tool) must be continuous throughout the process.
8. Staffing:
This chapter defines the number of employees that the vendor will provide, what their level of expertise needs to be and what their scope includes.
9. Deliverables:
This chapter outlines what the vendor will provide in terms of services and / or products. It is important to clearly define the timeline, entry & exit criteria and the description of each deliverable. This chapter is usually presented in a table.
