Managing decision interactions

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 or to start a Decision Driven® Solutions Framework (DDSF) trial today.

About decisiondriven

Innovator in Decision Management, Systems Thinking and System Engineering methods and tools
This entry was posted in Decision Concepts, Decision Driven Innovation, Decision Driven Product Development, Decision Driven Strategy and tagged , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

One Response to Managing decision interactions

  1. PM Hut says:

    Hi John,

    This is an excellent and unique article. I am interested in republishing some of your articles on PM Hut. Please contact me through the “Contact Us” form of the PM Hut site in case you’re OK with this.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s