Is Your Transformation Actually a Transformation?
A practical guide to diagnosing what you are really working on and how to navigate it.
At a glance (30 seconds)
Ask one question: Will this change how we create or capture value, beyond moving the same work onto a new system?
Sort the programme into one of three realities: 1/ IT modernisation, 2/ real business transformation, or 3/ digital theatre.
Then use the matching playbook: what success looks like, what to expect from leaders, and what to say in the room without getting yourself burnt.
The Feeling You Cannot Shake
You are three months into a programme everyone calls a “digital transformation”.
The town halls are energetic. The slides talk about reimagining the business. Your calendar is full of workshops with names like “Future State Design” and “Value Stream Mapping”.
But something does not add up.
The conversations are mostly about system configuration, data migration, and cutover planning (the planned switch from old systems to the new one). The benefits case is a spreadsheet of assumptions nobody has validated. Middle managers smile politely in steering committees, then go back to doing things the way they always have.
You are starting to wonder: Is this actually a transformation? Or is it something else dressed up in transformation language?
You are not imagining it. And you are not the only one who sees it.
This guide will help you diagnose what you are really working on, understand why programmes get mislabelled, and, most importantly, figure out how to do good work and protect yourself regardless of which type of programme you are in.
The Upshift Transformation Test
There is one question that cuts through the noise. Ask it about any programme that carries the word “transformation”:
Does this change how we create or capture value, beyond doing the same work on a new system?
If the honest answer is yes, you are in a real transformation.
If the answer is no but the work is still valuable, you are in an IT modernisation.
If the answer is no and the programme is mostly narrative and optics, you are in digital theatre.
Let me break down each one.
IT Modernisation
The programme is:
Replacing legacy systems
Moving to cloud
Standardising processes across the organisation
Automating manual work
Example: Moving from an unsupported on-premise ERP to a supported cloud platform, with standardised finance processes and stronger controls, but no change to products, pricing, or routes to market.
The business model stays the same. How the company makes money stays the same. The outcomes are lower cost to serve, better reliability, reduced risk from ageing technology, and improved controls. These programmes are necessary and valuable. They keep the company running. But they are not transformation in the value-creation sense.
Real Business Transformation
The programme is:
Changing how the company creates or captures value
Entering new markets or channels
Launching new products, services, or pricing models
Fundamentally redesigning how work gets done
Example: Shifting from one off product sales to subscription revenue, redesigning service delivery, incentives, and customer success so retention and lifetime value drive the P&L.
Technology enables new ways of selling, serving, pricing, or operating. Customers, suppliers, or partners will experience the difference. The P&L will move in ways that matter to investors. This is genuine transformation.
Digital Theatre
The programme is:
Called a transformation because it sounds impressive
Full of town halls, change campaigns, and glossy communications
Generating dashboards and decks that look sophisticated
Example: Rebranding an implementation programme as a “customer journey transformation”, while measures of success remain go live, training completion, and dashboard activity.
But underneath, the business operates almost exactly the same. The P&L does not move in a visible way. The main change is new software, new vocabulary, and a lot of activity that does not add up to value. Digital theatre often starts from good intent. But it raises expectations that the programme cannot meet.
Quick Diagnostic Checklists
You are likely in IT Modernisation if most of these are true:
The main driver is system age, support risk, or vendor sunset
Benefits are described as efficiency, standardisation, control, or compliance
Success is measured by go-live date, budget, and adoption rates
The benefits case mentions FTE savings but not new revenue or margin
Business users describe their work the same way as before, just “on the new system”
You are likely in Real Transformation if most of these are true:
There is a specific, measurable change in how the company will make or save money
The business case links directly to P&L drivers: revenue, margin, working capital, risk
Processes, roles, and decision rights will visibly change
Customers, suppliers, or partners will notice the difference
Senior business leaders own the programme, not just IT
You are likely in Digital Theatre if most of these are true:
Slides are full of vision language but vague on specific value changes
People talk about “journeys,” “ecosystems,” and “capabilities” but cannot draw a clear before-and-after for any process
Success means “go-live” rather than business impact at month 12, 24, or 36
Only a small share of the budget is allocated to changing how people work (process, roles, incentives, training, adoption), compared with technology delivery
Middle managers were not involved in design but are expected to “drive adoption”
The benefits case looks like an Excel wish list rather than a disciplined model
Why Programmes Get Mislabelled
If you have diagnosed your programme as IT modernisation or digital theatre, you might wonder: why does everyone keep calling it a transformation?
The answer is not stupidity or dishonesty. It is incentives.
“Transformation” gets budget approved.
A request for a $50 million “platform modernisation” faces tough questions. A request for a $50 million “digital transformation” that will “reimagine customer experience” and “future-proof the business” often sails through. The word itself unlocks funding.
“Transformation” accelerates careers.
Leading a transformation is a promotion-worthy achievement. Leading an IT upgrade is just doing your job. Senior leaders have strong incentives to frame their work as transformation, because that is what gets noticed.
External partners reinforce the narrative because it matches how the work was funded and sold.
Changing the label mid-stream creates governance and commercial friction, so most people avoid it. That does not mean the people involved are bad actors. It means the incentives point in one direction, and the easiest path is to keep the original story alive.
Many people see the gap, but few say it plainly in formal forums.
This is not a secret. Senior leaders understand the game. Consultants understand it. Programme team members understand it. The mislabelling is not a mistake – it is a feature of how large organisations work.
Understanding this does not make you cynical. It makes you realistic. And realism is what allows you to navigate well.
What to Expect Once You Know
Once you have diagnosed what you are really in, certain things become predictable. Here is what to expect from different players depending on the type of programme.
If You Are in IT Modernisation
Your boss may still use transformation language in public forums. That is fine – they need to. But in working sessions, the focus will be on delivery milestones, technical stability, and adoption metrics.
Colleagues will be pragmatic. They know this is an upgrade. Conversations will centre on configuration, testing, cutover, and training. Less vision, more execution.
External consultants will focus on implementation methodology and go-live readiness. The transformation narrative in the Statement of Work (SoW) may not match the day-to-day reality of delivery.
Steering committees will track RAG (Red-Amber-Green) status, timeline, and budget. Conversations about business value may be brief or formulaic.
Benefits reviews will focus on cost savings, efficiency metrics, and risk reduction. Expect modest outcomes that are hard to attribute cleanly to the programme.
If You Are in Real Transformation
Your boss will be under genuine pressure to deliver value, not just go-live. Expect hard conversations about outcomes, trade-offs, and business ownership.
Colleagues will include people from the business, not just IT and programme management. Cross-functional tension is normal. It means people care.
External consultants may push for scope that matches the transformation ambition. Watch for scope creep but also recognise that real transformation requires real investment.
Steering committees will ask about value realisation, not just go-live. Expect robust challenge on whether the business is actually changing.
Benefits reviews will be visible and consequential. Business owners will be named. There will be accountability for P&L impact, not just activity metrics.
If You Are in Digital Theatre
Your boss will maintain the transformation narrative in all forums. Challenging it publicly will not go well. The messaging is deliberate.
Colleagues will divide into true believers and quiet sceptics. The sceptics will find each other at coffee machines and in private conversations. You are not alone.
External consultants will validate the vision. Their fees depend on the programme continuing. Do not expect them to name the gap between narrative and reality.
Steering committees will focus on activity metrics, workshops delivered, systems deployed, people trained. Conversations about actual business impact will be brief or deferred.
Benefits reviews will be quietly rescheduled, redefined, or reframed. When they happen, expect explanations about “adoption curves” and “lagging indicators.” The hard numbers may never arrive.
How to Navigate Each Type of Programme
Whatever type of programme you are in, you can do good work, build your skills, and protect your reputation. The approach varies depending on what you are actually working on.
Navigating IT Modernisation
This is honest, valuable work. Your job is to deliver a stable platform that improves reliability, reduces risk, and creates a foundation for future change. Here is how to do it well.
Focus on what is actually measured. Go-live readiness, system stability, user adoption, issue resolution. These are the metrics that matter. Do not overinvest in transformation outcomes that are not in scope.
Be excellent at execution. Clean data migration, solid testing, smooth cutover, effective training. A well-delivered modernisation is career-building work. It demonstrates you can be trusted with complexity.
Manage stakeholder expectations quietly. You cannot contradict the transformation narrative. But you can steer conversations toward realistic outcomes: “After go-live, we will have a stable platform to build on. The real changes to how we work will come in subsequent phases.”
Document your contribution clearly. Keep a record of what you delivered, the quality of your work, and the problems you solved. When the programme ends, you want to be known for solid execution, regardless of what the initiative was called.
Build skills that transfer. Even if this is not transformation, you can develop expertise in system implementation, stakeholder management, cross-functional coordination, and delivery governance. These skills are valuable anywhere.
Navigating Real Transformation
This is rare and valuable experience. Real transformation programmes demand more from everyone but they also offer the most learning and the greatest career impact. Here is how to contribute at your best.
Connect your work to value outcomes. Understand how your workstream contributes to the P&L changes the programme is trying to achieve. If you cannot draw a line from your work to business value, ask until you can. This is how you make your contribution visible.
Build relationships with the business. Real transformation requires genuine partnership with people who own processes, customers, and revenue. Invest time with business stakeholders. Understand their incentives and constraints. This is where transformation succeeds or fails.
Embrace productive discomfort. Transformation is messy. Scope will change. Priorities will shift. Conflict between functions is normal, it means the change is real. Your job is to navigate ambiguity, not to eliminate it.
Challenge constructively. In real transformation, good ideas can come from anywhere. If you see a gap between what is being built and what the business needs, say so, but do it with data, options, and respect. Being the person who asks hard questions well is valuable.
Stay close to change adoption. Technology delivery is necessary but not sufficient. The real work is getting people to work differently. Volunteer for roles that put you close to users, training, and behaviour change. This is where transformation actually happens.
Think beyond go-live. Transformation benefits take months or years to materialise. Position yourself for roles in post-go-live optimisation and continuous improvement. This is where reputations are made.
Document the value story. Keep notes on business outcomes, not just deliverables. When benefits start to land, you want to be able to articulate your contribution. “I helped deliver the platform that enabled a 15% reduction in customer churn” is more powerful than “I was on the technology workstream.”
Navigating Digital Theatre
This is the most politically delicate situation. The gap between narrative and reality is wide. Your job is to do good work, protect yourself, and avoid becoming collateral damage when expectations are not met. Here is how:
Accept what you cannot change. You will not relabel this programme. Your boss needs it to be called a transformation. Fighting that battle is career-limiting and unwinnable. Focus on what you can control.
Do good work within realistic scope. Even if the programme is mislabelled, there is usually real work to be done. System implementation, process improvement, data cleanup – these are valuable. Do them well. Your execution quality is within your control.
Ask clarifying questions diplomatically. You cannot say “this is not a transformation.” But you can ask questions that surface the truth without confrontation:
“Help me understand how this will change how we make money, I want to focus my effort on the right outcomes.”
“What will be different about how we work after go-live? I want to prepare stakeholders.”
“Who owns the benefits after go-live? I want to make sure I am aligned with them now.”
These questions position you as diligent and aligned, not as cynical or obstructive.
Document carefully. Keep your own record of what was in scope, what you delivered, and what assumptions were made about benefits. Not to blame anyone but so you can speak precisely about your contribution when asked. When benefits do not arrive, you want a clear record that you delivered what was funded.
Find the other realists. You are not the only one who sees the gap. Find colleagues who share your perception. You do not need to say it loudly. But working alongside people who see clearly is better for your sanity and your work.
Manage your energy. Stop trying to transform things you were never funded to transform. Do not overinvest emotionally in outcomes that were never realistic. Do good work. Protect your wellbeing. That is enough.
Build transferable experience. Even in theatre, you can develop skills: stakeholder management, navigating ambiguity, delivery under pressure, political awareness. These are valuable. Use this programme to sharpen them, even if the programme itself does not deliver what it promised.
Questions You Can Use
Here are questions you can ask in steering committees, design workshops, or one-on-ones. They surface the truth without putting you at risk.
“How exactly will this change how we make or save money?”
Tests whether the team can connect scope to P&L. In real transformation, this answer is crisp. In theatre, it is vague.
“What would stay the same about how we run the business, even if this programme succeeds?”
Tests whether you are doing an upgrade or a redesign. If almost everything stays the same, it is probably not transformation.
“If we removed all the technology language, how would we describe this change in plain business terms?”
Tests whether this is a technology story or a business story. Transformation should be explainable without mentioning systems.
“Who in the business owns the benefits after go-live, by name?”
Tests whether value accountability exists. In real transformation, business owners are named. In theatre, it is unclear or deferred.
“How much of the budget is for changing how people work, not just implementing technology?”
Tests investment in behaviour change. If less than about 15% of the budget is aimed at changing how people work (process, roles, incentives, training, adoption), it is probably delivery dressed as transformation.
The Coffee Machine Conversation
Sometimes you want to acknowledge reality with a peer without sounding like the bitter cynic. Here is language that works:
“You know, I think what we are doing is important, the platform upgrade is valuable work. I just wonder if calling it a ‘transformation’ sets expectations we cannot meet. But that is probably above my pay grade.”
This names the gap while respecting the reality that you cannot change it. It signals that you see clearly, without positioning you as the problem.
The Quiet Clarity
You probably cannot change what your programme is called. You probably should not try.
But you can stop doubting your own perception. You can adjust your expectations. You can do good work without overinvesting in outcomes that were never realistic.
If you are in a real transformation, you now know what that demands, and what it offers. Engage fully. This is where careers are built.
If you are in IT modernisation, you know what success looks like. Deliver it well. Solid execution is valuable.
If you are in digital theatre, you know the game. Protect yourself. Do good work anyway. Find the others who see it clearly.
And the next time someone asks you about “the transformation,” you will know exactly what you are really working on, even if you never say it out loud.