How do we construct a Statement of Work (SOW)?

What is the process of constructing a Statement of Work (SOW) that is effective, legitimate, and provides tangible outcomes for our clients?

​

Statement of Work or SOWs (or even SoW) for short is 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.​Let's begin by clarifying what an SOW is.

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 Understanding Solutions (the SOW procurer) proposing what they intend to deliver. Or, more commonly, where the client defines what they want to be provided with. 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 the 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 on 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.

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, program, or service 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 the time, money, and quality of what should be delivered.

We highly recommend inviting external collaborators and SMEs (subject matter experts) to support defining the right scope (along with other details) as they will have a far more in-depth and detailed view of what can be done. This is an especially effective approach for organizations 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' that 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 authorize 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 are 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 are 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.

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 resources 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.

One area to factor in is how we track or align payment to the activities within the SOW.

A common approach is to align payment amounts and intervals to the effort being conducted, namely the milestones and deliverables. This is a common approach when using fixed-price models but we would actually advise you to 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!​

​

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 resources being deployed to deliver the outcomes.

At this point, we are now complete with the SOW creation.

We can now seek to get the SOW signed by all parties and begin delivery.

​

A version of this blog was first published on the Worksavvy blog. ​

​

​Get in Touch

Are you a client looking for assistance with your projects? Contact us for a chat. Are you an independent contractor or expert? Join our community.