Functional decomposition is a decision

Systems engineers do a task that is commonly known as functional decomposition.  This task starts at the very top of the definition of a system and breaks down all the functions required to support the product’s mission (use cases) into layers of finer and finer functions.  Functions are expressed as Verb-Object statements such as “Acquire target” or “Compute trajectory”.

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.

Manage knowledge, not documents

I stopped thinking much about documents 20+ years ago.  I know that most business processes still demand them (stage-gate, systems engineering, new product development, government contracting, proposals, etc.).  I know that lots of effort is expended in maintaining document templates, filling in these templates with paragraph prose, prettifying them to match format requirements, vetting them through reviews, publishing them to appropriate distributions and managing document baselines.  Systems engineers are trained in “Writing good requirements” as if requirements derivation was a product of Shakesperean talents, not thinking clarity and skill.

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 …

A 3V Traceability Model

I’ve written numerous posts on decision-to-requirements traceability based on the fact that decisions are the creators and consumers of requirements.  Consistent with this, I use a 3V (or 3-Vee) model of traceability that is best represented by a 3-D model of 3 traceability Vee’s connected together.

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.

Decision Driven® Information Architecture

Many of my previous posts have described the relationships among various types of knowledge: decisions, criteria, alternatives, requirements, risks, plans, etc.  There’s method (actually science) to my madness; here’s the Decision Driven® Information Architecture that I believe illustrates how decisions glue together all other types of future-creating knowledge.

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.

Situation patterns

Your job will typically fit into one of 3 patterns (roles, functions):

• 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!

Please sign up for our next Using Decision Patterns webinar.  It’s free!  See the What’s Happening panel on the left for details.

Failure to leverage decision patterns

“Manage Decisions across Domains” is the fifth process within my Decision Driven® methods engine.  That’s really consultant/nerd-speak for “Use decision patterns, dummy!” and “Never make a decision from scratch!”   Decisions patterns are a precious form of intellectual property, but are often overlooked because decision management is not seen as a vital business process or core competency.

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.

If you’d like to harness the power of decision patterns, please sign up for our next Using Decision Patterns webinar.  It’s free!  See the What’s Happening panel on the left for details.

Failure to manage decisions over time

Every decision has a time-context (planning horizon) that’s important to understand.  Even though decisions are fundamental questions/issues that demand an answer/solution (and in a sense, last forever), their alternatives (answers, solutions) have a limited “good-for” period in which they create value in the real world.  Alternatives become obsolete or a competitive liability; they must be replaced.

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. 

Please sign up for our next Using Decision Patterns webinar.  It’s free!  See the What’s Happening panel on the left for details.

Failure to manage decision consequences

Everyone believes that decisions have consequences, but many fail to proactively manage them.  You can make a great decision, select a great alternative and still fail during execution.  Here are a few examples of common “failure to follow-through” decision faults:

• 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.

Please sign up for our next Using Decision Patterns webinar.  It’s free!  See the What’s Happening panel on the left for details.

Common decision analysis errors

Yesterday I highlighted some common mistakes associated with failure to proactively identify and plan your decisions before diving into decision analysis.  Even if you have correctly focused on a high-priority, well-framed decision (successfully answered the “What do we need to decide?” and “How will we decide it?” questions), you can still screw up the Make Decision part of the process.

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.

Please sign up for our next Using Decision Patterns webinar.  It’s free!  See the What’s Happening panel on the left for details.

Decision faults: failure to proactively plan your decisions

In my October 10, 2008 post, I introduced my belief that all faults are decision faults.  Over the years, I’ve seen quite a variety of bad decision practices that lead to failure.  Here are some decision faults that I lump under the general category of failure to proactively plan your decisions:

• Failure to decide in a timely manner leads to “only one option”
• Wrong decision owners, stakeholders and contributors doom a decision to failure
• Inappropriate level of rigor/effort applied to a decision
• Stakeholders withhold important criteria until a preferred alternative is proposed – trump the analysis
• Implicit decision not recognized – opportunity for competitive advantage missed or inconsistent solution supported

Each of these is a form of ineffective Situation Appraisal – failure to proactively identify the decisions (fundamental questions/issues that demand an answer/solution) that make up your current situation, failure to frame/isolate the highest priority choices and failure to plan the decision analysis effort (How) and apply appropriate resources (How much) and personnel/roles (Who) to specific decisions.

I think the key to effective Situation Appraisal is to use a proven decision pattern to proactively create a Decision Network model of the situation.  The Decision Network serves as a Thinking Breakdown Structure that you can use to identify open, high-priority decisions and to build a realistic data-gathering and decision analysis plan for the most critical choices. 

These decision faults often share a common “presenting symptom” – if you are frequently blind-sided by a decision that seems to pop up from nowhere, you have likely failed at Situation Appraisal.  No decision should ever be a surprise – they fit into a predictable “big-picture” pattern.  But you have to look ahead!   

Please sign up for our next Using Decision Patterns webinar.  It’s free!  See the What’s Happening panel on the left for details.