A mind map is the right tool for the first two hours of a project and the wrong tool for the rest of it. It is very good at the question "what does this project consist of, and what depends on what", and bad at dates, assignments and progress, which are what the following six months are made of.
So the useful workflow is not "plan the project in a mind map". It is: map the scope, decompose it until the leaves are estimable, then export the leaves into whatever actually tracks the work. The map's job ends at the handover, and it stays useful afterwards as the thing you re-read when someone asks why a task exists.
Branch by deliverable, not by phase
The default structure is Discovery → Design → Build → Test → Launch, and it is almost always the wrong one. Phase branches describe how a project moves, not what it produces, so every deliverable ends up split across five branches and you can never see any one of them whole.
Branch by the things that will exist when you are finished:
# Website relaunch
## Content
## Design system
## Build
## Migration
## Launch comms
Each of those has an owner, a definition of done, and a clear "is this finished" test. A phase does not.
The exception is a genuinely sequential project, such as a construction schedule or a regulatory submission, where the phase is the deliverable. There, use a timeline layout rather than a radial one, so the order is drawn rather than implied.
Decompose to the estimable leaf
Keep breaking each branch down until you reach the point where you can say how long a leaf takes without arguing about it. That point is the bottom of the map, and finding it is the whole exercise.
Two signals you have gone far enough:
- A leaf is one person's work, in one sitting or one day. If two people are needed, it is two leaves and a handoff.
- Estimating it produces a number rather than a discussion. "Between two days and two weeks" means the node still contains an unanswered question, so split it at the question.
Two signals you have gone too far: the map has more than about a hundred leaves, or the leaves have become a checklist of steps rather than units of work. Decomposing "write the migration script" into eight lines of pseudo-code is transcription.
Three to four levels is the usual landing point. Deeper than that on one branch usually means that branch is a project of its own and wants a separate map.
The branches people forget
Add these four to every project map. They are the four sources of overrun, and they are missing from most plans because none of them is anyone's deliverable.
- Dependencies on other people. Every place the project stops until someone outside it responds. Legal review, an API key, a client sign-off. Give each one a name and a lead time.
- Unknowns. The things you cannot estimate yet. Do not leave them out because they are unestimable. That is precisely why they need to be visible, and a branch of them is the honest version of the plan.
- Not doing. Explicit scope exclusions. This branch prevents the most expensive conversation on any project, which is the one in month four about whether something was always in scope.
- Done means. The acceptance criteria for the project as a whole. Written at the start, when it is still cheap to disagree about them.
Cross-link the dependencies
Hierarchy shows containment; it cannot show that the migration cannot start until the content model is signed off. That fact lives between branches, and it is the fact that determines the schedule.
Draw those links. Then read the map for two things:
Nodes with many incoming links are the bottleneck. That is the thing to start first, regardless of where it sits in the plan, and it is usually not the thing anyone wanted to start with.
A chain of links four or five long is your critical path, roughly. A mind map will not compute it for you, but seeing the longest chain is enough to know which branch has no slack in it.
Cross-links between any two topics are what make the dependency layer possible, and checkboxes whose progress rolls up the branch mean each deliverable reports its own completion. Eight layouts, so a sequential project can be drawn as a timeline and a scoping map as a radial one.
What it doesEstimating on the map
Do it bottom-up and do it in ranges. Put the estimate on each leaf, let the branch total roll up, and resist the urge to reconcile the total with the date you were given. The gap between those two numbers is the most useful output of the whole exercise, and averaging it away destroys it.
Two habits worth keeping:
Estimate in ranges, not points. "3–8 days" carries the uncertainty that "5 days" throws away, and the width of the range tells you which leaves need more thought.
Add the coordination cost explicitly. A project of thirty tasks across four people is not the sum of thirty estimates. Reviews, handoffs and waiting are real work, and a branch for them is more honest than a percentage buffer nobody believes.
Then get out of the map
This is the step people skip, and skipping it is why "we planned it in a mind map" tends to end badly.
Export the leaves to a task tracker. Most mind map apps export Markdown or OPML, and most trackers import Markdown checklists, so this is a two-minute job. What the tracker does that the map cannot: assign owners, hold dates, show what is late, and be updated by six people at once.
Keep the map, though, and keep it read-only. Its remaining job is to answer "why does this task exist" and "what breaks if we cut this", which no task tracker can answer because both questions are about the structure the tracker flattened.
Re-open it for editing only at scope changes. A map maintained daily alongside a tracker is two sources of truth, and one of them is always wrong.
Planning a project alone
Slightly different rules, and better ones. Build the map in one sitting, do not decompose past two levels, and put dates only on the things with external deadlines.
The value for solo work is almost entirely in the "not doing" and "unknowns" branches, the two things that stay invisible when the plan is in one person's head, and the two that quietly consume a solo project.