How to Plan a Project

Start from the request, not the template

Most planning goes wrong in the first ten minutes, before anyone opens a scheduling tool. Someone hands you a request, something like "we need the new signup flow live before the campaign," and the instinct is to open a template and start filling in dates. The dates you fill in at that point are fiction, because you do not yet know what "the new signup flow" actually includes, who is free to build it, or what it depends on.

A plan is a sequence of answered questions, in a specific order: what is this, what does it depend on, who can do it and when, and only then, by when. Skipping ahead to the date is the single most common cause of a plan that is wrong before anyone has done a day of work on it.

Scoping without a scoping meeting

Scope creep has a bad reputation it doesn't entirely deserve. Most additions to a project are reasonable on their own. The problem is never one addition; it is thirty additions each individually approved by whoever was in the room that day, none of them weighed against the date. Written scope does not prevent additions. It makes each one a decision with a visible cost, instead of an invisible one.

You do not need a formal scoping meeting to get this. A short written note (what's in, what's explicitly out, and who signed off) attached to the project is enough. The value is not in the ceremony, it's in having something to point back to in week six when someone asks for "just one more thing."

Sequencing: find the handful that matter

New planners tend to draw dependency arrows everywhere, because in principle almost anything could affect almost anything else. In practice, a project of forty tasks usually has five or six dependencies that actually constrain the schedule: the design review that blocks three engineers, the data migration that has to finish before testing can start, the external vendor whose delivery date you don't control.

Find those few real constraints and the rest of the plan is just a list, orderable however capacity allows. Trying to sequence everything produces a chart nobody can read and a plan that is no more accurate for the effort.

Capacity: the step most plans skip

It's common to build a schedule against a name, something like "Priya will handle the integration," without checking whether Priya has any uncommitted time in that window. She might already be allocated to two other projects and a fixed block of support rotation. The schedule looks complete and is wrong before it starts.

Checking real capacity means looking at hours, not people: how many productive hours does this person actually have free across the plan's timeframe, after leave and existing commitments. It's tedious to do by hand and one of the more mechanical parts of planning to automate. A board that already knows who is assigned to what elsewhere will tell you this in seconds instead of a spreadsheet exercise.

A first draft beats a perfect plan

The instinct to keep refining a plan before showing anyone is understandable and usually counterproductive. The team that will do the work has information you don't: they know the sequencing assumption that's wrong, the dependency you missed, the estimate that's off by half. A draft in front of them for twenty minutes surfaces more correction than another two days of solo refinement.

Once the draft has survived that conversation, the plan's real job begins: staying current as the actual work diverges from it, which it always will to some degree. A plan that cannot absorb that divergence without a full rewrite was too rigid to begin with.

• Is scope written down somewhere more durable than a chat message?
• Have the real dependencies (not every conceivable one) been identified?
• Is the schedule checked against actual free hours, not headcount?
• Has someone who will do the work seen the draft before it became final?
• Is there a plan for keeping the plan current, or does it go stale after week one?

Keeping the plan honest after day one

The plan you draft on day one is the least accurate version of it you'll ever have. It's the version built with the least information. What matters more than getting it right initially is whether it can be corrected cheaply as reality diverges from it, which is mostly a question of whether anyone will notice the divergence early.

This is where a lot of planning effort gets wasted: a beautifully sequenced project plan that nobody updates, because updating it means opening a separate document and manually moving dates around. ShipSprint keeps this cheap by building the plan out of the board itself: a project is planned against each person's real capacity from the start, and because delivery forecasts are recalculated from the team's measured velocity as work actually completes, a date drifting off track surfaces weeks before its due date instead of on it.