[August 2026 edition]

The Art of Defining Problems, Part 1 — Turning a Request Back Into a Problem: As-is, To-be and Gap

Published: Aug 11, 2026
Reading time: ~15 min

Organising requirements, designing, implementing, releasing — the whole sequence rests on the premise that you correctly understand the problem to be solved. The work proceeds perfectly well even when that premise is wrong. You can implement a correct solution to the wrong problem, and technically it will look like a success.

1. What gets decided before requirements definition

Requirements definition is the step that settles the conditions the thing you build must satisfy. Before those conditions can be settled, what you are changing has to be settled. Which state is being moved to which state. Without that, the conditions cannot be written either.

The work of settling that “what are we changing” is problem definition. Where requirements definition deals with the solution side, problem definition deals with reality. The roles also differ in that problem definition can conclude that no system should be built.

This is not a matter of individual taste; it is defined as a step. The UK government’s Service Manual defines a Discovery phase that sits before the decision to build a service. The guideline duration is four to eight weeks, and the first instruction written there is not about research technique. The page explaining how the discovery phase works says that before research begins you must examine that solution and reframe it as a problem to be solved. Working from the premise that requests arrive with the thing to be built already decided, the national guidance instructs you to turn it back into a problem.

The same page also covers the case where the research concludes that nothing should be built. “Stopping at the end of discovery is not a failure if research shows it is the best thing to do. In fact, you will have saved time and money that is better spent elsewhere.”

The same order is standard outside software development too. SEBoK, the systems engineering body of knowledge, places System Concept Definition ahead of formally defining the system of interest, and has that stage examine the problem space and stakeholder needs. This stage contains Business or Mission Analysis and Stakeholder Needs Definition, which require answering what the solution should achieve and why it is needed before answering how to solve it.

The consequences of proceeding with the premise unchecked are equally fixed. Build a high-performance system and the users’ difficulties remain; automate the work and the procedure that ought to have been abolished is preserved; introduce AI and all you get is one more layer processing the convoluted rules.

2. What arrives is not a problem

So where does the problem come from? It is almost never handed over at the point the request arrives. What arrives is a solution or a symptom, and neither is the problem itself.

2.1 Requests arrive as solutions

We want to build a customer management system. We want to move Excel to the web. We want to introduce an AI chatbot. We want to digitise the approval workflow. We want a dashboard. We want to add search. We want to manage data in one place. Requests reaching system development take these shapes. None of them is a problem; each is a means already selected.

Behind “we want to build a customer management system” there can be several different problems. The history with a customer is lost when the person in charge leaves; several departments contact the same customer separately; management cannot see the state of sales activity. Which one is the actual problem changes the countermeasure: if the issue is information lost at handover, standardising the handover procedure comes first; if it is duplicate contact, sorting out ownership and contact rules comes first.

2.2 Symptoms point to neither cause nor target

Reports coming up from the field sit in the same position as requests. There are a lot of input errors, enquiries are not falling, processing is slow, the data does not match, meetings are long, the person in charge is overloaded, the system is hard to use, customer satisfaction is low. These are observed facts indicating that something is happening; as they stand, they fix neither the cause nor the target of the solution.

Take the single report “there are a lot of input errors.” The cause could be any number of things. The same information is being transcribed repeatedly; field names mean different things in different departments; the field did not need to be collected at all. Strengthening input validation will suppress part of the symptom, but if the transcription is unnecessary the thing to change is the abolition of that input step, and if the meanings of the fields are inconsistent then agreement on concepts and areas of responsibility is required.

2.3 Rewrite without touching the method

The entrance to problem definition is recording the request as it stands. What kind of system do they want, why do they think it is needed now, what event triggered it, who holds the budget and the decision. At this point you do not contradict them. Then delete from the request the parts that state a method of solution. If deleting “AI,” “workflow,” “dashboard,” “single source,” and “automation” leaves nothing about what they want to change, the problem has not been written yet.

For instance, “we need to stop managing this in Excel and introduce a customer management system” is, as written, a declaration of a solution. Fixed without writing a method, it becomes this. Sales staff record their contact history with customers in individual Excel files, so a change of account owner produces an average of three business days of handover work. When the owner changes, the necessary customer contact history must be available for review the same day. Written that far, SaaS, shared documents, standardised input rules, and changing roles all line up as candidates.

“We cannot manage the data in one place” gets the same treatment. Single-source management is a means, and being distributed is not necessarily the problem itself. The same customer’s address is stored separately in three business systems, and because not all of them are updated when it changes, an average of 27 misdeliveries occur each month. Written that way, physical data integration lines up alongside changing the reference method, change notification, and clarifying ownership.

Whether a means is still lurking can be checked with the following questions.

Question	What it checks
What changes if you introduce it	Whether the substance of the change can be stated
Why is that change needed	Whether the purpose exists separately from the means
If you were banned from using that technology, how would you explain the problem	Whether the description depends on the technology
Could the same outcome be achieved another way	Whether the options are fixed to one
If you build nothing, what do you change instead	Whether non-system measures are visible

If the last question cannot be answered, the request is still a solution.

3. Solutions arrive before the problem definition

3.1 Examination stops the moment an implementation comes to mind

Plenty of organisational problems can be handled with IT. If departments define data differently, write conversion logic that absorbs the difference. If the regulations are so convoluted that nobody has a grip on them, provide a way to search them. If nobody can decide who approves, build it so the approval route can be changed in configuration. All of these are feasible, and all of them work.

The trouble is that they arrive before the problem definition. Once the engineer receiving the request thinks of a matching implementation, examination moves on to how to build that implementation, without investigating why the data definitions differ or whether the organisation could align them.

On the engineering side, the order is prescribed. SEBoK’s Business or Mission Analysis states that, as the first process under ISO/IEC/IEEE 15288, you define the strategic problems, threats and opportunities, and then identify the classes of solution that address them. A solution class here means a type of means: build a new system, modify an existing one, combine several existing systems, change operations. Building a system lines up as one of those options. The same page also states that the problem space and the solution space are handled separately.

The same page also describes how to proceed when there is no existing system: describe the “as is” (current state) in terms of problems, threats and opportunities, and describe the “to be” (future state) as the state in which those are resolved. The As-is and To-be covered in the next section also appear in the standard steps of systems engineering.

The same order is present in Japanese standards too. System development starts with business analysis, published by IPA in 2026, explains the “business or mission analysis process” of JIS X 0170:2025 (ISO/IEC/IEEE 15288:2023) and lists its activities in this order.

Define the problem or opportunity space (analyse, define, prioritise)
Characterise the solution space
Evaluate classes of alternative solutions

Finish defining the problem and only then examine the solution space — the order is settled on the standards side. The same page also introduces BABOK, which explains a need as “a problem or opportunity to be addressed.”

GOV.UK likewise states plainly in how the discovery phase works that you must not start building a service during discovery. What it lists as things to understand at this stage are the constraints you will face if you move to the next phase, and legacy technology is treated as one of them.

Enter implementation without keeping this order and the system will run, but the divergent departmental data definitions and the convoluted regulations remain unresolved, so you go on maintaining the conversion logic and the search mechanism. If you run it on configuration without deciding who approves, then every time organisational roles are swapped around in a reorganisation every six or twelve months, the permissions and routes have to be reconfigured.

3.2 How the question is framed decides the conclusion

The situation causing difficulty and the question to be solved are different things. A paper on problem definition presented by Ali N. Mashayekhi and Soheil Ghili of Sharif University of Technology at the 2010 International System Dynamics Conference distinguishes the two as difficulty and ambiguity. The definitions are, respectively, “a difficulty is a troublesome situation which needs to be resolved” and “an ambiguity is a puzzle or question whose answer helps resolve a difficulty.”

The example the paper gives is Iran’s energy subsidies. The difficulty is that subsidy spending is extremely large, which is obvious to everyone. What the paper raises as the ambiguity is: given that most decision makers are aware of the catastrophic consequences, why have the subsidies never been abolished? Set “should the subsidies be abolished” as the question instead and the only place you can arrive is the conclusion that they should. Economists and politicians already know that, so however finely you build the model, you end up confirming a known conclusion.

The same contrast applies on the ground with business systems. Faced with the difficulty that an application takes ten days to process, set “how do we digitise it” as the question and the answer is confined to the design of the digitisation. Everyone knows it should be digitised, so this question ends by confirming a known conclusion. The ambiguity is instead: why has a ten-day procedure never been reviewed? The answer comes out in a form such as: no agreement has been reached between departments on transferring approval responsibility.

4. The gap between the current and the desired state

One format that makes a problem easier to handle is writing it as the gap between the current state and the state that should be achieved.

4.1 Writing it with three elements

A definition of a problem that is workable in practice takes the form of a gap, too large to ignore, between the current state and the state that should be achieved. Three things are required.

Current state (As-is)
Desired state (To-be)
The reason the gap cannot be left alone

All three cover only the states, the gap, and the reason the gap cannot be left alone. How to do it is not written. The means belongs to the solution side and falls outside the constituent elements of problem definition.

The current state (As-is) is written as observable fact rather than impression or conjecture. Applications take an average of seven business days to complete; 38% of applications are returned at least once; 62% of enquiries are checks on application status. Without measuring counts, times, error rates and waiting times, you cannot measure the effect after the solution either.

The desired state (To-be) is where means most easily creep in. “Introduce a system” is a method, not a state. Standard cases are processed by the next business day; applicants can see the processing status without making an enquiry. Written that way, the methods of realising it can be compared afterwards.

The reason the gap cannot be left alone is required just as much. Customers miss the contract start date; employees lose time they could spend on their actual work; there is a risk of breaking the law. Merely differing from the ideal does not make something an investment target — you need to state where it bites, in management, in operations, or on the user.

Writing the current state numerically is a long-standing idea in the A3, which originated at Toyota. It is a format that puts the current state, cause analysis, countermeasures, and the implementation plan onto a single 297 mm × 420 mm sheet of A3 paper.

The A3 handles everything from grasping the problem to the countermeasures on one sheet. The current state and cause analysis in the left half correspond to what we are calling As-is; the countermeasures and implementation plan in the right half belong to the solution side. Problem definition writes only as far as that left half.

The Lean Enterprise Institute’s description positions the A3 as a management process learned through dialogue about a specific problem, and holds that it stands independently of whether anything is recorded on A3 paper. Filling it in from the left is itself a device for preserving the order of confirming the current state before considering countermeasures.

4.2 Three layers: problem, cause, solution

4.2.1 Telling the three layers apart

Problem, cause and solution mix together easily. “Order processing takes an average of three days and misses the customer’s requested delivery date” is a problem; “there are too many approvers” is a hypothesis about the cause; “reduce the approval stages” is a solution. Fix the cause at the problem definition stage and the only solutions left for examination are the ones matching that cause.

4.2.2 Do not settle the cause first

In reality, several causes of slow processing often exist at once. The input information is incomplete; the approver is absent; exceptional and standard cases run through the same flow; there is a wait for a response from another department. When several factors interact to produce the phenomenon, settling on a single root cause first ties the scope of the investigation to it.

So before digging for causes, widen how the problem itself is framed. An article on reframing problems that Julia Binder and Michael D. Watkins wrote for HBR in 2024 presents this order as five stages.

Stage	Content
Expand	Set preconceptions aside and lay out the facets of the problem
Examine	Dig for root causes with the iceberg model
Empathize	Understand how stakeholders perceive it
Elevate	See the connection to organisation-wide tasks to address
Envision	Move from the problem frame to designing solutions

Examine, which digs for root causes, is second, and Expand is placed ahead of it. Of the frame-storming used here, the article says it helps teams identify assumptions and blind spots, reducing the risk of pursuing inadequate or biased solutions. It runs in the opposite direction from brainstorming, which multiplies answers to an already defined question.

Moving to solutions is the fifth stage, Envision. Widening the framing of the problem, digging for causes, understanding stakeholders, and seeing the connection to the organisation all come before the solution.

4.2.3 Check for causes that have crept in

Whether a cause has crept into the problem statement you wrote can be found by looking for causal words such as “therefore,” “because of,” and “the cause is.” Where you find one, separate whether it is an observed fact or a conjecture. Then check whether you can list three or more candidate causes, whether there is any counter-example, whether there are cases where the cause is present but the symptom is not, and whether any problem remains once the cause is removed. There are many cases where the causal hypothesis alone can be verified in advance without carrying out the solution.

4.2.4 Separate the problem from the task to address

In Japanese, 問題 (problem) and 課題 (task to address) are used almost synonymously, but IPA separates the two. Its 2019 seminar material defines a problem as “a fact” and “the negative gap between the state that ought to be and the current state,” and a task to address as “something you set yourself” and “what should be done in order to solve the problem.” The gap between As-is and To-be described so far is the problem; what you decide to work on in response to it is the task to address.

Accordingly, “reduce approval waiting time” is not a problem but a task to address, and “automate approval” is a means to it. What problem definition settles is what is happening, what needs to change, and what scope to investigate. Cause analysis and setting the tasks to address come afterwards.

From the same facts, a different problem can be written depending on where you cut. Part 2 settles the scope of the problem along four axes: boundary, standpoint, time, and constraints.