I spent 26 years inside one institution. When I left, I found out how much of my follow-through had never been mine. Deadlines came from somewhere. Review came from somewhere. And when a task stalled, someone noticed. On my own, all three vanished at once, and the result was a growing pile of things I had genuinely started and never closed.
This is the system I built to replace what the institution used to supply. It is not motivation. It is a cap.
Why do you abandon projects halfway?
You abandon projects halfway because starting is free and finishing is not. Every new idea gets funded with attention the moment it arrives, while the half-built ones sit unowned. The fix is not more discipline. It is a hard limit on how many things you are allowed to have started at once.
Two documented effects make this worse than it feels:
- Unfinished work keeps charging you rent. Bluma Zeigarnik’s classic 1927 experiments found that interrupted tasks were recalled better than completed ones — the open loop stays active in memory. Replication attempts since have been mixed, so treat it as a useful description rather than a law, but the felt experience is familiar: ten open loops means ten background processes running while you try to work on the eleventh.
- You systematically underestimate what finishing costs. In the planning-fallacy studies by Buehler, Griffin and Ross (Journal of Personality and Social Psychology, 1994), students predicted their thesis completion dates and finished substantially later than their own optimistic estimates, even when asked to imagine worst cases. Every new start is priced with that same broken estimate.
So the abandonment is not a character flaw. It is arithmetic. You keep buying at a price you were never quoted correctly.
How many unfinished projects are you actually carrying?
More than you think. When I ran a scan of my own backups, it surfaced 41 tasks that had been started and abandoned mid-flight — not ideas, not someday lists, but work already opened. Until you count, the pile stays invisible and every new start feels affordable.
Forty-one. That number is what changed my mind, because I would have guessed six or seven. This is not unique to solo work either: the Standish Group’s long-running CHAOS reports have tracked cancellation and failure rates in professional software teams for decades. Their methodology is debated and the headline percentages should not be quoted as settled fact, but the direction is consistent — funded, staffed, deadline-bearing projects still get killed mid-flight. Teams with managers abandon things too. The difference is that teams count.
Before you change anything, count. A folder scan, a search of your files by modification date, a scroll through your notes app. Write the number down. The number is the intervention.
What is the 2-item rule?
The 2-item rule caps work-in-progress at two started items per project. Ideas stay unlimited — you can capture as many as you like. Only starting is rationed. A third item cannot begin until one of the two is finished, handed off, or deliberately discarded. The queue does the saying-no for you.
Two mechanics make a work-in-progress cap effective rather than merely restrictive:
- Little’s Law (John Little, 1961), the queueing result behind Kanban: in a stable system, average cycle time equals average work-in-progress divided by average throughput. Halve the number of things in flight and, if your throughput holds steady, each one finishes in roughly half the elapsed time. Fewer things started is literally faster finishing — provided you do not quietly slow down as you cut.
- Switching cost. The American Psychological Association, summarizing task-switching research by Rubinstein, Meyer and Evans (2001), has cited switching costs of up to roughly 40% of productive time. That figure came from short laboratory tasks and is routinely over-applied to a whole working day, so take the direction rather than the decimal: every extra open item is a tax you pay before any of them move.
| Situation | Unlimited starting | 2-item cap |
|---|---|---|
| A new idea arrives | Work begins the same day | Captured instantly; started only if it displaces something |
| Idea capture | Unlimited | Unlimited (this never changes) |
| Saying no | Requires willpower in the moment | Handled by the queue, not by mood |
| Stalled work | Silently accumulates | Visible, tagged, and reviewed |
| Abandonment | Happens by drift, feels like failure | Happens by decision, treated as maintenance |
| Cost of a third start | Invisible | Explicit: something must close |
How do you enforce the cap when a new idea arrives?
At the moment the idea arrives, not later. The idea goes into the ledger immediately, so nothing is lost. Then one question gets asked and answered in a single line: which of the two open items closes first, or does this new one displace one of them? Capture is automatic; starting needs an answer.
The timing is the whole trick. Enforced at review time, a cap is a scolding session where you look at everything you failed to finish. Enforced at arrival, it is a single cheap question asked while the idea is still exciting and you are still willing to trade.
Three rules keep it from becoming bureaucracy:
- Never block capture. The idea is always written down, in full, immediately. Rationing capture would just push ideas into your head, which is the worst storage available.
- Answer in one line. Displace item A, or park this behind A and B. If the answer takes a meeting with yourself, the idea was not urgent.
- The person, not the rule, has the last word. If you decide the new thing genuinely outranks both, displace one and say which. The cap exists to make the trade visible, not to win arguments.
What changed after the cap?
The pile stopped growing, and stalled work became visible instead of shameful. I have not measured a completion rate and will not invent one. What changed is concrete: new ideas now arrive as ledger entries rather than open tabs, and every stall gets a reason attached instead of quietly disappearing.
The second change matters more than the first. Before, a stalled item just went quiet, and I would rediscover it months later with no memory of why it stopped. Now every stall carries the reason it stopped, which turns restarting from an act of archaeology into a lookup.
Which stalled projects should you restart first?
Restart the ones blocked on a one-line decision. In my ledger every stalled item is tagged by what it waits on: a decision, another person, an external reply, or me. Decision-blocked items are the cheapest progress available — one sentence unblocks them — so they get cleared before anything else.
| Blocked on | What it actually means | Cost to clear | Priority |
|---|---|---|---|
| A decision | You never chose between two options | One sentence | Clear first, always |
| Someone else | Waiting on a person you can reach | One message | Clear second |
| An external reply | Waiting on a party outside your control | Nothing but patience | Park with a follow-up date |
| Me | Real work remains; nothing is blocking it | Actual hours | This is what the 2-item cap protects |
It is easy to assume your stalled projects are all blocked on time. Tag them honestly and, in my own ledger at least, a surprising share turned out to be blocked on a decision I had been avoiding for months. Those are free wins sitting in plain sight.
When should you abandon a project on purpose?
When an item has gone untouched for 30 days. Those surface weekly as discard candidates, and most of them get discarded. Abandonment handled this way is maintenance, not failure — the item leaves the list with a decision attached, so it stops taxing attention it was never going to earn.
This is the part people resist, and it is the part that makes the cap survivable. If nothing ever leaves the list, the cap becomes a prison. Deliberate discard is what keeps the two slots liquid. A list you trust is one you have pruned; a list you have never pruned is one you have stopped reading.
Why don’t your notes help you finish?
Because they are indexed by topic instead of by symptom. A note titled with its subject is only findable if you already remember it exists. A note whose index line describes the problem you were having is findable at the exact moment the problem recurs, which is the only moment it matters.
I learned this the hard way. I built and shipped working software without being able to read code, and the only reason it worked was that I wrote down every point of failure as it happened. But the early notes were nearly useless, because I filed them by topic. Rewriting each index line to describe the symptom — what went wrong, what it looked like — turned a dead archive into something that answers questions. A knowledge system compounds only when it can be found under pressure.
How do you stop starting projects and not finishing them, step by step?
Count what you have already started, tag each item by what it is blocked on, cap starts at two per project, and route every new idea into a capture list instead of into your day. Then review untouched items weekly and discard on purpose rather than by drift.
One research note worth borrowing: Gollwitzer and Sheeran’s meta-analysis of implementation intentions, covering 94 independent studies, found that specifying when, where and how you will act produces a medium-to-large improvement in goal attainment over intention alone. The cap tells you how many things you may start. Implementation intentions tell you when the two you chose actually get worked on. Use both.
My own formula for this is Belief × Thinking × Action. It is a product, not a sum — a strong belief multiplied by zero finished actions is still zero. The cap exists to keep that third term from collapsing.
If you want the ledger and the cap to live somewhere other than a text file, the VisionDream app is designed around this idea — turning goals into daily habits rather than into a longer list of things you have started. And if you want the longer version of how I rebuilt structure after leaving a 26-year career, it is in my book, Why Do I Fail While Others Succeed?
What if two items feels impossibly restrictive?
Then you are measuring the cap against your intentions instead of your output. If you are carrying ten open projects, you are probably not finishing ten; you are finishing one slowly while nine decay. The cap does not reduce what you complete. It reduces what you pretend to be doing.
Start with three if two feels punitive. Count again in a month. The number that matters is not the cap — it is whether your pile of abandoned work is growing or shrinking. Mine was 41 and invisible. Yours is a number too, and finding it is the first honest thing you can do today.