Digital transformation rarely fails because a business picked the wrong software. It fails because nobody agreed on the problem, the offer was messy before it went online, the team was never brought along, and broken processes were automated so they could break faster. The technology is usually the last thing to go wrong, and the easiest to fix.
We learned this the hard way. Before starting Simple Scalable Solutions, our founders helped grow a travel tech startup tenfold in five years, then watched it implode two years after they left. That experience is why SSS exists, and it is where our 4 P's come from: Purpose, Product, People and Process. This post explains why transformation projects stall, and gives you a 4 P's self-check you can run before you sign for any new system.
Key Takeaways
- In BCG's 2020 study, only 30% of digital transformations met their targets and produced lasting change. Five of the six success factors BCG identified are about strategy, leadership, talent, governance and measurement; only one is about technology.
- Treat technology as the last decision. Settle Purpose, Product, People and Process first, then choose the tool that fits.
- Your team decides whether change sticks. Involve the people who do the work before you choose anything, not after go-live.
- Simplify a process before you automate it. Automating a messy process only produces mess faster.
- The self-check at the end fits in one short meeting. Two red flags in the same P means fix that P before you buy anything.
The real reasons transformation projects stall
Most transformation projects stall for human and strategic reasons, and the research on large companies points the same way.
In its 2020 report Flipping the Odds of Digital Transformation Success, Boston Consulting Group combined a survey of 825 senior executives with its own work on 70 company transformations. Only 30% of transformations met or exceeded their target value and produced sustainable change. Another 44% created some value but missed their targets, and 26% delivered less than half of what they set out to achieve. A 2018 McKinsey survey, Unlocking success in digital transformations, was even more sobering: just 16% of respondents said their transformation had improved performance and set the organisation up to sustain those gains.
The causes matter more than the headline number. BCG found six factors that moved the odds of success from 30% to 80%: an integrated strategy with clear goals, leadership commitment from the CEO through middle management, high-calibre talent, an agile governance mindset, effective monitoring of progress, and a business-led technology and data platform. Only the last of those six is about technology, and even that one is "business-led".
A word of caution: you will often read that "70% of change programmes fail" as settled fact. When Mark Hughes traced that claim through five well-known sources for a 2011 paper in the Journal of Change Management, he found no valid and reliable empirical evidence behind it. So don't lean on any single figure. The pattern across the better studies is what counts: success is the minority outcome, and the reasons are mostly about people and direction.
In small and mid-sized businesses, the stall usually looks like one of these:
- The tool came first. Someone saw a demo, the subscription started, and only then did anyone ask what problem it should solve.
- The team quietly worked around it. The new CRM exists, but real customer conversations still happen in chat apps and a shared spreadsheet.
- The owner stayed the bottleneck. Every approval and exception still goes through one person, so the system just adds another place to check.
- A broken process went digital. The quote that needed three sign-offs on paper now needs three sign-offs in software, plus a login.
None of these is a software problem. Each one maps to a P.
Technology is the last decision, not the first
The order of decisions decides the outcome. Choose the tool first and it quietly makes the other decisions for you: how you sell, who does what, which steps your process has. Settle the 4 P's first and the tool has a clear job you can judge every option against.
| Starting with the tool | Starting with the 4 P's | |
|---|---|---|
| First question | "Which system should we buy?" | "What problem are we solving, and how will we know?" |
| Who is involved | Owner and a vendor | Owner, managers and the people who do the work |
| What gets digitised | Today's habits, good and bad | A simplified, agreed way of working |
| Typical result | Low use, workarounds, a second project to "fix" the first | A system the team actually uses, measured against a clear goal |
Picture a 25-person distributor in Bangkok. A competitor mentions their new CRM, so the owner buys one. Six months later the sales team still keeps leads in their phones and the pipeline report is empty. The software works perfectly. Nobody decided what it was for, what counts as a "lead", or why a salesperson would bother updating it.
Purpose: start with the problem, not the tool
Purpose means you can state, in one sentence, what is wrong and how you will know it is fixed. If you can't, you are not ready to choose software.
A useful format is: "We are losing [what], because [why], and we will know it's fixed when [measure]."
- Weak: "We need to digitise our sales."
- Strong: "We lose roughly one in five enquiries because nobody replies within a day, and we will know it's fixed when every enquiry gets a reply within two working hours."
The strong version tells you what to look for in a tool (fast routing and reminders), what to measure after launch, and gives your team a reason they can repeat. People support changes they can explain to a colleague.
Three questions to settle Purpose:
- What business result will be different in six months, and by how much?
- What happens if we do nothing?
- Who owns this outcome, by name?
Product: fix the offer before you digitise it
Product means your offer is clear enough to put into a system. If every deal is custom, prices depend on who you ask, and nobody can list your packages in a minute, software will simply record the confusion.
Consider a small marketing agency where each account manager quotes differently. When the agency tries to build a sales pipeline, it cannot agree on the stages, because every sale follows a different path. The CRM is not the problem. The offer is.
Before you digitise, do three things:
- List what you sell in plain language, with standard prices or price ranges.
- Retire or bundle the variations that cause most exceptions. Fewer, clearer options are easier to sell and far easier to automate.
- Write the customer journey from first contact to repeat purchase. That journey becomes your pipeline, your onboarding and your follow-up sequence later on.
People: your team decides whether change sticks
People is the P that most projects underinvest in, and the one that decides whether you get any return at all. A system only works if people use it the way it was designed, every day, including on busy days.
BCG's research names a common blocker: the "frozen middle". Without real involvement, middle managers "often become sources of resistance, defending functional siloes and power bases." In a small business that might be one experienced supervisor whose informal way of working holds the operation together. If the new system ignores what they know, they will route around it, and the team will follow.
In Thailand and much of Southeast Asia there is an extra layer. Kreng jai, the instinct not to burden or contradict others, especially seniors, means staff may nod through a rollout meeting while privately expecting it to fail. Silence is not agreement. You have to create safe ways for people to say "this won't work for my job".
What a people-first approach looks like in practice:
- Involve the people who do the work before you choose anything. Sit with them. Ask what slows them down and what they would hate to lose.
- Answer "what's in it for me?" for each role. "Management wants better reports" persuades nobody on the front line. "You'll stop retyping orders twice" does.
- Name a champion in each team: someone respected, not necessarily senior, who tests early and helps colleagues.
- Train on real tasks, in the language people work in, close to launch, and again a few weeks later.
- Plan for the dip. Expect a few slower weeks while people learn the new way. Say so in advance so nobody panics and reverts to the old spreadsheet.
- Stay after go-live. Adoption is won in the first months of real use, not on launch day.
This is the centre of how we work: understanding your teams' needs and frustrations, then building the change with them rather than handing it to them. It runs through all our digital transformation and change management services.
Process: simplify first, then automate
Process means the way work flows is understood, agreed and as simple as possible before you automate it. Automation multiplies whatever it is given: a clean process gets faster; a messy one produces errors at speed.
One executive quoted in the BCG study put it well: deploying new IT architecture "without addressing product and process complexity would have minimal business impact, so we focused on radical simplification and then enabled this with new IT platforms."
A simple way to start:
- Map today's process on one page, with the people who run it. Use sticky notes or a whiteboard, not software.
- Mark every hand-off, wait and double entry. These are where time and mistakes hide.
- Remove before you automate. Ask of each step: what breaks if we stop doing this? Often the honest answer is "nothing".
- Write down the new version as a short checklist anyone can follow.
- Only then automate the steps that are repetitive, rule-based and frequent.
Rule of thumb: if your team can't agree a one-page drawing of the process, it isn't ready to automate.
A 4 P's self-check before your next tech project
Run this with two or three people who see the business from different angles, including someone from the front line. Mark each question honestly as a green light or a red flag.
| P | Question | Green light | Red flag |
|---|---|---|---|
| Purpose | Can we state the problem and the measure of success in one sentence? | Yes, and everyone gives the same sentence | Different people give different answers |
| Purpose | Is one named person accountable for the outcome? | Yes, with time to do it | "The vendor will handle it" |
| Product | Can we list what we sell, with standard prices, in a minute? | Yes | "It depends on the client" for most deals |
| Product | Is our customer journey written down? | Yes, first contact to repeat purchase | It lives in people's heads |
| People | Have the people who will use the system helped define what it needs to do? | Yes, before any demo | They will see it at training |
| People | Does each role know what is in it for them? | Yes, in their own words | Only management benefits are clear |
| Process | Is the current process mapped and agreed? | Yes, on one page | Nobody could draw it the same way twice |
| Process | Have we removed unnecessary steps? | Yes, the process is simpler than last year | We plan to automate it as it is |
How to read it:
- No red flags, or one: you are in good shape to start comparing tools. Use your Purpose sentence as the first test for every option.
- Two red flags in the same P: fix that P first. That is internal work, and it costs far less than a failed rollout.
- Red flags in three or four P's: pause the purchase. Buying now would digitise the confusion.
When you do reach the tool decision, judge each option by how well it serves the answers above, not by its feature list. In some cases that will be an off-the-shelf system; in others, a joined-up platform such as Scalify or one of our other solutions; occasionally, something custom. The 4 P's tell you which.
Already mid-project and struggling? Run the same check against the project as it stands. Red flags usually point to something you can fix without starting again, such as re-involving the team or simplifying one process.
Start with the problem, not the purchase
Digital transformation works when technology is the final step in a sequence: a clear Purpose, a Product that is ready to be digitised, People who helped shape the change, and a Process simple enough to automate. Get those right, and choosing the tool becomes the easy part.
If you ran the self-check and the red flags surprised you, or you would simply like a second opinion before your next project, talk your 4 P's through with one of our consultants. We will look at where you are, what is holding you back, and what to fix first, before anyone mentions software.