Project Management optimize

Tactical tips for creating a successful deliverables-based SOW

When you're creating a deliverables-based Statement of Work, Ken Hardin advises that you err on the side of clarity.

In my recent TechRepublic IT Consultant posts, I extolled the virtues (really, blessings) of working on a monthly retainer with trusted clients who have a lot of projects in the mill and need a steady, "variable cost" resource in their portfolio. But as an independent consultant, you rarely (if ever) luck into hourly retainer relationships; you have to find a sweet spot with a client who is willing to manage a variable monthly bill instead of just buying a three-month contract from a shop in Manila. And for large, strategic projects (aka "the big money"), you have to create a deliverables-based Statement of Work (SOW). There's no way around it.

A solid SOW is essential to the success of a consulting engagement. One of the best overviews on creating a successful SOW was published on ComputerworldUK.com about five years ago, but the wisdom still holds true. Too much ambiguity in the SOW, and the client might feel their business is not getting what they paid for, or even that they're being scammed. Too much minutia in the SOW, and your hands can be tied in adapting to what you learn about the project as you move forward -- a SOW is not a functional spec. And worst of all (at least from a consultant's point of view), if you don't clearly set expectations in the SOW, you can end up bleeding time and money in countless reviews, revs, and changes of your documentation and deliverables.

The best collection of tactical SOW tips I have seen is published by the National Contract Management Association. This PDF, compiled by author John E. Miller, comes at the issue from the client's point of view, but SOWs are a two-way street, and what's good for the client is almost always going to be good for you. Three highlights of the tip sheet, plus my own two cents, are:

  • Don't use words with multiple interpretations. This may seem like something of a no-brainer, but contracts and their supporting documents are the realm of the fine-tooth comb. Do not use "the project" when what you really mean is "the second round of business requirements interviews." Be laborious in spelling out every activity and deliverable. And while we are dealing with semantics, also take careful note of the tip sheet's advice to use "shall" when describing the vendor's (that means you) activities, and never let phrases like "either" or "and/or" into your SOW. Spell out exactly what you are going to do.
  • Add negative scope, specifically stating work that will not be done under the SOW. The tip sheet lists this in the form of a question, but I am inclined to view this as a basic tenant of deliverables-based SOWs. If the section is complicated enough to merit a meticulous breakout of tasks, it also merits a SOW of what not to be done. You can't be too combative with a client, but a simple rider to keep expectations under control will work for both parties.
  • Clearly define the acceptance and rebuttal loop. This is absolutely essential if you plan to get out of the project with a decent effective hourly rate and a solid relationship with your client intact. Clients (particularly VPs) never pay close enough attention to the details during the project, and always want to push you for added reviews and "tweaks" -- some of which can be major revisions on your end. Spell out how many review cycles and changes you are committing to in the SOW; be prepared to go an additional 15% or so just to keep the peace; and then be ready to start filing change orders. In the culture of SOW-defined projects, it's going to happen, so set expectations up front.

I recommend that you take some of the suggestions in this piece and adopt them as policy. The client always has the upper hand -- they write the checks -- and so it's in your best interest to err on the side of clarity.

About

Ken Hardin is a freelance writer and business analyst with more than two decades in technology media and product development. Before founding his own consultancy, Clarity Answers LLC, Ken was a member of the start-up team and an executive with TechRe...

4 comments
mikewor
mikewor

How will success be measured? Not sure if it should be in the contract or the SOW, but my preference is each item documented in the SOW shall define what will be regarded as a successful implemenation of that item. This helps prevent 'scope creep' and also gives the client an upfront view of what he will be expected to do when accepting the item.

stephen.holland
stephen.holland

Title Case is your friend, if you use a word with multiple meanings, define it for the purposes of the SOW - if you have a Master set of Terms and Conditions check to see if the term you want to use is defined already. Day, Business Day can have many meanings, when you use day and business day the commonly accepted definition will be used. if day for the purpose of your SOW means a day of week from 00:00 to 23:59 Sunday to Saturday then define Day as in your document. If business day means a day of the week between 8:00 and 18:00 Monday to Friday then define Business Day as just that and use it religiously. If a term is defined in the Master set of Terms, DO NOT redefine it in your SOW.

gcookman
gcookman

Make sure you have agreement on the process for changes. In some cases, you may want to be allowed to bill for time to price out a change. But make sure your client understands you are serious about changes.

Sterling chip Camden
Sterling chip Camden

Even if you never have a disagreement with your client, making sure you both understand exactly what's expected will make everything go more smoothly.