Project Management

Statement of work: essential or useless?

Chip Camden advises on how to write a statement of work that fits with an iterative development process, yet still provides assurances of value to the client and to the consultant.

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.

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

10 comments
Steve Chipman
Steve Chipman

Chip - this makes perfect sense. We're in the CRM implementation business and have made a big effort to chunk the SOWs.

Traditionally, CRM buyers have asked prospective implementation partners for up-front project estimates. However, as CRM systems have become more and more capable, in the absence of detailed requirements, this type of estimate has become an increasingly wild SWAG.

So, we recommend that the first SOW is for a limited engagement that we call "reqs & specs" - business requirements plus functional specifications - even before they commit to a specific CRM solution (the CRM ISVs don't love this, but the process ends up ultimately working in their favor).

We suggest to buyers, "why not start with a limited engagement, since this part is something you're going to need to do sooner or later anyway? By doing this first, you'll minimize risk and take the SWAG out of the implementation costs."

Despite the fact that this seems like a no-brainer approach from our side of the fence, it takes some conversation to change buyers' thinking. However, most people come around when the approach is presented properly.

Curtis_Wayne
Curtis_Wayne

Not much to add - very well stated and succinctly summarized. Great comments from others too. Can I borrow some of the statements herein to help me communicate the concept to customers? I'll be sure and reference you all ... or restate it in my own words and take the credit ;) Scope & expectation managment is at the heart of all projects, just a bit more so w/ software design and development. As the users & process owners get their hands on anything half functional, their vision melds into a new direction. It sure seems that EVERY SINGLE project follows the ever evolving path, challenging all project managment methodologies - requring the combination of key useful components from various approaches, as needed. Especially since no 2 projects ever evolve the same way. I have a salmon run waterfall approach I coined, because each step always involves a hgihly likely jump back up the flow, hopefully only 1 step back though!!! (the further the jump back, the more expensive to the process). Doing this inside a rapidly cycling loop involving SOWs at each cycle is very appealing. Selling the client on it likely requires experiecing at least 1 iteration. Therein lies the rub. Performing as much on the fly w/ process owners in person is extremely effective I've discovered. And the better the tools get w/ rapid interactive querying and GUI layout, the more feasible this becomes. The only part that gets expensive is trying to include multiple developers simultaneously, although the payoff has been huge when it's been possible. Enough on that ... I'll have to write my own paper! Enjoy!

alan.douglas
alan.douglas

@ stubones99: You're confusing the SoW with an RFP's requirements list, but your basic premise is sound ... The SoW is the agreement that's signed between the tenderer and the winning bidder, taking into account the final, negotiated parts of the RFP plus any afterthoughts. You have to use a formal process to request changes as well as settle the request, detailing the additional time, cost and/or (wo)manpower required to implement the change as requested. Remember, scope creep is a bad thing, and will cause ill will on both sides.

holarsen
holarsen

I completely agree with Stubones99 above here - the SOW is essential to avoid Scope-creep from the consultant's pow, and should in fact guarantee the customer that they get the results they are hiring for. If I had a penny for each Scope-creep my SOW's have caught, I'd be a rich man... :) Also the SOW becomes the primary source for incremental business, as new ideas and changes are integrated/implemented - but at a (reasonable) cost. Being a good consultant doesn't mean giving consultancy away - It means delivering what you have agreed with you customer at the time and cost agreed on at the outset.

stubones99
stubones99

Part of your SOW language should be how to amend the SOW. No deviation from the SOW without an Engineering Change Order (or ECO) or some other negotiated change document that effectively modifies the scope or directions of the SOW. An ECO can be drafted by either party, but has to be agreed upon by both parties and may include the financial impact of the change. Once both parties agree on the SOW, and any follow-on ECO's, your project should go well As I was told by my uncle (a well respected lawyer), "You don't write contracts for the days when the sun shines, but instead for the days that storm." and I agree with him. A SOW is important that makes all project bidders bid on the same job. Otherwise you could tell one bidder one thing and another bidder something different. If your company requires 3 or more bidders, the SOW will save time on the walk-thru since they all have the same orders. Make sure there an an avenue to add information to the SOW, since some vendors will point out omissions or oversights using their particular knowledge, for example necessary wire gauge for long power runs, etc. That might have been overlooked in the SOW drafting. The better you draft the SOW, the better competent vendors can create what you want. Every SOW needs to have a start and end date, and possibly milestones, depending on the duration and complexity of project. If completion payments are scheduled, the vendor needs to be complete on specific sections to get paid. Anyone who treats an SOW as unnecessary in my mind is suspect. If your project is a 20 foot CAT5 cable run from point x to point y, it still needs to be defined that it be done with CAT5 cable, not CAT3, and how you want the cable terminated on each end, and dressed along the run. The SOW should define that all ceiling tiles should be replaced neatly and not broken in the process and all waste / trash cleaned up. Project documentation like a SOW is your friend, regardless of where you stand in the project. If you are the stakeholder, you get to define what you want done and by what date. If you are the vendor, you know what has to be done, how it needs to be done and when, and who does what and supplies what materials, and when you are actually done.

avindia
avindia

Good Tips Break projects in subprojects look for short term deliverables/goals Even you write what is in Scope and what is not, it is important to create rapport with your client.Client shotould understand what to ask for SOW is must for Service Transition when your outsourcing internal IT to external Vendor otherwise both Client and Vendor can take undo advantage of it and start with blame game.

sjoec
sjoec

This post really hit home for me. With my most recent "new" client engagement I did just what I'm seeing recommended here. I broke down the long term expectation as I understood it into a bite size piece and first deliverable (which as it turns out, was a detailed proposal outlining an approach toward the desired long term goal as I understood it.) I'm a firm believer in the iterative approach to development, but I also believe that for a win-win relationship where both consultant and developer receive value, defining and delivering these bite-size chunks of a project works. As of this writing I am still waiting for the client to decide whether to take the next step. In the meantime, I have delivered what I promised, I have been paid for it, and am actively working exclusively on completing a long term contract with a major client. I like knowing that, at least for the moment, I can focus completely on the active project - which by the way, continues to be iterative as their business needs continue to change, and as they identify and define immediate needs. Our agreement (essentially a SOW), specifically states that items identified as non-contract related will be billed separately.

Tony Hopkinson
Tony Hopkinson

approach. Setting an expectation on day one for a non-trivial project, despite everybody knowing that the expectation will evolve over the lifetime of the project is managing the dashboard not the expectation. A truth everybody needs to understand, not just consultants.

Sterling chip Camden
Sterling chip Camden

Of course, the hardest part of selling the iterative process is getting the client to buy into the unknown. But if you present it as the only realistic choice, I think you can succeed. What do you think?

Sterling chip Camden
Sterling chip Camden

The most important thing is that both of you are happy with the arrangement, and unlikely to have your expectations disappointed. Great job!

Editor's Picks