How to Review Your Scope of Works Document

The scope of works (SoW) document is one of the biggest milestones in your ERP implementation. Once your SoW has been signed, your implementation is officially underway. 

Just like a blueprint, your SoW will dictate how your new ERP is built – getting it right is crucial. From the services and capabilities delivered, to who is doing what and how long it will take, everything should be clearly stated in the SoW.  Any gaps, ambiguity or misinterpretation in the wording of your SoW will almost always lead to disappointment, a break-down in trust between you and your IT services provider or, worse, a poor implementation.

In this post we’ll answer:

• What is a scope of works document?
• Why do you need a SoW?
• Who is responsible for a SoW?
• What should be included in your SoW 
• How to review your SoW statements 
• Finalising your SoW

1. What is a scope of works document?

Scope is ‘the sum of the products, services, and results produced in a project’. The ‘scope of works’ is a formalised document that puts all the scope details down on paper, setting out what is being delivered and by whom. In many cases, the SoW is either in PDF or a DocuSign format, created by your IT services provider (also known as an implementation partner) and presented back to you (the customer) in detail, calling out any terms and conditions or warranties. 

2. Why do you need a SoW?

Think of the SoW as a contract between you and your implementation services provider (otherwise known as your implementation partner). Once your project begins, a signed SoW will become a vital point of reference, reminding everyone involved in the implementation of what was originally agreed. Not only will an SoW ensure that your implementation partner delivers exactly what was promised and that you end up with a solution that meets your requirements, it will serve as a reminder of agreed milestones, timeframes and objectives.  Equally, the SoW safeguards your ERP project from the dreaded ‘scope creep’.  

Scope creep refers to any additions that weren’t included in the agreed scope. Thirty-three percent of organisations experience scope creep – and, as you can imagine, changing or requesting new capabilities half-way through a project is rarely a good idea. Scope creep can lead to significant time and cost blow outs, as well as jeopardising the quality of the implementation.

A highly detailed and accurate SoW, that follows a RACI matrix, is the best safeguard against scope creep.

3. Who is responsible for a SoW?

Your ERP implementation partner is responsible for preparing the SoW document. However, it’s important to remember that your partner will use much of the information from the original request-for-proposal (RFP) document as the basis for the SoW. (For tips on putting together a detailed RFP, download our free RFP template).

The SoW isn’t a legally binding document – but it will, most likely, be referenced in your commercial agreement with your implementation partner. With this in mind, the onus is very much on you (the customer) internal project team to ensure that your SoW has been comprehensively reviewed before signing. 

4. What should be included in your SoW

Your SoW should include:

1. Overview of your business workflows – these will need to be set up in the new ERP and a missed step in any of your business processes could lead to gaps in functionality. Microsoft Visio and other flow chart tools can help to ensure every process step is included.
   
   
   
   
   
2. Summary of deliverables – this is what you’re expecting your ERP implementation partner  to deliver, from the ERP system itself, any specific workflows or business processes to be created, support, maintenance and any new coding to facilitate integrations. For example, if a manufacturing business needs a workflow for a visual production scheduler to be displayed, this should be listed in the summary of deliverables.
3. Integrations – if your ERP system will need to integrate with other vital business systems, such as your POS, ecommerce or website, this may require significant work from your partner and must be included in your SoW. If you foresee the need to integrate more systems in future, this should also be referenced clearly.
4. Timeline – a project plan with allocated hours against each phase and milestone, from start to finish. Not only will this ensure that the project stays on track and no major milestones are missed (such as data preparation, training and user acceptance testing), it is a vital tool for planning staff resourcing and availability. A Gannt chart is one of the most effective ways to map out your project timeline and get an accurate idea of a project completion date.  

1. Solutions – ERPs generally have a number of modules  that can be set up for your business if needed, including financial management and accounting, inventory, service management, CRM, payroll, manufacturing and more. It is worth taking the time to scope exactly what your business needs, and when. If you have specific needs for your system now’s the time to include them – along with a summary of what is required. 
2. Customised add-ons or development – If your business has unique needs, you might need some custom development. However, the more you customise your ERP system, the more it will cost. But some customisations can bring significant benefits that will easily justify the additional costs, such as automated workflows, which will save your teams time and money. Your SoW should include all customisation requests and details of what is required.
3. The process for requesting changes or additional functionality – in an ideal world, your SoW will be water-tight and account for every request and responsibility. The reality is that oversights can happen and, if a vital requirement is missed or change needed, having an agreed process set out for making requests will help to keep communications on track. Without this process, critical needs or updates can be missed, or changes made without your sign-off.

5. How to review your SoW

Reviewing the SoW is one of the internal project team’s most important tasks – and your last chance to accurately set out your expectations for the implementation and avoid scope creep. 

One of the most common reasons for scope creep is a poorly defined SoW, so scrutinising not only the list of deliverables but the specific wording around how they will be delivered. Just because an item has been referenced, doesn’t mean that your implementation partner is committing to delivering it in the way you might envision (if at all).

Ask yourself:

• What exactly is being delivered?
• Who is delivering it?
• How does this address requirements?

Here are some examples of common ambiguous phrases found in SoW documents – and how to clarify them:

1. Set up accounts receivable:

• Does this include approval workflows for credit note approvals?
• What types of payment terms will be setup?
• Will credit limits be included as part of this setup?
• Does this include direct debit setup?
• Does this include a BPAY setup? 
  

• Does this include all the documents you’ll need for customers such as statements and invoices?
• Do you need specific fields set up on these documents such as payment terms, bank details or due dates? (You’ll need to specify these in detail.)
• Will this include necessary changes to match our existing invoice and purchase order layouts?
• Will we be able to update the layout if needed? (e.g. … swapping logo?)
  
  

• Will these match/replicate the reports that we use in the current system?
• Does this include our special report requirements, shared previously?
• We currently use a Power BI solution – will reporting include migration of our existing reports? 
  
  

6. Finalising your SoW 

Once you’ve fully reviewed your SoW, any sections that have been flagged for change should be marked up and shared with your partner. Either the requests you’ve flagged are within scope and the partner simply needs to change wording of the SoW to reflect this more clearly – or your requests are outside of the original RFP. 

At this point, unless you can demonstrate that your requests fall inside of your partner’s original proposal, they will be considered ‘outside of scope’ and probably require additional cost. Even if this is the case, it’s always better to spot and negotiate any additions before the SoW is signed.

Getting your SoW right – first time:

A poor scope has up-ended many a project – one of the worst recorded examples was a US airport’s automated baggage-handling system, which ended up with more than 2,000 design changes, 16 months late and $569 million USD over budget. 

In the rush to get your ERP implementation up and running, it can be tempting to sign your scope of work document quickly and hope that any misunderstandings around deliverables can be handled if, and when, they arise. But even the best client/partner relationships can fall foul of a poorly defined SoW. Taking the time to iron-out any ambiguity before work officially begins will save you time, budget and make for a better ERP implementation.

Planning to switch to a new ERP? Check out our other related blog posts, including:

•    Moving to ERP? Here's what you need to know
•    Setting up for Success: 50 Key Capabilities for your ERP Requirements
•    Finding The One: 6 Red Flags & Must-Haves in an ERP Services Provider