Would you like to be more profitable?
Digital Agencies have come a long way and most of them (at least those that have been around for some time) have gone through or are in the middle of going through a transformation from Fixed Price contracts to Time and Material contracts with some of their clients...
In other words, they are moving from a high risk / high reward to a low risk / low reward model. Fixed Price contracts are high risk because the agency promises to deliver something, to a specific price at a specific time. If the agency keeps within those boundaries or, even better, uses fewer hours to complete the agreed project, then the reward is high (if you haven’t undersold yourself, obviously). However, if the agency breaks one of the three legs, that often has a severe negative effect on the reward; therefore the risk is high.
Transitioning to the Time and Materials model changes all that. The risk is low, as you are selling a team for a set period to a fixed price. Very few things can go wrong here as you are being paid just to show up (most likely only a one-time payment if all you do is show up). However, the reward is low, as you just get paid for the hours you put in, regardless of the quality or speed of your work.
The ‘issue’ is, why should the client reap the benefits of your team’s increasing velocity?
I’m playing with the idea of Value Based Contracts. I must admit I have not tried them myself yet, but I believe they potentially could be a better deal for both the client and the agency.
Value Based Contracts fit nicely into most agency setups that are running some form of Scrum framework for their projects. They are based on story points. I’m sure most of you are familiar with Story Points but here’s a brief example that I really like:
Story points are estimates of work influenced by the amount of work, complexity, risk and uncertainty.
Imagine your athletic friend asks you to go for a run with him. You decide to run down to the lake. You might think: ‘I’m not 100% sure about the terrain but it’s somewhere between 4 and 5k, and there are quite a few crossings on the way there, oh and I haven’t run for weeks; God knows what running shape I’m in.'
Giving a time estimate for this run is not straight forward.
From your friend’s point of view, a time estimate is very straightforward: ‘I’ve run this route for years, I know 100% where I’m going and how fast I can run this one … easy to estimate.’
But you can both agree that a route of this amount of work, complexity, risk and uncertainty is equal to 3 Story Points, or 13 Story points, or 6 Story Points, it doesn’t really matter, what matter is that you both agree to the same value. That is your baseline for all other Story Point estimates going forward.
Next time you go running with your friend, the destination is the forest; you can now estimate that run relative to the baseline run. The forest run feels like it’s a bit longer and there are certainly more risks around it. So you decide that relative to the baseline this is a 5 Story Point run.
Back to the main point. Before your sprint starts, you would agree the sprint length with the client (or tell them: ‘this is how it’s gonna be’). The team feel they can deliver a total of 100 Story Points in a sprint, and the client agrees to that target.
You price per story point should be: Cost per day per team member x anticipated sprint days x your agency target margin / number of target story points per sprint.
That way your Value Based Contract with the client set is to deliver the value of 100 Story Points per sprint. Most clients prefer to operate with a max budget, the max budget should be set in Story Points and could be converted to money as per the formula above.
The risk is medium, as if you go under 100 Story Points, you will get paid less for the time your team has spent, but the reward is also medium if you hit the 100 Story Points before you planned to. Say, one of your developers could spend the time on upskilling, helping others, developing for another client or kicking back. Whatever is most helpful for the agency.
As with most consistent scrum teams, the goal is to increase the velocity over time. That is exactly what we are hoping for here as well, but with this model the agency gets the positives out of it and not the client. Of course, the trade-off is less money should the team underperform.
Most teams I’ve worked with share the same trend, it starts at a moderate pace, but over a few months the team (if kept consistent) picks up pace and quality. My thesis is that this model will be more profitable for agencies in the long run. I will share my results if I get a chance to try this.
One disclaimer: only attempt this on longer-running contracts, as the ramp up in velocity could be delayed in some instances.
Looking forward to hear your thoughts on this!
LAB is a specialist London-based web development agency - get in touch to see how we can help
- Is it time for us to move to value-based projects?