Fixed price is dead.

Before signing up to a ‘fixed price, fixed scope’ contract, we - as an agency - need to know what we’re getting into. That means having enough information to be confident that we’re not making a big mistake in terms of time and budget. So we need to understand the project scope, in full. There are plenty of cautionary tales of what happens if you get this wrong - just ask Airbus, or Carillion (who are no longer in business as a result of their fixed price cockups).

For short term, straightforward projects, fixed price can work well because we’ll probably have a clear understanding of what you’re after (for example, building a research report).

In these cases, fixed price contracts provide several benefits - you as the client know what you’ll get, when, and how much you’ll pay. Your agency focuses on delivering what they’ve committed to.

Fixed price projects can also work for bigger, more complex projects, but the devil is in the detail which means they require a lot of upfront documentation. And, there are big risks: requirements can be misunderstood; what you thought you needed to build doesn't solve the issue or isn't the best solution; technical complexity is misjudged; external factors can dictate new priorities and so on.

They also create an unhealthy tension. There’s clearly an incentive for agencies to finish ASAP to make more profit (and definitely a need to avoid losses by limiting overruns) whilst clients want to squeeze in as many tweaks and iterations as possible because they aren’t paying extra for them and they think it’ll make it better - not the recipe for a good, collaborative team.

Consider a process as (apparently) simple as producing designs for new web pages. How do we handle design sign-off? Does the contract include rounds of review and amends? How many? What happens if there still isn’t agreement once they’ve been exhausted? How does a contract define what “done” looks like?

The agile manifesto came about (in 2001) because it can be more effective to iron out the detail as you go rather than trying to understand and write down everything upfront. Not setting things in stone from day one also allows project scope to flex over time, which is an important consideration for any project that could be running for many months. The manifesto advocates for producing just enough documentation and running regular short feedback loops, to build at pace and define as you go.

We agree.

Agile contracts mean you’re buying inputs (time) from your agency partner - this is referred to as a ‘time and materials’ (T&M) contract. There’s an obvious issue with this: organisations do not have limitless pots of money to spend on a digital project. Budgets are set annually. Milestones to launch new digital services are driven by external factors (e.g. the launch of your new brand, your annual conference, etc.). You want confidence that your money will get you what you need.

Cue ‘Capped T&M’, all the benefits of an agile contract (delivering working software early, reacting to change, learning from feedback, defining and building the right things at speed, etc), but with a fixed budget and often a fixed launch date. This is the most common way the UK government commissions digital projects and it enabled us to change our scope of work several times during the four months we worked at the Department for International Trade last year, which was vital because of the changing Brexit timetable.

We use capped T&M contracts to deliver almost all of our projects (recent examples include Sue Ryder’s online bereavement counselling service, Samaritan’s webchat and MQ’s Participate service).

Sounds great, or does it? The problem is that despite the budget being capped, just buying time can still feel risky. How do you know, upfront, the features you’ll end up with? Or that the new service will meet the majority of your requirements?

It all boils comes down to how you structure your contract and approach your agency relationship. There are tried and tested approaches to de-risk this type of working and contract. 

Here's a few to think about:

For big custom build projects the GDS service manual phases of an agile project is a great place to start. We often contract separately for each phase. If you’re looking to build a new digital product, consider starting with a Design Sprint.

Your product owner has a vital role to play: holding the agency to account; planning each sprint; monitoring progress; unblocking the project; testing and accepting work; and refining the backlog. The more dedicated your product owner, the better the results.

We make this a fundamental part of every project. It means we’re aligned on what success looks like, and we're guided and motivated by the same goals (e.g. we can handle design sign off far more effectively when our goals are aligned). Consider creating live KPI dashboard (e.g. in Google Data Studio) and using impact mapping.

We aim to allocate max 70% of the budget on the first major release, leaving 30% for ongoing improvements.

In the short term, we forecast what will be delivered using sprint goals. We use roadmaps to make sure what is being built aligns with our clients’ wider strategy. Flexible scope contracts enable us to remain user centred, continuing to learn and react to evidence throughout the build.

At all times both client and agency know what will be worked on when, and how much budget will be spent.

The proof is in the pudding. We always recommend speaking to our clients about their experiences working in this way before we sign any contracts.