In his "Discourse on the Method" Descartes formulated four rules of thinking. The second reads: divide each of the difficulties under examination into as many parts as possible and as may be necessary to resolve them better. Almost four centuries have passed, and humanity has not come up with a better way to fight complexity. We have simply given it new names. In project management one of them is WBS, the Work Breakdown Structure.
It sounds bureaucratic, I know. An abbreviation from a textbook that people pass an exam on and forget. But in practice it is one of a manager's most underrated tools. And I want to explain why.
The brain cannot think about big things
The human brain copes perfectly well with a small number of things at once. Psychologists argue about the exact figure, but they all agree it is small: a handful of items, not dozens. When You try to think about the project "build an online store" as a whole, the brain sees a foggy cloud. It cannot estimate it, cannot plan it, cannot understand what is inside. So it either panics or pretends everything is clear.
Both options are bad. Panic paralyses. False confidence leads to an estimate of "about three months" that later turns into a year. There is only one way out: cut the cloud into pieces that fit in your head. That is decomposition.
How a WBS works
A WBS is a tree. At the top is the whole project. On the next level, its major parts. Each part is divided into smaller ones, and so on until the bottom level consists of work packages that can be clearly estimated, assigned to a specific person and checked for completion.
Take the same online store. The first level: catalogue, cart and checkout, payment, customer account, admin panel, integrations, infrastructure, launch. The catalogue divides into category structure, product page, search, filters, product import. Product import divides into file format, upload, error handling, price updates. And at this level You can already say: "upload and import error handling will take three days".
A few rules distinguish a useful WBS from a formal one.
- The 100% rule. The children add up to the parent. No more, no less. If something is not in the tree, it is not in the project, and no time or money has been allocated for it.
- Decompose deliverables, not activities. The nodes of the tree are what must come out, not what must be done. "A payment form that accepts cards" rather than "work on payments".
- Sensible depth. A work package should take from a day to a couple of weeks. Smaller, and You drown in micromanagement. Larger, and You are back to a cloud that cannot be estimated.
The main value: finding what was forgotten
The most valuable thing a WBS gives You is not a pretty diagram but the moment, while building it, when someone says: "Wait, who is going to migrate the data from the old system?" Or: "Is training the client's staff in the project at all?" Or: "Where is our testing under real load?"
Every project contains invisible work that nobody thinks about until it is time to do it. Data migration, server setup, documentation, user training, fixing what turns up during acceptance. This is exactly the work that eats deadlines, because it was not in the plan. A WBS drags it into the light before the deadline is named and the contract is signed.
A project almost never fails because of what was in the plan. It fails because of what was not.
What else decomposition gives You
Once the project is broken into clear pieces, You can hang everything else on them. Estimates: adding up small estimates is more accurate than guessing one big one. Responsibility: each package has a specific owner, and there is no "I thought he was doing it". Risks: You can see which packages depend on external factors, on the client, on third-party services. Control: progress is measured in closed packages, not in a feeling of "we're somewhere around seventy percent".
There is also a pleasant side effect: the client understands what he is paying for. Instead of one line saying "store development" he sees a structure and can decide for himself what to remove if the budget does not add up.
The fractal nature of the world
This topic is especially close to me, because our generator is called Fractal for a reason. A fractal is a structure in which each part resembles the whole. A good decomposition of a system works the same way: a project consists of modules, modules of screens and entities, screens of fields and actions, and the same rules apply at every level. When we describe a system in the Fractal languages, we are essentially building its WBS in machine-readable form, and the generator turns the leaves of that tree into working code.
What to do tomorrow
Take a project that seems big and foggy to You. Grab a sheet of paper or a whiteboard and draw a tree: the project at the top, five to eight major parts beneath it. Then break each part down one more level. Do not aim for perfection, aim to forget nothing. Show the tree to your team and ask: what is missing here? You will almost certainly hear a couple of items nobody had thought of. Each of them is a missed deadline You have just prevented.
