How the good/fast/cheap tradeoff really works

If you’ve worked on any technology project you may have run into the project management ‘iron triangle’. It's often used to illustrate the various priorities and constraints affecting a project.

For instance, to try and explain to a client why they can't have All The Things, for That Budget, by next Tuesday.

Good/fast/cheap: pick two

You can’t have everything. If you want it good and fast, it will be expensive. If you’d rather have fast and cheap, expect it to be pants. If you want good and cheap, you’ll have to wait a while.

That's the simple version, anyway.

The idea is that you get your client (or project sponsor) to tell you which of these things are most important to them. Then you can plan the project in line with their wishes.

The problem is, nobody wants a product that’s pants, or slow or expensive. So it’s kind of hard to get a client to tell you which wish they can do without.

The project management triangle is really about constraints, not wishes

No one has an endless budget. Even if they have all the funding in the world, there's a limit to what they're prepared to spend to get this thing. So everyone cares about the cost, but they don’t need ‘infinitely cheap’. They need ‘cheap enough’.

Same with functionality and time. There’s a minimal set of features that can deliver the desired benefits. There’s usually some deadline in mind for when the benefits should come on stream.

So what people need is something that’s good enough, fast enough, and cheap enough for their purposes. They really do need all three elements. Which is why it's hard to get people to pick only two.

So all three elements - functionality, time and budget - act as constraints on the project.

If you constrain one element, that affects the other elements too

This is because they're interlinked.

If you fix time, you also limit the functionality you can build. You can bring on more people, but after a while, they just get in each other’s way. There's no point in throwing endless budget at the problem - even if you have it. A set deadline tends to limit both functionality and cost.

If you fix a budget, you’re also limiting time and functionality. There's a limit to the hours of work you can buy. Development teams have a floor limit on how slowly they can work. There’s a limit to what you can build with the hours available, even if you lower your standards.

If you fix the functionality you want, that tends to push things the other way. You will need to throw unforeseen amounts of time and money at the project to get the features you want. But nobody has infinite amounts of time and money so this scenario rarely works.

Ignoring this reality is an easy way to wreck a project

Many projects have gone wrong because they started by fixing the functionality. Humans are terrible at estimating, so the budget and timeframes are usually unrealistic.

Costs spiral out of control. The launch date disappears into the distance. If the project does eventually go live, it's often with a fraction of the functionality that the client insisted on at the beginning.

Many projects try to manage this risk with ‘fixed price’ contracts. The idea is that the supplier takes the risk from underestimating. To cover this risk, the supplier whacks on a hefty premium. This is usually not enough to cover the cost overruns. Suppliers aren't any better at estimating than you are, especially when they’re trying to win a budget-conscious client. So the delivery team ends up working stupid hours to build the thing. Result: a totally pants product.

Focusing on the wrong constraint is also a great way to wreck a project

Time is usually a constraint, but it’s nearly always a made up one. Some businesses do have limited windows in the year when they can safely deploy updates. But more often the client picks a date at random. And then cling to it like it’s the most important date on earth.

If you ask a project sponsor what really matters, they talk about process improvement, or innovation, or delightful customer experiences. But what they actually care about is hitting the deadline that they promised their boss. So everyone works silly hours and the delightful customer experience goes flying out of the window.

No constraints can be pretty disastrous too

The thing is, at least constraints get you moving. They force you to make decisions about what’s important and what to cut. They help you get the thing out of the door and into the hands of users where you can see if what you built is useful.

I worked on an international project once. The conversation about data exchange formats had been going on for years. There was no testing - just documents and reviews - so the whole debate was hypothetical.

The development team just wanted it built and out the door. Good enough is good enough. If you realise you’ve missed a critical field, you can always add it in later.

This is why I don’t say to clients “good, fast or cheap - pick two.”. I ask them to tell me what good enough, cheap enough and fast enough means for them, and we go from there.

How do you manage client expectations? Let me know in the comments.