My Story
About 5 years ago, I ran my first big project.
I remember exactly how I felt when things went wrong.
We uncovered a dependency mid-project that we hadn't planned for. A critical report used daily by quality process engineers would break without it. No workaround. No go-live without fixing it.
First reaction: panic.
I thought I had missed something. That a good PM would have caught this earlier. (And maybe I would have, if I'd had my PRD template back then.)
Second reaction: okay, what do I actually do now?
I stopped thinking about what went wrong and started thinking about options.
What are we dealing with. How critical is it. What can we do. What does each option cost.
I put it in a one pager. Problem statement. Criticality. My recommendation at the top. Options below it.
That's what I brought to leadership.
Not "I missed something and we need more money." But "here is what we found, here is why it matters, here is how I recommend we move forward."
Almost nothing goes 100% to plan. That's not a sign of a bad PM. That's just how projects work.
The job is to look inside what changed, understand your options, and bring leadership a recommendation.
That email I was so embarrassed to send? That was actually my job.
It just took me a few years to see it that way.
The Golden Rule of Project Management
So when something changes, how do you actually think it through?
There's a framework for this. It's been around since the 1960s.
Every project has three variables: scope, time, and cost.
The rule: you can only lock in two. The third has to flex.
This is called the Project Management Triangle. And it's not opinion. It's a constraint.
Pull one side, the others move. Always.
This is why "can we do it faster AND keep everything AND not spend more" is not a real option. Something has to give. Your job is to know which lever makes the most sense, and come in with a view on it.
Here's what each scenario looks like in practice:
Scenario 1: Leadership wants it faster (compress time)
Time goes down. Something else has to give.
→ If you protect scope: cost goes up. You need more people or more hours.
→ If you protect cost: scope goes down. You're shipping less.
The question to answer: is the deadline driven by a real business need, or is it just uncomfortable to say a longer number?
Scenario 2: Budget is cut (reduce cost)
Cost goes down. Something else has to give.
→ If you protect scope: time goes up. The same work just takes longer with fewer people.
→ If you protect time: scope goes down. You ship a smaller version within budget.
The question to answer: what is the minimum viable version that still delivers real value?
Scenario 3: Scope grows (new dependency, new requirement)
Like my story. Something new appears that has to be included.
Scope goes up. Something else has to give.
→ If you protect time: cost goes up. You need more capacity to absorb it.
→ If you protect cost: time goes up. It'll take longer.
The question to answer: is this dependency truly non-negotiable, or is there a version of it that costs less?
The moment you internalise this, something shifts.
You stop panicking when things move. You start asking which lever makes sense to pull.
The Trade-off Framework
This is where we actually get to turn theory into practice.
Understanding the triangle is not enough. Let it help you transform project changes in your work from "oh crap something is changing" to "okay, here is how we can approach it."
Here's a step-by-step way to build your options before you walk into the room.
Step 1: Pressure-test the estimate first
Before you present anything to leadership, ask your team:
→ What's the riskiest assumption in this estimate?
→ Is any part of this waiting on someone outside our team?
→ Is the work sequential or can anything run in parallel?
You'd be surprised how often "6 months" becomes "5 months" just from answering these questions honestly.
Step 2: Check if you're ready for the conversation
Four questions. Be honest.
→ Do I know what's actually driving this timeline?
→ Have I pressure-tested the estimate with the team?
→ Do I know what cutting scope would cost us later?
→ Do I have a recommendation, not just options?
If you can't answer all four, you're not ready yet. Go back to step 1
Step 3: Build your trade-off table
One option per row. Clear parameters. And a clear recommendation.
Always include a delay option. It makes delay a conscious choice, not a default.
Always come with a recommendation. Don't present options and shrug. Leadership will ask. Be ready.
Step 4: Walk in and run the meeting
When you say "here are three ways we can approach this, my recommendation is X because..." you're not defending a timeline anymore.
You're facilitating a decision.
That's the difference between a PM who delivers estimates and one who gets invited back to strategy conversations.
🤖 AI Prompts to Help You Prepare
Use these when something shifts on your project:
→ "I'm a PM and a new dependency appeared mid-project. Here's the context: [describe situation]. Help me think through my options using the project management triangle."
→ "Help me build a trade-off table for this situation. The original plan was [X]. The new constraint is [Y]. What are my realistic options and what does each one cost?"
→ "How do I present a budget or timeline change to leadership without it feeling like a failure? Help me structure a one pager with problem statement, criticality, and recommendation."
→ "What questions should I expect leadership to ask when I present a scope or budget change, and how should I prepare to answer them?"
Want to Go Deeper?
If this newsletter made you realise you want a stronger foundation in project management basics, I'd recommend starting with PMI's free KICKOFF course.
It's less than an hour. Built by the Project Management Institute, the same body behind the triangle framework. Self-paced, beginner-friendly, and comes with a shareable badge when you're done.
→ PMI KICKOFF: free course here
Worth an hour of your time before your next complex project kicks off.
