Good, Fast, Cheap: Pick Two
Key Points
- The fundamental rule of project work (and many other endeavors) is “good, fast, cheap – pick any two,” meaning you can only reliably achieve two of those qualities at once.
- Adding more people can improve quality and speed but raises cost, and beyond a certain point extra head‑count yields diminishing returns or even slows the project due to coordination overhead (as described in Fred Brooks’s *The Mythical Man‑Month*).
- Giving a project more time can enhance quality and reduce cost because fewer resources are needed, but it sacrifices speed, making the delivery slower than desired.
- Insisting on high quality, rapid delivery, and low budget simultaneously creates unrealistic expectations that inevitably force a compromise on at least one of those dimensions.
Sections
- Good, Fast, Cheap: Choose Two - The speaker explains the immutable project‑management law that only two of high quality, fast delivery, and low cost can be achieved simultaneously, using a coding project example to illustrate why you must pick any two.
- The Good‑Fast‑Cheap Triangle - The speaker explains that a project can only excel in two of the three attributes—good quality, speed, and low cost—so prioritizing speed and cheapness inevitably sacrifices quality.
Full Transcript
# Good, Fast, Cheap: Pick Two **Source:** [https://www.youtube.com/watch?v=FTTRzy9VQnA](https://www.youtube.com/watch?v=FTTRzy9VQnA) **Duration:** 00:04:12 ## Summary - The fundamental rule of project work (and many other endeavors) is “good, fast, cheap – pick any two,” meaning you can only reliably achieve two of those qualities at once. - Adding more people can improve quality and speed but raises cost, and beyond a certain point extra head‑count yields diminishing returns or even slows the project due to coordination overhead (as described in Fred Brooks’s *The Mythical Man‑Month*). - Giving a project more time can enhance quality and reduce cost because fewer resources are needed, but it sacrifices speed, making the delivery slower than desired. - Insisting on high quality, rapid delivery, and low budget simultaneously creates unrealistic expectations that inevitably force a compromise on at least one of those dimensions. ## Sections - [00:00:00](https://www.youtube.com/watch?v=FTTRzy9VQnA&t=0s) **Good, Fast, Cheap: Choose Two** - The speaker explains the immutable project‑management law that only two of high quality, fast delivery, and low cost can be achieved simultaneously, using a coding project example to illustrate why you must pick any two. - [00:03:05](https://www.youtube.com/watch?v=FTTRzy9VQnA&t=185s) **The Good‑Fast‑Cheap Triangle** - The speaker explains that a project can only excel in two of the three attributes—good quality, speed, and low cost—so prioritizing speed and cheapness inevitably sacrifices quality. ## Full Transcript
Your boss just assigned you to lead a project and the expectations are that the quality is high, it's done in half the time, and it comes in under budget.
Should you just start working on your resume now or might there be a lesson for everyone in this assignment?
Maybe send them this video to inform future decisions because I'm going to reveal to you what I think is one of the immutable laws of the universe.
This is the E equals MC squared of project management or coding or almost anything you try to do.
It's this:
Good, fast, cheap, pick any two.
Don't believe me?
Think you can have all three?
I'm going to explain to you why you only get two and you can only pick those two.
So let's take an example of a coding project.
Large project and now we've got to try to optimize on all of these.
We're going to look at three different parameters.
Head count or the number people that we throw at the project.
There's the amount of time we give them to work on the project and then there's the speed.
That where they are expected to operate, in other words how fast do they have to produce this code,
so let's take a look what happens.
In the first example let's say I increase the headcount. I put more people on the project.
Well it could be good now because now, we have more people working on it, we can do more quality control, they can do more code reviews, and things like that.
Maybe even more design make a better project out of the whole thing it's going to be faster with more people on it potentially.
Because now, as they say, many hands make for light work.
But, is it gonna be cheap?
No, because guess what?
These people wanna be paid.
And the more we put on that, the more expensive the project gets.
And by the way, there is a point of diminishing returns at throwing more people at a project.
Former IBMer Fred Brooks wrote a book many years ago called The Mythical Man-Month,
where he talked about how, in one example, we know that it takes, typically, A woman nine months to have a baby?
Well, that doesn't mean you can have nine women have a Baby in one month.
So it doesn't always work out as simply as the math would indicate.
Spreadsheets are one thing, the real world is another.
So there's a point where throwing more people at a project actually doesn't make it better.
It actually could slow it down.
If for instance, we had a thousand people writing one line of code, that's gonna take a lot longer than one person writing that and actually getting it to work.
So let's take a look at another example.
We're going to look at the amount of time we give them.
So if we give then on this project more time, well then potentially more time better quality.
They can look at, again, the things that they're doing and make sure it works well.
More time, well, might be cheaper because we're not having to work as fast.
We didn't have to throw the number of people at the project.
We could do it with fewer people because we have the luxury of time.
However, what we don't get is fast because in fact that's the exact opposite of more time.
So we got to optimize on two out of those three in that case.
Then finally, let's take a look at speed.
Let's say we increase the speed of the project and we say you guys have to work faster,
you've got to produce more lines of code than you've ever done before in a very short period of time.
Well, what are we going to get in this case?
Well, it's going to be fast.
And that's what the objective was in that And if we're going really fast...
We can slop right through this stuff, and it's going to be cheap.
But you know what it's not going to be?
Good.
Because in fact, we just ran roughshod over all the process.
And now we end up with something that is fast and cheap, but not so good.
So there you go.
You've got three things you can optimize on.
Good, fast, cheap.
But you can only pick two.
And that's why I say this is one of the immutable laws of the universe.
And learn these lessons.
Pass them along to your manager.
Have your manager learn these lessons and you'll be a lot happier with the projects you produce.
If you think there's an exception to this rule,
and you aren't afraid of ripping a hole in the space-time continuum by discussing it,
after all, I said this is an immutable law of the universe, write it in the comments section below.
I'll be watching.