A Statement of Work (aka S.O.W.), is one of the most important documents in project management as it outlines everything that must be part of a project.
CONTENTS
Project management processes comprise many different documents, regardless of the industry, but in the SOW you can find a complete description of what the project will be.
Not only data sheets and forecast numbers, but a proper narration of the project work. Activities to be carried out, results to be obtained and deadlines, but also prices, conditions and project governance will be described.
Basically the Statement of Work is the most comprehensive document of the project to have an overview of what we are going to achieve and when and how we intend to do it.
Let’s take a closer look at what this article is about.
What is a Statement of Work?
A SOW is a formal project management document that is aimed at defining the entire scope of work of the project and clarifying results, costs and deadlines.
This type of document is used where projects require suppliers and external collaborators and is generally created as part of a contract.
Project managers should pay sufficient attention to provide a comprehensive SOW to all stakeholders to avoid conflicts regarding results, budget or deadlines.
A Statement of Work is practically “the Bible” for the work that the project aims to achieve, a key governance tool, whether it is used to direct work for a supplier or contractor, or to direct work internally.
The work included in this document is part of the contractual obligation, while activities not contained herein will only be executed if mutually agreed upon or introduced into the project through a modification request.
When is a SOW needed?
The importance of a SOW lies in its capability to acquire all the elements of work and critical activities of the project and is particularly useful in two situations:
- When a contract with an external supplier or consultant is signed
- As an intermediate planning phase for a large and complex project where the work is carried out internally.
You don’t need a Statement of Work when the project is small and straightforward enough to perform.
When should the SOW be drafted?
The SOW must be drafted after the scope statement, so during the planning phase of the project.
Notably, the scope statement should capture, albeit in very general terms, the product of the project.
For example, if you want to launch a project to develop software to capture and track orders, the scope statement should include a list of users used to place orders, software engineers and employees who send orders.
Furthermore, you could also include features desirable in the system, e.g. whether it is available on the Internet, what information it should store about every order, how the system will collect the payment for the order, etc.
The scope statement, in a nutshell, will provide information about what needs to be produced or built through the project.
Once you have determined what you are building, you need to capture the details of how it will be built; then you prepare the SOW.
The Statement of Work defines what needs to be done and must therefore be written before the work can be scheduled or a division of labour created.
What is included in the Statement of Work?
All elements included in the project scope statement should also be included in the SOW.
This should contain information on the final results at a more detailed level.
For example, if the scope statement includes an order acquisition and management system, this can be broken down into a database to acquire, store and track information, a front-end to interface with users, and a reporting system to manage reports.
Here is a list of categories of information that are usually included in the SOW:
- Introduction: begin with an explanation of the work carried out. In addition, state who is involved in the project.
- What is the goal of the project, what are the results, objectives and return on investment.
- Goal of the work: which activities should be carried out in the project and which processes? This includes results, time needed and even the general steps needed to achieve this goal.
- Where the work will be executed: will the team work at a central facility or remotely? However, in this part it is necessary to detail it, as well as specify where the equipment and software used will be located.
- Duties: adopt the general steps outlined in the scope document and divide them into more detailed assignments. If desired, break down the activities into milestones or phases.
- Milestones: define the expected time period for the completion of the project, from the suggested start date to the proposed end date. Specify billable hours per week and month and everything else related to project scheduling, e.g. if there is a maximum number of billable hours per supplier and/or contract.
- Results: explain what is due and when is due. Describe it in detail, such as quantity, size, color and everything that might be relevant.
- Planning: include a detailed list of when the final results must be presented, from which supplier will be chosen, the execution period, the review phase, development, implementation, testing, project closure, etc.
- Standards and tests: If there are industry standards that must be met, list them. Also, if testing of the product is planned, list who will be involved in this process, what equipment is needed and other resources.
- Define success: write down what the sponsor and/or stakeholders expect for the successful completion of the project.
- Requirements: list any other equipment needed to complete the project and whether a degree or certification is required for team members.
- Payments: If the budget has been set, you can list the payments related to the project and how they will be made – in advance, over time or after completion.
- Other: if there are parts of the project that cannot be traced back to the above categories, you can add them at this stage so that everything is covered.
- Conclusion: Determine how the final results will be accepted and who will deliver, review and sign the acceptance. Additionally, this part also includes specifications on the final administrative functions, such as confirmation that everything is signed, closed and archived.
As you can see, there is plenty of information that needs to be included in a SOW.
This must be specific and clearly defined so as to avoid any confusion later in the project when communication errors or disputes cannot be afforded.
Including visual elements in the SOW, graphics or other illustrations, can help to better focus the objective on various aspects of the project.
After writing the SOW down in detail, the final and crucial step is to get it approved.
For this, the project manager must make sure that those responsible have signed the Statement of Work; in case of disputes in the future, it will be possible to show the signed document in support of their actions.
Ultimately, the SOW therefore helps project managers by providing them with a support on which project plans can be built.
The document also helps to avoid conflicts during the project life cycle and keeps everyone involved on the same page as well as helping to reduce confusion to a minimum.
