The World Bank — When IT learns to frame the problem first

The pattern most IT teams don't talk about

Most large organizations share a version of the same friction between IT and the business. The business brings a need. IT hears a requirement. A solution conversation starts before anyone has agreed on what problem is worth solving.

This gap is rarely about competence. It's about sequence. Technical teams are trained to solve — to evaluate feasibility, estimate effort, architect systems. They're rarely trained to question whether the thing being asked for is the right thing to ask for.

The result is predictable: projects that are technically well-executed but miss the mark. Business units that feel unheard. IT teams that feel undervalued. And a slow accumulation of work that satisfied the brief without solving the actual problem.

The World Bank's IT leadership recognized this pattern and decided to do something specific about it.

What the World Bank wanted to change

The World Bank brought together multiple IT teams in Washington, D.C. with a clearly stated goal: help IT better connect with the business and scope projects before jumping to solutions.

This is a precise diagnosis. The problem wasn't a lack of technical skill. It wasn't a process failure or a tooling gap. The gap was earlier in the sequence — before any project was scoped, before any solution was proposed.

Teams were arriving at the wrong answer because they were answering the wrong question.

The decision was to train teams in two methods in sequence: Problem Framing Training on day one, Design Sprint Training on days two and three.

The combination was deliberate. Problem Framing teaches teams to define the right problem. Design Sprint training teaches them what to do once they have one. Together, they create a complete decision-making loop — one that begins with the business challenge and ends with a validated solution direction, without skipping the hardest step in the middle.

Day one: learning to question before proposing

The Problem Framing day started with a principle that most IT teams find counterintuitive: the first job when you receive a request is not to begin scoping the solution. It's to understand whether the problem behind the request has been clearly defined.

Participants worked with real challenges from their own context — not case studies, not hypothetical scenarios, but actual situations their teams were navigating. That grounding matters. It's much harder to default to solution mode when the problem on the table belongs to you.

The day covered three interconnected capabilities:

Surfacing assumptions. Every project request carries hidden assumptions about what the problem is, who it affects, and why it matters. Most teams inherit those assumptions without examining them. Problem Framing gives teams a structured way to make them visible — and to question them before committing to a direction.

Aligning stakeholders on a shared problem. In cross-functional contexts, different stakeholders often carry different versions of the same problem. IT might define it as a system limitation. The business might define it as a workflow failure. A third team might see it as a communication gap. Problem Framing creates a structured process for converging on a single, agreed problem statement — one that all parties recognize as accurate.

Translating fuzzy issues into clear problem statements. The output of a Problem Framing session is a precise, agreed statement of the problem worth solving. This is more useful than it might sound. A clear problem statement gives IT a defensible foundation for every subsequent decision: what to build, what to prioritize, and — equally important — what to push back on.

For IT teams whose default is to receive requests and begin executing, this represented a meaningful shift. Learning to frame before scoping changes the nature of the IT-business relationship. It moves IT from order-takers to thought partners.

Days two and three: learning to move from problem to prototype

The Design Sprint training covered two days, running participants through an accelerated version of the full four-day sprint process. The goal wasn't to simulate every detail — it was to give teams firsthand experience of the complete arc: from a defined problem to a tested solution direction.

Teams moved through each phase of the Design Sprint methodology: mapping the challenge, generating solution ideas individually before sharing them with the group, making decisions, building a prototype, and testing it. The emphasis throughout was on doing, not just learning. Understanding a method conceptually is very different from having run it yourself.

Two principles from the Design Sprint proved particularly relevant for IT contexts.

Together Alone — individual before group. Design Sprints separate idea generation from group discussion. Each person develops their thinking independently before it's shared. For IT teams that often operate in large technical review meetings where senior voices dominate early, this principle changed the dynamic. Ideas got more equitable attention. Quieter participants contributed meaningfully. The group's output improved.

Fail fast, learn faster. Design Sprints are built on the assumption that testing a rough prototype with real users early is always more valuable than refining a solution internally for weeks. For teams trained to build toward certainty before releasing anything, this is a genuine mindset shift. The sprint creates a structured permission to test before things are finished — and to treat the feedback as the point, not the interruption.

By the end of day three, teams had experienced both methods end-to-end with their own real challenges. They didn't leave with a report or a set of slides. They left knowing how to run both processes themselves.

What changes when IT learns to frame first

The outcome of the World Bank training wasn't a solved problem or a shipped product. The outcome was a capability — the ability to have a different kind of conversation with the business before any scoping begins.

That shift has practical consequences.

When IT teams can facilitate a Problem Framing session, they can push back on poorly defined requests without being obstructive. They have a structured process to offer instead: let's spend time understanding what we're actually trying to solve. That reframes resistance as rigor. It gives IT a constructive alternative to "we need more information before we can scope this" — which business units often experience as a delay rather than a partnership.

When IT teams understand the Design Sprint process, they can scope projects against a validated solution direction rather than an assumed one. The prototype-and-test loop creates a checkpoint that most IT projects skip: does this solution actually address the problem the business has? Running that check before committing development resources is significantly cheaper than discovering a mismatch at deployment.

The methods work together because they address the same root cause from two angles.

Problem Framing disciplines how a team enters a challenge. Design Sprint disciplines how they exit it.

Between those two disciplines, the space for misalignment shrinks considerably.

Why the training format mattered

Three days is a short period of time for a significant capability shift. What made it work at the World Bank was the combination of structure, real content, and the sequence.

Working with real challenges — rather than generic training scenarios — meant the learning landed immediately. Participants could test the methods against problems they already cared about and see where the approach added clarity. That direct application is what makes training stick beyond the room.

The sequence — Problem Framing first, Design Sprint second — also mattered. Running them in this order reinforced the relationship between the two methods. Design Sprint training is more meaningful once you understand why it needs a well-defined problem to work from. Problem Framing training is more compelling once you can see where a clear problem statement leads.

The goal was independence: teams leaving with the skills to run both methods without outside support, collaborating more effectively with other business units as a result.

What this means if you're managing the IT-business gap

The World Bank engagement is a specific story, but the problem it addresses is widespread. In large organizations — particularly in institutions where IT operates across multiple business units with different priorities — the gap between what IT receives and what the business actually needs is a persistent source of wasted effort.

Training alone doesn't close that gap permanently. Which?'s three-year investment, described in a separate case study, shows what it takes to embed a method into how an organization works long-term. But training is the entry point — the moment when teams first experience a different way of working and discover that they can do it themselves.

For IT leaders who recognize the pattern described here — teams that are technically strong but consistently miss the mark on project relevance, or that struggle to push back constructively on unclear requests — the investment in Problem Framing and Design Sprint training is an investment in the upstream conversation. The one that happens before any code is written, before any architecture is drafted, before any timeline is committed to.

Getting that conversation right is harder than it sounds. But it's also teachable.