Project Management Best Practices

Not another methodology comparison

This isn't a case for Scrum over Kanban, or waterfall over agile. That choice matters less than most debates about it suggest, and depends heavily on the specific work. What follows are practices that hold up regardless of which one a team runs: they're about how honestly the plan tracks reality, not about which ceremony produced the plan in the first place.

A team running the most fashionable methodology badly will still miss dates. A team running an unfashionable one well, with these habits intact, usually won't.

Plan against capacity, not headcount

"We have six engineers" is a headcount. "We have roughly four and a half engineer-weeks available next sprint, after two people's planned leave and the twenty percent everyone spends on support" is capacity, and it's the number a realistic plan actually needs. The gap between the two is where a plan that looked fine on the whiteboard quietly becomes a plan that was wrong before anyone started.

This isn't about padding estimates for safety. It's about using the real number instead of the convenient one, which usually means the plan commits to less than it feels like it should, and turns out to be right more often as a result.

Forecast from history, not from confidence

An estimate is a person's judgement about how long something will take, and it's systematically optimistic: people estimate the work they can picture, not the interruptions, reviews and rework they can't. A forecast, by contrast, takes how much a team has actually completed per cycle and projects it forward. It requires no discipline and no optimism from anyone involved, because it's a calculation on what already happened.

Teams that track their real completion rate and forecast from it consistently predict delivery better than teams that simply try to estimate more carefully. If one habit on this page is worth adopting first, this is usually it.

Make bad news cheap

The single biggest determinant of whether a project recovers from a slip is how early it's raised, and that depends entirely on what happens to the person who raises it. If flagging a risk gets treated the same as causing one, people will wait until the risk becomes undeniable, which is also the point at which it's most expensive to fix.

The practical version of this: react to an early warning by asking what would help, not by asking who's responsible. Teams notice within a couple of cycles which response they're going to get, and adjust their reporting accordingly.

This compounds with capacity planning and forecasting rather than sitting apart from them. A forecast built on real throughput will eventually show a date slipping on its own, without anyone needing to announce it, which takes some of the social risk out of the announcement, since the number said it before a person had to.

A quick self-check

• Is next sprint planned against actual availability, or against a headcount number that ignores leave?
• Are delivery dates calculated from measured throughput, or from someone's confidence?
• Did the last risk get raised weeks early, or on the day it became unavoidable?
• Is there a real cap on work in progress anywhere on the board?
• Could someone new find why a key decision was made without asking the person who made it?

Where the tool fits

These practices are cheap in principle and expensive in practice, because most of them require someone to keep updating something. ShipSprint tries to make the update itself close to free: work is planned against real capacity rather than headcount, delivery forecasts come from the team's own measured velocity as sprints complete, logging a day's hours takes about five seconds next to the task just finished, and a built-in wiki keeps decisions next to the work they affect, with page history. None of that replaces the habits themselves. It just takes away the excuse for skipping them because they were too much trouble to keep up.