Defend your time with the iron triangle
A law from project management theory that helps designers
Designers are in the tradeoff business. No one tells us that, but when your ideas have to be part of actual projects, tradeoff decisions determine their fate. Tradeoffs, defined as the balance between two desirable but incompatible elements, are unavoidable in the process of designing and making anything.
In Why Design Is Hard, the unavoidability of tradeoffs is explained this way:
When you explore different ideas for how to solve a problem, what is the conversation like in your mind? From Bryan Lawson’s excellent book, How Designers Think, we know that most designers compare different possibilities, exploring why one might be better (or seeking ways to combine the best of both).
…for example, in visual design, the concept of composition is about making tradeoffs between whitespace, hierarchy, and contrast to find balance. If you don’t do this, and everything gets equal attention, it’s probably a confusing, ugly failure. Similarly, a product that tries to do too many things, like a Swiss Army Knife, probably doesn’t do any of them particularly well.
A major frustration for designers is when they are asked to work faster. Since most leaders don’t understand how hard good design can be to achieve, they assume we must be wasting time. It’s a common myth about creativity that creative people have a pile of good and complete ideas lying around in our brains and if they don’t come out instantly it’s because we are lazy. When it reality it’s our process for developing ideas that justifies our value to organizations, not some mythical idea inventory.
To help you defend your creative process, there is a concept from project management every designer should know. It’s called the iron triangle, but it’s often represented as circles or a Venn diagram. Here’s the version found in Why Design Is Hard.
How the triangle helps designers
It’s common for bad leaders to make unrealistic demands. This sounds cynical, but much of my career was spent as a project leader and training them. Humans are just not good generally at projects, but that’s the topic of one of my other books.
The good news is the iron triangle is a fast way to improve the conversation you have with leaders. It gets some of them to wake up out of their stupor and realize the flaws in their thinking. It can elevate the conversation from being about design details to being about realistic expectations and the nature of tradeoffs.
For example, the triangle invites these conversations:
If you’re asked to work faster, say “I can do that, but quality will be lower.”
If you’re asked to raise quality, say “I can do that, but I will need more time.”
If you’re asked to work cheaper, say “I can do that, but it will be take longer or quality will drop.”
If you’re asked to add a feature, say “I can do that, but which one of these others will we cut?”
By establishing tradeoffs, leaders can more easily see the real costs of what they are asking for. Better leaders are comfortable with these more mature conversations. They mirror the way they talk with engineers and other important generative roles. On the other hand, the iron triangle also clarifies how bad the bad leaders you work for are:
…the triangle is a reminder to good leaders that they must make tradeoffs to succeed, and that’s often done by setting clear, realistic goals. On the other (much stupider) hand, bad leaders assume they are immune from the triangle (i.e., the Dunning-Kruger effect), which leads to failed projects that are slow, expensive, and bad, the trifecta of failure (aka the failfecta).
The iron triangle and things like it force clarity, even if it’s clarifying how foolish some of the people you work with are. It’s better to have your eyes open so you know what to expect in the future.
The iron triangle hides complexity
I don’t think you want me to get into the weeds of project management theory here, but it’s important to call out some limitations the iron triangle has.
One flaw in the triangle is it assumes you can always trade from one constraint (cost) to another (speed). But this isn’t always true. Sometimes throwing more money, or people, at a project makes things worse. And sometimes there aren’t easy ways to raise quality, perhaps because the way the project was engineered was flawed or the organization is dysfunctional. The iron triangle glosses over these real factors.
Another flaw is that an experienced designer, or engineer, can sometimes do high quality work quickly and cheaply. For example, if they’ve thought about the problem before, they can skip many of the usual steps required. And someone with decades of experience might know significant shortcuts and the right time to use them that less experienced people won’t.
Perhaps the iron triangle is misnamed, since it can have flex in it depending on your situation. Maybe, it should be called the plastic triangle? Or the mostly-iron-but-sometimes-squishy-triangle? I guess one meta tradeoff for naming tradeoff models is the more accurate the name, the worse it will sound and the less well known it will be.
I agree, but I´d like to question the "good"-part. I think we mean the same, but in my opinion it would be more on target to call it "depth of function". Example:
It´s okay that something is delayed = the solution are worked slow, but still has to be good (quality). Burn rate it slower, but probably when the invoices are summed up (when finished finished later) its probably the same expense if the result (good) should be the same.
If "good" --> "depth of function" you end up more with something that works within the diagram. A simpler version is planned, so the scope is restricted (not so complex) and harder prioritized. This should be faster, cheaper but the solution is still with a good quality for what was planned.
If you work as a designer my thoughts might not change that much, this model that I find very helpful (thank you!). But when you use this as a model when explaining to a stakeholder it could be more effective to level out specific functionality instead of using generic terms as "good".
Thank you!
Glad I came across this post. Learned about it 25 years ago, as a PMI waterfall project manager. Applies to every aspect of design. It should be taught in the magical Design Thinking bootcamps.