- Project Management Concepts
- Project Management Home
- Activity Based Costing
- Agile Project Management
- Basic Management Skills
- Basic Quality Tools
- Benchmarking Process
- Cause and Effect Diagram
- Change Management Process
- Communication Blockers
- Communication Channels
- Communication Methods
- Communication Models
- Communications Management
- Conflict Management
- Crisis Management
- Critical Chain Scheduling
- Critical Path Method
- Decision Making Process
- Design of Experiment
- Effective Communication Skills
- Effective Presentation Skills
- Enterprise Resource Planning
- Event Chain Methodology
- Extreme Project Management
- Gantt Chart Tool
- Just-In-Time Manufacturing
- Knowledge Management
- Leads, Lags and Floats
- Management Best Practices
- Management Styles
- Management by Objectives
- Monte Carlo Analysis
- Motivation Theories
- Negotiation Skills
- Organizational Structures
- PERT Estimation Technique
- PRINCE2 Project Methodology
- Pareto Chart Tool
- Powerful Leadership Skills
- Process Based Management
- Procurement Documents
- Procurement Management
- Project Activity Diagram
- Project Charter
- Project Contract Types
- Project Cost Control
- Project Kick-off Meeting
- Project Lessons Learned
- Project Management Methodologies
- Project Management Office
- Project Management Processes
- Project Management Tools
- Project Management Triangle
- Project Manager Goals
- Project Portfolio Management
- Project Quality Plan
- Project Records Management
- Project Risk Categories
- Project Risk Management
- Project Scope Definition
- Project Selection Method
- Project Success Criteria
- Project Time Management
- Project Workforce Management
- Project Management Softwares
- QC and QA Processes
- RACI Chart Tool
- Recognition and Rewards
- Requirement Collection
- Resource Leveling
- Staffing Management Plan
- Stakeholder Management
- Statement of Work (SOW)
- Stress Management Techniques
- Structured Brainstorming
- Succession Planning
- Supply Chain Management
- Team Building Program
- Team Motivation
- The Balanced Scorecard
- The Halo Effect
- The Make or Buy Decision
- The Rule of Seven
- The Virtual Team
- Total Productive Maintenance
- Total Quality Management
- Traditional Project Management
- Work Breakdown Structure
- Useful Resource
- Management Concepts - Quick Guide
- Management Concepts - Resources
- Management Concepts - Discussion
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
Statement of Work (SOW)
Introduction
When it comes to implementing or constructing large and complex systems (such as an enterprise software system), the work requirements and conditions should be properly documented. Statement of Work (SOW) is such document that describes what needs to be done in the agreed contract.
Usually, the SOW is written in a precise and definitive language that is relevant to the field of business. This prevents any misinterpretations of terms and requirements.
An SOW covers the work requirements for a specific project and addresses the performance and design requirements at the same time.
Whenever requirements are detailed or contained within a supplementary document, SOW makes reference to the specific document.
The SOW defines the scope and the working agreements between two parties, typically between a client and a service provider. Therefore, SOW carries a legal gravity as well.
Purpose of SOW
The main purpose of a SOW is to define the liabilities, responsibilities and work agreements between clients and service providers.
A well-written SOW will define the scope of the engagement and Key Performance Indicators (KPIs) for the engagement.
Therefore, the KPIs can be used to determine whether the service provider has met conditions of the SOW and use it as a baseline for future engagements.
SOW contains all details of non-specifications requirements of the contractor or service provider's effort. Whenever specifications are involved, the references are made from SOW to specific specification documents.
These specification documents can be functional requirements or non-functional requirements.
Functional requirements (in a software system) define how the software should behave functionally and non-functional requirements detail other characteristics of the software such as performance, security, maintainability, configuration management, etc.
Format of SOW
The SOW formats differ from one industry to another. Regardless of the industry, some key areas of the SOW are common. Following are the commonly addressed areas in a SOW:
1. Scope
This section describes the work to be done in a technical manner. If the system to be built is a software system, this section defines the hardware and software requirements along with the exact work to be done in terms of the final system.
If there is anything 'out of scope', those areas are also mentioned under a suitable subheading.
2. Location
The location where the work is performed is mentioned under this section. This section also details the hardware and software specifications. In addition to that, a description about human resources and how they work are addressed here.
3. Timelines
This defines the timeline allocated for the projects. It includes the development time, warranty time and maintenance time. In addition to calendar time, the man days (total effort) required to complete the project is also noted.
4. Delivery schedule
This section of the SOW describes the deliveries and the due dates for the deliveries.
5. Standards
The standards (internal or external) are defined in this section. All deliveries and work done should comply with the standards defined in this section of the document.
6. Acceptance Criteria
This section defines the minimum requirements for accepting deliverables. It also describes the criteria used for acceptance.
7. Mode of contract and payments
There are a number of engagement models when it comes to contracting a service provider.
In the domain of software development, there are two distinct contract models, fixed bid and a retainer.
In fixed bid, the project cost is a constant and it is up to the service provider to optimize the resource allocation in order to maintain the profit margins.
The client does not worry about the number of resources, as long as the delivery schedule is met. In the retainer model, the client pays for the number of resources allocated to the project.
Since SOW is an integrated part of a project, almost all senior members of the project team should become aware of terms and conditions of the SOW. Sometimes, especially in software development projects, a penalty is applied if the delivery dates are missed. Therefore, everyone should be aware of such demanding terms of a SOW.
Conclusion
SOW is a critical document for project management. It defines the scope of the work and the work agreements. Therefore, all stakeholders of the project should have a thorough understanding of the SOW of the project and adhere to it.