[Off-Topic] Negotiable Scope Contract

In my recent talks on agility I explain the difference between Fixed-Scope Contracts and Flexible or Negotiable-Scope Contracts.

In classical project management, there’s the image of the Cost × Time × Scope triangle. The objective of traditional mechanisms is to try to keep all of those points fixed and predictable. PMBOK is precisely a body of knowledge with that objective.

Today we know these mechanisms don’t work the way we’d like. The premise of “control” runs into one detail: real control is impossible, and the bigger the project, the more illusory it gets. We are not fortune tellers. We don’t have the power to predict the future. We laugh at the palm reader, yet we’re the first to think we can nail a 2-year project down to the detail.

Fixed-Scope Contracts are a necessity of classical project management, and their objective is a single one: to legally get a neck to squeeze. It’s the naive thinking that if the project goes wrong, it’s the vendor’s fault. Just charge the penalty and you’re done. It looks like a clever win-lose setup.

In practice it’s the definition of lose-lose. By the time you find out the project is heading to disaster, you’ve already lost many months. Even if the vendor pays the penalty, the client is left without the product, has lost time-to-market, and has paid the opportunity cost. Very large companies take longer to feel it, sometimes years, but the bill eventually comes due, and by then it’s too late.

Agility, on the other hand, requires a Negotiable Scope Contract, precisely because collaboration is a two-way street. Some clients think agility means nothing more than extra productivity and a delivery guarantee. Nobody can guarantee delivery, but you can guarantee a drastic reduction in risk.

Instead of waiting a full year to see if the project worked out, the client can tell as early as the first month whether things are heading in the right direction. Reducing risk means, worst case, losing a month or two instead of a year or two. The concept is win-win: I gain and you gain along with me.

That depends on a bond of trust between the parties, a bond that doesn’t need a contract amendment at every move. Plenty of clients balk at this because they have to work too; the process runs on collaboration. That’s the only way to guarantee real success on a project.

When people ask me about this, I strongly recommend reading the article Negotiable Scope Contract, from Improve It, written by none other than Vinícius Teles, one of the greatest XP authorities in Brazil. It’s a long read but worth it, since it breaks down every doubt in detail. He even left a contract template available for anyone who needs something practical.

I’m also asked how to convince a client to follow this model. Unfortunately I don’t think anyone has that answer (otherwise we’d be broadcasting it already). For now the only way is to first master every concept of agility, and I mean all of it, not the surface, because your client will have questions and you’ll need to answer them. It’s genuinely evangelization work.

Another technique is to offer two contracts: one fixed and one negotiable. The difference is that the fixed one will cost at least two or three times more than the negotiable. You need to explain the reasons. Technically, the fixed-scope contract carries much higher risk. In the negotiable one, risks are minimized.

Maybe the client’s biggest worry is the absence of fixed scope: “But if the scope isn’t fixed, doesn’t that mean I get less for what I’m paying?” That takes more argument. The central point is convincing them that neither you nor the client has the faintest idea what is actually needed. By starting the project with whatever is most prioritized, you guarantee that everything that matters gets delivered first.

Many studies show that up to 60% of the software delivered is never used by the client, indicating the monstrous quantity of features that were thought to be important but proved not to be.

The clients most open to this are the ones who value their own money. Smaller companies tend to resist less: they don’t have the time or the money for a six-month circus of “requirements gathering,” they need value delivered fast and at the best cost-benefit. The other day I heard about a consultancy running six-month sprints where the first “sprint” was requirements gathering. Yeah, hilarious :-)

Companies that are too big have too many layers of managers who don’t own the capital and don’t execute, and care only about climbing the ladder. Real results don’t matter to them. For that type, a fixed-scope contract matters even more, because they need someone to pin the failure on.

Explaining agility to that crowd is usually a waste of time. The justification is that traditional managers are needed to keep control. But if the premise is that control is illusory, traditional managers are dispensable. And they really are, but that’s for another article.

Anyway, I know it’s not easy to sell truly agile projects with negotiable scope, but we have to keep trying. I also know it’s hard to keep turning projects down, but if it’s obvious the client just wants a neck to grab, walk away. You don’t need that kind of project, the kind that delivers nothing but headaches.