Le Grand Plan: Replacing the Ship While Sailing It

The Finance Director fought me for months. Their off-the-shelf finance package promised everything - forecasting, reporting, analytics - and they wanted it to be the master system for the entire business. Everything else should feed into it.

I understood why. Finance had been operating partially blind. Each department calculated product margins differently. Sales would estimate one profitability number, production another, and then accounts would come out showing something else entirely. Nobody knew what was actually making money in a business that needed laser focus on profitability.

But making their finance package the hub would have locked us into a tightly coupled architecture for years. Every system dependent on it. Every change rippling through everything. We'd lose the flexibility we needed to keep improving.

The breakthrough wasn't winning the argument. It was understanding what they actually needed and finding a way to deliver that whilst keeping our architecture flexible.

We built "One Truth" - a single profitability model the whole business could trust. But we built it with proper schema design, data warehousing principles, APIs instead of brittle integrations. We gave Finance direct access to the data feeds they needed, integrated into their existing tools. They got what they needed. We got to keep replacing the planks.

That conversion happened over and over during what we called Le Grand Plan. Not just with Finance, but with Commercial, Operations, Production. Every stakeholder, every level. Being technically right wasn't enough. Delivering business wins wasn't enough either. You had to do both, and the balance shifted constantly.

The Simple Version

I was Head of Core Systems at a £40m ecommerce-driven printing manufacturer. The business had been growing 20% year-on-year for four or five years. Technology was seen as a growth driver. The systems worked. The teams were talented. Nothing was broken.

I'd been away for 20 months on sabbatical, and coming back gave me fresh eyes. The teams had done brilliant work - they'd evolved systems to solve current challenges, delivered features that drove growth, kept the business running whilst scaling rapidly. But I could see the architecture wouldn't scale to where we wanted to go.

Technical projects had proliferated across departments. The ERP was a tightly coupled monolith - functions built on top of functions, dependencies everywhere. Not because anyone had done anything wrong, but because that's what happens when you grow fast and prioritise delivery. You build what works today.

We needed better enterprise architecture. So we created Le Grand Plan: map the dependencies, sequence the work, build towards loosely coupled systems.

That's the elevator pitch. It's not wrong. It's just not the whole story.

The Real Version

The technical architecture wasn't the problem - it was a symptom. The real problem was that we were a successful, fast-growing business where nobody had a shared understanding of how the technology ecosystem actually worked.

Operations was optimising for one thing. Commercial for another. Finance for a third. Each had their own projects, their own priorities, their own version of what the business needed. The technology reflected that fragmentation - systems built in isolation, integrated through brittle point-to-point connections, each team protecting their territory.

I reported to the MD, but I was a peer to Finance, HR, and Commercial leads on the seven-person senior team. I had no positional authority over any of them. If I was going to orchestrate a multi-year technical transformation, I needed them to see it as their plan, not mine.

So I spent two months walking the business. I talked to supervisors about their systems. I talked to managers about connections between departments. I talked to heads about strategy and motivation. I built a dependency map - not just technical dependencies, but business dependencies. What relied on what. What blocked what. What unlocked what.

Then I brought it to our quarterly offsite. Seven of us in a room, including the two company owners. I laid out the map and said: here's what I think we need to do, here's where I'm making judgement calls. What would you change?

Not "what would you like?" - that gets you wishlists. "What would you change?" gets you engaged negotiation.

The Messier Version

The dependency map wasn't elegant. It was a mess of arrows and boxes showing projects at different stages, all interconnected. Some were in progress. Some hadn't started. Some we'd need to invent. Some would get superseded as we learned more.

The revelation for most people wasn't "we can't do X without Y" - they usually knew the first-level connections. It was "X needs Y, but we didn't know Y needed A, which is reliant on B." Hidden dependency chains running three or four levels deep.

Like route optimisation. We wanted to calculate lowest-cost production routing. Sounds straightforward. But that calculation depended on accurate material costs, which depended on fixing a £1M annual material variance gap, which required automated data capture from production equipment, which needed the imposition server replacement, which required workflow standardisation... you get the idea.

You couldn't fix one thing. You had to fix the chain. But you couldn't fix the whole chain at once - we didn't have the resources, and the business couldn't wait years for value.

So Le Grand Plan became a framework for sequencing: deliver value whilst systematically improving the architecture underneath. Never deliver just the top layer - always deliver a full slice that solved a business problem AND replaced a plank in the ship.

We started with Finance "One Truth" because we needed the whole business aligned on what was actually profitable. But we built it to make the next ten projects easier.

Production Performance Management was harder than it looked. We had the technical solution working, but people didn't trust the data at first. Some didn't engage at all. Some chased the wrong metrics - optimising for throughput whilst ignoring quality, gaming the numbers rather than improving the work.

We had to reframe everything. It wasn't about raw output. It was about balance - efficiency AND quality. We added quality metrics alongside performance metrics. We spent time with production managers explaining what we were measuring and why it mattered. Slowly, over six months, the cultural shift happened. When it worked, it freed up managers' time and gave visibility that gut-feel decisions never could.

The Material Variance Attack - that £1M opportunity - required five different projects to converge: automated data capture, VA Cave (our standard cost model), improved Nav reporting, better finance integration, production workflow changes. We couldn't do it all at once. We did it in phases, each phase delivering something useful, each phase building the foundation for the next.

The sequencing logic was always the same: what delivers business value now whilst making future work easier? What dependencies must we solve first? Where can we deliver wins for stakeholders whilst improving the underlying architecture? The plan was structured so each phase was win-win (a principle from 7 Habits of Highly Effective People that shaped how we operated) - business value and architectural improvement.

Some projects were technically impossible due to dependencies. Some we agreed at quarterly offsites. Part of the art was political - if I could squeeze in a project to help someone and gain goodwill, I would. If I couldn't, it went to the offsite where it would be evaluated against business priorities.

When people got frustrated with sequence or timing, seeing the dependency chains helped. Route optimisation revealed those hidden connections that added weight to technical debt arguments and drove cross-functional agreement. People could see how doing one project improved both direct and second-order dependencies.

The Version Nobody Talks About

Here's what the enterprise architecture frameworks don't tell you: the dependency map wasn't the solution. It was the conversation starter.

It made the invisible visible. Technical debt stopped being "the tech team's problem" and became a shared business constraint everyone could see. When Finance wanted their feature and Commercial wanted theirs, we could look at the map together and see the trade-offs. Not me telling them what was possible - us negotiating what was best for the business.

I'd put forward options: we can do this for Marketing, this for Customer Service, or this for Production. I'm suggesting this, but what do we think is best? Sometimes they'd push back and I'd adjust. Sometimes I'd hold firm on paying down technical debt and explain why - because I could see three projects down the line that would be impossible without it.

Some weeks I'd hold firm on architectural decisions and watch relationships get tense. Other weeks I'd compromise on something I knew was technically suboptimal because Finance or Commercial needed a win and the political capital mattered more than the perfect solution. That constant negotiation - knowing when to be immovable and when to flex - that's the job description nobody writes down.

The plan was structured so each phase was win-win - business value and architectural improvement. But that didn't mean feature work never got delayed for architectural reasons. It did. The difference was that people understood why, because they could see the dependency map and the trade-offs we were making together.

The Finance Director conversion became a pattern I saw everywhere. People would fight for their vision of how things should work. I'd listen, understand what they actually needed, and find a way to give them that whilst keeping our architecture flexible. Sometimes that meant building custom integrations. Sometimes it meant changing the plan. Always it meant one-on-one conversations about problems and solutions, not mandates from on high.

I wasn't the most senior person in the room. I was a peer. My credibility came from doing the work, delivering wins, being authentic about what I could and couldn't do. No jargon. No ego. Dig in and get it done for the team.

What I Understand Now

I only recently found the name for what we were doing. Mark Schwartz calls it the "TTheseus Ship" in A Seat at the Table - the idea that you can replace every plank on a ship whilst it's sailing, and end up with an entirely new vessel without ever stopping.

That's exactly what Le Grand Plan was. We spent three years delivering business value whilst fundamentally transforming the architecture underneath. We replaced the tightly coupled monolith with loosely coupled systems - APIs, microservices, proper data flows. Not in a big-bang replatforming that would have stopped all feature work. Piece by piece, always delivering, always improving.

But the Theseus Ship metaphor doesn't quite capture the full complexity. We weren't just replacing worn planks - we were also upgrading them. Replacing the motor with a larger one. Adding capabilities. Making the ship more capable whilst making it more maintainable.

And we were doing it with a crew that didn't all agree on where the ship should go.

The framework had to be collaborative. The quarterly offsites where all seven of us presented ideas, discussed, agreed on plans, allocated resources - that's where Le Grand Plan became real. Not as my technical vision, but as our shared understanding of what needed to happen and why.

The programme evolved constantly. Projects shifted priority based on business needs. New opportunities emerged. Some projects got superseded by better approaches. The dependency map changed as we learned what actually mattered. When COVID hit and the business pivoted, Le Grand Plan adapted. Key resources moved to different priorities. But the principles stayed intact. The goals remained.

By the time I moved on, we'd gotten far enough that the programme could evolve without me. It was never meant to be "completed" - it was a framework for getting the best impact we could from the time and resources we had.

The Pattern That Sticks

I'm doing it again now in my current role. Different company, different scale, different challenges - but the same fundamental approach.

The core ERP implementation is big-bang because it has to be. But every edge application, every integration, every enhancement - I'm building them using the TTheseus Ship model. Deliver business value whilst systematically improving the architecture underneath. Map the dependencies. Build alignment across stakeholders. Make every phase win-win.

The pattern works because it aligns incentives. Business stakeholders get their wins. Technical teams get to do things properly. Everyone can see the destination on the dependency map. The quarterly planning keeps us adapting to changing priorities.

But the real reason it works is the balance. Being technically right is not enough. Neither are wins for the business. You have to do both, and that balance isn't static.

Some days Finance needs their win and you adjust the architecture work to make it happen. Some days you hold firm on paying down technical debt because you can see it's essential for future capability. Some days Commercial and Operations have competing priorities and you have to negotiate what serves the business best, not what's easiest technically.

The dependency map gives you the shared language to have those conversations. The collaborative planning gives everyone ownership. The slice-of-value delivery approach gives you permission to do the right technical thing whilst solving real business problems.

But the balance - that constant negotiation between technical excellence and business value, between what we need today and what we need next year, between giving people their wins and building the foundation for future wins - that's what strategic technology leadership actually looks like when you're operating as a peer, not a dictator.

Le Grand Plan worked not because we had the perfect technical vision, but because we built alignment across organisational levels, made technical constraints visible as shared business problems, and delivered value whilst systematically replacing the ship we were sailing on.

The Finance Director became one of the plan's strongest advocates. Not because I won the argument about architecture, but because we solved their problem whilst keeping our options open. That pattern repeated everywhere - not convincing people I was right, but finding ways to give them what they needed whilst doing what was right for the business long-term.

It's messier than the frameworks suggest. The balance shifts constantly. You're replacing planks on a moving ship, and the crew keeps debating which direction to sail. But that's the real work of enterprise architecture at scale - and it's a pattern that sticks once you see it.