[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 that these mechanisms don’t work the way we’d like. The premise of “control” is that it’s impossible to truly have control. And the worst part: the larger the project, the more illusory these mechanisms become. For starters: we are not fortune tellers. We don’t have the power to predict the future. We laugh at fortune tellers, yet we’re the first to think we can predict a 2-year project with precision.

Even more, Fixed-Scope Contracts are a necessity in classical project management. Their only objective is to legally get someone’s neck to squeeze. It’s the naive short-term thinking that if the project goes wrong, it’s the vendor’s fault — just charge them the penalty and move on. It sounds like a clever win-lose scenario. But in reality it’s the definition of lose-lose, because by the time you discover the project is heading to disaster, you’ve already lost many months. Even if the vendor pays the penalty, the client still ended up without the product, lost time-to-market, and paid for opportunity cost. This type of contract is treacherous for both sides. Very large companies take longer to feel the pain — sometimes years — but eventually that cost will be collected, and by then it will be 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 more productivity and delivery guarantees. That’s not true. Nobody will ever be able to “guarantee” delivery, but we can guarantee a drastic reduction in risk. Instead of waiting a full year to see if the project succeeded, the client will be able to tell — perhaps by the first month — whether things are genuinely heading in the right direction. Reducing risk means, in the worst case, losing a month or two instead of a year or two. The concept is win-win — I gain and you gain together. A bond of trust needs to be cultivated between the parties, a bond that doesn’t require contract amendments at every move. Clients don’t like this because they also need to work, since the process requires collaboration. That’s the only way to guarantee true project success.

When people ask me about this, I strongly recommend reading the article Negotiable Scope Contract, from Improve it, written by none other than Vinicius Telles, one of the greatest XP authorities in Brazil. It’s a long read but worth it, as it breaks down each of the doubts in detail. He even made a contract template available for those who need a practical model.

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). The only way for now is first to master all the concepts of agility — not superficially, but truly everything — because your client will have questions and you’ll need to answer them. It’s genuinely an evangelization effort.

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.

Perhaps the main concern a client has regarding the absence of fixed scope is: “But if the scope isn’t fixed, does that mean I’ll get less for what I’m paying?” That requires more argumentation. The main argument is convincing them that neither you nor the client has the faintest idea what is actually needed. By starting the project with exactly what is most prioritized, you guarantee that everything important 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.

Clients who are most open to this are those who value their own money. Smaller companies should therefore have less resistance, since they don’t have the time or money for the circus of six months of “requirements gathering.” They need value delivered quickly with the best cost-benefit. The other day I heard about a certain consultancy running six-month sprints where the first “sprint” was requirements gathering… yeah, hilarious :-)

Companies that are too large have too many layers of managers who don’t own the capital, don’t execute, and are only interested in climbing the corporate hierarchy. They don’t genuinely care about results. For that type, a fixed-scope contract is even more important because they need someone to blame for failure. It’s usually a waste of time explaining agility to those types. The justification is that traditional managers are necessary to maintain 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 should always try. I also know it’s hard to keep turning down projects, but if it’s obvious the client just wants a neck to grab, walk away. You don’t need that kind of project that delivers nothing but headaches.