Make Sure Your ERP Statement of Work and Scope of Work are Spelled Out

Handshake agreements and complete trust in your ERP vendor or consultant are admirable, but it is vital that you have both the Statement of Work (SOW), including a well-defined Scope of Work, spelled out in the Engagement Letter or contract you ultimately sign.

Often lost in the shuffle of moving an ERP modernization or transformation project from the planning stages to reality is miscommunication between client and contractor about what has been promised during the selection and negotiation process and what has been legally agreed to between the two parties.

ERP Implementation “Bells and Whistles” Often Not Included in the Final Contract

It is not unheard of for unscrupulous ERP vendors to demonstrate “bells and whistles” during the sales stage that are quietly not included in the final contract.

The goal is to avoid unwanted surprises and to accomplish that, you need to understand the fine print on the contract you sign for your ERP implementation.

“You want to think about accountability and from a project management standpoint there is no better time to bake into these documents … very specific language that details project timelines, deliverables, milestones, and the like,” says Marcus Harris, software and intellectual property attorney in the video “How to Negotiate ERP RFPs, Contracts, and SOWs”.

ERP consultant Eric Kimberling, in that same video, says the danger is that a lot of organizations get so excited about the project in general that they get blinders on a little about how you mitigate against the risk and what you do when things don’t go well.

Take Control During ERP Implementation Contract Negotiations

It’s important for organizations to take control during ERP implementation contract negotiations.

The goal is to take advantage of this opportunity to leverage the contract process to your company’s advantage vs. not wanting to deal with the fine print and letting the ERP vendor write in what they want.

Daryl Crockett, data mitigation specialist, says that behavior tends to lead to things getting missed or language in the contract that benefits the supplier as opposed to benefitting the customer.

How bad can it get? Consider that data, which is at the heart of any ERP project, can sometimes not even be mentioned in a Letter of Engagement or contract.

“The contracts that I see, oftentimes, they don’t even mention data. As if it’s some sort of afterthought about the whole project which is crazy in my mind,” says Crockett. “

The first step, perhaps, is to have a good understanding of the terminology in these negotiations including the difference between a Statement of Work, a Scope of Work, and the Engagement Letter or formal contract:

• Statement of Work (SOW): This document lists the specific tasks that the consulting firm will be expected to perform throughout the project and the costs associated with this.
  
  
• Scope of Work: This defines the full scope of the project, including project goals, the deliverables you will receive, timelines, and how success will be evaluated. It should be included within the SOW.
  
  
• Engagement Letter: This is the actual contract, and once signed by both parties, will be the legal document governing the project moving forward. Both the SOW and Scope of Work need to be spelled out in the Engagement Letter.

Never assume items will be taken care of or executed if you do not see them in the fine print of the final contract. It will take time, but you will want your Engagement Letter with the ERP vendor to spell out everything in detail before signing.

Failure to heed this advice will not only hurt the chance of a successful ERP implementation but can likely put you on the path toward litigation with your vendor or consultant.

Statement of Work vs. Scope of Work and What’s Included

The terms Statement of Work (SOW) and Scope of Work sound very similar so it can be confusing.

“Project managers often create a statement of work, which includes a section known as the scope of work, to plan and execute projects successfully,” says Indeed. “Project managers typically complete a comprehensive draft of a project's SOW before work begins. In most cases, SOWs are legal documents that project managers use to maintain contractual agreements with clients and settle any potential disputes about project workflows, payment, and implementation.”

While the specific content of an SOW can vary based on the project, industry, and organization, it typically contains the following elements:

• Introduction and Purpose: This section provides an overview of the SOW, including the project's purpose, background, and any relevant context.
  
  
• Scope of Work: The central part of the SOW, this section defines the project's boundaries and outlines what work is included and, just as importantly, what is not included in the project. It specifies the project's objectives and goals.
  
  
• Location of Work: This section details where team members plan to perform their work, meet with other team members, and access project tools.
  
  
• Project Deliverables: List all the tangible items or outcomes that the project is expected to produce. These can include reports, products, services, software, or any other results of the project.
  
  
• Schedule and Timeline: Specify the project's timeline, including start and end dates, milestones, and key deadlines. This section may also include information on project phases and dependencies.
  
  
• Roles and Responsibilities: Define the roles and responsibilities of all parties involved in the project, including the client, project team members, stakeholders, and any third-party contributors.
  
  
• Resource Requirements: Identify the necessary resources for the project, such as personnel, equipment, facilities, and materials. This section may also include budgetary information.
  
  
• Quality Standards, Acceptance Criteria, and Industry Standards: Detail the quality standards that must be met for the project to be considered successful. This section may also outline how the client will evaluate and accept deliverables.
  
  
• Risk Management: Describe potential risks and uncertainties associated with the project and outline strategies for risk mitigation and management.
  
  
• Change Management: Explain the process for handling changes to the project scope, timeline, or budget. This can include the procedure for submitting change requests and obtaining approvals.
  
  
• Communication Plan: Define how project-related communication will occur, including reporting mechanisms, meetings, and the frequency of updates.
  
  
• Terms and Conditions Including Payment Details: Include any legal or contractual terms and conditions that govern the project, such as payment terms, intellectual property rights, confidentiality agreements, and dispute resolution procedures.
  
  
• Appendices: Attach any additional documents or reference materials that are relevant to the project, such as technical specifications, diagrams, or charts.
  
  
• Signature and Approval: Include a section for authorized representatives of both parties (client and contractor) to sign and approve the SOW, indicating their commitment to the project's terms and conditions.
  
  

The level of detail and complexity in each section of the SOW can vary widely depending on the project's size, complexity, and industry. It's essential to tailor the SOW to the specific needs and requirements of the project to ensure clarity and successful project execution.

Avoid These Pitfalls When Sealing Your ERP Deal

It’s natural to want to get your ERP transformation up and running but rushing to implementation is a mistake that can hurt organizations in the long run.

“A coherent and well-managed vendor selection process is vital when moving through the tender process for a big-ticket IT contract. When you engage with the ERP vendors in your bid you will be dealing with professionals who sell to people like you every day and they’re very good at it. Not exactly a fair contest, is it?” writes Tom Calder in ERP Today.

Calder says to avoid these pitfalls:

• Being in too much of a hurry to sign the contract.
• Focusing on product and functionality vs. the people you are partnering with.
• Not controlling the bid process.
• Settling for template contracts that benefit the vendor.
• Poor contract negotiation.

“Of course, it is possible to make all of the mistakes above (and more) and still buy a great system from a vendor leading on to a successful implementation. However, the deal will be on their terms and you won’t appreciate the impact of that until there’s a problem which, one day, there will be,” concludes Calder.

It can help to have a partner such as KnowledgePath during this difficult process. Contact us today to learn more about how we can make your ERP transformation a focused, efficient, and successful enterprise.