We Declare Transformation. We Implement the Status Quo.

Every technology decision is a leadership choice. Not a software choice. A leadership one.

Underneath the vendor demonstrations, the business case and the procurement paperwork, the choice usually comes down to two options.

Two options

Option one is the familiar path. We change the software, or the solution, and keep everything else. The status quo stays. The complexity stays. The old way of thinking stays. We redo the work the same way we are used to thinking about it, only on a newer platform. And the debt, in technology, in process and in the organisation itself, quietly increases over time.

Option two is the harder path. It asks for investment up front, to build an asset for the future. It asks for an open mind. It treats the change as a transformation, not an upgrade, and invests in change management to bring people along. It aims for simplicity. It re-designs, rather than reproduces.

Neither option is a mystery. Most leaders could describe both in a few minutes. The difficulty is not in knowing the difference. It is in what happens next.

What actually happens

Most organisations declare option two and do option one.

The business case speaks of transformation. The vendor presentation speaks of modernisation. The kick-off slides speak of re-design and simplicity. Then the requirements workshops begin, and the old processes are written down, one by one, as requirements. The customisations are approved, one reasonable request at a time. The change management budget is trimmed, because it looks soft.

There are three common versions of this.

Some declare option two and do option one, knowingly. The language of transformation helps the business case get approved. Everyone in the room understands that the real plan is a like-for-like replacement.

Many think they are doing option two, but are implementing option one. This is the most common version, and the hardest to see from the inside. Nobody intends to rebuild the old system. Yet every individual decision pulls in that direction, and nobody steps back far enough to notice the sum of them.

Many start with option two, then move to option one. The cost becomes real. The pushback arrives. A directorate resists the new process. The timeline comes under pressure. So the program retreats to the familiar, with a promise to revisit and improve later.

Later rarely comes. Once the system is live, the project team disbands, the budget closes and attention moves elsewhere. The promise to revisit simply becomes part of the debt that option one was always going to accumulate.

A familiar example

Consider a council replacing its finance and HR systems.

The business case is clear. Retire years of customisation. Standardise processes across directorates. Give managers direct visibility of their budgets. Invest in change management so staff adopt the new way of working. This is option two, written down and approved by Council.

Six months in, the design workshops are running behind. Payroll wants its existing reports replicated exactly. Two directorates want their own approval routes kept. Staff have raised concerns about changes to timesheet processes. The change manager’s engagement is cut back to cover a data migration overrun.

Each decision is defensible. Each is made with the intention of returning to it after go-live.

The system goes live close to the date. The steering committee reports success. And the council now runs its old processes, its old reports and its old approval routes on a new platform, with a fresh set of customisations to maintain through every future upgrade.

The business case still says transformation. The organisation is living option one.

Clarity is key

None of this means option one is always wrong. Sometimes a like-for-like replacement is the right decision. The old system is losing vendor support, the budget is limited, or the organisation has no capacity for a larger change right now. Those are real constraints, and choosing option one in response to them can be sound leadership.

The problem is not choosing option one. The problem is choosing it without admitting it.

When the declared option and the implemented option differ, everything downstream is distorted. The benefits in the business case never arrive, because the work that would have produced them was never done. Staff are told they are being transformed, and experience nothing of the kind. Leaders report progress against a plan that no longer exists.

So be aware of which option you are actually going ahead with. And then actually do it.

If it is option two, hold the line when the cost and the pushback arrive, because they will. If it is option one, say so, plan for the debt it will create, and stop describing it as transformation.

And whichever you choose, have good reasons for it. Reasons you could explain to Council, to staff, and to whoever inherits the system in five years.

Clarity is key.

The questions that remain

Here are some questions to ponder.

Which option does your business case declare, and which option are your design decisions actually implementing?

How many of your current compromises come with a promise to revisit later, and who will be there to keep that promise after go-live?

And if you are choosing the familiar path, have you said so out loud, with good reasons, or are you still calling it transformation?