Industry Insights
2022: Doing More With Less
The energy crisis hit Europe hard in 2022, and its effects rippled through every project I touched. Budgets that had been approved in the optimism of early 2021 were suddenly cut by a third. Clients who had been planning multi-phase transformation programmes were now asking a pointed question: can we get the same outcome at seventy percent of the cost?
The honest answer was usually no. But a more useful answer was: you can get a better outcome — if you’re willing to spend the money differently.
The Low-Code Surge
2022 was the year low-code and no-code platforms went from niche to mainstream. Power Platform, Mendix, OutSystems — these became standard parts of the enterprise conversation. The pitch was compelling: citizen developers building apps in days, not months. Drag-and-drop interfaces replacing weeks of custom development. Faster time to value at a fraction of the cost.
And for certain use cases, it worked. Simple workflow automation, basic data capture forms, internal tools that didn’t need to scale beyond a single department — low-code platforms delivered genuine value.
But for anything more complex, the same old problems resurfaced. Because here’s the thing about low-code: it doesn’t solve the analysis problem. It just makes the building faster. And if you automate a broken process, you don’t get a better process. You get a broken process that runs faster, fails faster, and is harder to fix because it’s now embedded in a platform that citizen developers can’t debug.
The Best Projects Spent Their Budget on Thinking
The best projects I worked on in 2022 had something in common: they spent roughly the first third of their timeline on analysis before anyone touched a tool. Not the old-fashioned, document-everything, boil-the-ocean kind of analysis. Focused, structured analysis that answered three questions:
- What is the actual problem we’re solving?
- What does the solution need to do — and not do?
- How will we know it’s working?
These projects didn’t produce hundreds of pages of requirements. They produced clear, concise problem statements, functional designs that developers could actually use, and acceptance criteria that meant something. When the build phase started, it was fast — because nobody was guessing.
The Worst Projects Jumped Straight to Building
The worst projects did the opposite. Under budget pressure, they cut the analysis phase first — because it was seen as overhead, not value. “We don’t have time for workshops. Just start building.”
The results were predictable. Features built to assumptions that turned out to be wrong. Integrations designed without understanding the data model on either side. User acceptance testing that surfaced fundamental misunderstandings about what the system was supposed to do.
One programme I observed spent four months building a customer portal that the operations team couldn’t use because nobody had asked the operations team what they needed. The rework cost more than the analysis would have.
Budget Pressure as a Clarifier
There’s a counterintuitive truth about constrained budgets: they can improve outcomes. When you can’t afford to build everything, you’re forced to prioritise. And prioritisation requires understanding — which requires analysis.
The organisations that thrived in 2022’s constrained environment were the ones that treated analysis not as a luxury that could be cut, but as the highest-leverage investment in their delivery pipeline. Every hour spent on clear problem definition saved three hours of rework downstream.
This wasn’t a new insight. I’d been saying it since 2019. But 2022 made it urgent. When the budget is tight, you cannot afford to build the wrong thing. And the only way to avoid building the wrong thing is to invest in understanding the right thing before you start.
The methodology I’d been forming in my head — the one that put structured analysis at the centre of delivery without slowing it down — wasn’t theoretical anymore. It was the difference between projects that delivered and projects that didn’t.