A digital transformation project can be technically successful and still be a commercial failure.
The new platform launches. The migration completes. The integrations work. Performance improves. The infrastructure is modernised.
Yet twelve months later, revenue has barely moved, customers are not behaving differently, employees have created workarounds and the board is wondering why the expected return on investment never appeared.
This is one of the recurring problems with large technology projects: organisations become so focused on delivering the technology that they lose sight of the reason they commissioned it.
Digital transformation is ultimately a business project delivered partly through technology.
That means the people responsible for customers, revenue, operations and commercial performance need to be involved from the beginning – not invited into the room shortly before launch.
Technical success is not the same as business success
Technology teams naturally measure the things they can control.
Was the platform delivered?
Did the migration work?
Are the APIs functioning?
Is the system secure?
Has performance improved?
Are uptime targets being achieved?
All of these things matter.
But none necessarily tells the board whether the investment was worthwhile.
A technically excellent ecommerce replatform might still reduce conversion.
A sophisticated CRM implementation might still be disliked by the sales team.
A new customer portal might work perfectly while making it harder for customers to complete the task they actually came to perform.
A data platform might contain extraordinary quantities of information without answering a single commercially useful question.
The technology can work exactly as specified while the project itself fails.
That distinction should shape how transformation projects are planned.
Start with the commercial objective
Before discussing architecture, platforms or vendors, there should be a much simpler conversation.
What is the business trying to achieve?
Perhaps the organisation wants to increase conversion.
Maybe it needs to reduce the cost of serving customers.
It could need to launch products faster, enter new markets, consolidate several legacy systems, improve customer retention or remove operational bottlenecks that are limiting growth.
Those objectives should determine the technology strategy rather than the other way around.
Consider two businesses replacing an ecommerce platform.
One wants to improve conversion and average order value.
The other wants to expand a catalogue from 100,000 products to three million products across several international markets.
Both might describe the project as an “ecommerce replatform”.
Technically, however, they are solving very different business problems.
The commercial objective determines what success actually looks like.
Commercial people ask different questions
A good technical team might ask:
Can the system scale?
How should the data model work?
Which APIs are required?
How should authentication be handled?
What are the infrastructure requirements?
Commercial people tend to ask different questions.
Will customers buy more?
Can the sales team actually use it?
Can we launch into another market?
How quickly can a new supplier be onboarded?
Does this remove operational cost?
What happens to conversion?
How does this affect margin?
Can marketing change something without waiting three weeks for development?
Neither set of questions is more important.
A successful transformation programme needs both.
The problems arise when one perspective dominates the project.
Bring commercial stakeholders in before requirements are written
One of the most expensive mistakes in transformation is discovering business requirements after development has already started.
By that stage, architecture may have been selected, budgets allocated and timelines agreed.
Changing direction becomes increasingly expensive.
Commercial involvement therefore needs to happen during discovery.
Sales teams understand where prospects disappear from the process.
Customer service teams know which problems customers repeatedly encounter.
Marketing understands where technology prevents campaigns or experimentation.
Finance understands where margin disappears.
Operations knows which apparently simple processes require enormous amounts of manual work.
Senior management understands where the organisation intends to be in three or five years.
Those perspectives can reveal requirements that are almost impossible to discover by examining the existing technology alone.
Do not simply rebuild the existing business
Transformation projects often begin by documenting the current system.
That is sensible.
The danger is turning that exercise into a specification for recreating everything that already exists.
A business may have spent ten years developing processes around the limitations of its existing technology.
Employees export spreadsheets because two systems cannot communicate.
Customer service performs manual checks because the platform cannot automate them.
Marketing requires developers to make basic changes because the CMS is restrictive.
Operations maintains complicated workflows because the underlying data model is poor.
If those processes simply become requirements for the replacement system, the organisation risks spending millions recreating its historical problems on newer technology.
Transformation should include asking:
Why do we do this?
Does it still need to happen?
Could it be simpler?
Could it be automated?
Would we design the process this way if we were starting today?
Commercial and operational stakeholders are essential to answering those questions.
Project management is more than keeping the project on schedule
Large digital projects require strong project management, but project management should not be reduced to deadlines, tickets and status meetings.
Someone needs to maintain the connection between technical delivery and commercial intent.
That becomes increasingly difficult as projects grow.
A board might approve a programme designed to improve customer acquisition and reduce operational costs.
Six months later, teams may be discussing individual integrations, database migrations and sprint priorities.
Each decision might be entirely reasonable in isolation.
But somebody needs to keep asking whether the overall programme is still moving towards the outcome the business originally wanted.
Scope decisions should have commercial context.
If a feature is delayed, what is the revenue implication?
If an integration costs twice as much as expected, what value does it create?
If a requirement adds three months to delivery, is the business benefit sufficient?
Good project management creates a mechanism for making those decisions rather than simply documenting them.
Give projects measurable commercial outcomes
“Digital transformation” is too vague to measure.
“Modernising our technology stack” is not much better.
Projects need outcomes that the organisation can evaluate.
Depending on the programme, those might include:
- increasing online conversion
- reducing customer acquisition costs
- increasing average order value
- reducing manual processing time
- shortening customer onboarding
- increasing catalogue capacity
- improving product availability
- reducing support enquiries
- accelerating entry into new markets
- improving customer retention
- reducing infrastructure or licensing costs
- shortening the time required to launch new products or services.
Not every benefit needs to be expressed directly as revenue.
But somebody should be able to explain how the investment improves the economics or strategic capabilities of the business.
Establish the baseline before changing anything
There is another surprisingly common problem.
Businesses complete transformation projects and then discover they cannot prove whether anything improved.
The old system has gone.
The new system is operating.
But nobody recorded the baseline.
If the objective is to improve conversion, establish current conversion rates.
If the goal is to reduce processing time, measure how long the process takes today.
If customer service costs should fall, understand the existing cost per interaction.
If automation should save employee time, measure the manual workload before implementation.
Otherwise, transformation becomes dependent on subjective assessments.
“It feels faster” is not a return-on-investment calculation.
Finance belongs in the conversation too
Transformation programmes frequently focus on the cost of building something while giving less attention to the economics of operating it.
The purchase price of technology is only one component.
There may also be implementation costs, cloud infrastructure, licences, integrations, maintenance, internal staffing, external support, transaction fees and future development requirements.
Conversely, new technology may remove existing costs.
It could eliminate licences, reduce infrastructure requirements, automate administrative work or allow several systems to be consolidated.
Commercial evaluation therefore needs to consider total cost of ownership.
A cheaper platform can become extremely expensive if every change requires specialist development.
A more expensive architecture may produce better economics if it allows the organisation to grow substantially without equivalent increases in operational headcount.
The question is not simply:
How much does it cost?
It is:
What does the business get for that cost over the useful life of the investment?
Transformation creates trade-offs
There is rarely a perfect architecture.
Businesses make trade-offs between cost, flexibility, speed, complexity and future capability.
A technically elegant solution may take two years to deliver.
A commercially pragmatic alternative might provide 80% of the capability within six months.
Sometimes waiting is worthwhile.
Sometimes those additional eighteen months represent lost revenue, delayed savings and opportunities handed to competitors.
Technical decisions therefore need commercial context.
Engineering teams should explain the consequences of shortcuts and technical debt.
Commercial teams should explain the value of speed and opportunity.
Leadership can then make an informed decision.
That is much healthier than either side making assumptions about what the other needs.
The people using the system need a voice
Transformation can also fail because organisations underestimate adoption.
A CRM platform does not create value simply because it has been deployed.
Employees need to use it.
A new internal workflow may be technically superior but still fail if employees find it unnecessarily complicated.
A sophisticated analytics platform is worthless if managers continue making decisions from spreadsheets because they do not trust it.
Users therefore need to participate throughout the programme.
That does not mean every employee should design the system.
It means the project should understand how people actually work, test assumptions with real users and identify where adoption could become difficult.
The best system is not necessarily the one with the most features.
It is the one that improves how the organisation operates.
Avoid the big-bang mentality where possible
Large transformation programmes sometimes attempt to change everything simultaneously.
New platform.
New CRM.
New data architecture.
New processes.
New integrations.
New customer experience.
New reporting.
This creates enormous dependency between workstreams and makes commercial value dependent on the entire programme succeeding.
Where possible, transformation should be structured so that useful capabilities can be delivered incrementally.
That allows businesses to test assumptions, measure results and change direction before every decision becomes expensive.
It can also allow investment to start producing returns earlier.
The organisation learns while the programme progresses rather than discovering at the end whether its original assumptions were correct.
Governance needs business representation
Transformation programmes require governance, particularly when budgets and operational consequences are significant.
But governance should not become a room full of technologists reporting technical progress to one another.
Commercial leadership should have meaningful representation.
A strong steering group might include technology, operations, finance, product, sales or marketing depending on the nature of the programme.
That creates a forum where decisions can be evaluated from several perspectives.
Technology can explain feasibility and risk.
Operations can explain practical consequences.
Finance can challenge economics.
Commercial teams can defend customer and revenue requirements.
Senior leadership can ensure the programme remains aligned with wider strategy.
That tension is useful.
It prevents transformation becoming disconnected from the organisation it is supposed to transform.
Ask the difficult question throughout the project
There is one question worth repeatedly asking during any major digital programme:
What business result does this produce?
Not every technical task will have an obvious direct financial return.
Databases still need migrating.
Security still needs implementing.
Infrastructure still needs maintaining.
Technical debt sometimes needs addressing simply because leaving it creates unacceptable risk.
But at programme level, there should always be a clear answer.
If nobody can explain what commercially improves when the project succeeds, the organisation should reconsider why it is spending the money.
Technology should enable the business strategy
The strongest transformation programmes do not begin with a fashionable technology.
They begin with a business that knows what it wants to become.
Technology then enables that change.
Perhaps the business wants to operate internationally.
Perhaps it wants to handle millions of products.
Perhaps it needs to automate processes that currently require hundreds of employee hours.
Perhaps customers expect a fundamentally better digital experience.
Perhaps legacy systems are preventing the organisation from moving quickly enough.
Those are business problems.
Architecture, software, data and AI are tools for solving them.
Silicon Dales: engineering around commercial outcomes
At Silicon Dales, complex technology projects are approached as business transformation rather than isolated development exercises.
That means understanding the commercial objective alongside the technical challenge: how customers behave, where operational costs occur, what teams need from the system, how data moves through the organisation and what the business needs the technology to support in future.
That can involve replatforming complex digital estates, integrating existing systems, automating business processes, building data infrastructure, handling large ecommerce catalogues or introducing AI where it can produce measurable operational value.
Technical capability matters enormously.
But technical delivery is only part of a successful transformation.
The most valuable technology project is not necessarily the one with the most sophisticated architecture.
It is the one that leaves the business in a demonstrably better position than it was before.