« Selling the Change | Main | Business Intelligence versus Business Knowledge: Who Cares? »

January 27, 2006

So What's Your Problem?

"I never walk into a room I don't know how to walk back out of." -- Robert DeNiro, RONIN

When is a "solution" not a solution? When it doesn't end the problem.

But why bother with a solution if "the right" problem hasn't been decided?

We say "decided", here, because problems are so often an onion that must be peeled, and somewhere amongst the layers we have to choose the place where we'll start "solving"... and choose a satisfactory place to stop.

I.

For example, when we get specific about our work on a "solution", do we know whether we're addressing the symptom, the problem or the cause? What is necessary, and what is sufficient?

Symptoms (sometimes called incidents) are signs that a problem exists, while a problem itself is an undesired disruption of, or diversion from, the state that we are relying on. The cause of the problem, sometimes called the "heart" or "root", is a detrimental change of the conditions that normally generate that state on which we rely. Often we don't get to stop there, since we might need to know why the base conditions changed.

The water on the basement floor is from the freezer: the ice block melted because the freezer went off because the power went out because the tree-pruners hit the power line while we were away...

Diagnostically, the habit is to focus heavily on these layers. We try to see the connecting thread from one layer to the other, and try to decide how much we ought to do to correct things. Is the requirement to hide symptoms, to restore or replace our reliance, or to reengineer the base conditions?

Sorting out those issues is the usual routine. Meanwhile, we frequently risk a huge amount of time solving the wrong problem.

II.

This is partly because a given symptom can sprout from many different problems, and to isolate the problem that really exists, we have to search for a variety of other symptoms that combine into the problem's "fingerprint". Those other symptoms may not yet appear, though -- so we also rely a lot on histories that say "if this particular symptom appears in certain situations, it is likely to be that particular problem."

Most of that is old hat for problem-solvers. But then there is the matter of having more than one way to solve the problem. Deconstructing the problem to fix it can lead to a revised idea of how serious the problem is or even of what is the real problem. This is because some problems are caused by other problems.

When problems are "chaining", it's naturally somewhat urgent to determine which problem will be the point where the first effort gives the most overall relief. But relief is not necessarily the solution.

More importantly, within any targeted problem, the challenge is to understand it correctly, so that remedial action will not change anything else that does not need to be changed. The law of unintended consequences can be harshly unforgiving.

Of crucial importance is to not have the solution to one problem be the cause of another problem.

As iluminated in the above table, isolating the correct solution-approach means we have to understand what intrinsic type of problem exists. Symptoms comes from this type, and the type comes from any of the ways that the basic conditions were disturbed before or after their creation. These disturbances come in three main flavors: complexity, difficulty and risk.

As revealed here, solving the problem thus becomes potentially very complicated. Our diagnoses can reveal a number of different and simultaneous causative issues creating conditions that spawn more than one type of problem. What's worse, we encounter phenomena such as one type of problem causing another type of problem. For example, errors can cause omissions, which in turn can cause defects.

III.

As we design the solution -- whether it is a simple one or a compound one -- we then face a parallel set of challenges in the solution effort: our effort itself has to overcome complexity, difficulty and risk.

Specifically, in designing, we have to deal with issues about our concept and execution including:
- choice of what to address (complexity);
- suitability to task (difficulty); and...
- opportunity costs (risk).

The short answer to those challenges is, of course, to get an expert. Getting an expert makes sense if:
- the assessment of the problem is either still-to-be-done or is accurately complete but highly specialized
- the assessment needs to be translated into differing vocabularies e.g. cross-functional or cross-departmental
- negotiating over competing solution priorities must be done
- suspected technical requirements exceed already in-hand resources.

The purpose of the expertise is to decide what solution approach will be used for a defined problem to get an explicit expectation met regarding an identified point in the future. This means realizing that final requirements may only partially satisfy needs; and that we might have to play the "choose your pain" game. But what makes any effort worthwhile is to spend it on solving the right problem.

So what are the chances, finally, that we'll get to the solution that we want?

In a mid-size organization, roles and responsibilities are likely already diversified enough so that nothing can be taken for granted about co-operation. Solutions that are delivered are not just the ones that seemed to be called for, but instead are the ones that are allowed. Closing the gap between the ideal solution and the allowed one may take strategy, but it invariably takes visibility of what's at stake for each key influencer of the solution development and solution adoption.

Thus an assessment of the delivery prospects for the solution is a critically important dimension of its design. The table below provides a procedural framework for delivery assessment (called "CLEAR", copyrighted, trademark pending) that presents the key touchpoints for information, permission and support of the proposed and evolving solution design.

In CLEAR, matching resolve with approval is the goal. The activity involves acknowledging, publishing and reconciling the fact that a variety of independent elements must cooperatively and compatibly generate the solution if it is to be successfully provided and used.

Posted by Malcolm Ryder at January 27, 2006 6:47 AM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/198

Comments

Post a comment