Project Management

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...

Editor's Picks