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: 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”...