Building a work breakdown structure
A good WBS makes estimating and scheduling straightforward. A bad one hides missing work behind a tidy-looking tree.
Deliverables, not activities
The most common failure is writing the structure as things people will do rather than things that will exist. "Design, build, test" is a process. "Approved space plan, fitted floor, signed-off network" are deliverables.
The difference shows up at the end. You can tell whether a deliverable exists. Whether "design" is finished is a matter of opinion, and that opinion gets contested at the worst possible moment. Naming outputs rather than efforts makes completion checkable.
The 100% rule
The children of any item should account for all of it and nothing more.
If a parent has three children covering 80% of what it means, the missing 20% appears nowhere. It will not be estimated, will not be scheduled, will not be assigned — and will still have to be done, at which point it arrives as a surprise. The structure looks complete, which is what makes the omission dangerous.
Checking this deliberately at each level is tedious and catches real gaps.
The double-count
Estimates belong on the work packages at the bottom of the tree. Everything above gets its number by addition.
When someone estimates a parent at 40 days and its children also total 40, a naive sum reports 80. It is easy to do and hard to spot once the structure is more than a screen tall, and the resulting plan is exactly twice the size it should be. The rule is simple: if it has children, its estimate comes from them, and any figure typed against it is ignored.
How far to decompose
Far enough that a work package can be estimated with some confidence and owned by one person. No further.
Breaking a two-day task into six twenty-minute steps adds administration and no information. A rough test in both directions: if you cannot estimate it, it is too big; if tracking it costs more than doing it, it is too small.
Codes move, and that is correct
WBS codes follow position in the tree. Insert an item and everything below renumbers. That is the right behaviour — the code describes where something sits in the structure, not what it is.
If you need an identifier that survives restructuring, that is a different concept and belongs in its own column. Trying to make WBS codes permanent produces a structure nobody dares reorganise.
What this tool will not do
It calculates from the figures you enter and nothing else. It cannot tell you whether those figures are honest, and a precise-looking output built on rough inputs is still rough.