The Development Process needs a well-defined commercial target. And a well-defined target entails a coordinated set of decisions that lead to this target. The Decision Hierarchy and the Strategy Table enable groups to link decisions to targets and targets to decisions.
At first glance, these tools are qualitative and appear to be mechanical and unproductive. But in a group setting, they become amazingly energizing and produce unexpected insights and shared understanding.
When are these tools useful? Here are some example situations:
- Innovation: Early stage innovation almost by definition does not have a well-defined commercial target. But it does need some direction to guide development.
- New Product Development: The commercial target has usually been well identified when the project was approved, but not always. In that case, strategy development may be called for. Also, a project needs to be re-defined after development “failure.”
- Newly acquired assets/products: These need to identify the decisions that will incorporate them into existing structures and goals.
Decision Hierarchy
The decision hierarchy identifies the scope of the alternatives to be addressed.
Policy decisions are the “givens” of the problem.
- Policy statements frequently represent decisions made at a “higher” level in the organization. These policy statements should be identified by the facilitator and the team leaders before any group sessions take place. Some examples: “We do not engage in Joint Ventures,” or “This new product will be manufactured in that existing plant,” or “The budget limit for developing this product is $5M.”
- The team should not waste time on alternatives that are ruled out by “higher” level decisions. However, sometimes evaluation will discover that a policy does not make sense. This can be the most valuable output from the evaluation, resulting in a reframing of the problem.
- If a policy is unknown but important, the team should assume a policy for purposes of getting through the workshop. The assumed policy should be verified later, and the analysis modified as needed.
- The team should not unduly restrict the range of alternatives by assuming unverified policy decisions.
Tactical decisions are the decisions that do not need to be made now, and the assumption is that they will be made competently during the implementation of the chosen strategy.
Strategic decisions are the decisions in “Focus on.” These are the decisions that will set the direction of the project. Here is the extremely simplified Decision Hierarchy that will be used in developing the Strategy table for an example product.
Strategy Table
The Strategy Table is a tabular representation of the decisions that are in focus. Some terminology is required to deal with the pieces of the strategy table – otherwise there will be widespread confusion. One set of terms is:
- Decision Area: Each column in the strategy table, representing the decisions to be made.
- Options: The choices which can be made in each decision area.
- Strategy: A set of choices that fit together, composed of one option from each decision area.
A useful visual metaphor is to liken the strategy to a control panel which consists of levers in each column (decision area). Each lever must be set in one and only one position. A strategy is a combination of lever settings in each decision area.
0 Comments