Using Scrum for Fixed Price Contracts

Return to site

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 contracrs

The problem with contracts is that:

You have to keep them, and
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, 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

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.
Turn these requirements into a Product Backlog, and implement it using Scrum.
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 it as easy as it sounds?

Yes, as long as you keep the following rules:

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.
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 for Public Sector RFPs?

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 contract types 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.

Originally published at agilegreece.org. Photo kindly provided by Christos Georgalas, christosg.org