For any strategy or design situation, a Decision Breakdown Structure (DBS) provides a way to decompose the situation into well-framed, loosely-coupled, bite-sized and manageable “thought packages“. It provides a way to “Image the whole, then execute the parts” when the work to be done is thinking that creates the future (aka decisions).
Project management uses a similar mechanism, a Work Breakdown Structure (WBS), to decompose the work required to complete a project (deliver something) into “work packages“.
Most project plans have 2 halves; a Design phase that conceives what the solution will look like and an Implementation phase that builds it and tests it so it’s ready to deliver. The typical Work Breakdown Structure models the Design phase poorly with large clumps such as: Requirements Analysis, System Design (preliminary, detailed, final), System Modeling and Documentation. This type of mush yields few meaningful and distinct milestones that can be used to assess the level of completion or effort remaining.
The design phase of a project is 99% decisions, plus the data gathering tasks that inform these decisions and the documentation tasks that communicate them to the implementers. If you use the Decision Breakdown Structure as the Work Breakdown Structure for this phase you get many meaningful and distinct milestones from which to assess progress. Each decision “thought package” is a self-contained analysis that takes inputs (derived requirements from parent or upstream decisions) and delivers outputs (a committed alternative, its selection rationale and its consequences: derived requirements, implementation tasks, risk mitigation actions).
If I tell you that my system design is 57% complete based on my guesstimate that Detailed Design is 32% expended or that the system design document is 57% written, you know almost nothing about my real status. However, if I say that I’ve made (committed to an alternative and communicated its consequences) 57 out of the top 100 decisions in my design, you know a great deal more. If I set up an Earned Value baseline for those 100 decisions (to reflect their varying scope and significance), I may know even more; that the 57 decisions imply that the System Design is really 88% complete and committed.
Using the Decision Breakdown Structure for the design phase of a project is the key to massively parallel thinking. The decision “thought packages” make ideal chunks of loosely-coupled, self-contained work that can be represented as a network of tasks to drive “critical path” or “critical chain” analysis. Each well-framed decision can be farmed out to additional staff to enable parallel efforts. This can eliminate the greatest bottleneck to rapid design, the concentration of decisions through a few “architects” and the inability to distribute the thinking among many “lesser mortals”.
In order to learn more about the Decision Breakdown Structure and its application to system or product design, we encourage you to start a Decision Driven® Solutions Framework (DDSF) trial today. Please contact the Decision Driven® Solutions team at email@example.com or firstname.lastname@example.org.