A Decision Breakdown Structure (DBS) for any complex strategy, system or project is a way to decompose the situation into well-framed, loosely-coupled, bite-sized and manageable “thought packages“. Each decision “node” within this structure is a well-framed “fundamental question or issue that demands an answer or solution.” Each decision has 2 halves; the problem domain (basic question and the stakeholders’ criteria that define success) and the solution space (alternatives and their consequences).
Don’t confuse a Decision Breakdown Structure (DBS) with the more commonly used Decision Tree (taught in most MBA programs). Decision trees represent a hierarchical roll-up of various combinations of alternatives (the solution space), typically so that a single value-measure such as NPV can be computed for the top decision node.
A DBS is much more than a tree or hierarchy of questions and answers. It supports a richer structure that provides a mechanism for managing the interactions (dependencies, cross-constraints) among multiple decisions. Decisions interact in 2 ways:
Requirement-dependencies: A decision is “made” (or “taken”) when a commitment is made to implement a specific alternative. At this point, all the inherent consequences (derived requirements) associated with this alternative become constraints that can affect any other decision on the project. These constraints affect other decisions by creating new criteria or changing their Must limits or weights. The answer in one decision changes the “success equation” or “trade space” associated with another decision.
Time-dependencies between alternatives: An alternative in one decision may enable an alternative in another decision, i.e. be a building block or prerequisite required to realize this solution. Delaying the availability of the predecessor alternative may delay the successor’s start date. In project management (critical path) terms, these are Start-Start dependencies. When you manage these dependencies, you are typically time-aligning a set of linked technology, capability, platform, product and market roadmaps.
The decision patterns housed in the Decision Driven® Solutions Framework (DDSF) start out as a tree in which the parent-child relationships between decisions represent the most common way that requirement and roadmap (time) dependencies flow down to lower-level decisions. As decisions are made (alternatives are selected), dependencies are created between these decisions and the tree becomes an ever-richer network of interacting decisions. Different answers create different dependencies, so you can’t know in advance precisely how your final DBS will be “wired” together.
The Decision Breakdown Structure (DBS) is a management tool that can give you proactive control of the thinking that creates the future. You could maintain exhaustive traceability for all decision-to-decision interactions, but most teams won’t tolerate this level of process discipline and rigor. Instead, they use a Pareto’s Law approach and capture and manage the “vital few” interactions that have the greatest impact. These are the toughest requirement cross-constraints that limit design freedom and the most at-risk time-dependencies that drive the critical path of the strategy roadmap.
The most unique feature of a Decision Breakdown Structure (DBS) is its ability to do triple-duty as a common framework for managing the interactions between decisions, requirements and roadmaps. If your organization currently treats these processes as independent silos, you can greatly simplify (“lean”) your processes by redesigning them around a Decision Driven® methods engine. If that sounds intriguing, give me a holler.
In order to learn more about the Decision Breakdown Structure (DBS), decision patterns and managing your decision interactions, please contact the Decision Driven® Solutions team at email@example.com or firstname.lastname@example.org to start a Decision Driven® Solutions Framework (DDSF) trial today.