Creating a WBS is an exercise in disaggregation: breaking things down into pieces and parts from a top-level notion of what the outcomes should be.
However, I've found it handy to then add the pieces and parts up from the bottom and see if their summation reveals any gaps.
That's the well-known 'V-model' from system engineering: break it down, then add it up and verify the top-down and the bottom-up come to the same project outcome.
Many recognize the 'V-model' as a variant of the well known dictum: "Tell them what you're going to tell them; Tell them; Tell them what you told them"!
That's why when I first saw Egeland's first bullet, I thought "right!", that's close to my thinking also. But, alas, his detailed description seems to confuse schedule and WBS. He writes:
1 – WBS forces the team to create detailed steps
The WBS forces the project manager, team members, and customers to delineate the steps required to build and deliver the product or service. The exercise alone encourages a dialogue that will help clarify ambiguities, bring out assumptions, narrow the scope of the project, and raise critical issues early on.
NO! The WBS does not delineate the steps to build anything. Actionable steps to do things are in the schedule.
If by 'steps' Brad means disaggregated deliverables, then ok. But if by 'steps' he refers to activities to achieve those deliverables, then NO.
There's no time line in the WBS, and as debated here before, no work in the WBS either. The WBS is just the proceeds of the work; and those proceeds--that is, deliverables--end at the 'water's edge' of the project.
