The practice and consequences of embedding the SOW into the contracts for software and services

Incorporating the SOW into the contracts for software and services strengthens those contracts, but that isn’t the primary purpose of doing it. The primary purpose is to determine the scope, shape, structure and day by day direction of the implementation project.

Implementation consultants work toward concrete goals: when we do this, you pay us X; when we do that, you pay us Y; when we finally do the last thing, you pay us Z and we’ve fulfilled our obligations under the contract. The user hopes that the contract is the only one there will be, the implementers (with greater reason on their side) hope that it’s only the first in a series, but both agree, going in, that it defines the entirety of everyone’s obligations toward the implementation project. And that contract must spell out concrete, achievable performance milestones directly tied to payments for work performed. No implementer will fall for “we’ll pay you when we’re happy,” nor should any implementer be asked to.

Every implementer’s oh-so-unique and proprietary methodology is designed primarily to demonstrate performance – and the performance to be demonstrated is their compliance with the terms of contract satisfaction. That compliance is 100% of what they work toward. Work that does not further that compliance is out of scope by definition (if you really want it done anyway, we’ll be happy to quote it). Experience has taught implementers that no other business model works. Consequently, when they are not given concrete and unambiguous goals to meet, they impose their own: this phase is done (and its associated obligations satisfied) when the customer order processing module is configured, that phase is done when we produce a balance sheet from test data we’ll show you how to enter.

Download our free E-Book; The Symptoms, Reasons, and Causes for ERP project failures from our web site: