How do I decide which project to drop when everything feels important?

TL;DR: Stop asking which goal matters least in the abstract. Work out how much time and attention you have, score every project against the same few criteria, and pause or drop the one with the weakest fit and the mildest consequence if it slips. Often you don't need to kill anything: you can slow, pause, defer or shrink a project instead.^[1][2]

Measuring different values that project has to you can be helpful.

Why does everything feel equally important?

Because you are judging each project on its own, against its own goal. Judged alone, almost any goal sounds worth doing.

Project governance looks at it differently. It treats a project as delivering "the defined scope within the defined constraints, such as cost, time, quality and risk".^[3] Those constraints are what you are short of. For each project, the useful question is whether it earns its share of your limited week, and you can only answer that once the limits are written down.

What should you measure before comparing projects?

Measure your capacity first, then the demand each project puts on it. If total demand is bigger than capacity, something has to move, whatever you feel about it.

Start by writing each project as a one-sentence outcome. "Launch the client portal by June" works. "Work on the portal" doesn't, because an activity can go on forever. If you write the outcome and notice it no longer serves anything you currently care about, mark it for pausing straight away.

Then estimate what each project needs per week: hours, money, focused attention, specific skills, and any fixed deadlines. Add the hours up and compare them with the hours you have, after meetings, admin, sleep and the rest of life.

Portfolio research is blunt about this: "Constraints such as budget and resources significantly influence project selection."^[4] The same work points out that budgets, people, benefits, risks, costs and the relationships between projects all affect which ones can run together.^[4] For one person, the budget is mostly hours and attention, and both are smaller than they feel on a Monday morning.

Say you have four live projects that together need 35 focused hours a week, and you have 20. No amount of prioritising inside that plan will make it fit. One or two of them have to slow down or stop.

How do you score projects fairly?

Use the same small set of criteria for every project and give each one a number. Consistency matters more than which criteria you pick.

The UK government's project delivery standard says new work should be "categorised and evaluated, based on their degree of strategic fit, expected benefits, efficient use of funds and risk".^[5] It also asks how each candidate affects existing work and what stakeholders think.^[5] That translates well to personal projects.

A workable version: score each project from 1 to 5 on

• strategic fit: how directly it serves a goal you hold now
• benefit: what you gain when it's done (income, a degree, a skill, a relationship)
• urgency: what a delay costs
• risk reduction: whether it removes a threat, like a compliance problem or a client about to leave
• dependency value: whether other work is blocked until it's done

Then handle effort separately. Either score it and subtract it, or divide the total benefit score by the estimated hours. A project with a decent score and a small cost can beat a high-scoring monster.

Government guidance on requirements lists several ways to prioritise, including simple or weighted scoring, stakeholder rankings and a top-ten technique.^[2] Any of them gives you a firmer basis than deciding by mood.

What would happen if this project slipped by a month?

This is the most useful single test. For each project, write down the concrete harm a one-month delay would cause.

Be strict about what counts. A missed legal or submission deadline counts. Lost revenue counts. A safety risk counts. Another project that can't start until this one finishes counts. "People will be disappointed" is weaker, and "I'll feel behind" is weaker still.

The projects with the vaguest answers are your candidates. If one of them also scored low on strategic fit, it is probably the one to pause.

A short decision rule: drop or pause the project with the weakest combination of current fit and measurable cost of delay, especially if it eats a scarce resource or overlaps with another project.

Do you have to drop the project completely?

Usually no. Stopping is one option among several, and it's often the most expensive one.

The London Fire Brigade's reprioritisation paper frames the choice as identifying "project work to slow, pause, or defer".^[1] It also recommends putting a number on the impact of each option so the trade-off is explicit.^[1] Requirements guidance adds de-scoping: "Low priority requirements can be descoped and high priority ones brought forward."^[2]

For a personal project, that gives you a ladder:

• De-scope: keep the project, cut it to its core. Ship the portal with login and invoices, leave the dashboard for later.
• Slow: give it two hours a week instead of ten.
• Defer: set a start date after your current crunch ends.
• Pause: stop now, with a written condition for restarting.
• Stop: close it and tell anyone affected.

Pick the lowest rung that frees enough capacity. If cutting one project to half its scope closes the gap, you don't need to stop anything.

What about projects you've already put months into?

Ignore what you've spent. The hours and money are gone whether you continue or not. The only question is whether the project earns its future cost.

This is hard, because a half-finished project feels like a debt. It helps to ask: if someone offered you this project today, at its remaining cost, would you take it? If the answer is no, the past effort is no reason to continue.

There is one honest exception. Some projects are expensive to restart, because you lose context and momentum, or miss a window with a collaborator. Protect those only when their strategic value justifies the ongoing cost. Otherwise pause them, and write a restart note while you still remember where you were. Note what's done, what's next and which file to open first.

How do you make the decision stick?

Write it down with a review date. Decisions that live only in your head get reopened every time you feel guilty.

For each project you change, record:

• what you decided (de-scoped, slowed, deferred, paused, stopped)
• the restart condition, if any ("when the thesis is submitted")
• a review date
• who needs to know, and when you'll tell them

Then tell those people. A short message saying a project is paused until a specific date is easier for most people to accept than silence and missed check-ins.

On the review date, rescore. Circumstances change, and a paused project may now be the most important thing on the list.

Turning the decision into a week you can follow

Once you know which projects stay, the remaining risk is that they all fight for the same hours again. Breaking each surviving project into jobs with minute estimates shows quickly whether the plan fits your real time.

TimeBud does this part: it breaks a goal into small jobs with estimates and dependencies, then plans today around your calendar, filling only open time and leaving breathing room after events. If the jobs don't fit the week, you see it before Friday, which is a good moment to revisit the de-scoping ladder above.

Try TimeBud free