John Fitch

I’ve always found it easy to quickly decompose a function into a set of 3 or 5 or 7 child functions that fully cover the parent function’s scope and intent.  However, the fact that I can break down a function in many different ways reveals a very important truth - Functional decomposition is a decision!  There’s more than one way to decompose any function; each model of N children is a unique alternative for the specific “Functional Model” decision.

Just like every other decision, the Functional Model choice has a criteria pattern that can be used to evaluate the relative effectiveness of one functional decomposition model compared to another.  Here are the criteria I use when I think through a particularly complex decomposition problem:

If you are a proponent of Model-based Systems Engineering (MBSE), remember that not all models are created equal!  Your first functional decomposition will seldom be the best you can do; you can use these criteria to test and improve your model.

Documents are lousy containers for knowledge.  Knowledge is created continuously when people THINK.  Thinking is always done is some CONTEXT which builds a LINK between knowledge objects (decisions, requirements, alternatives, risks, plans, models, …).  If you follow the typical document-generation process, you think, then switch gears to a completely separate process of writing that loses the context and fails to preserve the links.  It’s more work, takes longer and produces lots of redundant, disconnected, out-of-context information.

The Decision Driven® Information Architecture that I shared in my October 24, 2008 post is an example of an information-centric view of knowledge.  It links objects to objects as they are created; it maintains continuous traceability at the object level between the valuable bits of knowledge.  All knowledge is created and stored in context of the thinking that created it; there’s no second-pass writing assignment and no redundant copies of information spread about multiple documents.

A knowledge-centric process (of which my Decision Driven® methods are an instance) can generate all the documents that any process should require, but it treats these documents as mere “views” or “snapshots” of the real information.  These views can be regenerated on-the-fly and always match the latest state of the knowledge (which typically resides in a well-structure database).   That may be one reason why document-based processes still rule; an information-based approach makes visible the current state of your thinking and will highlight any gaps.  But the truth only hurts when it should …

If you’ve done quite a bit of systems engineering or new product development, you are likely familiar with the requirement-to-test/verification Vee.  If you’ve read my blog, I may have also convinced you of the value of capturing the requirements derivation process at its source by managing both requirements-to-decision and decision-to-requirements traceability (the second Vee).

My purpose today is to stimulate you to take advantage of a third type of traceability relationship between decisions and tests (verification events).  I believe this is low-hanging fruit that could be exploited by almost any organization.  Think for a second – your organization almost certainly demands and provides a specific test or verification method for each product requirement.  That means that you will be gathering product performance data (by direct test measurement or inspection, demonstration or simulation) that expresses how well your design satisfies each requirement.  If your specification calls for a performance of >1.0 flibberwidgets/nanosecond, you will very likely do a decision analysis (trade study) early in the design process to estimate the effectiveness of various design alternatives.  Your analysis (which may be done by an experienced-based paper estimate, extrapolating from similar designs, or running a simulation model) may estimate a value of 1.20 flibberwidgets/nanosecond, giving you a 20% design margin in your preferred solution.  However, when you complete your testing, you may discover that the product only delivered 1.05 flibberwidgets/nanosecond; passing the spec limit, but much more narrowly than expected.

If you ignore the concept of decision-to-test traceability, you may miss a great opportunity here and stop at this point saying, “Whew, I’m sure glad we squeaked by on that one!”  But there is free information staring you in the face at this point; you have a test result that reveals a 15% bias/error in the estimating technique that you used to inform your decision analysis/trade study.  This is free knowledge at this point; you already paid for it to meet a product testing requirement.  You can exploit it by asking, “What caused the bias in our estimating technique?” and “How can we improve our estimating technique so it will yield a better answer the next time we face this type of design decision?”

Learning organizations take full advantage of the knowledge they create to drive continuous process improvement.  Start today by capturing your decision analyses and maintaining decision-requirements traceability.  Then go a step further and improve the fidelity of your models by comparing your test results to your decision analysis predictions.

If you unbundle this information architecture and represent it as a single decision transform, you get a Decision Trace diagram:

From my experience, all of these information objects and relationships are both true and useful.  Failure to capture these types of data increases the risk of decision failure.  Failure to understand the relationships creates lots of knowledge that floats about, disconnected from its decision context.  Failure to maintain appropriate and continuous traceability (links) between these objects condemns you to have to recreate (if possible) your thinking if and when things change.

Of course, there are probably 10 synonyms for every class of object shown, so your first task may be to map your terminology to this universal model.  Once you do, I’ll be surprised if you can identify any additional types of information or links that are vital to the “future-creating” parts of strategy, systems engineering or new product development.

• Create: Innovate and define strategy, capabilities and solutions.
• Implement: Translate strategy, capabilities and solutions into reality.
• Operate: Manage, deliver, perform or support the stuff conceived and deployed by the other 2 functions.

These roles reflect different situation patterns that call for different thinking tools and knowledge flows.  If you accept the Kepner-Tregoe assertion that all human thinking can be mapped to 4 fundamental thinking patterns (rational process building-blocks), then a thinking model of the 3 situation patterns looks something like this:

Whenever I walk into a new situation, I first discern where I fit in this model and then determine what are the “open” issues to address vs. what’s been nailed down and fully resolved already.  Starting from this baseline, I know what thinking tools to use to make further progress; the questions to ask, the data to gather and how to add value to the current situation.

The Decision Driven® Strategy web service is designed to provide decision patterns so you can quickly build a Decision Network model of your situation to guide, facilitate and accelerate the decisions that will create your future.  However, you can also use decision patterns for project management/execution decisions and operational (day-to-day, recurring, routine) decisions.

Here’s a tip if you’re facing a career decision – It’s a lot more fun to work on the left side of this chart in the “Invent the future through decisions” role.  The folks in the middle are squeezed by project deadlines and may be blamed for failures when they successfully implement the bad ideas of others.  The operational workers on the right side of the chart have to live with both bad upstream decisions and failed implementation and still get the job done on a day-to-day basis.  Stuff flows downhill and it’s often not good stuff!

Here are some common symptoms of failure to leverage decision patterns:

• Knowledge from similar decisions not leveraged or misapplied
• Opportunity for common solution platform not recognized or pursued
• Process deliverables obscure and compete with high priority decisions – value-added thinking not rewarded

Decision patterns are powerful business accelerators and force-multipliers.  They can help you accelerate solutions into reality, reducing your time-to-market or time-to-capability.  They can power your platform engineering process to create high-value reusable assets that stretch your R&D dollars.  They can improve your product development process efficiency by highlighting the “value-creating” decisions between your stage-gates and buried in your development artifacts.

Decision management is a complex, “moving train” problem.  Every decision evolves or “turns over” at its own rate, so a Decision Network for a business strategy or product portfolio is really a network of asynchronous moving parts with a “mind of their own”.   Unless proactive thinking is applied to keep decisions/alternatives aligned, entropy will rule and your strategy will naturally fall apart into disconnected and ineffective pieces.  Most organizations don’t manage their decisions formally and holistically; their ad hoc processes fail to “Manage Decisions over Time“.   Or they have a strategic roadmapping process, but it’s decoupled from their real decision-making process.

Here are some common “Failure to manage decisions over time” defects that I’ve encountered:

• Next state of a decision not anticipated – solution gap results
• Full idea to opportunity critical path not managed – solutions delayed
• Knowledge from previous state of a decision not leveraged or misapplied
• Criteria inconsistent with time-context of the decision

You can cure these defects with an integrated decision management and roadmapping process.  Decision patterns can help you identify and frame your high-priority strategic decisions.  Integrated tools such as Decision Driven® Strategy can help you fast-forward your decisions to think about their future states and link and time-align (synchronize) the answers across multiple decisions.

• Next phase requirements inconsistent with upstream decision results (derived requirements lost, not traced to downstream baseline)
• MUST limits not balanced among decisions – failure to systematically manage shared budgets
• Cross-constraints not recognized between parallel decisions – decision inconsistencies not detected
• Significant risks and opportunities not addressed with timely actions
• Alternatives implemented do not match those evaluated and selected for implementation

Every decision that you make creates new requirements that should be captured and factored into future decisions.  Every decision selects a virtual alternative that must be implemented (made real) through set of of actions/tasks.  Almost all decisions “create” new risks that should be mitigated and opportunities that should be grown/exploited.  Failure to address these consequences in a timely and consistent manner can result in the failure of even a brilliant decision.

Most businesses treat requirements management, project management, risk management and opportunity management as distinct processes that operate on their own timing, independently of their decision processes (if they have decision processes at all).  Decisions create the future and you’ll be most effective at realizing the future you want if you manage these processes as an integral part of each decision you make.

Here are some common decision analysis defects that I’ve encountered in my travels:

• Stakeholder requirement missing (not asked for, not captured, no influence on decision)
• Stakeholder requirement misstated (wrong Must limit) or incorrectly prioritized (wrong weight)
• Duplicate or causal criteria sway the decision
• Narrow range of alternatives – tunnel vision
• Alternatives evaluated using inconsistent criteria or scales
• Bias for a favorite alternative sways the decision
• Scoring rationale not captured – scores don’t match best available estimates of performance
• Promising windfall/opportunity overlooked

There are lots of different flavors of decision analysis techniques, but they all involve understanding and relating the following types of information:

• Criteria: Stakeholders needs, goals, requirements, or constraints.  These are your definition of success for a specific decision.
• Alternatives: Possible answers, solutions to the fundamental question posed by the decision
• Performance estimates: Data used to score the effectiveness of the alternatives against specific criteria
• Uncertainties: Risks and opportunities

Of course, there is skill involved with asking the right questions and insightfully integrating this data to reach a conclusion.  Clumsy, rote, mechanical or sloppy use of decision analysis can also lead to bad decisions.