Problem Pyramid™ Prevents Prevalent Problem Statement Problems

Problem statements are a widely-used and well-regarded technique. Yet, I find many fail to achieve the benefits attributed to them.

The powerful Problem Pyramid™ overcomes problem statement shortcomings to provide expected value to projects.

Many projects use problem statements and often include them within a project charter. Defining the problem before undertaking its often-costly presumed solution is sound conventional wisdom—in theory. After all, no less a theoretician than Albert Einstein is often attributed saying to the effect that if he had only one hour to save the world, he would spend fifty-five minutes defining the problem, and only five minutes finding the solution.

Another widely-cited source of insights, Yogi Berra, said, “In theory there is no difference between theory and practice. In practice there is” (BrainyQuote.com).
In practice, problem statements tend to be what I call “conventional we’s dumb.” Many if not most actual problem statements not only give merely the illusion of soundness but also often outright mislead. Moreover, too often they become simply templates as substitutes for understanding.

Typical Contents

Sources seem to agree that a problem statement should state what the problem is, how bad the problem is, the value to be obtained from solving it (why), and its general expected solution (how). Frequently the why includes identifying those with the problem who need a solution. Some also emphasize the importance of quantifying the problem and/or its solution’s expected benefits (how much).

Projects often go awry when they focus on solving the wrong problem, or when they take mistaken actions because even the right problem is not adequately understood. Thus, problem statements are intended to increase chances of project success by assuring the project is solving the right, well-understood problem.

Too often, though, execution in practice falls short of those laudable purposes. An inaccurate or misleading problem statement in fact can contribute to exactly the types of project mistakes it was intended to prevent.

Actual Contents Issues

Far more than realized, problem statements describe the wrong—or at least not right—problem. Accurately defining the problem turns out to be much harder than generally assumed. Twelve people describing ostensibly the same situation often state a dozen different problems, and they still all may be wrong. What they call a problem instead could be symptoms, causes, measures, presumed solutions, or something else.

Yet, most conventional problem statements I’ve seen simply take as given whatever someone has declared to be the problem. When that someone is a higher-up, as often happens, their declaration of the problem is even less likely to be questioned.

Many problem statements I’ve seen are mainly venting, frequently piling on about how awful the problem is. Of course, the worse the problem is made to seem, the more likely a project will be initiated to achieve the proponent’s proposed solution and the less likely their proposed solution will be evaluated critically. Not surprisingly, proposed solutions almost always are intended to benefit the proponent most but frequently are ill-conceived and fail to deliver the proponent or the organization expected value.

Problem Pyramid™ Overcomes these Issues

The Problem Pyramid™ is a powerful six-step systematic disciplined tool for getting right the problem, its value measures, causes, REAL business requirements deliverable whats that provide value when satisfied, and a responsive product/system/software way how to satisfy the whats.

The steps/boxes need to be performed in numbered sequence, for each builds on the prior steps. Moreover, we don’t proceed from one step until it passes serious scrutiny to be sure it is correct. For each step we apply a number of disciplined evaluation guidelines that give far greater confidence it’s right before going to subsequent steps that depend on it.

For instance, with conventional problem statements, the problem seldom is meaningfully evaluated or even questioned; and management oversight, if it exists at all, usually consists of pointlessly asking the problem statement’s author whether they’ve correctly identified the problem—they’ll always answer “yes.”

In contrast, the Problem Pyramid™ confirms Box 1 is a problem, Box 2 current and Box 3 goal measures accurately apply to it, and achieving the Box 3 goal measures in fact indicates the problem has been solved, opportunity has been taken, or challenge has been met, which in turn provides REAL value. When measures are not defined or don’t match the problem, the problem is usually wrong, and the measures often are too.

Box 4 causes are the as is (or current state) process producing the Box 2 current measures that tell us we have a problem. We confirm Box 4 identifies all key causes and that together they reasonably explain why we have the Box 1 problem.

Box 5 describes the should be (or future state) process top-level REAL business requirements. We confirm these are business deliverable whats that when delivered, satisfied, or met reasonably will achieve the Box 3 goal measures and thereby provide value. We also confirm the Box 5 should be whats reduce or eliminate all the key Box 4 causes so the problem won’t persist.

Box 6 describes a product, system, or software way how to satisfy the Box 5 whats. We confirm the Box 6 how in fact will reasonably satisfy the Box 5 whats and thereby provide the Box 3 value. Most projects creep and fail because they start with a presumed Box 6 product how which turns out not to satisfy the Box 5 REAL business requirements whats that provide value when met, usually because the Box 5 whats have not been defined adequately, if at all.

The Problem Pyramid™ guides accurately identifying the REAL problem and providing REAL value by reducing/eliminating its fully-identified key causes. Moreover, the Problem Pyramid™ assures ordinarily-overlooked REAL business requirements deliverable whats that provide value when satisfied in fact are identified adequately and will reasonably be satisfied by a responsive product/system/software how.