What an ERP Project Manager Actually Does
Six months into a mid-size manufacturer's ERP rollout, the project manager realized nobody had ever actually been assigned to own data migration decisions — questions like what counts as a duplicate customer record, or which of three conflicting part-number formats becomes the standard going forward. The PM had been running weekly status meetings reporting on a workstream that, on paper, had no accountable owner. That gap is common, and it points to a persistent confusion about what an ERP project manager's job actually is, versus the roles that need to exist around them.
What the ERP project manager is not responsible for
The PM is not the technical configuration expert, not the executive who unblocks funding and cross-department disputes, and not the person who should be making unilateral business-process decisions — deciding, say, how the company will handle backordered items — on their own authority. When a PM ends up filling those roles by default, it's usually because nobody else was clearly assigned to them, not because the PM role was ever meant to cover that ground. A PM absorbing decisions that belong to a functional lead or an executive sponsor is a symptom of a staffing gap, not a sign the PM is doing their job well.
What the PM actually owns day to day
- The risk register — tracking known risks, their likelihood and impact, and mitigation plans, updated as the project progresses rather than written once at kickoff and ignored
- Scope control — evaluating change requests against the original project charter and forcing an explicit decision (approve with a timeline/budget impact acknowledged, or defer to a later phase) rather than letting scope quietly grow
- Vendor relationship management — holding the implementation partner or software vendor accountable to their statement of work and escalating when deliverables slip
- Status reporting to the steering committee — translating workstream-level detail into a summary executives can actually act on
- Resource scheduling — coordinating internal staff time against vendor consultant availability, which are two calendars that rarely line up naturally
The full cast of roles around the PM
| Role | Responsibility | Typical time commitment |
|---|---|---|
| Executive sponsor | Unblocks cross-department decisions, approves funding and scope changes | 2-4 hours/week |
| Steering committee | Approves major scope, budget, and timeline changes | Monthly meeting plus ad hoc |
| Functional/process leads | Own configuration decisions for their department | 30-50% time during design phase |
| Super users | Subject matter experts who test the system and later train peers | ~20% time throughout, spiking during UAT |
| Change management lead | Communication plan, training coordination, adoption measurement | Varies, often part-time until go-live approaches |
| Technical/data lead | Migration and integration decisions | Heavy during data migration phase |
A RACI example for a single decision
Take a concrete decision: should the system allow backordered items to auto-ship as partial shipments, or hold the entire order until it's complete? In a clear RACI structure, the warehouse operations process lead is Responsible for proposing the recommendation; the steering committee is Accountable for the final decision, since it affects customer experience and shipping cost company-wide; the PM and technical lead are Consulted, since it affects timeline and system configuration; and warehouse floor staff are Informed once the decision is made. Without that structure spelled out, this kind of decision tends to get made informally in a hallway conversation and then re-litigated three separate times by three separate people who each thought they owned it.
Skills that matter more than technical ERP knowledge
A PM who deeply understands the software but can't get two department heads to agree on a shared process will struggle more than one with moderate technical knowledge and strong facilitation skills. The specific abilities that show up repeatedly in successful ERP PMs: resolving conflict between departments that each want the system configured their own way, saying no to scope creep even when the request seems small and reasonable in isolation, and knowing when to escalate a stuck decision to the executive sponsor rather than trying to broker it personally for the third week in a row.
The most common role gap
Beyond the data-ownership gap in the opening example, the second most common failure is assigning the super-user role to whoever happens to be least busy at the moment, rather than whoever is most respected by their peers. Super users end up training and supporting their colleagues after go-live — if that person isn't someone the department already trusts, the training doesn't stick regardless of how good the underlying material is. Naming these roles explicitly and deliberately at kickoff, rather than letting them get filled by default or convenience, is one of the more reliable predictors of whether an implementation goes smoothly.
How the PM's focus shifts across the project
The job doesn't stay constant from kickoff to go-live. Early on, during discovery and design, the PM spends most of their time on scope definition and vendor management — making sure the statement of work actually matches what's being configured, and catching scope drift before it becomes an expensive change order. During data migration and testing, the PM's focus shifts toward risk management and cross-team coordination, since this is typically where the project's biggest schedule risks live. In the run-up to go-live and through hypercare, the job shifts again toward change management and adoption — status reporting starts mattering less than making sure end users actually have what they need to do their jobs on day one of the new system. A PM who keeps running the project the same way through all three stages is usually the one who gets caught flat-footed by a phase-specific risk nobody was watching for.
Internal PM vs. an external hire
Companies without ERP implementation experience often default to appointing an internal operations or finance manager as PM, on the theory that they already understand the business. That's a real advantage for navigating internal politics and knowing who actually makes decisions in each department, but it's a real disadvantage if that person has never run an implementation before and doesn't know what a healthy risk register or a realistic data-migration timeline actually looks like. An external, dedicated implementation PM brings pattern recognition from having seen where other projects went wrong, at the cost of a learning curve on the company's own internal structure and relationships. Many mid-size implementations end up pairing the two deliberately — an external PM running project mechanics, working alongside an internal co-lead who owns organizational context and relationships — rather than choosing one model exclusively.
Measuring whether the PM role is actually working
Steering committees often judge a PM purely on whether the project is on schedule, which is a lagging and incomplete signal. More useful indicators show up earlier: whether the risk register is being updated regularly with new items, or has stayed static for a month, which usually means risks are surfacing informally and not getting captured; whether change requests are being evaluated against defined criteria or approved reflexively because pushing back feels awkward; and whether status reports to the steering committee flag real problems honestly or read as uniformly positive right up until a deadline gets missed. A PM whose reports never mention a risk or a concern isn't necessarily running a smooth project — more often, it means problems are being absorbed silently until they can't be anymore, which is exactly the failure mode a good risk register is supposed to prevent.