Time to Bury This Old Stale Project Management Trilemma

I saw another tweet recently about this tired old triangle of project management. Really the whole framing is nonsense and should be buried for good.

The basic framing is that a project can be “feature-driven”, “date-driven” or “quality-driven”, but you can only pick two of these — if you try to do all three you fail.

I started writing a response and then went down a bit of a rabbit hole trying to figure out where it had come from in the first place. If you search for “project management triangle” you pretty quickly come to this Wikipedia page and this image:

This describes a very simple project management model where the quality of a product is constrained by the scope (features), the cost (resources applied) and time allowed. If you change one (e.g. try to accelerate the completion time) you need to adjust the other constraints (e.g. cut features or add additional resources) — otherwise quality of result will suffer.

This isn’t especially useful as a model for “driving” a project but as a very simple model it can be good for very simple decisions (“you idiot, you don’t really think we can “squeeze in” these additional features without changing anything else about the project schedule, do you?”). Or if you’re talking to the CEO you can replace “you idiot” with “respected sir/madam”.

A suggested variant is the “Common Law of Business Balance” or “Good, fast, cheap. Choose two.” This actually looks a lot more like the framing from the tweet we started with, but is usually used in the context of “You get what you pay for” — that is, you often have a choice of trading off quality for cost in some purchase. A longer quote with the same meaning, attributed to John Ruskin, was actually put in a frame and hung in Baskin Robbins ice cream stores for decades.

But that puts us pretty far from having something useful for managing a complex software project (or any other kind of project).

The “pick two” framing creates a false “trilemma” (like dilemma, but an impossible decision between three different choices rather than two). In reality, you never “give up” on one of features, date or quality — the challenge is how do you balance between the three and how do you create a framework for managing a project and making decisions along the way?

As a manager, you are allocating resources to achieve project goals. If you don’t understand what dates you are delivering to, you don’t understand what resources you are allocating. If you don’t understand what features you are delivering, you don’t understand what project goals you are achieving. All this needs to be done with a clear model of required quality. So you are always balancing these elements together, not “picking two”.

Let’s talk a little about the “driven” part of that initial framing.

The standard screed that is easy to find on the web that “date-driven sucks!” is typically an argument for some type of agile “feature-driven development”. It establishes a strawman for date-driven where both feature scope and date are locked in (by some pointy-haired manager) from above at the start of the project. This inevitably creates a mad scramble of bad quality or missed dates at the end.

This is a strawman — effective date-driven development looks nothing like this.

Hard dates might be set by some external requirement (e.g. hardware cycles for “software-in-a-box”) or some yearly “train” system — which is typically about simplifying the date discussion by just locking it down at the front. Or might emerge through some investigations about business requirements and rough early SWAGS on feature costs. In any case, the key thing is about locking down one of the variables and communicating a “simple message”.

Date provides the purest and clearest “simple message” — critical for managing at scale. Date allows a wide collection of independent teams to coordinate with minimal overhead. Reducing coordination costs is one of the keys to delivering on big projects. Date sets clear constraints on acceptable dependencies — both internal and external. Date provides the framework for setting clear intermediate deadlines in a big project.

In contrast, using “feature driven” on a major initiative ignores the reality that any “feature” of real size has a thousand internal decisions and trade offs. Using feature driven as the framing and then abandoning clear constraints at the start discards one of the strongest ways you actually empower the people under you to make their own decisions.

Clear constraints empowers rather than disempowers. Without constraints, the decisions start percolating up because the framing for all the intermediate decisions that need to be made inside the project is so weak. If they don’t percolate up, they get made in diverging ways by different teams since the teams don’t have a strong framing for making them in a consistent way.

My experience with “feature driven” in a large project is you end up with lots more poorly prioritized work getting done as well as more unevenness in the decisions being made as some teams “push the envelope” because they’ve made a local decision about how important their sub feature is and how much completion risk they can expose the overall project to.

The fact that teams are working to a clear date constraint does not mean they have abandoned accountability for achieving real product and business goals (“features”). It just means they have a clear model of the constraints they and partner teams are operating under to achieve those goals.

During my 10 years running Microsoft Office development, we added more and more teams working against consistent date-based constraints. We were initially worried that the increase in number of teams would result in multiplying the risk of slipping the project — if N teams each had some probability P of shipping on time, the ultimate risk of slipping would be (1 -P^N) — which approaches 1 as N gets large.

In practice, the model was more of a heavier and heavier flywheel that guaranteed staying aligned — it became clearer and clearer to each team that the constraints were rock solid and they needed to deliver against them. No one team could believe they were important enough to slip the entire Office release.

Treating “quality driven” as symmetric to either feature-driven or date-driven is nonsense. Quality is something that gets built into the product throughout and provides framing for how engineering executes but not as a trade-off or framing for date or features.

Since the “agile industry” is so prolific in their communication, I’ll just add that the framing above is somewhat independent of whether you’re delivering in an “agile” way — either with an effectively continuous deployment or frequent (daily, weekly, monthly) deployments. Continuous delivery is great for all kinds of reasons. For a large project, beyond other benefits it allows you to break dependencies that were only present because distribution was synchronized. And breaking apart dependencies is a key way to simplify managing the project.

But a large project will inevitably have larger product goals that play out over longer time frames than the deployment frequency and will generate real dependencies between teams. Clear dates are the best framework for coordinating those and understanding how you are allocating resources against your priorities.