Iron Triangles and Vicious Circles

Julia from IT
Mar 5, 2018 · 4 min read

If you’ve worked as a project manager, or with project managers, you might have heard of the Iron Triangle — the triple constraint that means any change to cost, scope or schedule of a project requires a change to at least one of the other two, or a loss of quality.

This is basic stuff, and well-known; most project managers wouldn’t dream of trying to fix all three constraints without providing significant slack. (Padding the estimated schedule is the most common way to build flexibility back in, even if the timeline still looks fixed to anyone outside the project.) But people involved in project or product delivery, even in supposedly agile organisations, often find ourselves asked to deliver inflexible scope, with a more or less fixed team size and to aggressive and fixed deadlines. How does that happen? What can we do about it? And what are the outcomes if we don’t fix it?

A Vicious Circle. If we’ve worked together, you might think this is about the product or project we were on. In fact the prompt for this was a cumulative effect, not any one particular experience. What can I say? Some people are driven to drink; I’m driven to diagramming.

I first drew the diagram above some years ago, and it seems to touch a nerve when I show it to people.

It paints a bleak picture: fixing all three of the ‘iron triangle’ constraints results in poor quality, tech debt, more delays and, worst of all, a stressed, demotivated team. And the damage is carried forward to the next deliverable, and the next.

So how do we get into this anti-pattern? Here are three examples I’ve seen:

  1. Sales teams for consulting firms selling fixed-price, fixed-scope projects and promising a *cough* ambitious delivery date. This is, sadly, expected (though not inevitable) in waterfall projects, but can also happen when the delivery teams are somewhat agile while the rest of the organisation isn’t.
  2. Someone deciding to announce a new product or major feature at a specific industry event. (I’ve even seen a press release announcing that there will be an announcement. How very meta.) Organisations who are otherwise ‘agile’ still often fall into this trap.
  3. A manager under pressure in a meeting commits, off the cuff, to a delivery date without checking it’s feasible. When it turns out not to be, that becomes the delivery team’s problem to ‘make it happen’ rather than the manager’s problem to reset expectations. This can happen anywhere that people are encouraged to only ever tell their managers what they want to hear.

Agile friends, at this point you may be shaking your heads, because none of these things should happen in a truly agile organisation. But the diagram did hit a nerve with people, so it’s clearly not just me. There are agile teams working within un-agile companies, divisions calling themselves ‘agile’ because their two-year waterfall projects have something vaguely resembling scrum ceremonies every two weeks, and genuinely agile organisations creating unhelpful constraints for themselves.

The solution is simple: we need to get our sales people, marketers and managers to stop making these commitments.

I said it was simple, I didn’t say it was easy.

To make it possible, here are three truths we have to help our organisations get comfortable with:

  1. If it ain’t built, you don’t know when it will be. Estimates are just that, and they’re usually wrong. (There’s another blog post in this, but in short: if all your projects look like the diagram above, how can anyone in your company ever get better at estimating?)
  2. If you promise something that nobody else committed to, that’s on you. If you’re being told it can’t be done, spend your time figuring out how to communicate a realistic message to your managers or customers, not beating up the folks trying to help you.
  3. Sometimes you’ll have to tell your manager or customer news they don’t want to hear. If that sounds difficult then keep reading, I have some suggestions.

Influencing outside of our own team takes effort and, most importantly, credibility. Practically, where can we start?

I worked with a very smart senior leader who once said he didn’t like to talk about missed deadlines, he preferred to talk which risk we were swapping for another. If there is any hope of un-fixing a locked-in cost, scope or schedule then risk-based conversations are the key.

Here are some talking points for conversations with your stakeholders:

  • Schedule: Is this deadline important enough that we can risk the quality and reputation of our product? Illustrate the point with examples from past launches. (Unless you’re in a brand new startup, this has very likely happened before.)
  • Scope: Is it so important that we deliver everything on that date that we’d risk quality? Can we create most of the value with a less risky set of deliverables? For this conversation to work, you need to understand the goals of your organisation and how this piece of work helps meet them. If the top priority is, say, to increase the number of subscribers, can you provide most of the growth with a reduced scope, then add more features later?
  • Cost: If the delivery date is genuinely immovable, and there is no way to reduce scope, the cost will have to go up, or we risk loss of quality. Usually this means more people, and the earlier you can ask for extra help, the more chance there is of a good outcome. Can you bring in contractors? Can you borrow people from another team? If the deadline and scope really can’t be changed, even if extra cost is unpalatable, is it worse than the risk of releasing a low-quality product?

Understanding the goals of your organisation is vital. When you can articulate the key risks and the tradeoffs available in a way that is meaningful to your stakeholders, you have your best chance of getting buy-in to break out of this damaging cycle. From there, you can begin to restore the health of your projects, your products and your teams.

Disclosure: I am a Product Manager at eBay. The opinions expressed are my own and do not represent the views of eBay.

Julia from IT

Written by

Product manager from a background in EUC, ITSM, Agile, DevOps. Talks a lot. Sometimes on stage. Views expressed are my own.