Back to independent consulting

In mid-October, 2012 I transitioned back to my preferred business model as an independent consultant.  My four years as a Senior/Principal Systems Engineer with a very large government contractor were rewarding; but I grew weary of the layers of overhead folks who didn’t add to the value delivered to the customers or end users of my services.  At my core, I’m an entrepreneur who enjoys working at the bleeding edge of Systems Thinking methods and tools while helping customers solve their most challenging problems.

In the near-term, I am fully booked working with a great customer.  In parallel, I plan to refresh the Decision Driven® Strategy and Life web applications with the latest user interface technologies.  I’m working through the business model decisions on how to package these tools and the embedded decision patterns into revenue-producing products and services.  Please stay tuned for new developments.

In the interim, feel free to contact me at if you have a Decision Management or Strategic Roadmapping challenge to overcome.


John Fitch

Decision Driven(r) web site/application changes

The Decision Driven® Strategy and Life web sites and web applications will be offline for a while as I update them to match my changing business model.  I am 100% engaged in leveraging Decision Driven® courseware, software and decision patterns in my “day job” (contractor working with the U.S. Army), so I can’t do justice to the subscription web service or on-the-road consulting models.  The courseware, web applications and decision patterns can be made available to third-party consulting firms that seek a ready-to-use service delivery platform.  I’m always open for short-term consult-for-pay or consult-for-equity engagements with entrepreneurs that want to innovate business strategies and accelerate new products to market.  Please contact me at

John Fitch

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:

Criteria for a functional decomposition decision

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!


Get every new post delivered to your Inbox.