When a Project Runs Late, Reduce the Feature List First

When a personal project runs late, adding more time is the easiest response.

Another two hours tonight, another half-day at the weekend. The feature list stays intact while the calendar keeps yielding. For someone who already has a job, this can become a second job with no closing time.

Some work really does need more time. The question to examine first is whether the extra hours finish the original work or feed a project that keeps adding features.

More time can grow the scope

In the "Set Boundaries" chapter of Shape Up, Basecamp describes a time budget: decide how much the problem deserves, then design a solution that fits.

This reverses listing features first and estimating their duration afterward. Time is fixed while scope can change. The book describes one-to-two-week and six-week budgets for team projects. It does not establish a general rule that eight hours of unfinished work should be cut to four.

One example is straightforward. With a week left, the author can fix typos or add a section. Leaving out the extra section preserves time to improve what is already there.

The reduction concerns additional scope. The quality of the retained work still matters.

A time budget brings the trade-off forward.

Fix the budget, then choose the scope

For a side project, consider a hypothetical four-hour weekend budget to test whether one person can complete a document-submission flow.

This round might need only a form, with notifications sent manually and results checked by hand. Accounts, dashboards, and full automation can wait. The version answers one question: will someone use this flow, and where does it become difficult?

Four hours is only an example. It could be two hours or two days. A budget does not remove irreducible work or justify cutting security checks, data integrity, or legal requirements.

If the smallest useful result still does not fit after those conditions are preserved, there are honest choices: narrow the problem, use the round to investigate a key risk, or accept a larger budget. No rule requires a barely usable product within four hours.

This differs from simply lowering quality. There can be fewer features, but the promised step must work all the way through. Documents arriving and their status being retrievable complete the experiment. A polished page alone establishes only that the page exists.

I prefer each round to end with an observable result and a clear account of what remains undone. The information gained can then determine whether another round is worthwhile.

Spare time is limited already. Asking the feature list to respect that fact makes a more workable plan than asking every evening to stretch indefinitely.