An ERP doesn’t get deployed by an IT team working alone in a corner. Research by Prosci on ERP implementations shows that human factors matter six times more than technical factors in achieving expected benefits (Prosci, 2025). In other words, choosing the right people to carry the project has more impact than choosing the software itself.
Yet team composition is rarely treated with the rigor it deserves. We appoint a project manager, designate some “business experts” and hope everything falls into place. The result: gray areas in responsibilities, decisions that drag on without proper arbitration, and users who discover the system on go-live day.
This article details the essential roles of an ERP project team, proposes a concrete RACI matrix by phase, and identifies the most costly organizational mistakes.
Why team composition determines everything else
Human factors: the primary cause of failure
According to the Standish Group (CHAOS Reports), only 31% of IT projects complete within scope, budget, and timeline (Standish Group, CHAOS Reports). The pattern holds for ERP: implementations that fail to achieve 70% of expected benefits represent between 11% and 31% of cases, depending on organizational change management maturity (Prosci, 2025).
The causes are consistently the same: insufficient training, misaligned stakeholders, lack of structured change management, unclear communication, poor cross-functional collaboration. These aren’t software bugs. These are people and governance problems.
Executive sponsor: the top success factor
The Standish Group CHAOS Report ranks executive sponsorship as the top success factor for IT projects. When the sponsor is competent and engaged, 74% of projects succeed (Standish Group, CHAOS Report). When absent or passive, the success rate drops by half.
An ERP touches processes across multiple departments (finance, procurement, production, HR, sales). Without an executive-level sponsor capable of arbitrating cross-departmental conflicts, the project gets bogged down in political compromises that erode scope and extend timelines.
The 7 essential roles in an ERP project team
1. Executive sponsor
Profile: C-suite member, often CFO, CEO, or CIO depending on the project’s primary objective.
Responsibilities:
- Champion the project’s strategic vision and communicate it across the organization
- Arbitrate scope conflicts between departments
- Approve budget and go/no-go decisions at each milestone
- Unblock resources when the project team faces difficulties
Common pitfall: appointing a “ceremonial” sponsor who signs the initial budget then disappears. An effective sponsor dedicates at least half a day per week to the project during critical phases.
2. Project manager
Profile: experienced project manager with business process knowledge, not necessarily a technical expert.
Responsibilities:
- Plan and track schedule, budget, and scope
- Coordinate work between internal teams and the integrator
- Manage risks and escalate blockers to the sponsor
- Facilitate steering committees (COPIL) and project committees (COPROJ)
Common pitfall: leaving project management solely to the integrator. The integrator has their own interests (billing, internal schedules). The organization must have its own project manager to defend its priorities.
3. Change manager
Profile: senior profile with cross-functional credibility, often from HR, internal communications, or a specialized consultancy.
Responsibilities:
- Map the new ERP’s impacts on each user population
- Design and execute the internal communication plan
- Organize training (timing, content, format)
- Measure post-go-live adoption and drive corrective actions
Under-investment in change management is well documented: failing organizations spend less than 10% of their total budget on training and change support (ERP Focus). Prosci recommends integrating a change component from project scoping, not at project end.
4. Key users (power users)
Profile: operational business experts, recognized by peers, freed up 50% minimum during design and testing phases.
Responsibilities:
- Formalize target processes with the integrator (design workshops)
- Validate configurations and test business scenarios (functional testing)
- Train end users in their department (cascade training)
- Serve as floor support after go-live (level 1 proximity support)
How many are needed? Count at least one key user per major functional module (finance, procurement, sales, production, logistics). On a mid-market project with 5 modules, that’s 5 to 8 people. On an enterprise multi-site project, 15 to 25.
Common pitfall: designating “available” people rather than the most competent ones. Key users are the ambassadors of the future system: if they’re not credible with their colleagues, cascade training won’t work.
5. Technical architect / CIO
Profile: internal technical leader (CIO, infrastructure manager, IS architect).
Responsibilities:
- Validate technical architecture (cloud, on-premise, hybrid)
- Manage interfaces with existing systems (CRM, WMS, BI, payroll)
- Handle data migration (extraction, cleansing, loading)
- Ensure security, performance, and GDPR compliance
6. Data owner / data steward
Profile: hybrid business/IT profile, often from finance or supply chain management.
Responsibilities:
- Define quality rules for master data (customers, suppliers, items, BOMs)
- Drive data cleansing before migration
- Validate data migration results
- Establish post-go-live data governance
This role is too often neglected. Data migration is one of the top three causes of ERP project failure, along with change management and inadequate team composition (ECI Solutions).
7. Integrator / vendor partner
Profile: integrator team (functional consultant, technical consultant, integrator project manager).
Responsibilities:
- Bring product expertise and industry best practices
- Configure the system according to target processes
- Develop approved customizations validated by steering committee
- Provide transition support during post-go-live hypercare period
Watch out: the integrator is not the decision-maker. They propose, the steering committee decides. An integrator who imposes choices without business validation is a red flag.
RACI matrix applied to ERP projects
The RACI matrix (Responsible, Accountable, Consulted, Informed) clarifies who does what on each deliverable. Without it, gray areas turn into conflicts or inaction.
- R (Responsible): performs the work
- A (Accountable): approves and is held accountable (only one person per deliverable)
- C (Consulted): provides input before decision (bidirectional exchange)
- I (Informed): informed after decision (unidirectional communication)
Typical RACI matrix by phase
Phase 1: Scoping and ERP selection
| Deliverable | Sponsor | Project Manager | Change Manager | Key Users | CIO | Data Owner | Integrator |
|---|---|---|---|---|---|---|---|
| Strategic objectives | A | R | C | I | C | I | I |
| Requirements specification | C | A | C | R | R | C | I |
| Vendor evaluation grid | C | A | I | C | R | I | I |
| Final vendor/integrator choice | A | R | I | C | C | I | I |
Phase 2: Design
| Deliverable | Sponsor | Project Manager | Change Manager | Key Users | CIO | Data Owner | Integrator |
|---|---|---|---|---|---|---|---|
| Target processes (blueprints) | I | A | C | R | C | C | R |
| Gap analysis | I | A | I | R | C | I | R |
| Standard vs. custom arbitration | A | R | I | C | C | I | C |
| Data migration plan | I | A | I | C | C | R | R |
Phase 3: Build and testing
| Deliverable | Sponsor | Project Manager | Change Manager | Key Users | CIO | Data Owner | Integrator |
|---|---|---|---|---|---|---|---|
| ERP configuration | I | A | I | C | C | I | R |
| Custom developments | I | A | I | C | R | I | R |
| User acceptance testing (UAT) | I | A | I | R | C | C | C |
| Data migration (dry run) | I | A | I | C | R | R | R |
| Training plan | I | C | A | C | I | I | C |
Phase 4: Deployment and go-live
| Deliverable | Sponsor | Project Manager | Change Manager | Key Users | CIO | Data Owner | Integrator |
|---|---|---|---|---|---|---|---|
| Go/no-go decision | A | R | C | C | C | C | C |
| End user training | I | C | A | R | I | I | C |
| Technical cutover | I | A | I | I | R | R | R |
| Hypercare support | I | A | I | R | R | I | R |
| Internal communication | C | I | R | I | I | I | I |
How to read and use this matrix
Three fundamental rules:
- Only one A per row. If two people are “Accountable,” nobody really is. Accountability cannot be shared.
- No row without R. If nobody performs the work, the deliverable won’t advance.
- The A has veto power. The Responsible proposes, the Accountable validates. If the key user drafts the target process (R), the project manager validates scope compliance (A).
Adapt this matrix to your context. On a mid-market project with 50 users, the project manager and change manager are sometimes the same person. On an enterprise multi-site project, you’ll have one change manager per site and a central coordinator.
The 5 most costly organizational mistakes
1. No sponsor, or a ghost sponsor
The project loses its arbitration lever. Cross-departmental conflicts don’t resolve, decisions go up and down endlessly, schedules drift. This is the top organizational failure cause.
2. Part-time key users under duress
When key users must “do the project on top of their daily work,” design workshops are rushed, testing is superficial, and cascade training doesn’t happen. Result: an ERP configured on theoretical processes that nobody validated under real conditions.
Best practice: negotiate at least 50% release rate for key users during active phases (design, testing, training) from project scoping. Formalize this commitment with key users’ managers.
3. No change management owner
Without a change manager, training is reduced to a technical demo in a conference room and communication boils down to an email from the CIO. Users endure the change instead of understanding it. Adoption stagnates, workarounds multiply (back to Excel), and ROI never materializes.
4. Data migration handled at the last minute
When nobody owns data responsibility, cleansing is postponed until the last week before go-live. We then switch with duplicates, obsolete customer records, and inconsistent BOMs. The first days on the new ERP become operational chaos.
5. Implicit RACI (“everyone knows who does what”)
In a 6-18 month project involving 10-30 people, implicit responsibilities don’t hold. Critical tasks fall through the cracks (nobody tests interfaces, nobody validates access rights), and arbitrations happen in crisis mode instead of being anticipated.
Sizing the team according to project scale
| Criteria | Mid-market (50 users) | Enterprise (200 users) | Large corporation (500+ users) |
|---|---|---|---|
| Sponsor | 1 (CEO or CFO) | 1 (C-suite member) | 1 + project steering board |
| Internal project manager | 1 (part-time possible) | 1 (full-time) | 1 + PMO |
| Change manager | 1 (often combined with PM) | 1 dedicated | 1 coordinator + site liaisons |
| Key users | 3 to 5 | 8 to 15 | 15 to 30 |
| CIO / architect | 1 | 1 to 2 | Dedicated technical team |
| Data owner | 1 (often the CFO) | 1 to 2 | 1 per data domain |
| Integrator | 2 to 3 consultants | 5 to 10 consultants | 10 to 20+ consultants |
These are indicative orders of magnitude. Adjust based on number of modules, degree of customization, and number of sites to deploy.
Launch checklist: is your team ready?
Before launching design workshops, verify these ten points:
- An executive sponsor is named and commits to weekly time slots dedicated to the project
- An internal project manager is designated (separate from integrator PM)
- A change manager is identified with a budgeted training allocation
- Key users are nominated by module, with release rates validated by their managers
- A data owner is responsible for the data migration plan
- The RACI matrix is formalized and shared with the entire project team
- Governance instances are defined (monthly COPIL, weekly COPROJ)
- The integrator has presented their named team (not just “a senior consultant”)
- The budget includes a change management line item (training, communication, support)
- A project onboarding kit is distributed to all team members
If three or more points aren’t checked, take time to structure before launching. A well-staffed ERP project from the start costs less than a poorly staffed project that gets corrected mid-course.
To deepen this topic, consult our ERP change management guide and our article on the five phases of a successful ERP project. If you’re starting an RFP process, our guide to writing an ERP requirements specification will help you structure your requirements from the scoping phase.
