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.
- 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).
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).
- 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).
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.