Topic 3 — The project lifecycle

Goal: Follow a project through its standard phases from start to finish.

Lesson 3.1 — The shape every project shares

Renata's first week at Cartwheel, Tomás drops a one-liner into Slack: "Driver app needs to ship by end of quarter — you've got the squad, go." That's it. No plan, no scope, no list of tasks. Just a finish line and a team looking at her.

Her stomach drops for a second. Then something familiar kicks in. She planned a 300-person conference once with eleven weeks' notice. A project is a project. It has a shape, and the shape is always the same.

Every project — a wedding, a conference, a driver app — moves through the same five phases:

1. Initiation — decide why this project exists and whether it's worth doing at all.
2. Planning — work out how: the tasks, the schedule, the budget, the risks.
3. Execution — the team does the actual work.
4. Monitoring & Controlling — runs alongside execution, watching reality against the plan.
5. Closure — confirm it's done, hand it over, and learn from it.

These are the classic process groups from the project-management profession's main playbook, the PMBOK Guide. (Small piece of trivia worth knowing for interviews: the 7th edition dropped them, and the 8th edition — released in late 2025 — brought them back, now called Focus Areas. Same five buckets, friendlier label.) You don't need to memorize the lineage. You need the map, because the map is what stops you from getting lost.

Knowing the five phases means you always know which question you're supposed to be answering today.

Lesson 3.2 — Initiation: deciding whether to even start

Before Renata schedules a single task, she does something that feels almost too slow: she asks why.

Why a driver app? Tomás says couriers keep churning because the current web tool is unusable on a phone in a moving van. So the real goal isn't "build an app." It's "cut driver churn by giving them a route planner they can actually use one-handed at a delivery stop." That sentence is worth more than a month of code.

Initiation is the phase where you define why the project exists, what success looks like, and whether it's worth doing. Its single most important output is a clear, agreed goal and scope — a shared definition of success that everyone signs up to.

Renata writes it down, the way she used to confirm a wedding brief before booking anything. What's in: route planning, offline maps, one-tap delivery confirmation. What's explicitly out: in-app chat, driver payments, anything that smells like "version two." Then she walks it to Priya, the Product Owner who owns what gets built and why, and to Tomás, the sponsor paying for it. Both nod. Now it's real.

That written, agreed brief is often formalized as a project charter — a short document naming the goal, the scope, the sponsor, and the rough budget. It's the thing Renata can point at three months later when someone says "can we also add payments?" and the honest answer is "that was never in this project."

Skip this phase and you build something. You just might build the wrong thing, beautifully and on time.

Lesson 3.3 — Planning: turning a goal into a schedule

A goal is a destination. Planning is the route.

In planning, Renata breaks the goal into concrete tasks, estimates how long each one takes, finds the dependencies between them, and assembles a realistic schedule, budget, and risk plan. A dependency is just the rule that one thing has to happen before another: the map-rendering engine has to work before anyone can build offline maps on top of it. Task B can't start until task A finishes.

She sits with Marcus, her tech lead, to get the estimates — because the person doing the work owns the numbers, not the planner. Marcus is allergic to process, so she keeps it short: "Just tell me which pieces, and roughly how long, and what each one is waiting on." Out of that hour comes a list: auth, map engine, route algorithm, offline cache, delivery-confirm screen, QA pass.

Then she draws it as a Gantt chart — a timeline bar chart where each task is a horizontal bar, its length is its duration, and you can see at a glance which bars overlap and which sit end-to-end because one waits on another.

Week:           1    2    3    4    5    6
Auth         [====]
Map engine     [=========]
Route algo          [=========]      (waits on map engine)
Offline cache              [======]  (waits on map engine)
Confirm screen                  [====]
QA pass                            [======]

Reading that picture, Renata spots the trap immediately: route algorithm and offline cache both wait on the map engine, so if the map engine slips a week, two things slip behind it. That's the kind of pile-up you want to see on a chart in week one, not discover in week five.

Time spent planning is not time lost. It's the cheapest place to find a problem.

Lesson 3.4 — Execution and monitoring: the part that runs in parallel

Now the squad builds, and Renata's job quietly changes.

In execution, the team does the work — Marcus and Jamie write code, QA runs tests. Renata isn't writing any of it. Her job shifts to keeping it on track: coordinating who needs what, communicating status up to Tomás, and clearing blockers before they cost a day. When Jamie is stuck waiting on a test environment, that's Renata's problem to solve by lunch, not a thing she notices in next week's status meeting.

Here's the part beginners get wrong. They think you plan, then execute, then check at the end whether it worked. Wrong order.

Monitoring & Controlling runs alongside execution, every day, not after it. You continuously compare actual progress to the plan, and when reality drifts — and it always drifts — you adjust. The map engine takes nine days instead of five? Renata sees it on day three, not on the deadline. She has three honest levers: reprioritize (cut the offline-cache polish), add help (pull Jamie onto the map engine), or renegotiate the deadline with Tomás before it's a surprise.

Projects almost never go exactly to plan. Catching the drift early and steering is the whole skill. A plan you never check against reality is just a wish you wrote down in week one.

Lesson 3.5 — Closure: the phase everyone skips

The app ships. The team wants to celebrate and move on. This is exactly where most projects quietly waste their hardest-won lessons.

Closure is the final phase, and it's the one teams skip most. It has two jobs. First, confirm the deliverable is actually complete and accepted — Priya and Tomás agree the thing does what the charter promised, and you formally wrap up, close the budget, release the team. Second, and this is the part that compounds over a career, you run a retrospective, also called a lessons-learned review: what went well, what went badly, what we'd do differently next time.

Renata runs Cartwheel's first real retro. The map engine estimate was off by 80% — so next project, they pad anything touching mapping. QA got the build too late — so next time QA joins in planning, not at the end. Nobody is blamed. The point is the upgrade, not the fault.

A project that ships but is never reflected on teaches you nothing. The same team makes the same mistake on the next one, and wonders why every project feels like the first. Closure is how a team gets better instead of just busier.

Worked example — Cartwheel's driver app, end to end

Watch one project walk all five phases.

Initiation. Tomás wants a driver app by quarter-end. Renata digs past the request to the real goal — cut driver churn with a one-handed route planner — and writes a charter: route planning, offline maps, delivery confirm are in; chat and payments are out. Priya and Tomás sign. Output: an agreed goal and scope.

Planning. With Marcus's estimates, Renata breaks it into six tasks, maps the dependencies (everything waits on the map engine), and lays it on a Gantt chart that exposes a pile-up behind that one task. Output: a realistic schedule, budget, and risk list.

Execution. The squad builds. Renata stops planning and starts unblocking — chasing Jamie's test environment, shielding the team from a mid-sprint feature request Tomás floats.

Monitoring & Controlling. Day three, the map engine is running long. Renata sees the drift on her chart immediately, pulls Jamie over to help, and gives Tomás an early heads-up rather than a deadline-day shock.

Closure. The app ships and Priya accepts it. Renata closes the project and runs a retro: pad mapping estimates, bring QA into planning earlier. Output: lessons that make the next project smoother.

One project, five phases, a different job for Renata in each. That's the map.