Agile Fixed Price Contracts

Agile fixed price, sounds like a bit of a contradiction but as our role is to look after our organisations interest we have to try and push the boundaries

Being a procurement contractor means being flexible with your skillset. Recently I worked on a role that was more IT based, and though it’s slightly different to buying professional services, it’s not a million miles different.

There are some slight nuances and here I’m going to share what I learned about fixed price contracts for IT projects.

Before I start I’m going to borrow some wording from the dummies guide

Cost is a project’s financial budget. When you work on an agile project, you focus on value, exploit the power of change, and aim for simplicity. Agile Principles 1, 2, and 10 state the following:

(1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

(2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

(10) Simplicity — the art of maximizing the amount of work not done — is essential.

Because of this emphasis on value, change, and simplicity, agile projects have a different approach to budget and cost management than traditional projects. This table highlights some of the differences.

Traditional versus Agile Cost Management
Cost Management with Traditional Approaches Cost Management with Agile Approaches
Cost, like time, is based on fixed scope. Project schedule, not scope, has the biggest effect on cost. You can start with a fixed cost and a fixed amount of time, and then complete requirements as potentially shippable functionality that fit into your budget and schedule.
Organizations estimate project costs and fund projects before the project starts. Product owners often secure project funding after the product roadmap stage is complete. Some organizations even fund agile projects one release at a time; product owners will secure funding after completing release planning for each release.
New requirements mean higher costs. Because project managers estimate costs based on what they know at the project start, which is very little, cost overruns are common. Project teams can replace lower-priority requirements with new, equivalently sized high-priority requirements with no effect on time or cost.
Scope bloat wastes large amounts of money on features that people simply do not use. Because agile development teams complete requirements by priority, they concentrate on creating only the product features that users need, whether those features are added on day 1 or day 100 of the project.
Projects cannot generate revenue until the project is complete. Project teams can release working, revenue-generating functionality early, creating a self-funding project.

Based on the above Agile lends itself to a time and materials billing arrangement, but for us procurement professionals we want fixed budgets or fixed pricing.

Suppliers probably think procurement folks don’t get it, most IT buyers will get it straight away but for procurement professionals who occasionally dip their toes into the IT world, I’m going to delve into the ways to get a firm fixed price using a semi agile approach.

A firm fixed price contract means the buyer has a budget in which they will not exceed and this is written in to the contract as the price for either the contract or the scope of works. When looking after our organisations interest we will also try and fix the scope so that as many project deliverables are included within a fixed schedule.

In an Agile project environment the project flex’s to manage and welcome changing requirements, being Agile means getting the best outcome even if the changes are made late in to the day.

As a buyer most procurement professionals are not concerned with changes, but these changes must be accommodated within the fixed price contract and must not affect the set of agreed deliverables. This makes it difficult for suppliers to deliver an agile project against a fixed price. There is a balancing act between the supplier and the client to agree what can and can’t be changed in the original scope.

How do procurement professionals get the best of both agile plus a firm and fixed price?

  1. Invite suppliers to submit an RFP or ITT to understand the value proposition
  2. Issue a contract for a fixed price
  3. Start the project and define the goals in more details
  4. After the project kicks off;
  5. Define what success looks like
  6. Price is fixed for known elements and determined scope, if new complexities or scope changes are found outside of the fixed price, de- scope features that will not lead to project success and re-scope activities
  7. Continuously estimate the cost and schedule against the agreed milestones
  8. Request for a CCN for authority to modify the project scope (no material changes allowed) within the fixed price and fixed schedule
  9. Be clear on expectations. Quality can be abstract and not necessarily prescriptively written down in the statement of works. Agree with the supplier what the ‘definition of done’ actually means. Use an Acceptance Criteria or certificate.

Sometimes it’s too difficult to project cost too far in advance. Even procurement can’t accurately forecast future needs which means that the specification can be very much outcome based but on future fuzzy requirements. The best option is to fix parts of the project price into different scope of works.

Once the project is initiated and to a certain extent detailed analysis completed or sufficient knowledge is gained, the next phase should be re- baselined or tendered as a new contract.

What are the other options to maintain a fixed and firm price?

Flexibility is key. By adopting a pragmatic approach where the client supplier relationship is built on trust when re- baselining cost, work together to find the gap between fixed constraints. If it’s not fixed consider what trade-offs can be made.

If a new requirement crops up but it has a cost impact then consider swapping it out with a product backlog item of equal or greater size.