Most tracking tools are built for work that is moving. Stalled work is a different problem: it is quiet, it does not generate notifications, and it does not fail loudly. It just sits there. I learned this the hard way after leaving a 26-year career inside one institution and discovering that I had to rebuild, from nothing, the structure the institution used to supply for free — deadlines, review, and someone who noticed when a task stopped moving.
What is the best way to track stalled projects?
The best way to track stalled projects is a single plain-text ledger where every stuck item records what it is blocked on — a decision, another person, an external reply, or you. Habit apps track whether you showed up; a ledger tracks why you stopped. Only the second one tells you what to do next.
That distinction is the whole article. A habit app answers did I work today? A ledger answers what is standing between this project and its next move? Those are not the same question, and the second one is the one stalled work actually poses.
Why do habit apps miss stalled projects?
Habit apps model frequency, not blockage. Their data structure is a streak: done or not done, per day. A stalled project is neither — it is a task with an unmet precondition. Because most trackers have no field for that precondition, the reason a project stopped is never recorded anywhere, so it is never resolved.
This is a claim about product design, not about willpower, and it is checkable. Below is a comparison drawn from each product’s published feature documentation — not a usage test. The question asked of each tool is narrow: can it natively record what a specific task is blocked on?
Which trackers can record what a task is blocked on?
| Tool | Primary model | Native “blocked by” field? | Practical workaround |
|---|---|---|---|
| Streaks | Daily habit streaks | No | None — no project object exists |
| Habitica | Gamified habits, dailies, to-dos | No | Tags; blockage is invisible to scoring |
| TickTick | Tasks + habits + timer | No | Tags or a naming convention |
| Todoist | Tasks, sub-tasks, priorities, labels | No | A “@waiting” label, maintained by hand |
| Notion | User-built databases | Not by default; you can build one | Add a relation or select property yourself |
| Jira | Issue tracking with dependencies | Yes — “is blocked by” link, plus flags | Native, but heavy for personal goals |
| Plain-text ledger | One line per stuck item | Yes — you define the field | Not applicable |
Feature sets change; verify against current documentation before switching tools. The pattern, though, is stable: consumer habit and to-do apps model cadence, project trackers model dependency, and almost nothing in the consumer tier does both. If your stalls are mostly “I did not show up,” a habit app is the right tool. If your stalls are mostly “I am waiting on something,” it is structurally the wrong one.
What does a plain-text ledger actually record?
A plain-text ledger is one file that is the single source of truth for stopped work. Each line holds the item, the date it stalled, and one tag for what it is blocked on: a decision, another person, an external reply, or me. When a project document and the ledger disagree, the ledger wins.
The four tags do the real work, because they sort by cost of restart:
- Blocked on a decision — one line of thinking unblocks it. This is the cheapest progress available anywhere in the system, so these get cleared first, always.
- Blocked on another person — needs a nudge, not effort. A short message is usually the entire task.
- Blocked on an external reply — genuinely out of your hands. Do not re-read it daily; set a date to chase.
- Blocked on me — real work. This is the only category that costs a work session, and it should be the smallest one.
Before I tagged items this way, all four looked identical on a list: overdue. Sorting by blocker turned what felt like a wall of failure into a short queue of one-line answers and a shorter queue of actual work.
Why does the index line have to name the symptom?
Because you search for symptoms, not topics. A personal knowledge system only compounds when each index line describes what went wrong — “deploy fails after adding second environment variable” — rather than the subject area, “deployment notes.” Topic labels are unfindable at the moment you need them, which is the only moment that counts.
This rule is what makes a text file beat a prettier tool. Search is only as good as the words you wrote down, and when you are stuck you type the symptom you are experiencing, never the category an organized person would have filed it under.
The same habit is why I was able to build and ship working software without being able to read code. I could not debug by reading a stack trace. What I could do was write down every point of failure as it happened, in the language of the failure itself. The log became the map. That is the failure-log habit, and no streak counter substitutes for it.
What does the research say about unfinished tasks?
The published work points in a consistent direction, though it is uneven in strength: unfinished tasks tend to occupy attention until they are given a plan. Zeigarnik’s classic studies reported that interrupted tasks were recalled better than completed ones, and later work suggested the intrusion fades when a concrete plan is made — not when the task is finished. Writing down the next move may itself be the relief. Treat the studies below as a useful frame, not as settled measurement.
- Bluma Zeigarnik’s 1927 experiments reported that interrupted tasks stayed more mentally available than completed ones — the origin of the “open loop” idea. Later replication attempts have produced mixed results, so the size and reliability of the effect remain debated.
- Masicampo and Baumeister, writing in the Journal of Personality and Social Psychology (2011), reported that unfulfilled goals intrude on thinking, and that forming a specific plan reduced those intrusions — without the task being done.
- Gollwitzer and Sheeran’s meta-analysis in Advances in Experimental Social Psychology (2006), covering roughly 94 independent tests, reported that implementation intentions — if-then plans naming a cue and a response — had a medium-to-large effect on goal attainment.
- Asana’s Anatomy of Work Index, a vendor-published survey of knowledge workers rather than peer-reviewed research, has reported that a large share of the working day goes to coordination overhead rather than skilled work — the general category of overhead that unresolved blockers add to.
Read together, these point the same direction a ledger does: the fix for a stalled item is less likely to be more motivation than a recorded, specific next action attached to a named obstacle.
How many projects should you have started at once?
Two per project area, in my system. I cap work-in-progress at two started items after a backup scan turned up 41 tasks abandoned mid-flight — every one of them started with enthusiasm and none finished. Ideas stay unlimited and always get captured. Only starting is rationed.
Forty-one is a number I did not believe until I saw the file. None of those tasks had failed in any dramatic way. They had simply been overtaken by a newer, more exciting idea, and no tool anywhere in my setup was designed to notice that. A habit app would have shown a healthy streak the whole time, because I was working — just never on the same thing twice.
When a new idea arrives while both slots are full, the ledger forces a one-line question: close something, or explicitly defer this? Either answer is fine. The unacceptable outcome is the third silent start.
When should you discard a stalled project instead of reviving it?
Treat abandonment as maintenance, not failure. Items untouched for 30 days surface weekly as discard candidates, and in my own practice most of them do get discarded. A ledger that never shrinks stops being read, and a list you have stopped reading has already failed at its only job — being the place you look.
Discarding is not giving up on ambition. It is the maintenance that keeps the remaining lines trustworthy. If a project mattered, it will come back; ideas are cheap to recapture and impossible to recapture from a list you have learned to ignore.
Which should you choose: a habit app or a ledger?
Use both, for different jobs. A habit app enforces the daily repetitions that build capability; a ledger holds the projects that stopped and names why. If you can only run one, run the ledger — daily consistency without a record of blockers produces motion, and motion is exactly what stalled projects already have.
| Question | Habit app | Plain-text ledger |
|---|---|---|
| Did I show up today? | Strong | Weak |
| Why did this stop? | Not modeled | Core field |
| What is the cheapest next move? | Not modeled | Sort by blocker |
| How many things have I started? | Hard to see | Visible at a glance |
| What should I drop? | Not modeled | 30-day sweep |
| Findable a year later? | Depends on export | Yes — grep a text file |
| Motivation and momentum | Strong | Neutral |
The formula I rebuilt my working life around is Belief × Thinking × Action. It is a product, not a sum — a zero anywhere zeroes the result. A stalled project is usually not a belief problem or an action problem. It is a thinking problem: nobody ever wrote down what it was waiting for.
If you would rather have that structure handed to you than build it in a text file, the VisionDream app is a vision and goal app that turns goals into daily habits — the cadence side of this pairing. And if you want the longer argument for why the same people keep stalling in the same place, it is in the book Why Do I Fail While Others Succeed?
Start smaller than feels serious: open one text file, write down every project that has not moved in two weeks, and tag each with what it is blocked on. Then clear every item blocked on a decision. That first pass is short, and it usually closes more than a month of accumulated guilt.