The Work You Missed Was Never "Unplanned"

Week three, weekly status meeting. The dev lead raises a hand, hesitantly. "So... who owns the data migration?" The room goes quiet. The task appears nowhere — not in the estimate, not in the schedule, not on anyone's plate. But without it, there is no go-live.

Every PM wants to call this moment "an unforeseen variable." Let's be honest: it wasn't. In a system replacement project, moving the data existed from day one. It just wasn't in the plan. Missed work isn't "unplanned work" — it's work your plan failed to see. The distinction matters. The former belongs to risk management; the latter is a defect in planning quality.

Why we miss work

Anyone who has built a WBS (Work Breakdown Structure) knows: drawing the tree is easy. Being confident that the tree contains everything is hard.

Work gets missed in three recurring patterns.

First, we decompose only what's visible. Screens, features, documents — tangible deliverables get broken down well. But the connective tissue — migration, permission setup, performance test environments, stakeholder training — never makes it onto the tree.

Second, decomposition depth is uneven. One branch goes four levels deep while another sits as a single lump called "backend development." Big lumps are where missing work hides.

Third, the same work straddles two branches. When a task half-belongs to both "API development" and "integration," each side assumes the other owns it. So nobody does.

The answer is sixty years old

Each pattern has a proven remedy, codified in the PMBOK (PMI's Project Management Body of Knowledge) as the WBS principles.

The 100% Rule. Every parent node must equal exactly the sum of its children. If the children don't add up to the parent, something is missing; if they exceed it, out-of-scope work has crept in. Adopt this single rule as your review standard and most of the "connective tissue" work surfaces. The practice is simple: next to every parent node, ask "do my children sum to me?"

The 8/80 Rule. The lowest-level unit — the work package — should be no smaller than 8 hours and no larger than 80. Anything over 80 hours isn't decomposed yet. "Backend development, six weeks" is not a plan. It's a hope.

Mutual exclusivity. No piece of work may belong to two nodes at once. Where you see overlap, redraw the boundary. This is the vaccine against "I thought your team had it."

The principles are crisp. The problem is that they depend on human attention. With 30 nodes, you can review by eye. With 300, you can't. Building a PM tool, we ran validation across dozens of real-world WBS trees; in trees beyond 100 nodes, we almost never found one free of 100% Rule violations. That's not a people problem — it's a method problem. Rule-checking is work that belongs to a system, not a person.

The 100% Rule, before and after

Abstract principles need concrete examples, so take the most accident-prone node of all: "Go-live preparation."

Before review:

Go-live preparation = production deployment + launch announcement

After asking the 100% Rule question ("do my children sum to me?"):

Go-live preparation = production environment setup + data migration & reconciliation + accounts & permissions setup + deployment rehearsal (cut-over scenario) + rollback plan + operations handover training + production deployment + launch announcement

Six new tasks surfaced — every one of them the kind that makes someone raise a hand in week three.

Splitting the big lump — 8/80 in practice

Decompose "backend development, 6 weeks (240h)" into work packages:

Notice the by-product: the act of splitting forces the questions of deliverable and done criteria. A lump that can't answer them is exactly where missing work hides.

A 30-minute WBS completeness review

Open your current project's WBS and run this.

Structure check (10 min)

• Any leaf node over 80 hours → decomposition unfinished
• Any parent that doesn't reconcile with its children → 100% Rule violation
• Any task straddling two branches → mutual-exclusivity violation

Hidden work checklist (10 min) — the eight most commonly missed items in system projects

• Data migration & reconciliation
• Accounts, permissions, SSO setup
• Test environment & test data preparation
• Security review & vulnerability scan
• Stakeholder training & manuals
• Operations handover & monitoring setup
• Internal / client approval workflows
• Cut-over rehearsal & rollback plan

Ownership boundary check (10 min) — ask three questions of every work package

1. What is this task's deliverable? (No answer = it's an activity, not a task)
2. Who approves completion? (No approver = forever "in progress")
3. For work spanning two teams, who is finally accountable? (If not one person, it's no one)

The PM's action block

Three things to do tomorrow

1. Put the 30-minute review on your calendar now (alone first, before involving the team)
2. Pick the three largest over-80h nodes and decompose them with their owners
3. Add every checklist hit to the WBS and assign effort

Questions to ask in the next meeting

• "For this parent node — do the children sum to exactly 100%?"
• "For this 240-hour task, what is the first deliverable, and when?"
• "Which node contains migration, permissions, and training?"

Good signs / bad signs

What a tool should solve

The bottleneck in this review isn't judgment — it's cross-checking. Summing, overlap-detection, and size validation across 300 nodes is a system's job, not a person's. That's why the first thing we built into wbsgantt was an engine that flags 100% Rule and 8/80 violations at save time. When rule-checking becomes free, the PM's thirty minutes go entirely to judgment.

Missed work always comes back. Wearing a face that wasn't in the plan, holding an invoice that wasn't in the budget.