Leadership & Management
Are you leading a transformation or managing an installation?
An ERP implementation is a profound business transformation, yet a staggering 75% fail to meet their objectives. The reason? A critical confusion between Leadership and Management.
Leadership provides the vision and the organizational will—the “Why.” Management provides the execution and the discipline—the “How.” You must master both.
If you are meticulously managing execution without strategic leadership, you aren’t just inefficient; you’re efficiently heading toward the wrong destination.
Getting the right things right
There is a symbiotic relationship between leadership and management. They are different things, but one doesn’t work without the other.
Leadership owns “Vision to Value” This involves establishing a clear strategic Vision, ensuring Alignment with business objectives, securing an active Sponsor, and guaranteeing measurable Value. A break in this chain collapses the entire strategic foundation. Leadership ensures you are doing the right things.
Management owns Control—the disciplined orchestration of scope, schedule, and budget. Management translates vision into a realistic plan, proactively mitigates risks, and controls execution with precision. Management ensures you are doing things right.
Success demands this seamless partnership: inspiring leadership sets the course management ensures the journey is completed.
Navigating the Intersection of Leadership and Management
Recognizing ERP Implementations as a Wicked Problem
Why ERP Projects are Not "Just Like Building a House”
Because building a house is a tame problem, and ERP projects are wicked problems.
In 1973, design theorists Horst Rittel and Melvin Webber coined the term “Wicked Problem” to differentiate a category of problems that were fundamentally different than “Tame Problems”. Their motivation was the failure of traditional problem solving as they were being applied to public policy in the 1960s and 70s. Wicked problems cannot be solved with the same methods as tame problems,
Tame Problems
Wicked Problems
Five Tame Problem Characteristics:
- Clearly Defined Problem
- Solved With a Linear, Rational Process
- Have an Ending
- Is Successful or Not
- You Get More than One Chance to Solve
Ten Wicked Problem Characteristics:
- No Full Understanding of the Problem
- No Definite End
- Evaluation is Relative
- No Immediate Test
- You Have One Shot
- No Single, Well Defined Solution
- The Problem is Unique
- Problems are Symptoms of Other Problems
- The Way the Problem is Expressed Shapes the Solution
- The Planner Cannot be Wrong
ERP implementations are wicked problems. Not convinced? Open the accordion for more detail.
ERP As a Wicked Problem
No Full Understanding of the Problem The problem isn’t fully understood until the solution is developed. | A project might begin with a stated goal like “replace our legacy system,” but as discovery workshops progress, the goals are expanded to address siloed customer data, a lack of business intelligence, or poor inventory management. The full scope and nature of the problem are only understood through the act of trying to solve it. |
No Definitive End | Go-Live is the End of the Beginning The project continues indefinitely through phases of hypercare, user adoption, process optimization, data cleanup, system upgrades, and continuous improvement. |
Solution Evaluation is Relative There are no ‘correct’ answers. Solutions are relatively good or bad. | Your solution may be ‘good’, an improvement over ‘bad’, but there may have been a ‘better’ solution. Also, success is subjective and varies by stakeholder. The CFO might see it as a “good” solution, an invoicing manager might see it as a “bad” solution because the new system takes more time than the legacy system did. |
No Immediate Test of the Solution The consequences of the solution play out over time. | You can’t immediately test the true impact of an ERP. Many organizations experience a dip in productivity after go-live as users struggle with the new system. The real benefits, like improved decision-making or increased efficiency, may not be measurable for months or even years. The long-term consequences are impossible to fully predict. |
You Have One Shot You cannot easily undo your actions and try again. | ERP systems are an enormous investment of time and money, and it fundamentally changes how people do their jobs. You cannot easily “undo” a go-live. |
No Single, Well Defined Solution | You can choose between dozens of systems and then choose one from hundreds of implementation partners. For all practical purposes, the software can be integrated with other systems, configured and customized in an infinite number of ways to suit your goals and business. |
Problem is Unique Problems may be similar to other problems, but wicked problems have unique aspects that require a fresh approach | ERP implementations share common patterns, but every single one is unique. A company’s specific data, political landscape, culture, competitive pressures, and existing processes are unique. An approach that worked well for one company may be spectacular failure at another because of these unique, deeply human factors. |
Wicked Problems are Symptoms of Other Problems For example, crime is a symptom of poverty. | The need for a new ERP is often a symptom of a deeper issue. The “problem” might not be the old software, but rather a lack of disciplined processes, a culture resistant to change, poor data governance, or the history technology investment. |
The Choice of Explanation Determines the Nature of the Solution The framing you choose puts boundaries around the solution set. | Depending on how deeper issues are understood, it may not be an ERP solution at all. If it is, how the ERP project is framed determines the approach. If it is framed as an “IT project,” the CIO will lead, the budget will be for technology, and the focus will be technical. If you explain it as a “business transformation project,” the COO or CEO will lead, the budget will be larger to account for change management, and the focus will be on people and processes. |
The Planner Cannot Be Wrong Planners are held accountable for their actions | The stakes for the project sponsors and managers are incredibly high. An ERP project leader whose implementation fails can cause millions of dollars in losses, cripple business operations, and face severe career repercussions. The pressure to get it “right” is immense. |
You can’t solve a wicked problem, but you can manage it.
Most ERP methodologies are designed for ‘tame’ problems. They have a linear path to success. Agile processes would be perfect candidate for ERP. Unfortunately, the monolithic nature of ERP prohibits this approach.
So, What Can You Do?
The most common thing to do, and the worst, is to pretend that the ‘wicked problem’ of ERP implementation is a tame problem. The next ribbon proposes an approach.
Managing Wicked Problems
What Do You Do With a Wicked Problem?
You can’t “solve” a wicked problem. You have to manage it.
Most ERP methodologies (like the “Adaptive 7”) are designed for tame problems. They give you a linear map when you really need a compass and survival skills.
The secret isn’t to throw away the methodology. It’s to adopt a new mindset within it.
The Tame Leader Trap
Treating the implementation as a machine.
- Sees the plan as a predictive blueprint.
- Treats all scope creep as an enemy to be defeat.
- Views dissent and new information as "noise" or "resistance."
- Focuses 90% on the *technical* build (the "what").
- Declares victory at go-live and disbands the team
The "Wicked" Leader's Approach
Cultivating an Ecosystem
- Sees the plan as a guiding compass, not a rigid map.
- Actively triages scope: "Is this a vital or a distraction?"
- Amplifies "weak signals" (the "canary in the coal mine").
- Focuses 90% on adoption and decision-making (the "why").
- Knows go-live is Day 1 of the ecosystem's life.
Your New Playbook
Your methodology doesn’t change, but your actions within it do. Here is how a “wicked” leader navigates each phase. If you have not read anything about the Adaptive 7 yet, it is a generic methodology intended to adapt to other methodologies – here’s a visual:
Phases 1-2: Explore & Plan
A “tame” leader starts with a detailed, 100-page plan. A “wicked” leader knows this is impractical. Instead, They focus relentlessly on the “Why.” They create a simple, powerful Guiding Vision (the “Compass”) that every single person can remember, and a strategy – a high-level roadmap.
Phase 3: Design & Build
This is when your Subject Matter Experts (SMEs) get their first real look at the system. When one person says, “This feels wrong” or “This is slower,” a “tame” leader dismisses it as “resistance to change.” A “wicked” leader runs towards that comment. They treat it as a “weak signal”—a potential symptom of a hidden problem (like a broken process, or a critical missed requirement). Amplifying this signal early saves you from a disaster at go-live.
Phases 4-5: Validate & Launch
During testing, you will find new problems. A “tame” leader says, “No scope creep! Launch at all costs!” A “wicked” leader knows this is a “one-shot operation” (by definition). You can’t undo it. Your job becomes rapid triage. You must distinguish “bad scope” (a “nice to have” feature) from “good scope” (a newly discovered, business-critical flaw that *must* be fixed). This requires political skill, not just project management
Phases 6-7: Stabilize & Grow
A “tame” leader is gone after go-live. The project is “done.” A “wicked” leader knows the ecosystem is just been “born.” This is the “No Stopping Rule” in action. Your focus now shifts from *building* to *cultivating*. This means obsessing over user adoption (Are they using it?), business value (Is it working?), and future adaptation (What’s next?). This phase never ends, and it’s where the real ROI is found.
Culture's Role in Preventing Catastrophic Failure
A "Controlled Flight Into Terrain"
The night before the launch of Columbia, engineers from Morton Thiokol held a heated teleconference with NASA managers, arguing that launching in such cold temperatures was an unacceptable risk. NASA officials, under pressure to maintain their launch schedule, were furious. They challenged the engineers’ conclusions, one NASA manager exclaiming, “My God, Thiokol, when do you want me to launch? Next April?”
“Wrong-Site Surgery” errors have occurred many time. In 1995, for example, a patient with kidney cancer had his healthy kidney removed instead of the cancerous one, forcing the patient to have another surgery and go on dialysis. Often a nurse or technician fails to call out their error under the assumption that “the surgeon knows best,” or for fear of reprisal.
Korean Air Flight 801 crashed on its final approach to Guam. The co-pilot and flight engineer were aware that the captain was making a mistake and the plane was too low. Due to the high-authority, hierarchical cockpit culture at the time, they were not assertive enough to successfully challenge the captain’s decision. The plane crashed into a hill, an event known as a “controlled flight into terrain.”
Even in life and death situations, culture matters.
The King's Clothes
It’s not a perfect analogy. The fable is simple – ERP Implementations are complicated, and there really is a cloth being woven. But there are lessons worth learning.
In the Fable ...
In ERP Implementations ...
Two swindlers promise a magnificent, magical cloth that is invisible to anyone who is incompetent or stupid.
The ERP promises a “transformative,” “fully-integrated,” “best-practice” solution that will solve all problems.
No one will admit they can’t see the cloth for fear of being labeled unfit for their position.
Project team members, even executives are afraid to admit they don’t see or understand something, for fear of being seen as “not a team player,” or “not competent.”
Each member of the court who sees the empty loom sees nothing, but hears from others how magnificent the cloth is, and they agree.
.
The project manager knows a key module is failing but reports the status as “green” or “yellow” because they don’t want to be the bearer of bad news or be seen as incompetent. Others, who may have their own doubts, see the “green” status and remain silent
The king parades through the streets, naked, with everyone pretending to admire his beautiful new clothes.
The system goes live with uncertain value, poorly defined processes, bad data, poorly trained users, or any of a number of critical problems.
A child, unaware of what his statement might imply, shouts, “But he isn’t wearing anything at all!”
The ‘children’ in ERP projects have nothing to lose and they speak out – after it’s too late.
Lessons for ERP
- Foster Psychological Safety: Leaders must explicitly and repeatedly state that questioning the process and pointing out problems is a sign of engagement, not resistance. They must reward, not punish, the messengers who bring bad news.
- Embrace “Show, Don’t Just Tell”: Never accept abstract promises. Demand to see the “cloth.” Insist on Conference Room Pilots (CRPs) and hands-on demonstrations with your company’s data and your real-world business scenarios.
- Value the “Child’s” Voice: Actively seek out feedback from end-users throughout the process. Put the new system in front of the people who do the work every day and listen—truly listen—to what they say.
Leaders Need Followers, Who Then Become Leaders
What are the characteristics of a leader? With over 80,000 books on leadership available on Amazon, it must be complicated. Recognizing leaders is much easier: leaders have followers.
ERP implementations require leadership from many different people playing many different roles. It can’t be the sole responsibility of the project sponsor. Other organizational leaders, the implementation team, the project change champions, all need to follow the leader.
I can’t put this more eloquently, or in a more entertaining way, then this popular video on the concept.
Navigating Leadership
From Mandate to Mission
Your Project is a Mandate, but That's Not Good Enough
Almost every project starts with a mandate, such as “our old system is dying.”
The problem with this is
Navigating Management
The PM's Quest: A Knight's Guide to the ERP Kingdom
The Organizational Governing Structure
If you were to compare a corporate governing structure to a state governing structure, what would it be? I had a project management instructor ask that once, and I have benefited from his answer ever since. Corporations are not democracies or republics, and they’re not dictatorships. Corporations have “feudal state” power structures.
The Monarchy
The C-Suite is the Monarchy, setting the overall direction and holding ultimate power.
The Lords
VPs and Department heads are the Feudal Lords. They control their own “fiefdoms” (their departments), command the loyalty of their subjects, and control resources.
Foreign Allies
Foreign allies act in ways that benefit your organization and theirs. Your implementation partner is a foreign ally. So are vendors and customers.
Project Managers are Knights
Project Managers are knights, charged by the Monarchy with a quest (the project). To succeed, the knight must travel through the lands of various lords.
- Authority on Loan: A PM is not without authority, but a PM’s authority is only on loan from the monarchy. They must act on behalf of the monarchy, truly pursuing the quest, and to disrespect the knight is to disrespect the monarchy.
- Navigating Fiefdoms: The knight must negotiate passage, supplies, and soldiers from different lords who may or may not be friendly. A PM must negotiate with people from different kingdoms, each with their own priorities.
- Divided Loyalties: The soldiers a lord lends to a knight are ultimately loyal to their lord, not the knight. Likewise, project team members are loyal to their functional manager, not the PM. The knight is, first of all, a diplomat, and going to battle is a last resort.
- Keeping Allies from Becoming Enemies: The monarchy chooses alliances, but the knights keep them. The Project Manager works directly with the implementation partner, focusing on their common goals while recognizing that the partner (a knight from another land), has their own feudal governance structure to answer to.
- The Quest is Everything: The knight’s entire purpose is tied to the success of the quest. The project’s success entirely defines a PM’s role. Once the project is done, the “fellowship” disbands and the knight awaits a new quest.
The analogy, and the role of the PM as a knight, has helped untangle some fundamental challenges of project management:
- Authority vs. Influence – PMs have little or no authority, and influence is often their best option. However, when influence fails, an active monarchy willing to intervene on your behalf can be invaluable.
- Cross-functional contention is not dysfunction; it’s reality.
- Understanding the divided loyalties of the people and partners on the project.
Management's First Job: Ensuring Capability
PM's Can't Do the Impossible - Ensuring Capability
Before you can do anything, you need to be capable of doing it, and it turns out that love is not all you need.
Clayton Christensen’s RPV model (see the Capability Overview), provides a proven “recipe for success,” and before you undertake any activity, as a PM you need to ensure that you have all three dimensions of a capability. And you need to stay on top of them, because they can change as activities progress.
Any gap in any dimension of a required capability should be escalated and resolved as soon as possible.
“Players make the manager, it’s never the other way.”
Sparky Anderson
From Vendor to Partner: Forging a True Implementation Alliance
Your implementation partner is your most important and most challenging relatiionship
- There is no “Us” and “Them.” There is only the Implementation Team.
- Banish blame in favor of “in this together” problem solving.
- Value bad news delivered early over good news delivered late.
The "No Surprises" Protocol
Psychological safety is built on clear rules. Resolve conflict through a defined Escalation Matrix, not emotions.
Resolution Target
Level 1 (PM to PM)
Daily blockers
< 48 hours
Level 2 (Steering Committee)
Budget variances & process decisions
< 72 hours
Level 3 (Executive Sponsors)
Contractual disputes & Go/No-Go
< 1 week.
Scope & Reality
Scope creep is the silent killer of ERP success. Adhere to a rigorous Change Control process.
The Filter: Every new request is asked: “Is this critical for our value goal? Can it wait until phase 2?”
The Trade-off: Scope is zero-sum. Adding requirements after sign-off requires adding budget/time OR removing other scope (“Scope Swapping”).
The Goal: Adapt business processes to the software (“Vanilla”) rather than customizing software to legacy processes.
Responsibility
Ambiguity causes friction. Explicitly define any”Grey Areas,” such as …
Area
Client
Partner
Data
Extract, Harmonize, Clean
The ‘Map’, Load
Testing
User Acceptance Testing (UAT). Validating the system supports real business scenarios.
Unit & System Testing. Ensuring the code and configuration work technically.
Process
The “Why”. Defining the desired business outcome and value.
The “How”. Mapping that outcome to system best practices.
Decisions
Velocity. Making timely decisions to prevent schedule slippage.
Guidance. Providing clear options and recommendations.
Beyond "Good Vibes"
Track the health of the partnership using objective KPIs, reviewed monthly by the Steering Committee:
- Decision Velocity: Average time to approve a configuration decision.
- Scope Variance: Percentage of new requirements added post-design freeze.
- Relationship Pulse: “On a scale of 1-10, how likely are you to recommend this partner/client today?”
Building Independence
The goal is for the Partner to become obsolete.
- Train the Trainer: Train your “Super Users,” who then train your end-users.
- Continuous Transfer: Knowledge transfer happens at the end of every sprint, not just at the end of the project.
- Offboarding: Execute a formal transition plan to hand over support to your internal team”
The Taxonomy of Leadership Success
Getting Leadership right requires getting a hierarchy of things right. Explore the taxonomy of Leadership critical success factors below. Click the grey + to reveal more detail.
Leadership- Vision & Direction
- Strategic Alignment
- ERP Purpose
- Business Case Advocacy
- Future Orientation
- Inspiring Vision
- Narrative
- Symbolic Actions
- Goal Clarity
- Influence & Sponsorship
- Visible Sponsorship
- Active Presence
- Communication
- Resource Backing
- Coalition Building
- Cross-Functional Champions
- Partner Alignment
- Political Navigation
Trust & Culture- Psychological Safety
- Safe to Speak Up
- Learning Orientation
- Respect for Expertise
- Integrity & Authenticity
- Actions Match Language
- Consistency
- Engagement & Communication
- Stakeholder Engagement
- Listening Channels
- Tailored Messaging
- Inclusion
- Effective Communication
- Clarity
- Frequency
- Storytelling
- Change Leadership
- Championing Change
- Role Modeling
- Advocacy
- Energy & Momentum
- Resilience Building
- Coping with Setbacks
- Celebrating Wins
- Persistence
- Empowerment
- Decision Empowerment
- Rapid Escalation
- Accountability Clarity
- Empowered Teams
- Capacity Building
- Leadership Development
- End-User Enablement
- Knowledge Sharing
The Taxonomy of Management Success
- Maangement
- Planning and Project Definition
- Project Planning
- Integrated Master Plan
- Timeline and Schedule
- Budget Planning
- Communicating Complexity
- Scope Definition and Control
- Setting Clear Scope and Objectives
- Defining "Out of Scope"
- Change Control Implementation
- Execution DIscipline and Monitoring
- Project and Program Management Discipline
- Methodology Applicaton
- Project Initiation (Kick-off)
- Status Reporting and Monitoring
- Managing Project Phases and Go-Live
- Risk and Issue Management
- Proactive Risk Management
- Maintaining a Formal Risk Register
- Issue Escalation Path
- Planning for Post- Go-Live Support
- Resource Orchestration
- Team Enablement
- Resource Scheduling
- Maintaining Client Ownership and Control
- Due Diligence and Contract Management
- Vendor and Partner Management
- Structured Communication Plan
- Establishing a True Partnership
- Engaging Stakeholders and Fostering Buy-in
Leadership and Management in the Project Lifecycle
An overview of activities for Leadership and Management success, by phase, from the beginning of the project. Click any of the phase buttons below for a summary.
