ERP Implementation Team Roles: Who Does What, and Who Decides

What are ERP implementation team roles?

ERP implementation team roles are the defined positions and accountabilities that carry an Enterprise Resource Planning rollout from discovery through go-live and into stabilization. Because an ERP system touches finance, operations, sales, and reporting at once, the team is deliberately cross-functional: it combines executive sponsorship, day-to-day project leadership, business-process experts from each affected department, technical specialists, change agents, and an external implementation partner who supplies platform-specific experience the in-house team rarely has.

NetSuite frames the team as the single biggest controllable variable in the project: every ERP implementation needs key members drawn from across the organization and at all levels of seniority, providing sponsorship, insight into business processes, and practical support. The discipline of defining who owns what—before configuration begins—is what separates a team that delivers on scope from one that drifts into overruns and rework.

The stakes are structural, not anecdotal. Panorama Consulting notes that many high-profile ERP failures can be traced back to a lack of sponsorship, and that the absence of a clear, active executive champion is a root cause of change resistance. 2026 discrete-manufacturing research lists inexperienced implementation teams (about 35% of failure drivers) and lack of executive sponsorship (about 31%) among the top preventable causes—right alongside poor data migration. Prosci’s 2025 ERP research goes further: human and organizational factors matter about six times more than technical factors in realized benefits. In other words, the failure mode is rarely the platform—it is a team without the right roles, authority, or time commitment.

The core ERP implementation team roles

A defensible ERP team is built around a small set of non-negotiable roles, then extended with supporting roles as scope grows. The list below blends NetSuite’s, Visual South’s (2026 update), and ERP Research’s role breakdowns, which agree on the same backbone: a sponsor who owns the vision, a project manager who owns delivery, functional leads and SMEs who own business fit, data owners who own master data, a change lead who owns adoption, and technical specialists who own the build and cutover.

For small and mid-size enterprises (SMEs), several of these roles are typically combined into fewer people, and the external implementation partner absorbs the technical and data-migration load that a larger enterprise would staff internally. What never collapses—regardless of company size—is the executive sponsor, a named project manager with real hours, and at least one accountable data owner per critical master-data domain. Those roles must be named individuals with real authority and real time.

The executive sponsor: vision, authority, and air cover

The executive sponsor is the senior leader who champions the implementation and carries final accountability for its business outcome. Panorama Consulting describes the sponsor as someone from the executive team who leads change efforts by building a coalition of sponsorship with peers and managers - remaining active and visible throughout the project rather than signing the business case and disappearing. NetSuite adds that the sponsor typically makes final decisions about the project, including whether to increase the budget, which processes to automate, and whether to add or remove personnel.

A sponsor who is merely named but not engaged is worse than none, because it creates the illusion of governance. Panorama's four concrete responsibilities give a usable job description: build a sponsorship coalition among peers and managers; stay engaged by showing up to project meetings; demonstrate ongoing support visibly when the project hits roadblocks; and communicate the need for change early, answering the 'what's in it for me?' question for every affected team.

Practically, a strong sponsor does three things on a recurring cadence. They unblock resources - freeing SMEs and approving backfill - because only an executive has the authority to pull busy operators off their day jobs. They arbitrate scope conflicts at the steering committee, weighing customization requests against business value. And they own the narrative, repeating the 'why' to the organization at every milestone so the project never loses organizational momentum. If any of these three is missing, scope creep and adoption resistance usually follow.

The project manager: delivery, schedule, and scope control

The project manager is the point person who keeps the implementation on schedule, within scope, and within budget. NetSuite describes the PM as the person who coordinates every step of the implementation—vendor selection, process mapping, testing—updates the project plan at each stage, and serves as the liaison between the executive sponsor and the team members. On most SME rollouts the PM is the single source of truth for status, risk, and decisions.

The role demands a specific blend of skills that Panorama flags as hard to find: both ERP experience and project management experience, where project management means scheduling tasks, managing the timeline, and managing scope. A capable ERP PM runs the workstream plan, the RAID log (risks, assumptions, issues, dependencies), the change-request queue, and the status reporting rhythm that feeds the steering committee. They also run the UAT cycle and the cutover checklist—the two moments where weak project management most often produces go-live failures.

A common SME mistake is to assign the PM role to someone who “has the time” rather than someone who can do the job. SAP is explicit that an ERP project requires recruiting the people you cannot do without—the busy people who know the processes, work well with others, and have executive respect—and dedicating them full-time. Visual South’s 2026 guidance is even more direct for the customer-side project owner: free 60–75% of their calendar or the project will derail. A part-time or under-qualified PM is one of the most reliable predictors of schedule slip and scope drift.

Functional leads, SMEs, and super-users: the business-fit engine

Functional leads and subject-matter experts (SMEs) are the people who make the system fit the business. ERP Research defines the functional team lead as the person responsible for the functional aspects of the project, working with business users to ensure the system is configured to the business requirements—while the business analyst maps those requirements to platform capabilities. SMEs (often called super-users in go-live and hypercare) supply the granular process detail: exactly how an order flows, how a costing exception is handled, how a return is booked.

NetSuite underscores that early involvement of end users and department experts improves system fit and drives stronger adoption post-go-live. These are not optional reviewers pulled in at UAT; they are co-designers who sit in configuration workshops, validate the future-state process maps, and own the acceptance criteria. Without them, the partner configures to assumptions, and the business discovers the gaps at go-live when they are most expensive to fix.

The super-user role extends past go-live and is the backbone of a change network. Super-users answer non-technical questions from peers, champion adoption inside their department, run first-line floor support during hypercare, and feed improvement requests back into the backlog. Visual South calls a strong super-user the single most critical long-term team member for self-sufficiency after the partner leaves. Name them explicitly in the team plan—do not treat adoption as something that happens by itself.

Technical lead, developer, and data migration lead: the build and cutover

The technical team lead and developer own the build: customizations, integrations to other systems, extensions, and the technical architecture that keeps the platform performant. ERP Research frames the technical team lead as responsible for the technical aspects of the project, working with the development team to ensure the system is designed and built to specification. For most SMEs, this role lives with the implementation partner, with internal IT providing environment access, identity and security review, and ongoing infrastructure ownership.

The data migration lead is the role most often underestimated and most often the cause of a painful go-live. ERP Research defines the data migration team lead as responsible for migrating data from legacy systems to the new ERP, working with business users to ensure data is migrated correctly and integrity is maintained. The job spans data assessment and cleansing, field mapping, conversion scripting, reconciliation against source, and the dry-run cycles that prove the cutover will work. SAP lists data cleansing as one of the most time-consuming activities in the whole project and recommends starting it as early as possible. 2026 manufacturing-focused research still ranks poor data migration among the top failure drivers (cited around 38% of discrete-manufacturing ERP failures in one industry synthesis).

Crucially, migration mechanics and data ownership are not the same role. The partner (or internal conversion team) executes loads and scripts; a named internal data steward or data owner accepts quality for each master-data domain—items, customers, vendors, chart of accounts, BOMs. Secret CFO’s widely shared practitioner thread puts it bluntly: every ERP is a giant multi-dimensional database of master data relationships, and if the master data is poor, the system is poor. A team that has not named both the migration lead and the data owners before build begins will discover at go-live that no one owned data quality.

The ERP steering committee: the body that prevents drift

If the project team runs the work, the steering committee governs it. Pemeco defines the ERP steering committee as the body responsible for driving strategic goals, applying organizational resources, and making key project decisions - staffed by decision-makers with the foresight, influence, and leadership to guide a long-term, strategically important transformation. Panorama specifies the membership: the CEO, the CIO, the ERP project manager, and business managers at the EVP or VP level - a cross-functional group with ultimate authority over every aspect of the implementation.

The project manager is the committee's window into performance. Pemeco notes that the PM is an essential member who reports status, risks, and issues, and raises the requests that require steering-committee decision-making. This keeps the committee grounded in reality rather than politics: decisions are made against actual schedule, budget, and risk data, not against the original business case that has already drifted.

The steering committee exists precisely because scope creep, competing department priorities, and the 'emotional curve' of a long project will otherwise pull the implementation off course. Pemeco argues that as the project moves through predictable rough patches, people fall down an emotional curve and resist the system unless the committee continues to champion it and pushes directors and managers to do the same. A committee that meets on a fixed cadence, makes decisions in the meeting, and visibly backs the sponsor is the single most effective antidote to drift.

What the steering committee actually does

Panorama's six steering-committee responsibilities give a ready-made charter. First, provide project direction as active, vocal change champions. Second, ensure organizational alignment by reviewing deliverables against corporate strategy. Third, control timelines and budgets so that customization requests and change orders get a reality check before they are approved. Fourth, approve changes and make decisions - signing off only on requests that align with project goals.

Fifth, provide internal resource support - the authority to pull SMEs off their day jobs and supply backfill, which no project manager can do alone. Sixth, ensure project ownership by keeping executives actively engaged at every critical juncture rather than letting them take a hands-off approach. Pemeco reinforces this with three enabling imperatives: create a clear charter with measurable KPIs, map and engage the affected stakeholder groups, and invest in change management so adoption is actively managed rather than hoped for.

The practical test of a working steering committee is decision velocity. If a scope question, a budget top-up, or a resource conflict sits unresolved for weeks, governance has failed regardless of how often the committee meets. The fix is a standing agenda, a single decision owner per item, and a rule that every meeting ends with documented decisions, owners, and dates.

Decision rights: who approves what (a working RACI)

Governance only prevents drift when decision rights are explicit. ERP Research argues that clearly defining the roles and responsibilities of each member is crucial—including the project manager, functional leads, and technical leads—so there is no confusion or overlap in responsibilities. The most reliable way to make that concrete is a lightweight RACI for the decisions that recur on every ERP project: scope changes, budget changes, customization requests, data freeze, data sign-off, integration readiness, and go-live approval.

The pattern that works for SMEs keeps three decision tiers separate. The steering committee approves anything that changes scope, schedule, or budget, and owns the formal go/no-go. The executive sponsor approves resource trade-offs and cross-department conflicts that cannot be resolved at the team level. The project manager runs day-to-day decisions inside the approved scope—configuration choices, sequencing, defect triage—and escalates only what crosses those thresholds. Functional leads remain responsible for process acceptance and UAT quality in their domain.

The table below is a starting RACI you can adapt into the project charter and partner SOW. The point is not the letters themselves but the conversation that produces them: forcing the team to agree, in advance, who decides each category of question is what removes the ambiguity that quietly expands into delay—and what keeps a partner from “deciding for” the business on scope they do not own.

Resource allocation: the 25% rule and backfill

The most common structural failure on an ERP team is not a missing role—it is a present role with no time. SAP is unusually specific about the threshold: no one who is unable to dedicate at least 25% of their weekly time (a minimum of 10 hours) should be added to the key project team, because anyone spending less than a quarter of their time can barely catch up on project activity, let alone add value. SAP goes further, recommending that the people you cannot do without be dedicated full-time—40 available hours per week. Practitioners echo the same hierarchy: put your best people on the rollout and backfill their day jobs; temporary project-only hires are second-best; “do it with the existing overloaded team” is last.

This rule has a direct consequence for staffing: if your best finance controller or warehouse lead is the right functional lead but is still running their department, you must backfill their operational duties or the project will starve. Panorama makes the same point from the resource side, noting that project managers need both ERP and project-management experience and that internal resources must be genuinely freed to contribute—not asked to absorb the project on top of a full operational load. Visual South’s 2026 guidance targets 60–75% freed capacity for the customer-side project owner; key PMs and solution architects commonly need 50–100%.

SAP’s capacity math makes the trap concrete. The vendor walks through a worked example: a 12-month target go-live that requires 42,000 work-hours against only 28,080 hours of available team capacity per year—meaning go-live is missed by roughly 50% before the project starts. The remedies SAP lists are all governance decisions: reduce scope, extend the date, add more internal and external resources, or phase the project. None of those levers can be pulled by a project manager alone—which is exactly why resource allocation belongs on the steering committee’s agenda, not buried in the workstream plan.

Sizing the team for an SME rollout

ERP Research observes that team size scales with company size and project scope, but the roles stay broadly the same—smaller teams simply combine roles into fewer people. For an SME implementing Microsoft Dynamics 365 Business Central or Odoo, the internal team is typically compact: one named executive sponsor, one project manager (often partner-supplemented), one functional lead per major module in scope (finance, sales, operations), and a handful of SMEs or super-users per department.

The implementation partner carries the technical, data-conversion, and methodology load that a larger enterprise would staff internally: the technical lead, conversion specialists, the QA or test lead, and often the training-content lead. This is the core economic argument for using a partner on an SME rollout—you buy fractional access to specialist roles you could not justify full-time, while keeping the business-fit roles (sponsor, PM, functional leads, SMEs, data owners) internal where the institutional knowledge lives.

Use the FTE table below as a planning floor, not a promise. If the steering committee cannot free that capacity, the schedule is fiction—and the honest response is to either phase the rollout or extend the timeline, not to pretend a stretched team will absorb the work. Robert Half’s 2025 Canadian hiring research found that 44% of tech and finance hiring managers expect outside help most for implementation itself, and 27% already cite ERP skills as a departmental gap—evidence that under-staffed internal teams are the default risk, not the exception.

Customer vs SI: who owns what (and what belongs in the SOW)

Role charts fail in practice when the statement of work (SOW) is vague about customer obligations. The system integrator (SI) or implementation partner brings platform methodology, configuration skill, conversion tooling, and delivery management for the work they sell—but they do not replace your process owners, data owners, or change network. Buyers who assume “the partner will implement ERP for us” systematically underestimate headcount, master data, and culture change—the three underestimations Secret CFO and many operators keep repeating.

Draw the boundary in writing before kickoff. Customer typically owns: business process decisions, requirements prioritization, master-data cleansing and freeze acceptance, SME availability, UAT execution and sign-off, training attendance and floor support after go-live, and the go/no-go decision. Partner typically owns: solution design against agreed scope, configuration and documented customizations, technical environments, conversion scripts and load runs, integration build for in-scope interfaces, test-script frameworks, train-the-trainer content, and defect resolution for partner-built work during hypercare. Grey zones—report design, integration ownership for third-party systems, cutover command-center staffing—must be named explicitly or they become change orders.

Contract language that protects both sides is boring and valuable: named key personnel with seniority requirements and substitution rights; a RACI attached as a schedule; customer dependency clauses with lead times (SME workshops, data extracts, environment access); a change-control path that matches the steering committee; acceptance criteria per workstream, not a single vague “go-live.” Ask for the partner’s staffing mix on your project—senior functional leads vs junior configurators—and price the senior hours you actually need. An SI that underbids with a junior-heavy team is not a bargain if your SMEs end up teaching the product.

How the team model overlays Dynamics 365 and Odoo

The team structure above is platform-neutral, but the cadence and emphasis shift with the platform. On a Microsoft Dynamics 365 rollout - particularly finance and operations - the partner team maps onto Microsoft's Success by Design and FastTrack methodology, which front-loads design decisions, blueprint sign-off, and a formal go/no-go gate. That puts extra weight on the functional leads and the business analyst during design, and on the project manager to enforce the readiness checkpoints before cutover.

On an Odoo rollout, the methodology is typically more modular and phased - app by app - which favors tight functional leads who can sequence modules and a data migration lead who handles a rolling cutover as each app goes live. Odoo's lower per-user cost and rapid configuration often tempt teams to under-resource governance, but the same sponsor, PM, and steering-committee roles apply: the speed of the platform does not remove the need for decision rights and resource allocation.

In both cases the implementation partner is the platform expert and the internal team is the business expert. The division of labor is the same; only the rhythm of design reviews, integrations, and cutover differs. A platform-neutral partner can help you apply the same governance discipline to either stack rather than letting the platform's defaults dictate your team structure.

Super-user network and change agents: how training actually scales

A training plan without a network is a one-time classroom event. Successful ERP programs treat super-users and change agents as a standing operating model: a small set of trained, trusted people in each department who translate the new process into local language, intercept resistance early, and keep adoption alive after the partner’s hypercare window ends. Prosci’s ERP research and case write-ups repeatedly show that human and organizational factors dominate benefit realization; a named change lead plus a distributed agent network is how those factors get operationalized.

Sizing is practical, not ceremonial. Long-running SAP community guidance uses a simple starting ratio of roughly one super-user per 50 end users (end users ÷ 50), adjusted up for complex shop-floor or multi-shift environments and down for highly centralized finance teams. Select for credibility and teaching ability—not for who has spare calendar. Super-users should join design workshops early, own UAT scenarios for their area, complete train-the-trainer before end-user waves, and staff a visible floor-support rota for the first weeks post-go-live.

Separate the change agent network from pure technical super-users when the org is large enough. Agents carry the “why,” the timeline, and the feedback loop to the project team; super-users carry “how” in the system. Both report into the change lead on a fixed cadence (weekly through go-live, then biweekly through stabilization). Measure what matters: training completion, UAT pass rates, ticket volume by process area, and time-to-competency on critical transactions—not slide-deck attendance alone. When the partner leaves, this network is what keeps the ERP from becoming shelfware.

Common team-structure failures and how to avoid them

Most ERP team failures cluster into a handful of repeatable patterns. The first is the absentee sponsor—a named executive who never shows up, leaving the project manager without authority to resolve cross-department conflicts or free resources. Panorama’s guidance is direct: coach sponsors regularly, hold them accountable to the duties of the role, and treat an unengaged sponsor as a project risk to be escalated, not accommodated.

The second is the under-resourced functional team—SMEs assigned “in addition to” their day jobs, so configuration decisions get made without the people who know the process. SAP’s 25% minimum and 40-hour ideal exist precisely to prevent this; if the steering committee will not backfill, the schedule must bend. The third is weak governance: a steering committee that meets but does not decide, letting change requests and scope creep accumulate until they break the timeline and budget together.

The fourth is the missing data owner: conversion scripts exist, but no business person accepts master-data quality, so dirty customers, items, and BOMs land in production. The fifth is the part-time PM who updates a Gantt chart but cannot run RAID, cutover, or hard conversations with the partner. The sixth—flagged constantly by buyers and practitioners—is an SI bench stacked with juniors learning the product on the client’s dime while seniors appear only for steering meetings. Put named senior functional and technical leads in the SOW, require resume approval for key roles, and define substitution rules before kickoff.

The seventh pattern is treating the ERP rollout as a technology project rather than a people, process, data, and technology project. Practitioner threads and Prosci’s 2025 findings agree: consultants can deliver configuration, but they cannot own culture change or clean your master data for you. The remedy in every case is the same discipline this guide is about: name the roles, give them real time, put decision rights in a RACI the steering committee actually uses, staff the change network, and review the team’s health at every milestone with the same rigor you review the schedule.

Frequently asked questions