Writing a Good Statement of Work (SOW)

In the world of software development, bulk of the software being developed in customer software. Where the software is being developed to meet specific needs of only one customer. In such cases, the starting point for the project planning is the SOW and is fundamental to the success of the project.

Writing a good statement of work is no easy task. Having an vaguely worded SOW is an invitation for a project failure and is often the reason parties end up in a dispute.

A best practice is to have a joint team from both the developer & customer organization to write an SOW. This will reduce the likelihood of conflicts during the project startup stage.

From project management perspective, a good SOW must have the following features:

1. Background

The SOW should explain the background of the project explaining why the project is necessary and critical for the organization. Having the business background for the project is important so that everyone in the project team understand the bigger picture and the goals for the project, i.e., the project success criteria must be clearly articulated in such a way that every one in the project team understand what has to be accomplished.

The SOW sets the context of the project by defining the purpose, objectives, scope, constrains, assumptions and reference documents.

2. Points of Contact

Specify points of contact, including who will be the customer [project] managers interfacing with seller personnel during work accomplishment. At a minimum, a point of contact who has decision-making authority during work accomplishment should be specified. This individual will participate in CCB meetings and will be empowered to provide direction to the seller during work accomplishment.

3. Task Specifications & Deliverables 

This is the main section of the SOW. The SOW should specify the individual tasks that has to be done by seller/developer and by the buyer/customer. In a custom software development, there will be inputs & tasks to be done by the buyer.

For each of the tasks, there must be an associated deliverable, which lists out when & how that task is associated with the list deliverables. The SOW must also list out the dependencies (if applicable) for each task.  These tasks will be rolled into the project plan.

All deliverables must have specific dates. But this date could be changed only upon the approval from the CCB.

4. SOW $$ Value

The SOW should have financial information:

1. Total value of the contract
2. Payment terms, schedules & conditions.
3. Limits for certain types of expenses.

The financial information provides the limits of the project and gives the buyer an idea of the total costs involved. The pricing of such custom software development projects can be in terms of: Fixed Price or Time & Materials billing. Financial terms sets the ground for project planning.

5. Project Life Cycle

Though SOW is written for a one-off development, there could be multiple deliverables and maintenance works associated. Defining the life cycle of the software being developed will give developer and buyer various options for risk mitigation, and also gives greater flexibility to add new features as business conditions change. For example, customer wants a billing system to be built and maintained for a period of 5 years. During the period, vendor/developer is asked to release patches & upgrades every six months. This system will give greater flexibility for the buyer in terms of getting new/additional features, and also serves as a risk mitigation strategy in cases where when there is a feature schedule slippage, or when customer finds a bug in actual production usage.

6. Change Control Board

Change Control board and Change control mechanism must be explicitly defined in the SOW. The change control mechanism must be understood by all stake holders & team members. All changes to the initial SOW must be approved by the CCB and must be documented and tracked to a particular change request ID. CCB also provides as a channel for customer-vendor dialogue and interactions.

7. Risk Assessment & Risk Mitigation plan

SOW must have section in which the known risks at the start  are documented and appropriate risk mitigation strategy defined. For example, changes to taxation rules could be risk to the billing software project. In addition, the SOW must allow the seller to assess the risks involved in accomplishing the work as per SOW.  The Project plan will have the complete risks documented and risk assessment plans documented.  Also see: Risk Assessment in Software development

8. Joint Project Management Office

Since custom software development is a joint activity of the buyer & developer, a joint project management office will be required. The working details, authority & responsibility between the buyer & developer must be documented in the SOW. Having a pre-stablished Project management policies will help speed up decision making during project execution.

9. Existing Seller Practices

Today majority of software service providers e.g.: IBM, HP, Accenture, CSC etc have an established engineering practices and organizational policies and procedures that sellers are supposed to follow. The SOW must have a reference these items. Developers follow their internal policies & procedures and this in some cases may impact the project or may be impractical for the project or could be in conflict with the buyer's policies.  So having an clear reference to the vendor practices, policies, & procedures will help avoid future conflicts and when required the SOW can specify which of the vendor practices, policies, & procedures that must be changed or waived for this current development.

Closing Thoughts 

In the world of custom software development the SOW is the starting point for the project. Having a well defined SOW is critical for the project's success. In many cases, there will be master agreement between the vendor and buyer, which provides details on Joint Program management policies, pricing & payment mechanisms, and project governance details. In such cases, the SOW should have a reference to the relevant sections of the master agreement.

Having a well defined SOW forms the solid foundation upon which the project will be completed.