From Issue to Problem: Causes, Symptoms and Analytical Boundaries

Problem definition is not a ceremonial introduction before choosing a solution; it is one of the central analytical decisions. Weak framing can confuse an observation with a cause or hide an untested assumption. For example, “we lack a new online application” assumes that technology is both the problem and its remedy. A more neutral framing starts with what can be observed: “a share of requests exceeded the target completion time during the last three months, with substantial variation across request types.” This wording leaves causes open to investigation rather than closing them prematurely.

Issue, symptom, cause and mechanism

An issue is a pattern that deserves attention, such as rising delay or falling uptake. A symptom is a manifestation of the problem and may be what users notice first. A cause is a factor contributing to an outcome, while a mechanism is the pathway connecting a factor to that outcome. If request completion slows, a backlog may be a symptom; limited capacity at a specific review step may be a possible cause; and a queue forming because arrivals exceed processing capacity may be a mechanism. A plausible explanation is not yet proof; evidence should strengthen or weaken the hypothesis.

Problem boundaries: who, what, where and when?

An analyzable problem needs boundaries. Specify affected groups, the service or behavior of interest, the time period, the organizational or geographic scope when relevant, and the baseline or benchmark used for comparison. Boundaries do not mean ignoring everything outside them; they clarify what the evidence is intended to describe. Where no official target exists, analysts may use a time comparison or comparison with similar groups cautiously, while making clear that comparison alone does not establish causation.

Frame the problem without embedding the solution

A useful problem statement combines four elements: an observable undesirable outcome or gap, affected groups or units, clear time and scope boundaries, and explicit uncertainty about causes. For example: “During the last quarter, the share of requests taking more than 20 days increased in two service categories; preliminary data suggest possible review bottlenecks and differences in application completeness, but the contribution of each factor is unresolved.” This is more analytical than “we need automated review” because it does not build a particular instrument into the problem definition.