What "One Solution Definition" Actually Means In Practice
Most people walking into urban planning meetings use the term loosely. They hear it on a podcast or in a conference keynote and assume it refers to some single master plan that covers every problem a city might face. That is not what it means. The concept is far more constrained and far more useful than the buzzword version. One Solution Definition is a methodological framework where every urban intervention — from a zoning change to a transit line to a green corridor — is traced back to one primary problem statement before any design work begins. You do not sketch a park. You define the specific failure condition the park is meant to resolve, then you design only what is necessary to resolve it. I learned this the hard way around 2014, when I was part of a mid-sized city team that had been tasked with reducing neighborhood flooding in a mixed-use corridor. We had three separate proposals on the table: a bioswale system, a raised plaza with subsurface retention, and a complete street redesign with underground culverts. Each was championed by a different consultant. Each claimed to solve the flooding problem. None of them checked the actual hydraulic model against the same baseline assumptions. The flood risk was not one problem. It was two: stormwater velocity during 10-year events, and groundwater seepage during prolonged saturation. The bioswales handled the first. The culverts did nothing for the second. We spent four months and about sixty thousand dollars in professional fees before someone pointed out that we were solving different problems with different tools and calling it one integrated solution. That failure is exactly why the One Solution Definition framework exists. It forces a discipline that most planning departments skip because it feels slow. You pick one problem. You define its measurable parameters. You build the intervention around that single definition. Everything else gets filtered through it.
The Future Of Urban Planning Implementing The Concept Of One Solution Definition
Urban planning is moving toward this framework because the alternative is becoming financially unsustainable. Cities are running out of budget for projects that look good on renderings but fail to resolve the underlying conditions they claimed to address. The shift is not philosophical. It is fiscal. When a transit-oriented development misses its ridership projections by forty percent, the city does not blame bad marketing. It blames a flawed problem definition. One Solution Definition attempts to catch those failures before ground is broken. The process has five stages. I will walk through each one with the kind of detail that actually matters, not the kind that sounds good in a government white paper. Stage one is problem isolation. You write a single sentence that states the failure condition without any suggested remedy built into it. Not "we need more green space." Not "the neighborhood needs better transit." Those are solutions disguised as problems. The correct form is something like: "Residents within a half-mile radius of the industrial corridor experience particulate matter exposure above EPA standards during weekday commuting hours between seven and nine AM." That is specific. It is measurable. It contains no built-in answer.
Stage two is parameter definition. You attach numbers to the sentence. How many residents? What is the current measurement? What is the threshold? What is the time window? You pull data from existing sources before you commission new studies. Traffic counts, air quality monitors, census tracts, property values, hospital admission records. In my experience, about sixty percent of the data you need already exists in municipal databases or public records. The rest requires targeted collection. If you cannot define the parameters, you do not have a problem statement. You have a complaint. Stage three is causal mapping. You identify what drives the failure condition, not just what correlates with it. This is where most plans go wrong. A correlation between low tree canopy and high surface temperatures is not the same thing as causation. Your causal map should distinguish between direct drivers and contributing factors. In the flooding example from earlier, the direct driver was combined stormwater and groundwater pressure on aging infrastructure. Contributing factors included impervious surface percentage, pipe diameter specs from the 1978 building code, and topography. You address the direct driver first. You note the contributing factors for future phases. Stage four is intervention selection. You choose the smallest intervention that resolves the defined problem within the defined parameters. Not the biggest. Not the most politically attractive. The smallest. This sounds counterintuitive to people who think urban planning means big visible projects. But smaller interventions produce higher return on investment because they are easier to measure, easier to adjust, and easier to scale if they work. A raised plaza with subsurface retention costs less upfront than a full street redesign. If it solves the problem, you keep it. If it does not, you know exactly what failed and why. A full street redesign obfuscates that feedback loop.
Get the Full Details
Stage five is success measurement. You define the metric before you start, not after. You decide what number proves the intervention worked and what number proves it did not. Then you build the monitoring system into the project timeline and budget from day one. I have seen too many projects where the success metric was "community satisfaction," which is impossible to measure consistently. Use hard numbers. Particulate matter drops below the threshold. Flood depth decreases by X inches during Y-year storms. Commute times shorten by Z minutes. These are binary. They do not require a survey to interpret.
Common Pitfalls That Break The Framework
The framework is simple. Applying it is not. Here are the mistakes I see repeatedly. Pitfall one is problem scope drift. You define a clean, narrow problem. Then a councilmember wants the project to also address blight. Then a community group asks for a public art component. Then the environmental review uncovers a wetland. Within six months, your one-solution definition has become a one-problem-plus-everything-else proposal. The intervention bloats. The budget inflates. The success metrics become contradictory. The workaround is strict change control. Any addition to the scope requires rewriting the problem statement and redefining the success metrics. If you cannot rewrite it cleanly, the addition does not belong in the project. Pitfall two is data paralysis. Teams sometimes spend years collecting data before they ever define the problem. They want perfect information. Perfect information does not exist. You need enough data to define the parameters with acceptable confidence, then you move forward. In practice, that means you collect data until the marginal value of another dataset is less than the cost of collecting it. I usually set a hard deadline: forty-five days from project kickoff to final problem statement. If the team cannot produce a defensible one-sentence problem definition by then, they are not collecting data. They are avoiding decision-making.
Pitfall three is solution attachment. Consultants and agencies often fall in love with their preferred intervention before the problem is fully defined. A landscape architect will push green infrastructure. A traffic engineer will push road widening. A policy wonk will push zoning reform. The framework requires you to remain genuinely open until Stage Four. I have found that the most effective way to prevent premature solution attachment is to require the problem statement to be signed off by someone who will not benefit from any particular intervention. An independent auditor, a community representative, a different department. Someone with no skin in the game.
Where The Framework Fails
I want to be blunt about the limitations because the people selling this concept rarely are. One Solution Definition does not work for chronic, systemic problems that have no single causal chain. Housing affordability is not one problem. It is a cluster of interdependent issues: zoning restrictions, construction costs, wage stagnation, demographic shifts, speculative investment. You can define sub-problems within the broader issue, but you cannot isolate one solution for the whole thing. The framework is most effective for discrete, bounded problems with clear physical or environmental parameters. It breaks down when applied to social or economic phenomena that resist clean measurement. Another failure mode is political interference. If a decision-maker has already chosen the intervention and is only seeking justification, the framework cannot stop them. A city council that has pledged to build a new convention center will find a way to define the problem as "our city lacks sufficient convention capacity" regardless of what the data says about demand, economic impact, and opportunity cost. The framework requires genuine commitment to evidence over preference. That is a cultural requirement, not a procedural one. It cannot be enforced by a checklist.
There is also a time cost. Applying the framework rigorously adds approximately three to six weeks to the pre-development phase of a typical urban project. For agencies operating on compressed timelines or under political pressure to announce results quickly, this is a real tradeoff. The framework saves time downstream by reducing redesigns and Scope creep, but the upfront investment is visible and immediate. I recommend using it selectively: apply it to projects over a certain budget threshold or complexity level, not to every small improvement initiative.
A Real Example From A Recent Project
Two years ago I worked on a corridor revitalization project in a suburb that had been struggling with declining retail occupancy for a decade. The initial problem statement from the consulting team was: "The corridor lacks vibrancy and needs streetscape improvements to attract new businesses." That is not a problem definition. It is a wish list with decorative language attached. I rewrote it. The new one-sentence definition: "Vacant ground-floor commercial spaces along a 1.2-mile corridor exceed thirty-eight percent occupancy loss, correlated with pedestrian traffic counts below twelve hundred per hour during weekday business hours, despite proximity to a commuter rail station." That was the actual problem. Not vibrancy. Not aesthetics. A specific gap between foot traffic potential and realized occupancy, measurable with existing data. The causal map showed three direct drivers: poor pedestrian access from the rail station due to a four-lane arterial cut, lack of ground-floor residential units to generate evening and weekend foot traffic, and parking-heavy site design that prioritized cars over people. Contributing factors included lease terms that discouraged small tenants and a commercial tax abatement that favored anchor stores over diversified occupancy.
The selected intervention was small. A two-block pedestrian priority zone connecting the station to the commercial stretch, combined with a zoning overlay allowing mixed-use ground floors and restricting surface parking frontage. Total cost: under two million dollars. No new roads. No demolitions. No grand plaza. Success was measured at twelve months post-implementation: vacant ground-floor commercial occupancy dropped from thirty-eight percent to twenty-two percent. Weekday pedestrian counts in the priority zone rose to two thousand one hundred per hour. The numbers met the pre-defined thresholds. The framework held. The version that would have been produced without it: a main street redesign with ornamental lighting, planters, and a central fountain. Cost: eight million. Ridership impact: uncertain. Vacancy trend: likely unchanged, because the fountain does not create foot traffic that the arterial road prevents.
What To Do If Your Agency Is Not Ready
Not every planning department has the capacity to adopt this framework wholesale. If you are working with limited staff or tight deadlines, start with Stage One only. Force every proposal to be accompanied by a single-sentence problem definition written in the format I described. That alone will eliminate roughly half the weak proposals that reach your desk. It is the lowest-effort, highest-return change you can make. If you have more bandwidth, add Stage Two and Stage Five. Define the parameters. Measure the outcomes. Everything else is incremental improvement on top of that foundation. Do not try to implement all five stages across every project simultaneously. You will burn out the team and produce nothing. The framework is a discipline, not a product. It does not come in a software package or a consulting contract. It comes from requiring your team to think harder before they design harder. That is not always popular. It is always necessary.
