Summary
This post is a departure from the normal technical content of this blog. I'm going to share my thoughts on the topic of Statement of Work (SOW) development in the domain of IT services. The content of this post is strictly my opinions as I'm not an attorney nor have any legal training whatsoever. Those opinions are based on ~20 years in Professional Services and active in the writing and implementing of SOWs for technology services. In many cases, the lessons described here are written in blood/tears from mistakes I and others have made in the past.
SOW Components
A SOW is a contract, pure and simple. It's the sort of contract that is the standard for describing services in the technology space. Below are the typical sections in a SOW.
Header with Parties
This is generally a boilerplate section with a definition of the parties involved in the SOW. There are typically two:
- Service Provider (SP): This is the organization delivering the services.
- Customer: This is the recipient of those professional services.
Lines can be blurred in some instances. Example: A SP could be both a provider and recipient in an engagement if they are subcontracting some or all of the services being delivered to a Customer under a SOW.
Scope
The 'Scope' is (or should be, more on that later) the main content of the SOW. This is where the tasks and deliverables of the included services are described. This area is the domain of SP SOW author and typically gets the most attention from both the SP and Customer. Rightfully so, as this area dictates what the Customer will actually receive for their money and what the SP is beholden to deliver.
Terms, Conditions, and Assumptions
Typically a section of the SOW is carved out for boilerplate legal language and/or clarifications to what is/is not included in the SOW scope. This is usually a list of bullets. The SOW author may put some content in this area, but this is usually the domain of both sides' Legal/Contracting organizations.
Pricing
This section covers just what you'd expect - the cost of the services described in the Scope. The structure of the content here is dependent on the SOW design pattern being employed. Those models are described next.
SOW Design Patterns
In my opinion, there are only two SOW models: Fixed-bid, Time and Materials. I'll discuss another model later that I consider an anti-pattern.
Fixed-Bid
This model can be employed when both sides (SP, Customer) clearly understand the services to be delivered. This type of SOW is harder for the author to construct as more work has to be put into describing the scope. It's also typically more difficult for the SP to execute profitably as the cost in fixed-bid engagements is just that - fixed. Costs remain static if the corresponding scope also remains static. The SP charges exactly what the Pricing section dictates - whether it took 1 or 1 million hours to deliver the tasks + deliverables of the Scope.
All that being said, this is the SOW model that most Customers typically feel most comfortable with. They have a budget for a project and want an assurance that they'll get the project completed in that budget. Fixed-bid can provide that assurance - if requirements remain fixed.
Pricing for this model is best structured around billing milestones tied to a tangible activity or deliverable. Each milestone represents a percentage of the total services cost of the SOW. Milestones must be well-bounded as to what 'done' means for that milestone as billing is triggered when 'done' is achieved.
Example milestone: Acceptance of Design Document. The 'Design Document' and the concept of 'Acceptance' must both be rigorously described in the Scope section of the SOW such that both parties agree to what completion of that milestone entails.
Time and Materials (T&M)
This model is typically employed when it is not possible to clearly define the scope of the given project. That can be for a variety of reasons: scope simply isn't known at the time of SOW development, requirements are fluid, or - the Customer simply wants access to resources with certain skill sets, i.e., staff augmentation, without specific deliverables. This is in contrast to a project-based engagement.
As the name suggests, the Customer pays for exactly the amount of services delivered by the SP - typically, metered by the hour. The SOW will state the number of hours included in the price and an hourly rate. A good T&M SOW practice is to include a 'circuit-breaker' clause that states the Customer will be notified when the expended hours have reached some critical mass. Example: 20% remaining. The Customer can then decide whether they want to increase funding to extend the SOW. In any case, the services end when the funded hours are expended regardless of the state of the project.
A really bad practice in T&M is to state that 'deliverables' are included (bad from the SP perspective, but probably considered fabulous from the Customer side). Those two concepts are antithetical. A 'deliverable' implies something that's guaranteed to be produced under the SOW. The duration of a T&M SOW is by definition limited by the funded hours. Scenario: A 'deliverable' is incomplete but the funded hours have all been expended. Now what?
An anti-pattern variant of T&M is 'Capped T&M'. This non-sensical model is an attempt at a hybrid of T&M and Fixed-bid: the hours are capped at a level but the Customer only pays for the actual amount expended. The real mess comes when the SOW author includes deliverables. The Customer gets the fabulous deal of guaranteed 'deliverables' but only pays for actual hours expended up to a fixed maximum. The SP gets the short end of that stick. They didn't understand their scope well enough for a fixed-bid SOW but now have to deliver at what is, in essence, a fixed cost. Net, this is an imbalanced situation.
Summary graphic below.
SOW Authors
I'm going to speak to this from the SP perspective as they are typically the party that generates the SOW. It's their services and the SOW represents their quote for those services. There are occasions when the Customer will generate the first draft of a SOW but those seem to be less common in my experience.
On the SP side, SOW development is almost always a team effort. There is a main author of the scope content and then various other parties that provide review and/or auxiliary content. Those other parties are invariably Contracting/Sourcing, Legal and the management of the Services arm that will be responsible to implement the tasks/deliverables of the SOW.
As far as that 'main author' - who should that be? In my experience, the best results come from individuals that have real-world, hands-on experience in the technology. This is almost always people that were/are in the Professional Services practice or have independently taken an active role in keeping themselves technically relevant. It's these subject matter experts (SMEs) that are best suited to follow the sale from the beginning with the SP Sales team. They hear the Customer explain the requirements first hand and understand any constraints that the Customer has expressed during the sales cycle.
I've seen a number of SPs that do not utilize SMEs for SOW development. Instead, they'll use weak/generic scope statements or create a separate SOW group altogether that is detached from the Sales process. Below is a listing of the issues I've seen over and over again with this model:
- Authors that have no historical context on the engagement. They weren't involved in the sales cycle so they didn't hear all the conversations with the Customer. They come in cold to the sale. As such, it's almost impossible for them to write a coherent fixed-bid SOW.
- Authors that have little to no technical or operational background. They simply can't go to the level of detail necessary to capture the scope because they don't have a firm understanding of those details.
- Authors that have too much technical background (and no sales background) and produce SOWs that go off the deep-end in technical content. These SOWs wind up looking like technical design documents instead of a contract that a business leader is going to have to decipher and agree with prior to signing.
In most cases where the SP doesn't use their SE for SOW development, that SP is only comfortable with T&M engagements. That's for good reason as their risks skyrocket in fixed-bid SOW's developed on incomplete information.
SOW Do's/Don't
- #1 - Create a balanced first draft of the SOW and strive to keep it that way. By 'balanced', I mean fair to both sides: Customer and SP. Imbalanced SOWs just lead to protracted negotiations and in some cases - no sale.
- Do write detailed scope content.
- Don't write scope content that resembles a technical design document.
- Don't put deliverables in T&M SOWs.
- Don't put labor hour breakouts in Fixed-bid SOWs. That's an unnecessary artifact that potentially leads to confusion and protracted negotiations. By definition, the fixed-bid engagement will be delivered at a static cost. The hours to do so are irrelevant. Labor breakouts in T&M are fine and expected.
- For Fixed-bid SOWs, do tie billing milestones to tangible results.
- Avoid putting fixed delivery dates in any SOW. Sometimes this cannot be avoided due to the Customer's requirements. In those cases, something akin to a formal project plan is going to have to be developed prior. That means the Services arm will have to be pulled in for a detailed analysis of the requirements and project plan development. In most cases, that will be a non-billable exercise as it's prior to the SOW being executed.
- Don't attempt to write an exclusion for every item you can think of that's out of scope. By definition, anything that's not explicitly listed as in-scope is out of scope. The universe of 'out of scope' is infinite. You can't hope to capture infinity.
- In the same vein, if the SOW has more content around exclusions than it does around scope definition - that SOW is likely of poor quality. This is a sign that the author does not understand the engagement or technology.
Copyright ©1993-2024 Joey E Whelan, All rights reserved.
