Trade-offs in classic project management
Imagine that it’s Christmas, and this year it’s your responsibility to host a big family gathering…
Sixteen people are coming; some you know well, others not. Some are old, some are children. There’s a lot to do. As well as doing all the cooking, you’ll also need to help keep them entertained on the day. And preparing for this is on top of a busy job – and if you get them all presents, it could be quite expensive too.
Some people would find this situation quite stressful…
“Should I get them ALL a present? How much should I spend on the wine… will anyone notice if it’s a supermarket plonk rather than something fancy? Do I do just a roast, or the full starters, Christmas pudding too? What about a vegetarian option? Should I cheat and buy a Christmas cake, or take the time to make one? And if I’m in the kitchen all day, how can I keep them all entertained?”
If ‘Host Christmas Day’ was your project, then what you actually have here is a classic trade-off between Cost, Quality and Time. (The capitals are deliberate.)
In general, all projects – especially software projects – have the same trade-offs. And the general rule of thumb when looking at project Costs, Quality and Time, is pick any two – because you can’t have all three.
Want it fast and cheap? Then it’ll have to be rough and ready…
It needs to be excellent but there’s not a lot of budget? That’s going to take some time…
Need it quickly, and it has to be perfect? That’s going to be expensive…
This trade-off is sometimes referred to as The Iron Triangle of project management… Pick any two.
“Pick any two…”
Why does this matter?
If you have a project to deliver then:
- This model can help frame your thinking.
- It could help to find out which of the three are the most important, and specifically which is the least important (though often the answer is “I need all three”).
As a rule of thumb, I’ve found that Quality is the one that is least likely to be discussed – because it’s the hardest to measure. Ever sat in a meeting where people probe in great detail “when will it be done?” and “how much will it cost?”, with almost no detailed discussion on what exactly ‘it’ is?
This is a key reason why, after some software projects are delivered, people often start to become critical; “I assumed it would also do X”… because the unspoken emphasis from the start was on doing it as quickly and at the lowest cost possible. So the Quality was inadvertently sacrificed.
Working with these constraints
Traditional thinking says you should define the Quality you’re after at the start; for example, a requirements document or specification would define how much a software system had to do. But this specify-up-front approach is often fatally flawed (more later).
Usually a far better approach is to understand and acknowledge these fundamental constraints and trade-offs, and work in an Agile way to steer the project to the right destination.
GOOD-ip-IDEA 