How to Read a WBS as a New PM at a Scale-Up Software Company
A short detective guide for individual contributors who've just inherited a software WBS at a scale-up — what to look for, what's normal, what's a red flag.
Reading a WBS the way the work will eventually read it
Most new PMs read the WBS for what it says. The skill is reading it for what it doesn't.
If you've just joined a scale-up software project as a new PM, the WBS is one of the first artifacts you'll be handed. Reading it well is detective work — looking for what's missing, mis-sized, or vague — not just understanding what's there.
This short guide is the four-question read-through to do in your first week. Each question takes about ten minutes; together they tell you most of what you need to know about whether the WBS will hold up.
Four questions to ask of an inherited WBS
0 / 4- Does every leaf-level work package have a named owner? If not, the work is currently unowned. Find out who owns it now and update.
- Are there any branches that consist of a single line item? Single-line branches usually mean the work hasn't been decomposed. Migration, operations readiness, and internal tooling are the most common offenders.
- Are dates and durations on leaf-level items, or only on branches? Dates only at the branch level mean the schedule is aspirational, not bottoms-up. The estimation pattern lives here.
- Is the post-launch period in scope? If the WBS ends at launch, you'll be disbanding the team into the next project while bugs are still surfacing. The expansion pattern shows up here as informal post-launch firefighting that nobody scoped.
“I scored my inherited WBS in 30 minutes against these four questions. Three of the four were red. The conversation I had with the program manager that afternoon saved me from absorbing about six weeks of unscoped work into the project's ambient overhead.”
- Day 1Pull the WBSGet the working version, not the slide deck version. They're usually different.
- Day 2Walk the four questions30 minutes per question. Take notes.
- Day 3Conversation with the program managerBring your findings. Frame as questions, not critiques.
- Day 5Document the gapsWhatever didn't get resolved becomes a tracked risk in your first weekly status.
The four questions are deliberately light. They produce signal, not certainty. Use them as a fast first read, then escalate to the WBS health assessment for a more thorough scoring. For broader retrospective context on what most often goes wrong, see twelve WBS mistakes on implementation projects; for the upstream scope statement work, see the scope statement health assessment.