TechRepublic reader David Rippel sent me an email that read in part:

One of the most dreadful things I find myself doing is writing statements of work (SOWs). I’m sure you have created a few yourself!

In my opinion a SOW is the most important, yet entirely useless document you’ll ever write as a consultant. Allow me to explain.

A good SOW wins you business. However, my experience has always been that we (the client and I, mutually) deviate from a granular SOW by the second day of a given consulting engagement. Customers get new ideas, and as a consultant I feel that I am providing more value when I start being creative to make these ideas a reality. Bonus if it’s something I can reuse on another project later.

On the flip side, creativity and deviation from a SOW during a project can bring about much frustration and timelines can slip.

So, where is the balance? Do you have any suggestions for the community on how to write an effective SOW which can be a functional tool during the project?

Is everyone eating this project management time as a cost of doing business, or is there a point where you draw the line (time spent on SOW vs. value of project you are pursuing)?

From the consultant’s perspective, the best answer to this dilemma seems to be billing by the hour, day, week, or month for as long as it takes to do whatever the client wants. On the other hand, “there ain’t no such thing as a free lunch” — what you gain in billing security might come at the cost of client satisfaction. Your client wants to be secure about how much they will end up paying, so you could lose business to someone who can give them more solid assurances — even if they charge more.

Ken Hardin wrote a piece about SOWs last year in which he advocates clarity and a focus on deliverables. I found his third point to be the most important: “Clearly define the acceptance and rebuttal loop.” The less attention you pay to that process, the more you create the expectation that the project will fulfill the magical dreams of the Waterfall model in which everything can be defined up front so any failure to come to a happy ending can be blamed on somebody’s laziness. Since your client writes the checks, guess who gets to assign that blame?

But it isn’t even about guilt or innocence. Today’s projects have much more complex and fluid requirements than the “take this input and produce this output” projects of 40 years ago. Trying to define those requirements up front ossifies your project and makes it obsolete before you’re even halfway finished. An iterative development process that expects and embraces changes of direction is far more realistic — but it comes at the price of not knowing everything about where you’re going until you get there. How do you write an SOW that fits with that process, yet still provides assurances of value to both parties?

The answer, I think, is to break the project into smaller chunks. You can state general long-term goals up front, but you can only be specific about goals for the next month or week at a time. That means writing a new SOW and getting buy-in from your client for each of those periods. I can hear some of you moaning at that thought. Let me also suggest that the process of writing the SOW will become more streamlined — perhaps it becomes only an email or a stand-up meeting. Likewise also with acceptance. You’re also likely to evolve towards a standard compensation per period. The key to this approach is that both sides gain assurance of value through regular review and the ability to back out at the end of any period. Neither of you has to commit for the long haul, though the longer you work together, the more valuable you’ll become to each other.

And now I will show you a more excellent way: In each of those periods, do more than you promised. Even if it’s only a little more, it will build trust that you are looking out for your client. With that, most clients will in turn look out for you. They won’t take unfair advantage of you, because they don’t want to lose the first honest consultant they ever met. But even if they do, a short project cycle will allow you to get out before they can do you too much harm.