A Decision Breakdown Structure (DBS) is the decomposition of any strategy or design challenge into a hierarchy of decisions (questions that demand answers). First time “framers” of a DBS often have difficulty in understanding that they have to use the decision pattern in a “rolling-wave” manner. They can’t copy and paste the whole enchilada and fill-it in blindly. Let’s explain why.
When you populate a project DBS you will encounter three types of decisions intermingled in the tree:
- Single answer (Concept/Technology): These decisions down-select from multiple competing alternatives to the single best-fit solution. Examples include your company’s Vision, the Technology that will deliver a specific product function, the Component that will implement that technology or the Supplier of that component. Other than for redundancy/risk mitigation, you should only have one “Committed” alternative at any time.
- Multiple answer (Portfolio): In these decisions you commit to N out of M alternatives. Examples include the set of Core Competencies that differentiate you from competitors, the Target Markets that you will serve, the Products/Services that you will offer and the Use Cases that each product or service will support.
- Multi-part answer (Architecture): These decisions lead to alternatives that can best be represented by a model of interacting elements and visualized as boxes and arrows. Examples include Product Architecture, Business Architecture and Organization Design.
For simplicity, I usually refer to these decision types by their shorthand names: Concept or Technology, Portfolio and Architecture instead of the generalized names that reflect the roles each play in the topology of the DBS.
- Single answer concept/technology decisions are often “leaves” that capture how a strategy or design converges to a single best-fit solution. If a single answer decision has children, they will typically represent the elaboration of the strategy/design into another layer of detail.
- Multiple answer portfolio decisions are where the DBS diverges (fans-out) into a pattern-based branch for each alternative chosen.
- Multi-part answer architecture decisions are typically followed by child decisions that elaborate the design for each “box” (architectural element) and “arrow” (interface/interaction between elements).
In a fully-populated DBS, Portfolio and Architecture decisions never reside at the leaf-level; they define the scope and structure of an enterprise or system and beg for further elaboration. But in your first pass at an initial project DBS, you have to stop at each Portfolio or Architecture decision. Your decision pattern can tell you the decisions that follow, but you can’t know the number or names of the branches until the decision has been made. If I select 3 target markets (X, Y, Z) for my company, I will create a branch named for each of them when I develop my strategy to conquer that market (beginning with my Market X Positioning vs. my competitors).
Thankfully, all of these decision types share the same “Make Decision” process, information model (e.g. criteria, alternative, performance estimates, risks, etc) and data visualizations (e.g. Evaluation Matrix, Spider Chart, etc.). Once you have mastered the thought process for one decision of any type, you are fully qualified to tackle the other types.
If you are having difficulty in breaking down a complex challenge into its decision/thinking parts, please contact firstname.lastname@example.org. We are happy to assist!