Topic 4 — Scope, time, and cost — planning a project

Goal: Master the triple constraint and the basics of planning.

Lesson 4.1 — Two of three

In her hotel years, Renata ran a 300-person medical conference where the client called eight days out and asked to add a gala dinner, keep the same date, and not spend another dollar. She remembers exactly what she said: pick two. Add the dinner and hold the date, the budget moves. Add the dinner and hold the budget, something else gets cut. Hold both, the dinner waits.

That same shape rules software, and it has a name. The triple constraint — the "iron triangle" — says every project balances three things that are tied together:

• Scope: how much you're building, which features, how polished.
• Time: the deadline.
• Cost: the budget, which on a software team is mostly people's hours.

The three are linked, so you can't change one without moving another.

• Want it faster? Cut scope or add cost (more people, or the same people for longer).
• Want more? You'll need more time or more cost.
• Locked the budget and the date? Then scope is the only thing left that can flex.

At Cartwheel, Tomás (the engineering director who sponsors Renata's driver-app squad) loves to ask for all three at once: more features, sooner, no new hires. Renata's job isn't to say yes and quietly hope. It's to hold up the triangle and ask which corner is fixed and which can give.

Any one corner is yours to move for free. The cost of moving it shows up in the other two.

Lesson 4.2 — The corner nobody names

So where does quality go in all this?

Quality sits in the middle of the triangle, and it's the corner stakeholders forget. When you squeeze scope, time, and cost all at once — same features, sooner, no extra money — the pressure has to escape somewhere, and it escapes through quality. The team skips tests, glosses the edge cases, ships the login screen that works on a clean run and breaks the moment a driver's phone loses signal mid-delivery.

That's the dangerous part: quality drops silently. Nobody decides "let's make it worse." It just degrades under a triangle that's been squeezed too hard, and the bug reports arrive a month later when everyone's moved on.

A good project manager drags that hidden trade-off into the open. When Tomás pushes for everything, Renata doesn't argue and she doesn't cave. She says: we can do two of these three well — which one matters most? Naming the trade-off out loud is the whole move. It turns an impossible promise into a real decision someone with authority gets to make.

Lesson 4.3 — From "build the app" to a plan you can actually run

Priya, Cartwheel's Product Owner, hands Renata the next bet: let drivers log in with their phone number instead of an email. Renata can't plan that. "Build phone login" is a wish, not a task. You can't estimate it, can't assign it, can't tell if it's halfway done.

So she does the one move that makes any plan possible. She breaks it down.

The tool is a Work Breakdown Structure (WBS): take the goal and split it into smaller and smaller pieces until each piece is small enough to estimate and assign to one person. "Build phone login" becomes:

• Design the login screen
• Build the screen (front end)
• Wire up the send-a-code service (back end)
• Build the code-verification step
• Test the whole flow

Now there's something to hold. Each line is concrete enough that Marcus can look at it and say "that's about a day" or "that one's nasty, give me three." You don't plan the mountain. You plan the steps up it.

A WBS is rarely fancy. It's often just an indented list or sticky notes on a wall. The discipline is knowing when to stop splitting: small enough to estimate honestly, big enough that you're not drowning in fifty-item lists for a two-day job.

Lesson 4.4 — Estimates are ranges, not promises

Renata asks Marcus, her tech lead, how long the code-verification step will take. "Half a day," he says, barely looking up. It takes him three.

Marcus isn't lazy or lying. He's human, and humans are spectacularly bad at this. There's a documented name for it — the planning fallacy — and it affects most people: we picture the smooth version where nothing goes wrong, and we forget the lost afternoon to a flaky test, the dependency that wasn't installed, the meeting that ate Tuesday. Optimism is the default setting, and it wrecks schedules.

Three habits keep a project manager out of the trap:

• Ask the people doing the work. Marcus knows the code-verification step better than Renata ever will. Estimates handed down from above and not built from below are guesses wearing a suit.
• Treat every estimate as a range, not a number. Pros think in three points: an optimistic case, a most-likely case, and a pessimistic one. "Two to four days" is honest. "Three days" pretends to a precision nobody has.
• Add buffer for the unexpected. The unexpected is a certainty you can't yet name, not a surprise. A common rule of thumb is to pad an estimate by around 20%, more for anything unfamiliar.

An estimate is a forecast, not a contract. Treating it like a promise is how a date you guessed becomes a date you get blamed for.

Then comes the assembly. With the tasks, their estimates, and the dependencies between them — which task must finish before another can start (you can't test login before login is built) — Renata lays out the schedule: what happens, in what order, by when.

Lesson 4.5 — The chain that sets the date

Renata has eight tasks for phone login, and they're not a straight line. The design screen and the back-end code service can happen at the same time, on different people. The verification step needs the code service done first. Testing needs everything done.

Here's the question that decides the deadline: what's the longest chain of tasks that have to happen one after another? That chain is the critical path — the longest sequence of dependent tasks, and therefore the project's minimum possible duration. You literally cannot finish faster than that chain takes, no matter how many people you throw at the rest.

The payoff is knowing where a delay actually hurts. Tasks on the critical path have zero room: if the code service slips a day, the whole launch slips a day. Tasks off it have slack (also called float) — spare time before they'd start blocking anything. When Jamie, the squad's QA engineer, is a day late finishing a side task that's off the path, Renata doesn't panic; there's slack to absorb it. When the back-end code service slips — that's on the path — she's on it immediately, because that one moves the launch date for everyone.

That's the project manager's radar. You can't watch every task with equal alarm. The critical path tells you which delays are noise and which are real.

On the budget side, the same realism applies. On a software team the budget is overwhelmingly people's time, so Renata tracks the hours the squad is actually burning against the hours she planned. The instant the trend points over — say the code service is eating double its estimate — she flags it early, while there's still room to cut scope or move the date. The cardinal sin is the silent overrun that surfaces only when the money's already gone.

All of it ladders up to one principle, the thread running through every lesson here: realism and transparency. Build an honest plan, track against it, and say the hard thing early. A project manager who promises the impossible to keep a sponsor happy, then misses, burns trust they don't get back. One who sets a realistic plan and tells the truth as it changes becomes the person everyone wants running their project.

Worked example — Phone login, end to end

Priya prioritizes phone login for the driver app. Tomás wants it in two weeks, with no new hires, "and let's also add face-ID while we're in there." Watch the whole topic show up at once.

Renata starts with the triangle. Two weeks (time) and no hires (cost) are the fixed corners Tomás just set. So scope is what flexes — and she names it: face-ID is real scope, not a freebie, and bolting it on means either slipping the date or dropping it. Tomás, seeing the trade-off stated plainly, parks face-ID for later. Two of three.

Then she builds the WBS with the team: design screen, build screen, build code service, build verification, test the flow. Five tasks small enough to estimate.

She asks Marcus for the numbers — not the other way around. He gives ranges: the code service is "three to five days, it's new infrastructure." Renata takes the honest end and adds buffer, because new infrastructure is exactly where the planning fallacy bites.

Laying out dependencies, she sees the screen and the code service can run in parallel, but verification waits on the code service and testing waits on everything. The critical path runs code service → verification → testing: about nine working days. The design screen has slack, so when Jamie gets pulled onto a production fire for a day, Renata stays calm — that task was off the path.

Mid-sprint, the code service starts running long. Because it's on the critical path and on the budget line, Renata raises it that day, not at the deadline. Priya trims one polish item to protect the date. The plan was honest, the bad news came early, and Tomás got a launch he can trust — which is the entire job.