Trade-offs, the iron triangle and saying no

When work runs late, everyone wants something sooner, and nothing moves without moving something else. The iron triangle of project management, also called the triple constraint, names the levers: scope (what gets done), time (when it's done) and resources (who does it), with quality caught in the middle.

The sides are linked. Squeeze one, say with an earlier date, and another has to give: less scope, more people, or a later finish somewhere else. And if nothing visibly gives, quality pays quietly: rushed work, lost orders, bugs discovered in March.

At CatChow's first monthly review, every lever is on the table. Scope: move clinic orders to the new warehouse system first and subscriber orders later. Time: accept the end of February for the whole move. Resources: hire two contractors now. Quality: put all 14 PurrPoint clinics on the old system and accept some lost orders.

Seeing all four side by side is the point. It turns an accidental outcome into a deliberate choice that the whole room can discuss.

Knowing the levers isn't enough; you have to pick one. Start from what matters most right now, then pull the lever that protects it.

For CatChow, what matters is a date for the clinics, not a finish date for the whole warehouse move. That rules out the other levers one by one. Quality is out: lost clinic orders are exactly the stock-outs the clinic theme exists to remove. Time alone doesn't help: waiting until March gives Brandon, the key account manager, nothing to tell his client, PurrPoint. Resources would backfire on a late, undocumented system.

That leaves scope, and staging it works. Move clinic orders first: they run on the new system by mid-January, so all 14 clinics can start in February. Subscriber orders follow, and the whole move finishes at the end of March instead of the end of February.

So the trade-off is explicit: about a month later overall, in exchange for clinics getting what they need roughly six weeks sooner. That's worth making, because the clinic theme is what's waiting. Staging or cutting scope often saves the one date that counts.

When a project runs late, adding people looks like the easiest lever. Often it's the one that works worst. An old observation, often called Brooks's law, says that adding people to a late software project makes it later.

Two forces explain why. Ramp-up: newcomers need training, and the only people who can train them are the ones already doing the work. Coordination: every extra person adds conversations, hand-offs and chances for misunderstanding.

CatChow's warehouse move shows both. Nobody ever documented the old system, so two contractors would spend January learning it, and Lucy's two engineers would spend January teaching instead of moving data. The money is real and approved; the speed-up isn't.

This isn't an argument against ever adding people. It's a warning about adding them late, to work that's hard to split and that depends on knowledge only a few people have. In that situation, the budget is better spent elsewhere, for example on taking other work off the team's plate.

Brooks's law is about adding people late to work that's hard to split. Change those conditions, and extra people can help a lot.

They help when they join early, before the work is under way, so they learn alongside everyone else and the plan is built with them in it. They help when the work splits cleanly into separate parts that need little coordination, such as two independent integrations or a batch of similar content pages. And they help when the newcomers bring knowledge the team lacks, rather than needing to absorb knowledge the team has.

Before pulling the resources lever, ask three questions. How long until a new person is productive? Who has to stop their own work to train them? Can the work be divided so the newcomers rarely need the core team?

If the answers are “weeks”, “the people we can least spare” and “no”, look at another lever: stage the scope, protect the team's focus or accept a later date for the less important part. More people is a strategy for the start of a project, not a rescue at the end.

A good no refuses the request, not the person. It has four parts, in this order:

1. Restate the need behind the request, so the person knows they were heard.
2. Say plainly what won't happen, and why. No hedging, so nobody leaves with false hope.
3. Offer what you can do for that need now.
4. Say when, and under what condition, the answer could change.

Take a partner clinic director who asks for a stock tracker for every brand on her shelves: a different product, since only the CatChow part serves CatChow's key results. Her need: knowing what's running low before the shelf is empty. So: no to the all-brand tracker; an early place in CatChow's clinic theme, which covers that need; and what would change the answer, such as many partner clinics asking for the same.

Each part does a job. Starting with the need shows the refusal isn't about the person. The plain no prevents false hope. The offer keeps the relationship working on the real problem. The condition shows the door isn't closed for good.

The same four parts work for a founder, a colleague and a client.

With a colleague, the four parts of a good no still apply, and the first carries the most weight: start from what they need, not from what you're refusing. Brandon doesn't need January for its own sake. He needs something firm to tell PurrPoint, and he needs not to look as if he over-promised again.

So build the answer around that. First, give the reason in the client's terms: expanding now could cause the very stock-outs PurrPoint wants gone. Then give a real next step, with a condition: clinic orders move to the new system by mid-January; if the December review holds up, all 14 clinics start in February.

That's a no he can sell: a reason his client cares about, a date with a clear condition, and nothing he'll have to take back later.

Three versions don't work. Blaming someone else (“that's Lucy's call, not mine”) leaves him empty-handed and damages the team. Hiding behind the document (“the roadmap says two clinics”) gives no reason at all. And saying yes anyway trades one awkward conversation now for a much worse one later.

In real drafts, the part most often missing from a no is the offer: what you can do for the underlying need now. A reply can acknowledge the need, refuse clearly and even name a review date, and still leave the person with nothing. That's when a client starts looking elsewhere; she can always buy from someone else.

For the clinic director, the offer is concrete. Once the online order form works for PurrPoint, it can reach other partner clinics, and knowing what's running low is part of the clinic theme. So: an early place in what CatChow is building. That may even make her a useful early tester.

There's a tempting shortcut that looks kinder: “it's on the roadmap for later.” It's kinder today and worse in spring, when she asks where it is. A clear no with a real offer is the kind version.

When you review your own draft, check all four parts and ask of the offer: does it help with her actual need, starting now? If the honest answer is “nothing yet”, say what you'll tell her and when.

Some ideas are good and still don't make the cut. Loyalty points are one: a few comments behind them and eight person-months of work. For such ideas, the honest answer is not now, and it has to be a real one.

A vague “later” is just a slow no. It sounds kind today, but nobody knows when “later” is, the requester keeps asking, and in a few months it feels like a broken promise.

A real “not now” has two parts. The reason, tied to the criteria: weak evidence, high effort, no link to this year's objectives. And the way back: the condition under which the idea returns, written so anyone can check it. For points: if churn is still above 8% at the June review, once the Now themes have had time to work, points come back, starting with a small test. Add what would bring it back sooner: evidence such as cancellation surveys in which people name the price.

The idea isn't lost; it's queued behind evidence. Saying so plainly is what lets the founders accept the answer.

Keep every “not now” in one place: a “not now” list, separate from the roadmap's columns. Each entry is short and has the same parts:

• The reason, tied to the criteria, such as weak evidence or high effort.
• A condition for coming back that can be checked: a number, a test result, a change in objectives.
• When it will be looked at again, such as the June review.
• What evidence would bring it back sooner.

Two things don't belong in an entry. A promise for next quarter “to keep everyone happy” is a yes in disguise. A bare “low priority” is a vague later that nobody can act on, with no reason and no way back.

The list gives every requester an answer they can repeat, and keeps the Later column from Timeframes and the roadmap disclaimer short: ideas that serve no current objective wait here instead.

How it fits together: The iron triangle handles trade-offs on delivery; a good no and a real “not now” handle those on requests; both are choices made in the open. Version 4 is the ranking plus this list. Next, module 5 gets people behind it.