How do we construct a Statement of Work (SOW)?
Updated: Apr 18, 2021
What is the process to construct a Statement of Work (SOW) that is effective, legitimate and actually provides tangible outcomes for your client?
Statement of Work or SOWs (or even SoW) for short are not new.
They have been in existence and operation for many, many years across many industries and verticals and are used in a multitude of ways. Unfortunately, quite often not as well as they should be.
The purpose of this article is to walk you through the process and areas of consideration as we construct the SOW.
We will cover off these key elements of the SOW:
Explaining how we capture Scope, Deliverables and Milestones
Documenting Assumptions, Caveats & Dependencies - what are they and why are they needed
How we validate our success with Acceptance Criteria & Reporting
Pricing and Risk considerations - what's out of our control needs consideration
Let's begin by clarifying what an SOW is
The SOW is a contract or ‘framework’ within which organisations define, procure, provide and manage a set of outcomes between multiple parties, typically on a B2B basis.
The ‘outcome’ can truly be anything. From simply providing a resource to do some 'work' through to large, complex projects and programmes with thoroughly documented and defined criteria. They can be used to document a simple 1-hour piece of work through to multi-year programmes and services (the latter would typically have a lot of supporting documents in addition to the SOW).
The SOW can either be ‘constructed’ by the providing organisation to their client (the SOW procurer) proposing what they intend to deliver. Or, more commonly, where the Procurer defines what they want to be provided. In either case there is usually some sort of discussion or negotiation on what the actual outcomes will look like.
SOWs are used significantly across IT, Technology, Construction, Engineering and Professional Services. They are also used in both Public and Private sectors, globally.
SOWs can be known by many other names:
Scope of Work
Schedule of Services/Work
Specification Document/Requirements
Project Schedule etc.
Essentially, they all refer to the same thing - defining and documenting a set of requirements, which will be provided and paid based upon performance (completion) of said requirements (the deliverables).
One thing that must be understood is that whilst the SOW is used as the contractual element to agree what is being delivered, there are typically additional components (or processes) that ‘surround’ the SOW in order to ensure its effectiveness.
These additional aspects are the Service components. In essence a series and process of continued governance for tracking, reporting, checking and measuring everything (and everyone) involved in what is contracted through the SOW. This article highlights these components but does not cover them in detail. If you are interested, we've written a dedicated Compliance and Governance guide to explore these areas in detail.
Now we understand what the SOW is (a legal document detailing a set of outcomes), let’s explore how they are constructed in practice…
Defining and Documenting Success
SOWs as we’ve already discussed can be very simple or incredibly complex. They can be used for pretty much any purpose, although certain instances and engagements are far more appropriate for SOW due to the nature and effort of how they are built and managed.
Irrespective of who starts the process (procurer or provider), there needs to be an understanding and agreement on the set of requirements (the Scope) along with the objectives and intended outcomes of the project, programme or service which is being delivered in the SOW.
The first hurdle or step is to agree on what can actually be delivered against the requirements.
This is where a slight misalignment on expectations can arise – the Procurer may want something to be delivered which may not actually be feasible, possible or practical based on the time and/or their budget.
The best way to approach capturing accurate scope definition is through collaboration. Having the right parties (both business and technical, internal and external) working together to agree and document what can and cannot be achieved in the timeframe and budget requirements. Taking a non-collaborative approach usually leads to a level of failure and/or scope creep which impacts time, money and quality of what should be delivered.
We highly recommend inviting external collaborators and SMEs (subject matter experts) to support on defining the right scope (along with other details) as they will have a far more in-depth and detailed view on what can be done. This is an especially effective approach for organisations that don’t retain their own permanent staff or are moving into delivering something very new.
The next step in constructing the SOW is to break down the scope into applicable and measurable deliverables and milestones.
These ‘metrics’ are what define the actual outcomes (deliverables) along with the timeline and check-points (milestones) to measure success and performance against, upon which the successful completion typically triggers payment, but not in all cases.
To summarise:
The scope is the overall project requirement and a set of goals/objectives to be delivered - it is the 'what' and 'why'
A deliverable is a defined 'sub-goal' which makes up part of the overall objective
A milestone is a check-point of success against the deliverable, to validate the project is on track
Now we have an agreed/defined scope of activity along with the underlying deliverables and milestones we need to consider the ‘what if’ conditions - the dependencies, caveats and assumptions.
The 'what if' Conditions
These conditional elements (assumptions, caveats and dependencies) are important to define as it establishes a set of prescribed variables that need to exist (or be met) in order for the scope, deliverables and milestones to be successful.
Put simply, what we expect, anticipate or assume to be true until proven otherwise.
It is very difficult, sometimes impossible to define a 100% accurate scope and set of deliverables and milestones, especially if there are time constraints in place.
In the majority of instances when building SOWs, we need to take the information we’ve gathered or been provided with a ‘pinch of salt’ and as such we use assumptions, caveats and dependencies to commercially protect ourselves (and others) against the outcomes and service we are proposing.
So, what are these ‘what if’ conditions:
An Assumption is an assumed condition we define in order to prescribe how the Service (SOW) will be delivered. For example we assume all relevant documentation is up to date, or that the CFO will authorise deliverables etc.
Caveats are a conditional statement based on an outcome, task or assumption being subject to something else (the condition) happening. For example, reports will be produced on time, subject to all stakeholders providing the required information as requested within our timeframe.
Dependencies define and detail what we expect and/or need to be provided in order for the successful completion of a milestone/deliverable, without which delivery will be impacted. For example access to IT systems, or response to any clarification questions within 24 hours etc.
Capturing and defining the above conditions requires collective input and reinforces the need for collaboration. A finance SME would not be suitably equipped or experienced to understand and define what dependencies are required to develop a new piece of software.
By this point in the process we’ve defined our scope, objectives, deliverables and milestones along with our ‘what if’ conditions.
What’s left to consider?
Well we still need to consider defining the acceptance & sign-off criteria, service reporting and communications (governance), pricing and finally any additional conditions or information we require to ensure success.
Whilst we've captured our deliverables and milestones along with what we need to deliver the tasks, how do we actually validate a task or outcome has been completed? Beyond our own belief of course.
Acceptance and sign-off criteria is the answer…
Validating Success
Recall that the SOW is a document outlining what one party (the Procurer) wants and what another party (the Provider) will deliver.
Whilst we may agree or collaborate on what needs to be delivered, the interpretations of success will likely be very different between parties.
We use acceptance and/or sign-off criteria to agree on what ‘good’ looks like and what constitutes success for each task/deliverable/milestone. In essence we are stating when something is complete ‘I expect it to look like this’.
Just as we did during the scoping, it's recommended we collaborate to agree and define what ‘good’ is and what the expected output will be. In the absence of any collaboration, either party can define the expected output, which if the other party accepts will be duly bound to deliver. As such we need to make sure all parties agree, otherwise disagreement and misalignment on success is very likely to ensue.
As we mentioned at an earlier point, it is recommended every SOW includes a level of governance and compliance.
Why?
Well as we’ve explained, the SOW is just a document which details a set of requirements. What many don’t fully recognise is there’s an inherent service ‘wrapping’ the SOW requirements which must be provided at some level and in-turn be managed correctly.
Without this ‘service’ in place to report, track and measure any success, along with capturing potential scope change (through a change process), failures, risks etc. it would all be very subjective with no facts or validation.
This article does not cover these aspects in detail as they are so important. We’ve written a dedicated article solely focussed on explaining the reasons, process and crucially benefits of ensuring some level of governance is in place across every SOW that is provided.
By this stage we’ve created a robust and well-structured SOW, but something crucial is missing? How are we going to get paid for all this great work we’re agreeing to?
Pricing and Risk
The fee structure (pricing model) depends on many variables.
Does the procuring party have a fixed budget in mind?
Does the procurer want to 'outsource' their delivery risk?
Does the procurer want a fully managed outcome or do they simply want to procure flexible resource and consume as needed?
Is the provider comfortable with taking full commercial accountability for the outcome?
Are there too many unknowns (despite all our great collaboration) to make a definitive assessment and accurately define our success criteria?
Are there lots of 3rd parties involved which will affect how the provider manages and delivers?
These are just a handful of considerations, we could additionally consider logistical issues, scheduling problems, equipment supply etc. into our pricing decision process.
Ultimately it will relate back to two questions:
What is the commercial risk profile of the Provider?
How well defined are the requirements and are they ‘simple’ to deliver?
We can’t answer the first question easily, that is different for all businesses.
What we do know however is that the more we do something, the more comfortable we become with it. In other words, if the SOW is the first time you’ve done this, or is providing outcomes in an area you don’t know well, the risk profile will likely be higher.
With regards to the second question, well this relates back to all of the information we’ve captured so far and making an assessment on the relative ‘simplicity’ of what needs to be delivered.
We just stated the more we do something the easier something becomes; this unfortunately doesn’t mean it is simple though. The project might have so many variables that it would be very difficult to nail down a fixed-price, unless we could charge such a massively inflated amount for our services – we do not advocate this approach as it is very easily uncovered in relation to the value being provided.
In general, the more experience we gain, the more comfortable we become and the more open to risk (calculated of course) we become in providing outcomes. Surrounding ourselves with knowledge by working and learning from others (SME's for example) will enable our risk consideration to become more objective and more easy to define good vs bad - for your respective business.
One area to factor is how we track or align payment to the activities within the SOW.
A common approach is to align payment amounts and intervals to effort being conducted, namely the milestones and deliverables. This is a common approach when using fixed-price models but we would actually advise you take this approach on ALL pricing models, even including time and materials (T&M whereby we are providing a more 'skills-only' engagement.
Why you may ask?
It is important to track effort against activities, we can still hold accountability on a T&M engagement, and whilst there may be less liability or risk commercially to the provider if something overruns, it is still good value for the procurer.
In this instance we might predict a level of effort to complete each task/activity and map the price to this based on the relevant T&M rates. Of course, these rates are subject to everything going according to plan (caveats), which as we know they may not. As we've recommended though, we should be reporting and tracking on this anyway as part of the overall service we provide, notifying the procurer of any impending issues, hopefully ahead of time. Another reason why governance is so critical!
A lot of the time providers see no value in providing a level of 'service' coverage when doing T&M engagements - this is hugely shortsighted. Not only does providing a lite-touch service provide value to your clients, and may well help you win more business, it more importantly gives you feedback, knowledge and experience for future opportunities.
With our pricing sorted, we’re nearly done!
Have we missed anything?
Our final step is to cover the bases and include any additional information or considerations we’ve not captured elsewhere throughout the SOW and will really depend on the outcomes and project being requested or provisioned.
Some examples could include any specific client resources/equipment we need to be provided by the procuring party. We will certainly want to include some key stakeholder information like primary contact details, project name from the procuring side, service location and hours of operation. Additionally, we might want to include some specific notice periods or clauses (if different to our main service terms) and if applicable name key resource being deployed to deliver the outcomes. Note, naming resource is not recommended if when utilising SOWs in the UK you are using independent contractors (PSCs) to deliver due to HMRC IR35 legislation.
At this point we are now complete with the SOW creation - Congratulations!
We can now seek to get the SOW signed by all parties and begin delivery.
Of course, if you have followed all the guidance throughout and taken a collaborative approach signatures should hopefully be a mere formality.
To arrive at this stage is quite an achievement and everything we’ve done has been rather manual and time consuming. Lots of calls, emails and meetings are likely required to capture all the necessary information, get it documented, shared, agreed etc. This is a very old-school, traditional approach. Effective perhaps, but very inefficient and certainly doesn't scale well on time or resource.
What if there was a simpler, more effective way?
Well, there is…and it’s called SOWaaS®
SOWaaS® (Statement of Work as a Service) is an industry pioneering, full lifecycle SaaS software platform which is designed specifically to simplify and significantly improve and automate the process of capturing, creating, validating and managing SOWs along with every aspect contained within and surrounding them. SOWaaS® supports and empowers every party in the supply channel, from procurer to supplier, to collaborate and work together to deliver better value and better outcomes for a fraction of the time and cost it would take to do through traditional channels.