The 11 Things Killing Your Transformation Project
Ingrained silent resistance, or the biggest risk that nobody wants to talks about or executive ego trip which are secretly undermining your whole programme.
Transformation projects are notoriously difficult, with failure rates often cited as high as 70%. The challenges are rarely technical; they are human, political, and systemic. Below are the 11 most common, and often unspoken, reasons these projects collapse. Along with fixes that will work.
1. Silent Resistance
The Problem:
Right from the start people aren't arguing with you in meetings; they're just nodding. They've seen the 'next great thing' fail multiple times before. They are annoyed, tired, and plan to keep their heads down and get on with the day job, and get paid regardless.
The Fix:
- Go Underground: Don't rely on formal meetings. Schedule 1:1, non-project "coffee chats" with mid-level managers and high-performing individual contributors. The goal is to listen, make them feel heard and not sell. Find out where they are.
- Acknowledge the Past: Explicitly state: "We know a number of projects failed and that was painful, and you bore the brunt of that. But we are trying to do it differently this time." Acknowledge the problems and challenges and never gloss over past failures.
- Quick Wins for Them: Identify small, tangible pains in their day-to-day work (BAU) and fix them first using the new project/process. Give them a reason to believe.
2. The "Part-Time" Fantasy
The Problem:
You've been allocated '50%' of the best subject matter experts. In reality, their daily operational fires (BAU) will always take priority. You don't have a project team; you have a list of people who are too busy to help you.
The Fix:
- Buy Out Time: The project budget must pay for backfill staff to cover the SMEs' BAU. If you need 50% of an SME, budget for a 50% temporary hire to do their old job.
- Full-Time Commitment: For critical, short-term phases (e.g., requirements gathering, UAT), demand 100% allocation. Present this as a non-negotiable contract to the SME's line manager.
- Incentivize Line Managers: Tie the line manager's performance bonus to the quality and timeliness of the project deliverables from their team members.
3. The Hidden Risk
The Problem:
The elephant in the room that everyone whispers about in the corridors isn't even on your risk register. It's unmanaged because it's too politically dangerous to write it down. For example; that everybody knows the CIO, CFO, and CEO are completely misaligned. Head of IT just doesn't want to do it.
The Fix:
- The quiet conversations: Give people the opportunity to express "uncomfortable truths" in private before working out a strategy to address it. Do not just sweep the problem under the carpet, as 'hoping it will sort itself out' is not a plan!
- The Alignment Workshop: Force a single, closed-door workshop with those principle stakeholders who aren't on the same page. Together develop a single, agreed-upon '1 page-North Star' statement and a 'Go/No-Go' success metric. Do not leave the room until the statement is signed off by all parties.
- Don't get a 'Yes', get a 'that's right': Individually check that you're not just getting "Yes" because they felt pressured into it and they are sick of the conversation. It should be a "that's right, we agree, this is what we are going to do".
4. Process Ignorance
The Problem:
You don't know what your processes actually are, or who really owns them. You are transforming a theoretical model of the business, not the reality. Then you bring in consultants that further muddy the waters by layering in what they think is best practice, ignoring what's really happening.
The Fix:
- "Gemba" Walks: Adopt the Japanese concept of going to the "actual place" where work is done. Spend a day watching three different people perform the same process, documenting the variations (the 'shadow' process).
- Process Ownership Contracts: Before transformation begins, create a simple charter defining the actual process owners and the process SMEs (specific names, not a job title). People are uncomfortable owning a very large process. You need to split it down into sizeable chunks where people are actually working. Being the global process owner from Opportunity to all the way to Cash isn't realistic, all you will get is a Process Owner who will just focus on the things they are comfortable with.
- Consultant Control: Mandate that consultants must map existing "As-Is" processes before introducing any "To-Be" best practice. Budget 30% of the initial phase for this discovery work.
5. Incomplete Requirements
The Problem:
Your requirements are full of holes because of Points 1 and 2. The silent resistors didn't tell you the nuance, and the hidden risk means you're building for a scenario that doesn't exist.
The Fix:
- Negative Requirements: Ask "What must not happen?" or "What parts of the old system must be kept?" This unlocks the tribal knowledge held by resistors, as they focus on loss aversion rather than new possibilities.
- User Story Mapping (USM): Use USM workshops with a diverse group of end-users. Focus on the actual user journey, not abstract features. If you can't map a feature to a specific user goal, it's out of scope.
6. The Executive Ego Trip (The Pet Project)
The Problem:
This is somebody's vanity project. The rest of the business doesn't see why it's necessary. Even worse, the sponsor who launched it with fireworks has already mentally moved on to the next shiny object, leaving you with no air cover to force difficult decisions.
The Fix:
- Transfer of Ownership: Immediately assign Business Owners who are not the executive sponsor. These people must be senior managers whose day-to-day work depends on the project's long-term adoption, not just the launch date.
- Value Realization Office (VRO): Establish a small VRO reporting directly to the COO/CFO. This team focuses solely on tracking quantifiable benefits and ROI (Return on Investment) for the project, turning it from a 'pet project' into a 'profit center.'
7. Training by Osmosis
The Problem:
The plan assumes that if the user interface is 'intuitive' enough, nobody needs training. You think a 40-minute webinar the day before go-live counts as 'Change Management.' Not only does this mean people don't know how to use the new process and system, it means they definitely haven't tested it before go-live either.
The Fix:
- Role-Specific Training: Abandon generic training. Training must be task and role-specific. An invoice approver only trains on invoice approval, not the whole system. But they get an overview of the process steps before and after so they know their part in the machine.
- Micro-Learning: Develop three-minute, high-definition instructional videos hosted on an internal platform. Then back it up with hands on examples to work through. Focus on specific, high-frequency tasks. Ask users to really try to stress and break the system.
- Post-Launch Hypercare: Fund a dedicated, visible, on-the-floor support team for the first four weeks post-go-live. This support should be in the user's workspace, not on a remote helpline.
8. Shadow IT
The Problem:
You think the ERP runs the business? No. It's Dave in Accounts and his macro-laden Excel sheet from 2008. If your transformation breaks Dave's spreadsheet, the company stops.
The Fix:
- Discovery First: Before selecting a tool, run a full discovery of all critical, non-standard system interfaces. Specifically hunt for all high-risk spreadsheets, access databases, and local applications.
- Retirement Plan: For every Shadow IT element discovered, create a formal "Retirement or Integration Plan." If Dave's spreadsheet is critical, treat it as a formal requirement to either fully integrate its function or build a dedicated replacement.
- Empower "Dave": Bring "Dave" onto the core project team, make him a Subject Matter Expert (SME), and pay him a bonus for helping decommission his own shadow system.
9. The Silver Bullet Delusion
The Problem:
Leadership believes buying the tool is the transformation. They signed the contract and popped the champagne, confusing purchasing software with changing human behavior. They think that if they just make IT easier to use, it'll fix their underlying cultural problems.
The Fix:
- The 70/30 Rule: Reframe the transformation budget. State explicitly that this is a Business transformation, not an IT transformation. Allocate a budget and a team for change management, process redesign, training, data migration, and implementation.
- Outcomes over Features: Shift executive reporting from "We installed the module" to "We reduced invoice processing time by 40%." Focus entirely on quantifiable business outcomes.
10. "Agile" Chaos on a Rotten Foundation
The Problem:
Nobody fixed the technical debt from the last project, so you are building an ivory tower on sand. To hide this, the team uses 'Agile' as an alibi for having no plan, no documentation, and moving goalposts, not taking time to test, just throwing out minimum viable product. It's not iteration; it's unplanned chaos on legacy systems.
The Fix:
- The Debt Surcharge: Dedicate 20% of all initial sprints/phases to technical debt clearance (e.g., Automations and APIs that actually reduce the data double handling, data cleanup, dependency mapping). Ring-fence this budget and treat it as a mandatory investment.
- Documentation Minimum: Require a 'Definition of Done' that includes lightweight architecture document and user training notes for every major feature delivered.
- "Wagile" Hybrid: For enterprise transformation, adopt a "Wagile" (Waterfall up front, Agile for delivery) model. Lock down the high-level scope, architecture, and interfaces (Waterfall) and then execute the build and iteration (Agile).
11. The Enormity of the Problem
The Problem:
It's just too big. You are replacing the entire suite of systems, touching everything and everyone in the business. Nobody can get their heads round it. Stakeholders glaze over in workshops because the scale is just paralyzing.
The Fix:
- Micro-Launches: Deconstruct the project into three to five independent, sequential mini-projects, each with its own Go/No-Go decision and defined business value.
- The Pilot Program: Run a complete, end-to-end launch on a small, contained area of the business (e.g., a single region, a single product line, or a non-critical department). Prove the model works before scaling.
- Phased Rollout Schedule: Break the implementation into defined phases with clear dates, as outlined in a schedule.