Leading projects

Lead work that runs through other people and teams: shape it so it ships, track risks and dependencies, and report honestly.

Also called one-pager, project charter

What: A one-page document stating the problem, why now, the time budget, goals, non-goals, owners and how success will be measured.
Why: It aligns every team before work starts and gives you something to point to when scope starts to grow.

Also called Shape Up, time box

What: Deciding first how much time a problem is worth, then shaping a solution that fits that time, instead of estimating a fixed scope.
Why: Fixed time with variable scope makes projects finish. It forces the trade-off conversations early rather than at the deadline.

What: Removing or deferring parts of a project, openly and in writing, so the most important part ships on time.
Why: Scope cut early and announced costs little trust; a late surprise costs a lot. It is a normal leadership tool, not a failure.

Watch out

Quietly dropping features or quality near the deadline without telling stakeholders.

What: Checkpoints that each deliver something working you can demo, such as one end-to-end flow for internal users, rather than finished layers like "backend done".
Why: Demoable milestones show real progress and expose integration problems early, when there is still time to adjust.

Watch out

Milestones that are 90 percent done for weeks because nothing integrates until the end.

Also called RAID log, risk register

What: A living list of what could go wrong and what you need from other teams, each with an owner, a date and a mitigation, reviewed weekly.
Why: Most cross-team projects slip on dependencies, not on code. Tracking them makes asks visible early enough for other teams to plan.

Also called RAG status, red amber green, status update

What: A short written update saying whether the project is on track, at risk or off track, why, what changed and what help is needed.
Why: Leaders skim. A consistent format with the status and the ask at the top lets people act without a meeting.
Example: Status: at risk. Payments API contract slipped one week. Mitigation: mock contract for now. Ask: payments team confirms final schema by Friday.

Watch out

Reporting green until the week before launch, then jumping to red.

What: The observation that adding people to a late software project makes it later, because new people need onboarding and communication paths multiply.
Why: It reminds leaders that cutting scope or moving dates usually rescues a late project better than adding headcount.

Go deeper