Frame a valuable problem and comparison baseline

**Skill and decision.** A proposal to “build an app that coordinates field technicians” does not yet state the problem. The app is one possible intervention. If missing spare parts cause most delays, a routing app may consume money without changing the outcome. The innovation manager must turn a proposal into a testable problem: whose job is impeded, what happens without intervention, which causes remain uncertain, and what improvement would justify spending. The output is a problem card that permits several solutions to compete. Technology is an option, not the objective.

Choose a unit of analysis before collecting numbers. Here it is one maintenance request from registration to an accepted resolution. Separate four elements. A **symptom** is an observed result, such as a long resolution time. A **need** is what the user is trying to accomplish, such as restoring service before a critical deadline. A **possible cause** is an explanation requiring evidence, such as slow assignment of a technician. An **intervention** is a proposed change, such as automated dispatch. Do not promote a cause from hypothesis to fact because one interviewee mentioned it. Record the observation, its source and date, the strength of evidence, and an alternative explanation. Design a check that can distinguish competing explanations. If request logs do not separate the time before assignment from the time waiting for a spare part, improving the event log or auditing a sample may be the first sound decision.

A useful problem card records the primary beneficiary, payer, and operator; the job and context; the size and timing of the problem; the baseline and its source; the cost of the current state to users and the organization; the alternative that will remain if no action is taken; constraints; and a decision threshold. Define an **outcome measure**, not only an activity count. App opens count activity. The proportion of critical requests with service restored within four hours measures a result. Add a guardrail that detects unwanted harm, such as the share of requests reopened within seven days. Agree on the success threshold before examining pilot results. Otherwise the team may silently move the threshold to make the preferred project look successful.

Check the numerator and denominator before paying for a technology trial. Do the 120 critical requests include cancellations? Does “resolved” mean service actually restored or a ticket administratively closed? Are the two districts comparable in travel time and equipment mix? If the indicator definition changes during the pilot, an apparent rise cannot simply be attributed to the intervention. Name the owner of the baseline and specify how another analyst can reproduce the count. A problem card becomes reviewable when another person can trace its definition, source, period, exclusions, and arithmetic.

**Transfer limit.** A problem card does not show that an intervention will succeed. Better data may be more valuable than a product trial at this stage. Under the Oslo Manual, a new or improved product must be made available to potential users, or a new or improved process brought into use, to count as an innovation. The proposed app is an innovation candidate, not an achieved innovation merely because it was proposed. The source supports this conceptual boundary; all figures and organizations in the worked case are invented for instruction. [OECD/Eurostat, Oslo Manual 2018, chapter 3](https://www.oecd.org/en/publications/oslo-manual-2018_9789264304604-en/full-report/component-9.html).

**Stress-test the baseline.** Suppose district A resolved 36 of 60 critical requests within four hours and district B resolved 18 of 60. Together they produced the earlier 54/120 = 45% baseline, but their separate rates are 60% and 30%. During a later trial, A receives 90 requests and resolves 54 on time; B receives 30 and resolves 9 on time. The combined rate rises to 63/120 = 52.5%, even though each district stayed at exactly 60% or 30%. A change in the mix of requests created the apparent overall improvement. The problem card should retain baselines by district and relevant fault class, then specify in advance how a changing mix will be compared. One approach is to show each subgroup rate and an aggregate standardized to an agreed fixed mix. Excessive slicing also makes samples thin, so report counts beside rates. This example does not prove that every observed improvement is compositional; it reveals an alternative explanation that a fair test must address.

A good problem card differs from a budget request because “no new technology” remains a possible answer. If the forty-request audit points toward missing codes or parts, a form change or supplier arrangement may create more value than a new algorithm. Present these options in neutral language and state what evidence would reverse the recommendation. Where the data source is itself unreliable, tie the investment gate to its reliability. A month-long pilot on logs that cannot be re-extracted cannot support a dependable comparison. Have the data owner document time fields, the definition of “critical,” and any date when classifications changed. The board can then distinguish a genuine opportunity from a numerical rise caused by a changed definition.

**Cause decomposition before choosing a tool.** If the register says that sixty-six requests were late, do not select the first cause offered by a department head. Draw at least two branches: time before technician assignment and time after assignment until service restoration. Split the latter into waiting for a part, waiting for authorization, and carrying out the visit. Some branches occur in sequence rather than as mutually exclusive causes; a request may wait for both a part and a technician. Do not add overlapping branch counts and call the sum “all delays.” Build one event timeline per request, identify the first event that pushed it beyond the service target, and retain secondary contributors. Teams may still disagree on the remedy, but they will now be discussing a shared record rather than incomparable numbers.

Suppose an audit sample contains thirty late requests. In twelve, a part was unavailable before assignment; eight waited for approval; six had multiple delays; and four cannot be classified because the event log is incomplete. Do not announce that “40% of all company requests are delayed by parts.” The 12/30 = 40% applies to this **late-request sample**, perhaps taken during an unusually busy week. Improve event recording, inspect requests across periods and sites, and test an intervention that addresses a supported mechanism. Even if twelve is correct, the answer need not be an app: reorder timing or supplier arrangements might matter more. State in the problem card which remaining uncertainty could reverse the option choice rather than displaying one appealing percentage.

When setting a 60% speed objective, inspect its effect on stakeholders. Staff might close a ticket before the customer confirms restoration, so the worked case pairs speed with reopening. They might also move technicians away from a remote district to raise the overall mean. Show results for districts and more severe request classes separately and ask whether a deliberate minimum standard is needed for each. Do not let one aggregate reward shifting waiting time to people least able to challenge it. This is not a promise that every case has identical targets; it is a distributional check before making the outcome a funding gate.