Although I’m somewhat biased, I believe decision patterns are the ultimate differentiator for anyone who offers consulting services. Decision patterns are a form of high-level knowledge capture and reuse; they distill out the essence of the thinking that has worked in the past and make it immediately transferable to a new situation. However, the key to reusable decision patterns lies in a few subtle concepts that make all the difference:
- The definition of a decision: I define a decision as a “fundamental question/issue that demands an answer/solution“, not the more common usage in everyday speech that equates a decision with the alternative that I’ve committed myself and my resources to implement.
- Decision Networks, not Decision Trees: If you extend the decision definition above, it creates a Thinking Breakdown Structure of questions (a Decision Network), not a branching structure of possible solutions/alternatives (a Decision Tree). Each decision is a fully-framed decision analysis that may interact (hence cross-constrain) any other decision in the network. Decision Networks maintain a problem domain – solution space separation at every decision node, which enables the Decision Network to be an innovation framework.
- Solution-independent decision framing: Each decision within the pattern should be framed to be as solution-independent as possible; avoid stating a decision as a binary choice that embeds 2 alternatives in its title. Instead of saying “S-Corp or C-Corp” use “Incorporation Strategy”. Embedding alternatives in the decision title is the perfect recipe for tunnel vision (which is not a great consulting services differentiator to add to your business card!)
- Rolling-wave pattern instantiation: This sounds very technical, but it’s simply the realization that there are natural branch (fan-out) points within any decision pattern. These branch points are either multiple-answer portfolio decisions or multi-part answer architectural decisions for which the alternatives are best represented by flowcharts or models. Your decision pattern can anticipate the types of decisions that will fit as children or grandchildren of these branch points, but you can’t know the number or name of the branches until these decisions are made.
- Criteria patterns: The decision pattern should include the top 7-15 factors to consider for each decision to save time and ensure that important evaluation criteria aren’t overlooked. A proven criteria pattern also helps avoid “double-dipping” (overlapping, dependent or redundant criteria that often result from on-the-fly brainstorming) and non-relevant factors (criteria/requirements relevant to other decisions, but not within the frame/scope of the current decision).
A proven decision pattern is the key to blazing speed in understanding the client’s problem, capturing their strategic decision/roadmap baseline (a quick reverse engineering exercise) and isolating the vital few decisions that will drive a successful consulting engagement. It sets up the ability to collaborate with the client on these decisions and provides a consistent, visible/transparent format for gathering stakeholder inputs, evaluating alternatives and communicating your solution recommendations.
If you want your consulting business to outlive you, then it’s essential that you begin to capture your lessons learned as reusable decision patterns. There’s no better way to pass on your knowledge and expertise to your team.
I created the Decision Driven® Strategy web application to provide a consulting services platform. Although I seed the tool with a proven pattern of 250+ strategy and engineering/design decisions (and their criteria), you may further tailor this pattern to fit the industries and clients that you serve.
Filed under: Decision Concepts, Decision Driven Strategy Tagged: | alternative, architecture decisions, collaboration, consulting, consulting services, decision baseline, decision framing, decision network, decision patterns, decision tree, domain expertise, innovation framework, knowledge management, portfolio decisions, problem domain, reverse engineering, solution space, thinking breakdown structure