Scope Limbering

One of the basic tenets of agile development is that requirements changes aren't just expected, they are welcomed. This poses a particular challenge when an external company, like Thoughtworks, is doing work for client. Many clients want a FixedPrice arrangement, which is really fixing scope because they see the FixedScopeMirage. But a fixed scope contract is totally at odds with agile development, so what is a company like us to do?

Over the last year or so we've been pretty successful at what I call Scope Limbering - starting with a fixed scope contract but working with the client to help them understand the way agile development works to overcome the FixedScopeMirage.

To illustrate, here's a specific example with a client that I'll call Nebbiolo. As is often the case with our work, we came in because another delivery company had failed (you'd recognize their name, but I'll spare their blushes). They'd spent a long time gathering requirements but got nowhere with development. So the client had detailed requirements which had cost a lot of time and money, and were feeling rather sore from the other firms inability to get things done. So they insisted on a fixed scope arrangement, based of course on those detailed requirements.

We took a look at those requirements and estimated it would take us about half a million dollars to build it. Like most people tackling a fixed scope project, we added a buffer - in this case quite a large buffer doubling it to a full million. This was still less than the original contracting company's estimate. (We charge much higher daily rates for our people, but since we have better and more productive people, we can actually do the job for less.)

We weren't at all shocked to discover that despite the detailed and heavily reviewed requirements, the requirements changes still came thick and fast. For each one we estimated the scope of the change and figured out how much it would cost, but didn't charge the client for the change. Slowly but steadily the changes ate up the buffer. After about six months or so the changes had used up the buffer completely. We'd been quite open with Nebbiolo during this whole time, so they weren't surprised when we told them that we couldn't afford to eat the cost of the changes any more. During that time we'd collaborated closely with Nebbiolo and they'd grown to trust us. We had no problem finding more money, indeed it took another half million to cover the requirements changes that were needed before we delivered.

At the end of all this Nebbiolo agreed that the fixed scope approach was a mirage, and we would do future projects together using a more flexible charging scheme.

I think the key to this story (and we have half a dozen similar examples) is that from the beginning we sought to put the relationship between our companies on a collaborative note rather than a confrontational note. The biggest problem with the fixed scope contract is it immediately pits the client and contractor on opposite sides where they are fighting each other about whether something is a change and who should pay for the change. An agile approach hinges upon replacing that confrontation with collaboration (customer collaboration over contract negotiation).

A tripling of actuals over initial estimates isn't unusual in our industry. Mostly I believe this isn't because we are so bad at estimating (although we aren't exactly stellar at it), but it's mainly because it's so hard to get a decent set of requirements. Many delivery companies take advantage of that by low-balling the initial bid and making profit on scope changes. But this approach sours the ongoing relationship with the client - which leads to the whole industry gaining a bad reputation. The story of Nebbiolo is one way to arrange things to keep the relationship in good shape, and I think we need more that for our whole industry.