How to write a statement of work (SOW)

Document directory

• Do I need to write sow?
• When do I write sow?
• What does sow contain?
• Next step

The sow, sow, is the work Bible that must be created for the project. Sow is a key management tool, whether directly guiding the work of suppliers or contractors or internal work. Sow must contain a description of all expected work. This description does not need to be very detailed. It is unrealistic to capture details in sow for large projects, but the description should be extensive, it should also include the work that generates the project deliverables and administrative work, such as the project report.

 

If the work is done by the supplier or contractor, sow will become a key part of the contract. The work contained in this document is a contractual obligation that the supplier or contractor must undertake. Work not included in sow or introduced due to demand change is only performed with mutual consent, and is not a contractual obligation. Although there is no legal agreement, sow is also important to internal teams because resources should be configured according to the work defined in sow. This article will help the intern project administrator to write an efficient sow.

Do I need to write sow?

Sow is a practical organization tool to capture project work. Its value lies in its ability to capture all the key work elements of the project and apply them to the following two scenarios: as part of a contract with an external supplier or contractor, or for a large, complex internal project, as an intermediate plan step. When the project is small and simple enough that you can directly convert the scope description to a work breakdown structure tool (such as MS Project), sow is not required.

 

Sow is very helpful when the project is large and complex, because it allows you to hire experts in specialized fields that cannot access the MS Project. Anyone with writing communication and work skills can describe the job to be done. Sow is also used as a communication tool to describe the scope of the project.

When do I write sow?

Sow should be written after the scope description during the project planning phase. Scope description should be written first and captured in a very general manner. Suppose your organization is starting a project to develop a software-based system that is used to capture and track software orders. The scope description should include the language. It may also include a list of supported users, such as order input clerks, software engineers who configure orders, report-generating managers, and shipping personnel who ship orders. It may also include functions in the system, such as whether it is accessible through the Intranet or the Internet, how many orders should it store, what information should be stored for each order, and how the system collects payments. The scope Description provides information about what you need to create.

 

Since you know what you need to establish, You need to capture the details of how you establish it. Now you need to write sow. The sow defines the work to be done, so it must be written before the work is planned or decomposed.

 

What does sow contain?

Sow starts from the description of the range. All elements captured in the range description should appear in sow. Scope description tends to capture deliverables of a project at a high level; sow will include deliverables, when to deliver, and how to build deliverables. Sow should also contain a more detailed description of deliverables. For example, if the scope description contains a system for sequential storage and management, you may break down deliverables into databases for storing tracing information, A report system that interacts with users on the front-end and manages reports.

 

The sow information classification standard check list:

• Scope of Work
  -Detailed descriptions of work, the software and hardware to be used, and the accurate features of work
• Work Location
  -If the location for work completion is different from the standard location, it may be offshore.
• Performance period
  -Project start and end dates, maximum working hours of each period, and so on
• Deliverable plan
  -The project deliverables expire. This includes the completion date of development, QA testing, user acceptance testing, and so on.
• Applicable standards
  -Industrial or other standards applicable to deliverables of projects. It may be any standard, such as ISO, CMM, or cmme.
• Receiving Conditions
  -These should contain any quality standards that must be met, such as zero bugs with a priority of 1. They should also contain other conditions that must be met, such as the number of test cases and the number of test cases executed.
• Special requirements
  -These will include any qualifications regarding labor force, such as PMP-certified project managers

Scope of Work, performance period and deliverable plan are mandatory information. Others are optional and only applicable to those projects that require them. For example, the work will be performed in the execution agency, so it is meaningless to involve the office space; sow involved in the work of the consulting company will involve the studio and who is responsible for providing it.

 

The scope of the work to be executed should include administrative work and work on deliverables of the project. The administrative work also includes project management. If you work for internal customers, project management is not included. On the other hand, project management helps to set expectations of customers/initiators. This includes reports and other communication tools used to return project progress to sponsors. It should also include any information from the team, such as the progress report. For example, the project time is input into the time tracking tool.

 

Do not try to capture too much information about deliverables or how work is done. Remember to set an expected effect when you put the information into sow. It is difficult to change everything that is already in Sow (you need a change application approved by the initiator or customer ). You should not try to capture details about the project deliverables. It is enough to describe the methods to be used and the main deliverables. The waterfall method allows you to capture more details about work and project deliverables.

Next step

The next step is to let the project initiator or project customer approve sow. Sow becomes a formal project scope benchmark. Everything in sow must appear in the final project.

Sow captures what the project team is going to do, but at a high level of detail. To complete the work breakdown structure (WBS), you need to further break down the work. You may find that the unique identification of each job in sow will help ensure that all deliverables and Work Packages described in sow appear in WBS. You should also check the sow Based on the scope description to ensure that all work in the scope description appears in the sow.

 

The start and end dates captured in sow should be captured in WBS. If you use MS Project or similar tools to Create WBS, the start date is the first entry. The end date is used as a constraint. Once all information, work breakdown, and task plans in WBS are captured, you need to check the generated end date based on the end date in sow. Similarly, the planned date from sow is used for the primary deliverables.

You should use sow as a communication tool to explain the project work to the project sponsor by publishing sow and other project documents on a public and accessible site. Remember to update sow after the change is approved.

 

Be careful to capture the correct information about the project's work, make sure that the information is accurate, and make good use of this information in other planned activities can save the scheduled time. Remember: sow is a "active" document. Any change that appears in sow should be reflected in it.