Manager toolbox: Decomposition
Hey–you know what we forgot to do? Testing.
Decomposition is a simple tool to keep you and your team from forgetting things. I feel every IT manager should have a basic understanding of decomposition.
The term is primarily used in project management: a “Work Breakdown Structure” (WBS) is a decomposition of a project into work packages. But, the concept of decomposition can be applied widely, to things like
- Risk breakdown structures,
- Requirements breakdown structures,
- Service level requirements,
- Future-state planning, and
- Professional development plans.
People often try to do “bottom-up” planning: we need to do thing #1, and thing #2, and thing #3. But it’s easy to miss stuff if you stick to bottom-up planning. Decomposition is a form of top-down planning.
A decomposition is much like a document outline. You’re taking a big idea and breaking it into units.
However, in a decomposition you guarantee that each level sums to the one above it. You guarantee that you’re not leaving anything out.
Decomposition starts with the top: what’s the big idea, goal, or thing that we want to break down?
You then take your top-level item (say, a project) and divide it into smaller and smaller units, all the while guaranteeing that each sub-level is a 100% representation of the previous level:
Why decomposition is useful
By guaranteeing that each sub-level represents its parent level, you know that your small units at the bottom of your decomposition are 100% of what is needed. You basically map your big idea into its (say) 100 bite-sized components.
In the project world, this is great because the project manager can make sure the small things are done and know that the project’s done.
This approach also makes it easy to catch things you may have forgotten. As you and your team review the decomposition, you can continually ask yourself “what did we forget at this level?” For example, “should we put training on this?”
How to build a decomposition
There are really good project management training classes that cover how to build a breakdown structure. This blog post won’t make you an expert–here I can just introduce the concepts.
You can build a decomposition structure as a team, using sticky notes on a wall.
As you work, keep a few things in mind:
- Decomposition is more of an art than a science. There is no one correct way to build a decomposition. Once you’ve chosen an approach, stick with it if at all possible.
- Components are often expressed as nouns, not verbs. You are not identifying what work needs to be done; you’re identifying what must exist. (The work will then follow.)
- People need to review the whole decomposition, not just one part. System administrators should look at the training team’s components, for example. You want a lot of eyes because you’re trying to find what’s missing: a training environment may be needed, for example.
- Know when to stop decomposing. Typically, you stop when the zone of control is clear: when one person or team can clearly own the component.
Expert mode: re-using decompositions
Save your decompositions for the future. You may want to use all or parts of them in the future. If one project required a training environment, for example, then you might be able to pull out those parts for a future project that needs a training environment.