- Work Breakdown Structure
- Traditional Project Management
- Total Quality Management
- Total Productive Maintenance
- The Virtual Team
- The Rule of Seven
- The Make or Buy Decision
- The Halo Effect
- The Balanced Scorecard
- Team Motivation
- Team Building Program
- Supply Chain Management
- Succession Planning
- Structured Brainstorming
- Stress Management Techniques
- Statement of Work (SOW)
- Stakeholder Management
- Staffing Management Plan
- Resource Leveling
- Requirement Collection
- Recognition and Rewards
- RACI Chart Tool
- QC and QA Processes
- Project Management Softwares
- Project Workforce Management
- Project Time Management
- Project Success Criteria
- Project Selection Method
- Project Scope Definition
- Project Risk Management
- Project Risk Categories
- Project Records Management
- Project Quality Plan
- Project Portfolio Management
- Project Manager Goals
- Project Management Triangle
- Project Management Tools
- Project Management Processes
- Project Management Office
- Project Management Methodologies
- Project Lessons Learned
- Project Kick-off Meeting
- Project Cost Control
- Project Contract Types
- Project Charter
- Project Activity Diagram
- Procurement Management
- Procurement Documents
- Process Based Management
- Powerful Leadership Skills
- Pareto Chart Tool
- PRINCE2 Project Methodology
- PERT Estimation Technique
- Organizational Structures
- Negotiation Skills
- Motivation Theories
- Monte Carlo Analysis
- Management by Objectives
- Management Styles
- Management Best Practices
- Leads, Lags and Floats
- Knowledge Management
- Just-In-Time Manufacturing
- Gantt Chart Tool
- Extreme Project Management
- Event Chain Methodology
- Enterprise Resource Planning
- Effective Presentation Skills
- Effective Communication Skills
- Design of Experiment
- Decision Making Process
- Critical Path Method
- Critical Chain Scheduling
- Crisis Management
- Conflict Management
- Communications Management
- Communication Models
- Communication Methods
- Communication Channels
- Communication Blockers
- Change Management Process
- Cause and Effect Diagram
- Benchmarking Process
- Basic Quality Tools
- Basic Management Skills
- Agile Project Management
- Activity Based Costing
- Project Management Home
Useful Resource
Selected Reading
- Who is Who
- Computer Glossary
- HR Interview Questions
- Effective Resume Writing
- Questions and Answers
- UPSC IAS Exams Notes
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 cpent 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 pabipties, responsibipties and work agreements between cpents 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 basepne 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, maintainabipty, 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. Timepnes
This defines the timepne 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. Depvery schedule
This section of the SOW describes the depveries and the due dates for the depveries.
5. Standards
The standards (internal or external) are defined in this section. All depveries 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 depverables. 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 cpent does not worry about the number of resources, as long as the depvery schedule is met. In the retainer model, the cpent 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 appped if the depvery 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.
Advertisements