Using Scrum for Fixed Price Contracts

Using Scrum for Fixed Price Contracts

The first question I usually get when teaching or preaching Scrum is “Sounds nice, but you surely can’t use on a Fixed Cost/Price contract, can you?” Well, let’s see.

Note: for this article’s context we will assume that your company is implementing IT projects for external customers.

 

The problem with contracts

The problem with contracts is that:

  1. You have to keep them, and
  2. You can’t change them

Why not? Because contract change usually requires escalation to top management and involves a lot of people not directly related to the project implementation, like Sales & maybe Legal (your side) and Procurement and maybe Legal (customer side).

 

The problem with Fixed Price contracts

A Fixed Price/Cost contract is created to legally bind a supplier with a customer, fully defining all three basic project aspects: Cost, Time, and Scope. The problem with this type of contract is that it assumes full predictability on all three aspects, something that is, in all but the simplest projects, not realistic. The reason Fixed Price contracts are the norm is that Customers prefer them, falsely believing that they transfer the risk to the supplier (i.e. if the project proves to be twice more difficult than originally expected, it’s the Supplier’s problem –or so they think).

 

Is it really Fixed?

So, a Fixed Price Contract has a Fixed Price, a Fixed delivery deadline, and a fixed scope, right?

NO.

Let me explain:

As contracts are usually signed well before the project has really started, the scope is not, can not be adequately broken down, analysed and clearly defined. What is usually included as “Scope” is a bunch of high level requirements that will be later refined (during the “Requirements”/”Analysis” phase of the waterfall model). Of course “later on” is too late for readjusting the cost, as the price has already been fixed. So what really happens is that after analysis (and/or even later on) the Project Managers of the supplier and the customer, fight, threat, negotiate and finally agree on the real scope of the project (as opposed to the one defined in the contract). In essence they silently change the scope of the project, without altering the actual project documents.

 

Can you use Scrum for Fixed Price Contracts then?

Of course, but first you have to accept (both supplier and customer should accept that) that scope is not, can not, be adequately defined in the contract.

Then

  1. Do a partial analysis, to find out what are the absolutely minimum requirements that will barely cover the “high level requirements” included in the contract. No extra functionality, no additional interfaces, no fancy UIs, just the essentials to cover the contract “scope” and get it off your back.
  2. Turn these requirements into a Product Backlog, and implement it using Scrum.
  3. After this has been implemented, run more sprints to enhance your product with all the additional functionality that will make the project acceptable, successful or absolutely great (depending on the time you have left on the contract).

 

Is this as easy as it sounds?

Yes, as long as you keep the following rules:

  1. Do it with someone you trust. This approach requires a small “leap of faith” from both sides, particularly the customer side, so it’s better to do it with an existing and “good” customer, one that knows you well and trusts you. Do not try this with a new customer.
  2. Find a reliable Product Owner. Turning the contract “scope” into a workable Product Backlog is no small feat. It is essential that the customer provides for this role a person who has the business domain expertise, the required technical knowledge, and the authority to take scope decisions. Finding the right person might be the most difficult part of the process, the first time you do this with a customer. Do not settle for someone less than the right person, and next time will be much easier.

 

Can you use this method with Public Sector RFPs too?

Absolutely, as long as you find a suitable and willing Product Owner (which is much more difficult in the Public Sector), and an executive sponsor that understands the basics and accepts Scrum. Despite the more conservative/waterfall wording needed in these types of contracts, Scrum can (and should) be explicitly stated as the implementation framework. Have this, and you are on for a successful Public Sector project that will stand out from the rest.

 

Are there other contracts I can use when using Scrum?

Of course, you can use Time and Material, Cost Reimbursable, or any other contract type that does not attempt to define scope and price before the project start.

Scrum

All photographs by Christos Georgalas (christosg.org)

 

Conclusions

Fixed Price Contracts, much favoured by the market, are designed to transfer the implementation risks to the Supplier, making the application of Scrum appear difficult. However, their vagueness in scope definition, along with a certain degree of customer trust, can allow you to execute them using Scrum and enjoy all the benefits that come with it. As a Project Manager I never thought I would write this, but, as far as contract scope definition is concerned, Vagueness is your friend!

 

Dimitris has been practicing, teaching and preaching Agile and Scrum since 2011. He holds a degree in Computer Science, a PhD in High Performance Computing and a MBA. He has considerable experience in the Software Industry as a Project Manager and a PMO head. He is a certified PSM I and PSPO I. In 2016, Dimitris founded AgileForValue.com.

Twitter LinkedIn 

  • http://about.me/vantoniadis Vagelis Antoniadis

    I totally agree with you Dimitris and I would like to point out a bit the “leap of faith” part. Yes trust is crucial and trust is something you build over time. The most important arguments in order to start using Scrum with a client who is used in fixed price/fixed scope projects have to do with transparency. Scrum is all about transparency and if you can convince the customers that they will know exactly where their money goes and what value is created from every sprint, they will start thinking differently about scrum.
    But, there is always a “but”, here comes the involvement part. Most of the customers don’t care about transparency because they don’t really want to get involved in the process. They just want to receive the deliverable they have in mind at the end of the project, pay the agreed amount of money and that’s it. This doesn’t happen because they are lazy but because they have different priorities and no time to spend on participating in the project.
    So the bottom line is that the leap of faith is all about trust and this trust will give you the time to prove to the customers that it is for their interest to be really involved.

  • http://agilegreece.org/ Agile Greece

    Comment from Vagelis Antoniadis:
    I totally agree with you Dimitris and I would like to point out a bit the “leap of faith” part. Yes trust is crucial and trust is something you build over time. The most important arguments in order to start using Scrum with a client who is used in fixed price/fixed scope projects have to do with transparency. Scrum is all about transparency and if you can convince the customers that they will know exactly where their money goes and what value is created from every sprint, they will start thinking differently about scrum.
    But, there is always a “but”, here comes the involvement part. Most of the customers don’t care about transparency because they don’t really want to get involved in the process. They just want to receive the deliverable they have in mind at the end of the project, pay the agreed amount of money and that’s it. This doesn’t happen because they are lazy but because they have different priorities and no time to spend on participating in the project.
    So the bottom line is that the leap of faith is all about trust and this trust will give you the time to prove to the customers that it is for their interest to be really involved.

  • Pingback: Using Scrum for Fixed Price Contracts - Agile G...()