Problem-solving is decision-making, problem analysis is not

I’ve mentioned previously that the word, decision, is used with 2 distinct meanings.  First, a decision is a fundamental question or issue that demands an answer or solution.  Second, a decision is the alternative that I’ve committed to implement.  In Decision Driven® Solutions Framework (DDSF), I always use the first definition for a decision and am careful to call alternatives, alternatives (or options, ideas, solutions).

The term, problem, is even more over-loaded.  We use it to describe situations beyond our control, risks, lack of resources, defects (deviations from expected behavior) and also decisions.  When someone states that they are engaged in problem-solving, they most often really need to make a decision, i.e. generate a creative solution to a set of demanding requirements.  In a few cases they mean something very different; they don’t understand why something has failed (to behave as expected) and they need to do problem analysis (aka root cause analysis) to explain “Why?”

This is a very important distinction in human thinking patterns.  Problem analysis looks at past or present “out-of-spec” behaviors and seeks to explain why in terms of cause-effect analysis.  It doesn’t generate any “fixes” for the problem.  Its output is “confirmed root cause”; once the “Why?” question is answered its job is complete.

Problem-solving implies generating solutions (aka alternatives) that meet stakeholders’ requirements.  This is occasionally in response to something being broken (a corrective or adaptive action), but more often is just the desire for something new and better.

Creative problem-solving and decision-making are the same thought process.  They both stand in the present and look forward to a better future.  They are accomplished by the same steps (although this is often obscured by terminology).  They have the same basic information model:

  • Decision/problem: Frames the question, issue or concern to be attacked
  • Criteria: stakeholders’ requirements, goals, constraints that define success
  • Alternatives: ideas, options, solutions (possible answers)
  • Performance estimates: How well the alternatives satisfy the criteria

I’ve heard it said, “If it looks like a duck, walks like a duck and quacks like a duck, it’s probably a duck”.  Problem-solving is almost always just another word for decision-making; problem analysis is a very different animal.

Start your free trial of the Decision Driven® Solutions Framework (DDSF) and experience first-hand how YOU can practice creative problem solving with its powerful, yet “simple to use” capabilities. Please contact the Decision Driven® Solutions team at trial@decisiondriven.com or solutions@decisiondriven.com.

About decisiondriven

Innovator in Decision Management, Systems Thinking and System Engineering methods and tools
This entry was posted in Decision Concepts and tagged , , , , , , , , . Bookmark the permalink.

4 Responses to Problem-solving is decision-making, problem analysis is not

  1. Linda says:

    Hi John,

    Your post reminds me of a book I recently read called Jack’s Notebook by Gregg Fraley. Have you heard of it or read it?

    It is a book about creative problem solving written in an innovative way IMO. It’s a fiction format, with lessons on creative problem solving woven into the story. Kind of hard to describe, but it was a very interesting book and a worthwhile read.

    Fraley’s hero has a dream and in the story he learns how creative problem solving (including analysis and decision making) can make it come true. I know I will apply this process to my work and life challenges.

    Cheers,
    Linda

  2. decisiondriven says:

    Linda,
    I haven’t read Jack’s Notebook – I’ve been too busy writing software. Gregg Fraley (based on his website) reminds me of Gerald “SolutionMan” Haman (www.solutionpeople.com). Both of them appear to combine great insights on how to stimulate innovation with much better stand-up comedy skills than I can muster. You might also want to check out my April 13 post, “Decisions bridge innovation and execution” written in response to IBM’s innovation vs. execution commercials.

  3. Bruce Lerner says:

    John,
    It appears to me that decision-making is the selection of one alternative from a set of alternatives that best addresses a given set of criteria. It is not directly a mechanism for developing a set of alternatives. Problem solving as described above does appear to address the generation of alternatives. A complete method to navigate from problem analysis (determining root cause) to problem mitigation (in its best scenario – solution) must address both problem solving AND decision-making. If problem-solving and decision-making are essentially the same, what activity generates alternatives?

  4. decisiondriven says:

    Bruce,
    As you know, the full end-to-end process for making any decision includes a series of steps:
    Frame the decision, define criteria, define (find, create or synthesize) alternatives, evaluate alternatives, commit to implement one or more alternatives). That’s the level at which I’m comparing problem-solving and decision-making. Both include all these steps, i.e. they populate the same information model.

    Problem analysis uses a completely different information model that describes observed behaviors and tests possible root causes against them.

    99% of the decisions that I’ve helped folks with over the years did not require a root cause analysis step before starting decision-making. The reason why a need, gap, shortfall or undesirable condition existed was already known – no one had invented a better way yet. So the sequence of problem analysis followed by decision-making is very rare in strategy or product design. It occurs most often in testing or operations.

    Systems engineers use the term, problem analysis, when they are seeking to understand a set of customer/user requirements. From an information model perspective, they are just capturing the derived requirements that flow from a set of previous customer decisions (probably not well-articulated) so they can then use these requirements as criteria for the next level of decisions that they must make to create a solution to the customer’s “problem”. None of this is root cause analysis; it’s all decisions and requirement-to-decision-to-requirement traceability.

    I always test these things against the information model; if a process populates the same object classes, attributes and relationships; it’s the same process.

    John Fitch

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s