In a previous article, we introduced the statement of work (or "SOW"), gave its definition and offered a few quick tips on the subject.
In this article, we now propose to move from theory to practice by going into detail, into the substance of the SOW (appreciate the pun) which is one of the main contractual documents a contract manager must master. To do so, we will (a) start by explaining why an SOW should be put in place, then (b) draw up a checklist of the 10 best practices to follow for a successful SOW, before giving you, in the final section, (c) an SOW template you can reuse.
A. Why draft an SOW?
Without going back over our previous article mentioned above, a Statement of Work (SOW) is an essential document in most complex contracts (IT, engineering, large projects, etc). The SOW sets out the expectations, responsibilities and obligations of each party involved in a project. By clearly establishing these elements from the outset, an SOW helps prevent misunderstandings and reduces the risk of later disputes. Indeed, a well-drafted SOW serves as a reference throughout the project, ensuring that all parties understand and comply with the agreed terms.
Another major benefit of drafting an SOW is that it helps structure and detail the expected deliverables. This includes technical specifications, timelines, performance criteria and quality requirements. By having a clear and detailed view of what needs to be achieved, project teams can better plan their resources and activities, improving efficiency and productivity. Moreover, this clarity helps to better manage the expectations of clients or stakeholders.
The SOW also plays an essential role in cost and budget management. By precisely defining the tasks to be carried out, the resources required and the deadlines, it becomes easier to track expenditure and ensure the project stays within the planned budget. This helps avoid cost overruns and delays, which can have significant financial consequences for the company. In addition, a good SOW facilitates discussions and negotiations with suppliers and subcontractors, as it establishes a clear and common working basis.
Finally, drafting an SOW helps strengthen transparency and accountability within the project team and towards clients. By documenting each party's roles and responsibilities, as well as the processes for checking and validating deliverables, the SOW creates a structured and transparent working framework. This transparency helps build trust between parties and ensures better collaboration throughout the project. Furthermore, in the event of a disagreement or dispute, the SOW can serve as a reference document to resolve conflicts fairly and quickly.
In conclusion, drafting an SOW is an essential practice for ensuring project success, and a key element of risk and opportunity analysis by the contract manager. Once drafted, the Statement of Work should provide a clear and detailed view of project expectations, while also facilitating project management by strengthening transparency between stakeholders. For these reasons, it is crucial to devote time and effort to drafting a quality SOW, easier said than done… but we give you a few pointers in sections B and C below!
B. SOW: Top 10 best practices
As we have just seen, the SOW is a key element in IT contracts, or more generally in engineering contracts involving project management. To make sure you don't miss anything essential, we have prepared a checklist to keep with you when drafting or reviewing these SOWs. Here are the 10 key elements to check in the SOW of an IT contract:
- Favour a dedicated meeting over email: this may seem trivial, but for a subject as sensitive as reviewing or drafting an SOW, it is preferable to be able to discuss the SOW and its content during a dedicated meeting, rather than sharing it in an email which, all too often, will remain stuck in an inbox or be read only superficially.
- Get the various stakeholders to contribute actively: rather than proposing an overall review of the document, which puts each of your contacts in a fairly passive position and risks not challenging the status quo, split the SOW into different sections or work packages according to the contributions required, and clearly ask each stakeholder to contribute to that section. For example, you might ask a quality manager to review the section dedicated to quality assurance, or an HSE manager to review the sections on safety commitments and expectations and provide a minimum of 3 inputs.
- Put yourself in the other party's shoes: if some elements seem clear and unambiguous to you, is the same true for your counterparty (or counterparties)? While it can sometimes be tempting to leave imprecise wording unresolved, particularly to avoid complex negotiations, this is unfortunately rarely the right approach. To borrow a quote from N. Boileau: "what is well conceived is clearly stated, and the words to say it come easily." In short: beware of imprecise wording, shortcuts and other inconsistencies, which will become thorns in your side during project execution. At the very least, any drafting ambiguity should be identified, understood, and its impact quantified.
- Start with a detailed outline: faced with the anxiety of a blank page (or, let's be honest, sheer laziness), the simplest approach is to focus on substance rather than form. Like an architect of the contract (and of the SOW in this case), start by drawing up an outline (section C below can help), then detail it, so that all the topics you want to cover are addressed. Once this detailed outline has been validated, all that remains is to fill it in.
- Make sure a RACI is in place: this may also go by another name, such as a "workshare", but the key point is that "who does what" must be clearly identified in the SOW. Who will coordinate the various work packages? Will I be consulted or informed when my partner's monthly reports are sent? And so on. These are all questions that must not go unanswered, particularly regarding project and contract management & administration, at the risk of paying the price organisationally.
- Beware of interfaces: perhaps one of the most important yet most neglected best practices in SOWs! While the previous point covered the RACI and "who does what", it is too often the case that a clear split of roles and activities is made for the main components of a project, but interfaces are dealt with superficially, whether due to lack of time, lack of attention, or lack of technical knowledge (each party generally being an expert in its own field, but somewhat less so in the counterparty's). The main recommendation here is to identify these interfaces (which almost systematically become points of friction during contract execution) and take the time to discuss with the relevant stakeholders to identify risks, clarify roles, and put in place the necessary actions to stay in control.
- Clearly describe your deliverables and performance indicators: it can sometimes be difficult, for a company purchasing products, services or technology in which it has no expertise, to accurately translate its operational needs. Whether you are the supplier or the client, you should precisely define what must be delivered, whether products or services. For example, on the documentation side, rather than listing deliverable titles, think about specifying what each document must contain. Then, for products, in addition to a technical data sheet, it will sometimes be necessary to specify their intended use, as well as the input data and/or operational constraints the product must meet. Finally, performance indicators are also important, whether SLAs in managed services contracts or wind resistance or endurance for an aerial drone (UAV), these indicators are particularly important in an SOW.
- Be precise about acceptance conditions: as precise as possible at the SOW drafting stage. At the very least, state who will draft and who will approve the testing or acceptance procedure, the main elements to be checked during these acceptance operations, as well as the terms (with or without reservations) and consequences in the event of total or partial non-conformity.
- Avoid leaving the SOW until the last minute: at the risk of not having time to implement the best practices we have just mentioned. A last-minute SOW is a bad habit we see far (too) often in many companies. To convince everyone of the importance of prioritising the SOW among the documents to be drafted first (on a par with the contract!), remember that while the contract secures an order, the SOW secures the project margin! This is obviously a huge simplification, but broadly speaking, one could say that while the contract records revenue, the SOW preserves EBITDA! The quality of your SOW will impact the execution of your project, and in most cases its profitability, a concept worth instilling in your teams to get everyone behind this document.
- Make sure of the SOW's place in the hierarchy of contractual documents: a best practice that may seem obvious, but which in practice is a step that is sometimes forgotten or overlooked. Indeed, no matter how much time and effort you put into producing a magnificent SOW, if it ends up relegated to last place among the applicable documents, behind the offer and your supplier's general terms and conditions (if you are the buyer), the minutes of a negotiation meeting (unfortunately, we have seen this before), or even bank guarantee templates, your SOW's usefulness risks being reduced to almost nothing.
That concludes these 10 best practices. If you can think of more, feel free to let us know in the comments, or by contacting us directly!
C. SOW template
Finally, you may be reading this article just for the template, so here we are. First, let's start with a few reminders (and an important disclaimer): an SOW must be tailored! It must meet the specific needs and constraints of a company or a project. The SOW will also differ depending on the nature of the project. An IT project will inevitably have different content from a construction project, which will itself differ from a government project to acquire armoured vehicles.
However, it seemed difficult to end this article without giving you something concrete! We have therefore prepared a standard SOW outline template below, and added a few useful links for downloading SOW templates if needed:
1. SOW outline
A. Background
- Present the general background of the project, including the objectives and reasons justifying it.
B. Definitions
- Provide definitions of the key terms and acronyms used in the document to ensure a common understanding.
C. Scope of supply
- Describe the products, services and/or outcomes expected from the project, including what is included and excluded from the scope. In the case of a consortium, grouping or multiple parties, state who provides what.
D. Roles and responsibilities
- Identify the roles and responsibilities of the various project stakeholders, in particular using a RACI if necessary, paying particular attention to interfaces.
E. Schedule
- State the main stages, milestones and key dates of the project, including deadlines for each deliverable.
F. List of deliverables
- List and describe the specific deliverables each party must provide, with a minimum level of detail and performance or quality indicators where necessary.
G. Acceptance criteria
- Detail the acceptance criteria and processes for the project's deliverables, including any required testing and inspections.
H. Availability and maintenance
- Specify the availability requirements for the product or service and the maintenance conditions during and after delivery.
I. Quality and HSE
- State the quality standards to be met, as well as health, safety and environmental requirements.
J. Project progress monitoring
- Describe the mechanisms and tools for monitoring project progress, including progress reports and review meetings.
2. SOW templates to download
If you need SOWs specific to a particular field of activity (construction, IT, engineering, defence, etc.), a few useful links may give you some inspiration:
- General project SOW in English: SOW template from the State of Georgia (USA)
- Infrastructure construction project SOW: SOW template from the Bureau of Indian Affairs (US administration)
- Vehicle acquisition project SOW: SOW template from the Government of Saudi Arabia
- IT SOW (SaaS/EaaS): SOW template from the US General Services Administration
Happy reading, and best of luck with your SOWs!