This is Part 6 of 7 in the Productivity Enhancement Series
- Part 1 — Foundation: The Productivity Stack · The Enemy of Productivity
- Part 2 — The Physical Layer: The Machine and the Room
- Part 3 — The Workflow Engine: The Workflow Engine · The Self-Improving Workflow
- Part 4 — The Knowledge System: PARA · Progressive Summarisation · The Operating System
- Part 5 — The Tactical Toolkit: The Tactical Toolkit
- Part 6 — JIT Project Management:
- Part 6.0 (this article): Just-in-Time Project Management (pull a project through the system only when it’s due)
- Part 7 — AI as a Worker: The Agentic AI Framework · From Chat to Continuous Worker · Persistent Memory
Table of Contents
- The problem with carrying every project at once
- Just-in-time, borrowed from the factory floor
- Just-in-time vs just-in-case
- How the system pulls a project forward
- Running it: a few active, the rest dormant
- Part 6 Takeaways
- Your JIT Task List
- Sources & references
The problem with carrying every project at once
By now the stack works: the workflow catches everything and the knowledge system feeds it. The failure that’s left is scope. People try to make progress on every project they’ve ever started, all at once, and the result is forty half-open loops, each generating a low hum of guilt, none actually moving. Carrying every project at once is how you stay maximally busy and minimally finished. Just-in-Time Project Management is the discipline of pulling a project into active work only when it’s genuinely due, and leaving the rest dormant without guilt. It’s the last term this series keeps from the original framework1, and it’s the one that fixes overwhelm.
Just-in-time, borrowed from the factory floor
The name comes from manufacturing. The old way (just-in-case) was to stockpile huge inventories of parts so you’d never run short. It tied up capital, filled warehouses, and most of the stock sat idle and went obsolete. Toyota’s just-in-time approach flipped it: produce and pull parts only as demand calls for them, holding almost no inventory.2 Less waste, less clutter, more responsiveness.
Your projects are the inventory. The just-in-case mind stockpiles open projects "so they're ready"; the just-in-time mind keeps almost all of them dormant and pulls one forward only when its moment arrives. The dormant projects aren’t abandoned, they’re archived or parked, costing you nothing, ready to activate when their deadline actually approaches. You hold a tiny “inventory” of active work and let real demand (a deadline, an opportunity) pull the next one in.
Just-in-time vs just-in-case
The same split explains why so much learning is wasted, and it’s worth seeing because it’s the same mistake in another costume.
Just-in-case learning is hoarding knowledge you might need someday: the course you bought and never finished, the pre-built curriculum you couldn’t stick with. ==The reason a pre-built curriculum is so hard to commit to is that it doesn’t match a problem you have right now.== It’s abstract, so it doesn’t stick, and you resent the time.
Just-in-time learning is learning the thing when a live project demands it. On-the-job, pulled by a real problem. You learn the specific React hook when the feature needs it, the specific clause when the contract hits your desk. It sticks because it’s immediately used, and it’s never wasted because you only ever learn what the work actually pulled for.3
This is why JIT project management and the Learning series are two faces of one principle: let real demand pull the work and the learning forward, instead of stockpiling either against a hypothetical future. Most “I should get ready” effort is just-in-case waste.
How the system pulls a project forward
When a project’s moment arrives, the rest of the stack assembles it for you. This is the payoff for building the lower layers.
- The project activates (a deadline approaches, or you deliberately pull it from the parked list).
- You pull its Resources just-in-time. Everything you filed under it in PARA, plus relevant maps, comes into the active project. You’re not starting from a blank page; you’re starting from everything past-you already gathered.
- You learn what it pulls for. Any skill gap the project exposes, you fill now, on the job, because now it’ll stick.
- You define the next action (Part 3.0) and execute, single project in focus.
- On completion, the whole thing sweeps to Archives, and the active inventory drops back down, ready to pull the next one.
The AI multiplier on JIT
This is where AI earns its place at the top of the stack. When you pull a project forward, an assistant can assemble the kit: gather the relevant resources and maps, draft the project plan and the first next action, and summarise what you already know about the problem. The blank-page cost of starting a project drops to near zero, which is exactly what removes the resistance that made you stockpile in the first place. And a fully repeatable project type can be handed to an agent to run, which is Part 7.
Running it: a few active, the rest dormant
The operating rules:
- Cap your active projects. A small number you can actually push on this week (many people find three to five is the honest ceiling). Everything else is parked, not active.
- Parked is a real, guilt-free state. A parked project isn’t a failure; it’s inventory waiting for demand. Reviewing the parked list is part of your weekly review: does anything need to activate yet? Usually the answer is no, and that’s fine.
- Let deadlines and opportunities do the pulling, not anxiety. The trigger to activate a project is “its moment has come,” not “I feel bad about it.”
- Finish before you start. Completing an active project (and sweeping it to Archives) is what frees a slot to pull the next one. ==The goal is a high completion rate, not a high open rate.==
The feeling you’re aiming for: a short list of things genuinely in motion, a long list of things safely waiting, and no guilt about the difference. That calm is the whole reward of the system, and it’s only possible because the layers beneath it mean nothing parked is ever lost.
Part 6 Takeaways
- Carrying every project at once is how you stay busy and unfinished. JIT pulls a project into active work only when it’s genuinely due.
- Borrowed from manufacturing: just-in-case stockpiles (open projects, unfinished courses); just-in-time pulls on real demand. Less waste, less clutter.
- The same split explains learning: pre-built curricula don't stick because they don't match a problem you have now; on-the-job learning does.
- When a project activates, the stack assembles it: PARA resources, maps, and a learn-what-it-pulls-for approach. AI drafts the kit so the blank page disappears.
- Run it with a capped active list, a guilt-free parked list, deadlines doing the pulling, and a finish-before-you-start rule.
- Aim for a high completion rate, not a high open rate. The reward is calm: a few things moving, the rest safely waiting.
Your JIT Task List
This week
- List every project you currently consider “open.” The number itself is probably the lesson.
- Pick the three to five that are genuinely active this week. Park the rest, explicitly and without guilt.
- For one parked project, confirm its resources are filed under it in PARA so future-you can pull it cleanly.
- Catch one piece of just-in-case learning (a course or “research” with no live project) and drop it until a project pulls for it.
- Add “review the parked list: does anything need to activate?” to your weekly review.
Sources & references
Footnotes
-
“Just-in-Time Project Management” is Tiago Forte’s term, kept from the source framework. It reframes project work as pulling resources and effort forward only as a project genuinely demands them, rather than maintaining many projects in parallel. It sits at the top of the productivity stack because it depends on the workflow and knowledge layers being in place. ↩
-
The just-in-time manufacturing method (the Toyota Production System) minimises inventory by producing and supplying parts only as downstream demand pulls them, reducing waste and holding cost. It’s the source analogy for pulling projects and learning on demand rather than stockpiling them. ↩
-
This connects to the Learning series: knowledge acquired in response to a concrete, current problem is retained far better than knowledge studied “just in case,” because it’s immediately retrieved and applied. The note that pre-built curricula fail to match your live on-the-job problem is the learning-side statement of the same just-in-time principle. ↩