Episode 6 - Activity Isn’t Progress Designing Organisations That Deliver

Why do organisations working on projects, programmes, and digital transformation often feel incredibly busy yet still struggle to deliver?

In this episode of the Regen on Purpose Podcast, Karen Gray explores a common challenge in project management and organisational transformation: the gap between activity and real progress.

Drawing on experience working across complex transformation programmes, Karen shares why projects drift, why technology teams are often brought in too late, and why capacity and focus are the real constraints.

Learn how leaders can design organisations that finish work, build momentum, and deliver results.

Transcript

SPEAKER_00 0:00

Hi, I'm Karen Gray and this is Regen on Purpose, the podcast about designing organizations that learn, adapt, and deliver what matters. In this podcast we explore how organizations navigate change, not by just launching new initiatives, but by designing systems that actually matter over time. Because transformation doesn't succeed through effort alone. It succeeds when organizations are designed to learn, adapt and continuously improve how work gets done. Hello and welcome to Regen on Purpose, where we explore regenerative leadership, delivery, and systems that strengthen over time. I'm Karen Gray, let's begin. So let me ask you something. Have you ever been involved in a program where everyone seems incredibly busy? Calendars are full, meetings everywhere, plans are constantly being updated, but progress still feels slow, lots of activity, but somehow delivery isn't accelerating. Most people who have worked in large organizations will recognize that feeling. There's energy, there's movement, there's constant discussion, and yet the outcome sometimes seems to take much longer than expected. I've seen this pattern many times working across transformation initiatives. Because activity and progress aren't the same thing. And in this episode, I want to explore why that happens and what leaders can do differently if they want organizations that actually deliver. When organizations begin transforming, activity naturally increases. New systems are introduced, new processes appear, priorities shift. And often multiple projects are running at the same time. Transformation programs rarely involve just one initiative. They usually involve dozens of moving parts, technology upgrades, process designs, regulatory changes, customer improvements, and all of that work has to happen while the organization continues running the day-to-day operations. So calendars fill up quickly: steering groups, working groups, program or project boards, delivery meetings, status reviews, risk discussions, planning sessions, everyone is working incredibly hard. But here's the challenge. Delivery doesn't come from motion, it comes from completion. And sometimes organizations become very good at staying busy without actually finishing the things that really matter. In fact, most of the common patterns in large organizations is that work expands faster than it finishes. New ideas get added, the scope grows, dependencies appear. And gradually the program becomes more complex than anyone had intended. So quite often in my career I've been parachuted into programs or projects that were actually struggling. Usually with one simple request. Can you help us finish this? And I don't say this to sound like a hero. Most of the times the teams involved have been working incredibly hard. People care deeply about delivering a good outcome. But when someone is brought in at this stage, it's often a signal that something early in the program hasn't quite worked the way it was intended. And quite often that comes back to a very simple question that wasn't fully answered at the start. Why are we doing this project? What problem are we actually trying to solve? And just as importantly, what happens if we don't deliver it? Because when that clarity isn't there, projects can start to drift. Scope expands, priorities change, new features are added. And over time the project can gradually become something quite different to what it originally intended. So organizations end up with a lot of activity, but not always the progress they expected. Another pattern I've seen quite often is when technology teams are brought into the project far too late. The business may already have defined the solution. The scope is agreed, the timeline is set, and then technology is asked to join the project. But by that stage, some of the most important design decisions have already been made. Sometimes without fully understanding the technical implications. So delivery becomes much harder. Timeline stretch, complexity increases, and the teams end up working much harder trying to catch up with the decisions that were made earlier in the project. This isn't usually because anyone intended to create these problems. It simply happens because organizations often design the projects in phases. Business first, technology later. But increasingly, technology is not just an implementation detail. It's part of the design itself. So when those conversations happen too late, organizations sometimes discover that what looked simple on paper is far more complicated in practice. When I look across programs I've worked on, the projects that really matter usually fall into three categories. The first is regulatory or compliance work. These projects simply have to happen. If they don't, the organization faces regulatory or legal consequences. So the timelines are fixed. There is very little flexibility. The second category is systems reaching end of their life. Licenses expire, technology platforms stop being supported, or systems simply stop working. At that point, replacement isn't optional. And the third category is technology that no longer works well for the organization or for its clients. The system might technically still function, but it's no longer helping the organization move forward. Customers expect better digital experiences. Teams create workarounds, and the organizations spend more time maintaining old systems than improving the services. And when those three drivers combine regulatory pressure, aging technology, and rising customer expectations, organizations can find themselves running many large programs at once. But even when the reason for the project is valid, if the organization hasn't clearly prioritized the work and designed how the delivery will happen, the same pattern appears. Lots of activity, but slower progress. In most transformation programs, the real constraint isn't effort, it's commitment. And it usually isn't technology. The real constraint is capacity and focus. People are still running the day-to-day business, as usual, serving customers, operating systems, managing risks, and at the same time they're learning new systems, adapting to new processes, supporting change across the organization. And when too many initiatives compete for attention, delivery slows down. One of the simplest ways to recognize this problem is to ask a different question. Instead of asking how busy are we, ask what are we actually finishing. Completion creates momentum. Completion builds confidence. Completion creates visible progress. Teams feel the difference when work finishes. Stakeholders see the results, and the organization gains confidence to move forward to the next stage. But when work keeps expanding without finishing, the organization feels permanently busy without ever finishing or completing something. So what can leaders do differently? A few things can make a real difference. First, reduce the number of priorities. Most organizations attempt to do too much at once. And often the fastest way to accelerate delivery is to simply focus on fewer things. Second, design how work flows. Transformation isn't about launching projects, it's about designing how work moves across teams, decisions, leadership structures. And when that flow works well, delivery speeds up. And third, value completion. Finishing work is one of the most underrated drivers of momentum. Completion frees capacity, completion builds confidence, and completion creates space for the next stage of change. And this is where something interesting starts to appear. When you see an organization that is constantly delivering well, they tend to behave differently. Which is actually very similar to what we see in nature. Natural systems don't survive by simply pushing harder. They survive because they adapt and renew themselves. They evolve, they rebalance, they regenerate. And increasingly the same principle applies to organizations. If we design organizations purely for efficiency, they can eventually become fragile. But when organizations are designed to learn, adapt and renew, they become far more resilient. And in many ways, that's what regenerative thinking is about. Not just sustaining performance, but continuously renewing the organization's capability to perform. Because in the end, stronger organizations don't happen by chance. They are designed. Designed to learn, designed to adapt, and designed to renew their ability to perform. And that's regeneration on purpose. Thanks for listening to Regen on Purpose Podcast. Thank you for listening to Regen on Purpose. Sustainability is a starting point. Regeneration is the natural progression. Until next time, design for strength and start building what lasts.