Rethinking the Statement of Work

On this week’s Rethinking Professional Services webinar series, we discussed rethinking the much-maligned Statement of Work. This document has served as a pain-point for professional services teams for decades. My opinion is that our lack of understanding of the intent of this document is a key reasons why projects find themselves in trouble.  My experience has been, that rewriting it with a different focus can led to greater project success and better customer references.

Cart Before the Horse

At IBM, many years ago, I was taught that the role of the SOW was to explain the solution in detail so that the customer couldn’t exploit the ambiguity of solution design and delivery. As a result, we would pump the SOW full of detailed architecture diagrams, methodology workflows, build estimates and project plans. We’d “nail it shut” as my risk manager used to say.

While this appears to still be the prevailing approach, I've come to realize that it is also a restrictive one. Writing the SOW in this was is a highly constrained vision of our project team’s capabilities. This means that we view our team as being fundamentally flawed and to correct these flaws we must provide a systematic and centralized authority to dictate the solution specifics, even before completing the solution design. Is this really what they need?

Why force the project team to deliver a solution conceived during the sales process? This doesn’t mitigate risk, it adds it.

While a completely unconstrained SOW (i.e: let the chips fall where they may) would also be a disaster, wouldn’t we benefit from a more balanced vision? A less constrained approach would recognize that our project teams and the customer are skilled at playing specific roles within the project environment and will shape the solution as they travel the project’s journey of discovery. If we could still provide the required risk mitigations, wouldn't it be better to establish the parameters for the project and set the operational guidelines instead of dictating its final destination?

Detail Affects Change Control Effectiveness

When the SOW says, “The Customer will receive a blue colored widget that is four feet high”, then the customer is expecting a widget to these exact specifications. We may find during the design that a three foot high widget is all that is needed. This would save us money and time, but the effort of changing the customer’s expectation is daunting. Why should the customer accept a three foot high widget? After all, we promised a four foot high widget.

When we set an expectation with specific details, it creates a barrier to changing that expectation in the future because it creates a strong bond between the promise and what the customers think they need. The more detailed the SOW, the more expectations we will need to reset. Each reset of an expectation is a fight that fatigues both the customer and the service provider. This is one of the reasons why we often find teams reluctant to pursue change orders unless they think they are critical.

If we rewrite the previous example as, “The Customer and Service Provider will agree the color and dimensions of the widget during the Design Phase. All available colors and dimensions will be approved by the Service Provider.” This approach allows our team to specify the dimensions of the widget once they know what height is needed. If the customer pushes for a larger widget, there was no initial promise to make the widget any larger, so we aren’t having to back out of a promise.

Backing out of a commercial promise is a form of leverage that the customer will often use against us and it’s a legitimate use. If we can’t guarantee that it will happen, then we shouldn’t have written it into a legally binding document.

This example highlights that projects risk is actually mitigated by leverage, not by detail.

The “L” Word

The “L” word, is Leverage and it is an often unspoken part of the ongoing relationship between service provider and customer as they work together to deliver a solution. The SOW, just like any other contractual agreement, should generate enough leverage for each party to hold the other party accountable to fulfill its role in achieving an equitable outcome.

At CirrusOne, our SOWs were written entirely for the purpose of generating balanced leverage for both parties. A project that runs out of budget is one where the service provider has lost the leverage to have the customer accept the change in price caused by the changing scope. A project that never achieves its goals is one where the customer has lost the leverage to keep the service provider accountable. By balancing the leverage within an SOW we reduce risk because the parties now have a blueprint to which they must comply. This was one of the core reasons CirrusOne was able to achieve a 95% project success rate. 

Over three years we proved that our project success was not a fluke, but a carefully crafted approach to rethinking the way we established and controlled projects.

For a blog post, it’s difficult to go into meaningful detail but we do have a best practice template that details this approach. This week’s webinar recording provides a series of examples, including contractual clauses that we have used in the real world, that help generate this leverage within different parts of the SOW. If you are interested, please contact us and we'll send it to you for free.

Of course, we must learn to sell this approach, just like we would sell any other part of our service. For the most part, this shift creates a differentiation that many services firms are looking for. From the customer’s perspective it is refreshing, if not compelling, to work with a firm who differentiates empty promises from real knowhow. At CirrusOne, over a 3-year period, we won 5 out of 6 engagements where an SOW was presented and the customer made a decision between us and other vendors. It was very easy to compete against firms that jam pack their SOWs with details because we could easily point out that the customer hadn’t given enough information to provide such certainty.

Scratching the Surface?

The truth is, I’ve been amazed at how this shift can affect a project’s ability to be successful. While not fool proof this approach provides a proactive and positive project environment that is very effective.

There is clearly a plethora of options that we are yet to explore when reimagining the SOW. My goal is ignite a passion within the industry to continue to investigate how the SOW can empower teams to achieve success rather than trap them in an outcome that isn’t wanted.

What do you think?