This website covers knowledge management, personal effectiveness, theory of constraints, amongst other topics. Opinions expressed here are strictly those of the owner, Jack Vinson, and those of the commenters.

The problems with problem statements

Jon Miller suggests there are problems with problem statements in Top 10 Problems with Problem Statements:

The problem with problem statements is that hardly anyone knows how to correctly formulate a problem statement and instead they put a lot of information there in place of sound arguments and justification for action, and people would be better off leaving the writing of problem statements to professionals.
[Referenced by a friend on the CriticalChain mailing list.]

Of course, the above statement is problematic, as Miller suggests.  These are the things he says problem statements should not do / be.

Assign a cause

Contain the solution

Are based on conjecture or belief rather than fact

Are too long

Do not describe actual current condition or problem condition

Do not describe the ideal or desired condition

Are not measurable

Are unclear

Are not specific

Refer to issues outside of the scope of the actual problem

This is good, basic advice on clear writing.  I don't know whether it requires a professional - just some practice and coaching.  In the Theory of Constraints world, training on the "thinking processes" include similar reminders on how to write clearly when putting together problem statement: current problems, potential problems, actual obstacles, etc.

For example, here are the list of recommendations for writing problem statements (UDE's - undesirable effects, in the TOC lingo):

  • Express in a single sentence, present tense

  • Exists in current reality

  • It is an effect (not a cause, absence of a solution, or an obstacle)

  • It is clearly negative (quantified or qualified)

  • It is a single effect without conjunctions or explanations. (Multiple problems deserve multiple statements.)

  • It's a problem that is valid in the current situation. (It affects your ability to achieve the goal.)

  • No blame

  • Do NOT include perceived reasons for its existence (no names, no "because ...")

  • Not the absence of a solution (that others have argued for)

With obstacles (to an implementation), there are a similar set of checks, with an emphasis on "does the obstacle actually exist."

If you hear someone say, "I have a clarity reservation," you know they have been to a lot of TOC training.  This simply means, the statement you've articulated isn't clear enough.  It may be missing one of these pieces or it just doesn't make sense.  "Let's clarify it for everyone's benefit."

The Future of KM for Nancy White

Jack's new adventure - Boston and Aspen Technology