![\"Infographic](\"/article-assets/problem-statement/problem-statement-cinque-elementi.jpg\")
The question sounds rhetorical and isn't: the two paths bring different documents into the meeting and produce different decisions.
\nWhen someone is asked to put a problem in writing, something else almost always ends up on the page: the goal to reach, the visible effect, or the intervention already chosen.
\nA problem statement is the written description of a gap: what is happening, where and since when, how much it's worth, who bears the effect, and what lies outside it.
\nThe step applies to a professional with two team members, to a fifteen-person family business and to a hundred-person organization: what changes is who holds the pen, not the temptation to skip it.
\nIn 2022, 80.9% of Italian companies with at least three employees were controlled by one person or one family [5]: the person who sees the problem and the person who decides the intervention are often the same, and the written statement is the point where the two come apart.
\n\n\nA well-written problem doesn't say what you want to achieve or who got it wrong: it measures the distance between how the work is going and how it should be going, and states where it stops.
\n
This article walks through the three swaps that empty a problem statement, the five elements that make it verifiable, the four steps to write it, three before-and-after rewrites, the test that closes it, and the most common mistakes.
\nIs writing what isn't working the same act as writing what you'd like to achieve?
\nIt isn't, and to notice it you only need to reread the line you just wrote: if it contains a future-tense verb or an action to launch, that line doesn't describe the problem.
\nA problem statement is the written description of a gap: what is happening, where and since when, how much it's worth, who bears the effect, and what lies outside it.
\nThe verb already states the work it asks for: define comes from the Latin definire, \"to limit,\" derived from finis, \"boundary\" [6].
\nTo define is to determine by setting limits, as in the phrase \"to define precisely the terms of a question\" [6].
\nIn everyday use, \"problem\" means any situation that presents difficulties, obstacles or drawbacks to deal with [7]: it's the broad word, and the statement is the act that narrows it.
\nThe distinction that matters isn't with opposites, which are easy to spot, but with the four things that take the problem's place at the moment of writing.
\nIt isn't the goal, which says where you want to get, not what keeps you from being there already.
\nIt isn't the visible effect — the complaint, the reminder call, the emergency meeting — which signals the problem without saying where to look.
\nIt isn't the cause, which is the result of the analysis and not its starting point.
\nIt isn't the request for intervention, which often arrives phrased as a lack and already names the answer.
\nThe value of this distinction has a long history: \"a problem well put is half-solved\" is how Dewey, in 1938, opens his analysis of inquiry, adding that getting the problem wrong makes all the inquiry that follows irrelevant or off track [1].
\nThe act that comes before the statement is noticing that a problem exists, and it's covered in problem finding; the act that comes after is the search for causes.
\nWhen there are many known problems and the question is which one to start with, the choice is made before writing, ranking them by weight with the Pareto chart: the statement then covers a single item.
\nThe technical name for the intermediate phase is problem setting (short definition in the glossary): the problem statement is what that phase produces.
\nWith the gap written down, it remains to understand why something else ends up on the page.
\nOn a sheet that asks you to write the problem, what actually gets written?
\nUsually one of the three things the problem is not, and the swap happens without the writer noticing.
\n\n\nA well-written problem doesn't say what you want to achieve or who got it wrong: it measures the distance between how the work is going and how it should be going, and states where it stops.
\n
The swap has a measured root: in Nutt's study of 356 decisions made in medium-sized and large organizations in the United States and Canada, 37% of cases started from a ready-made idea, treated as a direction to impose, and the responses born this way were fully adopted in 42% of cases [2].
\nIn more than 26% of cases the starting point was instead a problem definition, but the author observes that the definition is often hasty and misleading: symptoms get analyzed while more important issues are left out, and the full adoption rate stops at 44% [2].
\nThe European Commission's methodological guidance for impact assessments names the same swap as the most common mistake: concluding that a problem exists because a tool, a regulatory framework or a database is missing — when those \"lacks\" are possible responses to a problem that hasn't been defined yet [3].
\nThe same guidance also has a name for the second move, backward engineering: an analysis conducted with the intervention already chosen in mind, which comes out confirming it because that was the starting point [3].
\nThe three swaps can be recognized by the shape of the line, even before its content.
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| The swap | How it sounds | Why it doesn't hold up | How to recognize it |
|---|---|---|---|
| The goal in place of the problem | \"get on-time deliveries to 95% by June\" | it says where you want to get, not what keeps you from being there | the line contains a numeric target and a future-tense verb |
| The effect in place of the problem | \"customers are complaining\" | it's the visible consequence: whoever reads it doesn't know where to look | the line names a reaction — complaint, reminder, return — rather than a measurable internal fact |
| The intervention in place of the problem | \"we lack a management system,\" \"we need more training\" | it's already an answer, and it closes the search before opening it [3] | the line starts with \"we lack,\" \"we need,\" \"we have to\" |
scroll the table →
\nThe cost of all three swaps is the same: the analysis starts from a sentence that can't be checked, and so it produces conclusions that can't be checked.
\nWhoever reads the line a month later, or in another department, finds an intention rather than a fact.
\nThe remedy isn't writing more: it's writing the right elements.
\nWhat separates a line you can check from a line you can only comment on?
\nFive elements, and their absence is visible to the naked eye: where the number is missing, an impression remains; where the boundary is missing, a debate remains.
\n
The elements aren't an editorial invention.
\nThe problem framing tool the Asian Development Bank uses in the projects it supports asks for four pieces of information: the areas affected, the value of the impact, quantified where possible, the period over which the problem has persisted, and how often it occurs [4].
\nThe European Commission guidance adds the target, meaning who is affected by the problem and who produces it through their behavior, and asks for the current situation to be described before any proposal [3].
\nThe fifth element — what the problem is not — is the one the etymology of the verb define calls for on its own [6], and it's also the one companies write down least.
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Element | The question it answers | What it looks like once written |
|---|---|---|
| 1. Who is affected | who bears the effect, who produces it, who would need to change something [3] | \"the two customers who pick up on a fixed schedule\" instead of \"the market\" |
| 2. Current situation and desired condition | how things are going today, how they should go according to a rule, an agreement or a template | \"inspection is done on 6 parts out of 10; the template calls for 10 out of 10\" |
| 3. Where, when, how much | in which stretch of the work, in what period, how often [4] | \"at the packaging line, over the last three months, 9 times in 60 batches\" |
| 4. Impact | what the gap costs in hours, delays, rework or money [4] | \"about 9 hours of rework and two rescheduled deliveries\" |
| 5. What the problem is not | which nearby facts stay outside the scope | \"it doesn't concern catalog orders, which follow a different flow\" |
Causes don't appear on the list, and that's a boundary choice: the same European guidance treats them as the next step of the analysis, after the problem has been established [3].
\nIf you write the cause into the statement, you get an analysis that confirms the cause you already wrote.
\nThe fifth element deserves an extra line because it's the one that saves the most time.
\nStating what stays out keeps the next meeting from widening to everything that resembles the problem, and lets whoever searches for causes know when they're drifting away.
\nThe same element, taken to its most formal degree, is the \"is / is not\" template of the Kepner-Tregoe method: there the scope is built column by column, while here a single line stating what stays out is enough.
\nThe template is compact by design: five lines, not a page.
\nThe next step is putting them in the order in which they actually get written.
\nWho writes the statement, and how much time does it really take?
\nIt's written by whoever holds the decision, and in owner-run businesses that's both the advantage and the risk.
\nIn Italy, for example, in 2022 there were 826,953 companies with at least three employees controlled by an individual or a family, 80.9% of the total, and in these businesses management was entrusted to an internal or external manager in only 1.4% of cases, falling to 0.8% among those with 3 to 9 employees [5].
\nThe advantage is that there are few steps between whoever sees the problem and whoever decides: a business owner in a machining company who splits time between the office and the shop floor can write the statement the same day the event occurred.
\nThe risk is the other side of the same coin: whoever decides comes to the page with the intervention already in mind, and the statement risks being born as a justification.
\nThe four steps exist to keep the two apart.
\n![\"Diagram](\"/article-assets/problem-statement/problem-statement-quattro-passaggi.jpg\")
The reread by the people who do the work isn't a formality: the guidebook used in projects supported by the Asian Development Bank recommends looking for other ways to state the same problem, because word choice changes the perspective of whoever will read it [4].
\nWhen the problem crosses two departments, the statement is written by the one that bears the effect downstream and reread by the one that produces it upstream; the case where more than two departments are involved belongs to organizational problems, which need a map before they need a template.
\nWriting time is twenty to forty minutes, excluding fact gathering: it's an editorial rule of thumb, not a measured figure.
\nThe sheet stays minimal — a problem template with five lines and an evidence column next to each — and it's worth as much as the facts it contains.
\nHow a line changes as it goes through these four steps is easier to see on a case.
\nDoes the same sentence rewritten with five elements produce the same meeting?
\nIt produces a different meeting, because it shifts the discussion from opinions to the documents you need to go get.
\nThe three cases below are hypothetical and built for this article: they're meant to show the procedure, not to estimate a result.
\nCase 1 — family-run machine shop, 22 employees.
\nBefore: \"deliveries are running slow.\"
\nEverything that could be checked is missing: how many deliveries, in what period, for which customers, with what effect.
\nAfter:
\n\n\nOver the last three months, 14 of 96 orders shipped after the confirmed date, with an average delay of four days; the effect falls on the two customers who pick up on a fixed schedule, who have rescheduled two pickups. It doesn't concern subcontract work, which runs on a different flow.
\n
Case 2 — professional practice, three people.
\nBefore: \"clients keep calling to find out where we are.\"
\nThe line describes an effect — the phone call — and leaves out the internal fact that produces it.
\nAfter:
\n\n\nOver the last eight weeks, 31 of 54 files went more than ten days past the deadline communicated to the client at engagement, and in 22 cases the client called before an update arrived. Files waiting on documents from the client, tracked separately, are excluded.
\n
Case 3 — purchasing office of a 60-person company.
\nBefore: \"we need a new management system.\"
\nHere the line doesn't describe a problem but names an intervention, and it's the case the European guidance flags as the most common mistake [3].
\nAfter:
\n\n\nIn the first half of the year, 37 of 210 orders were issued at a price different from the last agreed price list, for a total discrepancy of about €11,000; the figure comes from comparing orders with signed price lists. It doesn't concern off-contract purchases, which are authorized individually.
\n
The three rewrites share the same shape: a counted fact, a period, a scope, an effect and a boundary line.
\nThe three rewrites don't name a person and don't name an intervention.
\nThe time between \"before\" and \"after\" isn't writing time but gathering time: the figures come from documents the company already had.
\nAt this point the statement is ready for the search for causes, which begins where this page ends — with the 5 whys technique when the chain is linear, with the Ishikawa diagram when there are many plausible causes.
\nBefore moving on to causes, though, it pays to check that the statement holds up.
\nWhen can a problem statement be considered finished?
\nWhen two people who weren't present at the events read it and understand the same thing, and when every line can be checked against a document or a number.
\nThe test is five questions, asked out loud over the sheet you just wrote.
\nIf an answer is missing, the statement isn't wrong: it's incomplete, and the step to redo is the first one, fact gathering.
\nThe stopping rule is the absence of new information: when one more question doesn't change the line, the statement is closed and the work moves on to the search for causes.
\nThe reverse also holds, and it's the part that costs most: if during the analysis the data contradict the statement, the statement gets rewritten [4].
\nThe reason this check pays off is as old as the study of inquiry: the way the problem is conceived decides which hypotheses are considered and which are dismissed, which data are selected and which are rejected [1].
\nA narrow, verifiable statement doesn't make the search for causes easier: it makes it possible, because it shows where to look.
\nFrom here the work changes tools, and the available methods are compared in the guide to business problem solving; when the question becomes \"why is this happening,\" the next step is root cause analysis.
\nWhat remains are the mistakes that empty a statement even when the procedure has been followed.
\nCan a statement respect the form and still be unusable?
\nIt can, and it happens for six recurring reasons, recognizable from the written line even before the outcome.
\nA person's name inside the statement. Nutt's study observes that those inclined to frame everything as a problem fail to see that problems invite blame: team members' energy shifts from looking for answers to defending their own position [2].
\nThe fix is to replace the name with the point in the work where the event happens — not \"the operator doesn't check,\" but \"at product changeover, no step confirms the parameter.\"
\nThe statement with no number. \"Often,\" \"lately,\" \"too many times\" describe the speaker's feeling and change meaning from one person to the next.
\nThe fix is to count for three weeks on a document that already exists before rewriting the line.
\nThe scope that keeps widening. \"Internal communication isn't working\" isn't a statement but a family of problems.
\nThe fix is what the European guidance calls decomposition: breaking a complex problem into simpler problems that can be tackled separately, while stating the links between them [3].
\nThe statement written after choosing the intervention. This is the backward engineering already mentioned: the analysis confirms the choice because that's where it started [3].
\nThe fix is to date the sheet and have the statement come before any quote.
\nThe claim without evidence. A line no document can confirm can't be disproved either, and the same guidance asks for tangible evidence, gathered with verifiable methods from neutral sources [3].
\nThe fix is the evidence column next to each line of the template: where evidence is missing, the line is a hypothesis.
\nThe statement that never gets updated. The first version is vague by design, and treating it as closed means carrying the error into the analysis [4].
\nThe fix is the second version, written after the data have been gathered and dated.
\nThe six mistakes share one trait: they save ten minutes of writing and cost much more in the search for causes, where you end up working on a line that can't be checked.
\nWhen the statement concerns a deviation from a written rule or a specification, the formal register it ends up in is nonconformity management.
\nThe decision study cited here covers 356 decisions made in medium-sized and large organizations in the United States and Canada, observed up to 1999 [2].
\nIts numbers describe a method risk — the hasty definition, the intervention chosen first — not a frequency measured in Italian companies.
\nThe European Commission guidance [3] and the guidebook used in projects supported by the Asian Development Bank [4] were developed for public policy and development cooperation projects: the writing criteria transfer, the scales and consultation procedures don't.
\nThe three before-and-after cases are hypothetical and built for this article: the figures are there to show the shape of the rewrite, not to estimate results.
\nA well-written statement doesn't by itself reduce how often an event occurs: it makes possible the analysis that reduces it, and the outcome is verified later.
\nWhen what's happening is an emergency — safety, a line stoppage, a blocked delivery — you contain first and define afterward: the order is reversed for practical reasons, not because the statement is less useful.
\nIt's the written description of a gap between how the work is going and how it should be going, with scope, period, frequency, impact and boundaries.
\nIt serves to make checkable against documents what would otherwise remain a shared impression.
\nThe goal states where you want to get; the problem statement describes what keeps you from being there already.
\nWritten together they blur: the European guidance for impact assessments flags the \"lack of\" a tool as precisely the most common mistake, because that lack is a possible answer and not a problem [3].
\nWith a present-tense sentence that contains the counted fact, the period, the scope and who bears the effect, with no names of people and no future-tense verbs.
\nA one-line problem statement example: \"over the last three months, 14 of 96 orders shipped after the confirmed date, with an average delay of four days, and the effect falls on the customers who pick up on a fixed schedule.\"
\nProblem setting gives the problem its shape — scope, measure, target — and produces the statement; problem solving chooses among alternatives and checks the outcome.
\nThe problem setting glossary entry gives the short definition, while the distinction among the three acts is developed in problem finding.
\nA problem statement starts from facts gathered from documents the company already has, not from sentences spoken in a meeting.
\nThe first version is written in a single sentence, in the present tense, with no names of people and no future-tense verbs.
\nThe coordinates are added to the sentence: the stretch of work involved, the period, the frequency and the value of the impact.
\nThen you state what stays out, because the boundary is the part that saves the most time in later meetings.
\nThe finished line is read to the people who do the work, and rewritten if the data contradict it.
\nThe closing test is five questions: reachable evidence, number and period, internal fact rather than external reaction, point in the work rather than a person's name, stated boundaries.
\nWhen one more question doesn't change the line, the statement is closed and the work moves on to the search for causes.
\nDefining a problem isn't the prelude to the work: it's the part of the work that decides everything else, because it measures the distance between how the work is going and how it should be going and states where it stops.
\nFive elements, four steps and a five-question test: the procedure fits on one page, and the time it takes is almost entirely fact-gathering time, not writing time.
\nThe three rewrites on this page apply unchanged to a practice with two team members and to a twenty-person machine shop, because the elements to put in writing don't depend on the industry.
\nWhen the problem has yet to be noticed — because the signals are there but haven't been named — the step before is problem finding.
\nWhen instead the line is written and the question becomes \"why is this happening,\" the map of available methods is in the guide to business problem solving, and the search proper begins with root cause analysis.
\nAfter a few months of statements written this way, the meeting changes subject: you discuss what the documents say, not what each person remembers.
\nThe time once spent reconciling different versions becomes available again.
\nAnd analyses that start from a verifiable line stop leading back to the starting point, because they point to a place in the work where you can intervene.
\n\n[1] Dewey, J., \"Logic: The Theory of Inquiry\", Henry Holt and Company, New York, 1938, ch. VI \"The Pattern of Inquiry\", p. 108. Full text consulted on Internet Archive: https://archive.org/details/JohnDeweyLogicTheTheoryOfInquiry
\n[2] Nutt, P. C., \"Surprising but true: Half the decisions in organizations fail\", Academy of Management Executive, vol. 13, no. 4, 1999, pp. 75-90, DOI 10.5465/AME.1999.2570556 (study of 356 decisions in medium-sized and large organizations in the United States and Canada). Publisher's page: https://journals.aom.org/doi/10.5465/AME.1999.2570556 — full-text copy consulted at: https://cebma.org/assets/Uploads/Nutt-1999-gecomprimeerd.pdf
\n[3] European Commission, \"'Better regulation' toolbox\", December 2025 edition, Tool #13 \"How to analyse problems\", pp. 90-93. Available at: https://commission.europa.eu/law/law-making-process/better-regulation/better-regulation-guidelines-and-toolbox_en — PDF: https://commission.europa.eu/document/download/9c8d2189-8abd-4f29-84e9-abc843cc68e0_en?filename=BR%20toolbox%20-%20December%202025.pdf
\n[4] Asian Development Bank, \"Problem Solving: Guidebook for ADB-Assisted Projects\", Mandaluyong City, 2016, \"Tool 1c: Problem Framing Tool\", pp. 17 and 26, ISBN 978-92-9257-329-4 (PDF). Available at: https://www.adb.org/sites/default/files/institutional-document/180614/problem-solving-guidebook.pdf
\n[5] ISTAT, \"Censimento permanente delle imprese 2023: primi risultati\", press release, November 14, 2023, Table 2, p. 4 (reference year 2022; 826,953 companies with at least 3 employees controlled by an individual or a family, equal to 80.9%; managerial leadership in 1.4% of these individually or family-controlled companies and 0.8% among those in the 3-9 employee class). Available at: https://www.istat.it/comunicato-stampa/censimento-permanente-delle-imprese-2023-primi-risultati/ — PDF: https://www.istat.it/it/files/2023/11/REPORTCensimprese.pdf
\n[6] Treccani, \"definire\", Vocabolario on line, Istituto della Enciclopedia Italiana. Available at: https://www.treccani.it/vocabolario/definire/
\n[7] Treccani, \"problema\", Vocabolario on line, Istituto della Enciclopedia Italiana (sense 3.a). Available at: https://www.treccani.it/vocabolario/problema/
","headings":[{"level":2,"text":"What a problem statement puts in writing, and what to keep it apart from","id":"what-a-problem-statement-puts-in-writing-and-what-to-keep-it-apart-from"},{"level":2,"text":"Goal, effect, intervention: the three swaps that empty a problem statement","id":"goal-effect-intervention-the-three-swaps-that-empty-a-problem-statement"},{"level":2,"text":"The five elements of a problem statement, one by one","id":"the-five-elements-of-a-problem-statement-one-by-one"},{"level":2,"text":"How to write a problem statement in four steps","id":"how-to-write-a-problem-statement-in-four-steps"},{"level":2,"text":"Three problem statement examples, before and after the rewrite","id":"three-problem-statement-examples-before-and-after-the-rewrite"},{"level":2,"text":"The five-question test to see if the statement holds up","id":"the-five-question-test-to-see-if-the-statement-holds-up"},{"level":2,"text":"The most common mistakes in defining a problem, and how to avoid them","id":"the-most-common-mistakes-in-defining-a-problem-and-how-to-avoid-them"},{"level":2,"text":"Limits and conditions of applicability","id":"limits-and-conditions-of-applicability"},{"level":2,"text":"FAQ","id":"faq"},{"level":3,"text":"What is a problem statement?","id":"what-is-a-problem-statement"},{"level":3,"text":"What's the difference between a problem statement and a goal?","id":"whats-the-difference-between-a-problem-statement-and-a-goal"},{"level":3,"text":"How do you define a problem in a single sentence?","id":"how-do-you-define-a-problem-in-a-single-sentence"},{"level":3,"text":"What's the difference between problem setting and problem solving?","id":"whats-the-difference-between-problem-setting-and-problem-solving"},{"level":2,"text":"Practical summary","id":"practical-summary"},{"level":2,"text":"Conclusion","id":"conclusion"},{"level":2,"text":"Sources and references","id":"sources-and-references"}],"tldr":"Should you start from what isn't working, or from what you want to achieve?","tldrItems":null}