Ask ten people what an ERP Project Manager does and you'll get ten different answers. Ask the ERP PM themselves and you'll probably get a wry smile. The honest answer is: it depends on the day — and on the size of the project. Here's what the role actually involves, and why it looks so different from one implementation to the next.
The ERP Project Manager is one of the most misunderstood roles in enterprise technology. From the outside, it can look like a glorified meeting organiser — someone who sends status reports, runs stand-ups, and updates a project plan. From the inside, it looks completely different: a high-stakes balancing act between technology, people, process, politics, and time, with very little margin for error and a great deal riding on every decision.
This article is for anyone trying to understand what an ERP PM actually does day to day — whether you're considering the role, hiring for it, or working alongside one and wondering why they always look mildly stressed.
First, What Is an ERP Implementation?
To understand what an ERP PM does, you need to understand what they're managing. An ERP — Enterprise Resource Planning — system is the software backbone of a business. It handles finance, procurement, inventory, manufacturing, HR, payroll, sales, and more, often replacing dozens of older systems and spreadsheets with a single integrated platform.
Implementing an ERP is not like installing software. It is a fundamental change to how a business operates. Processes get redesigned. Data gets migrated. Roles change. People have to learn new ways of working. And all of this happens while the business continues to trade, serve customers, and pay its staff. The ERP Project Manager is the person responsible for making that transition happen — on time, within budget, and without breaking anything critical along the way.
The Core Responsibilities
The ERP PM's role spans the full implementation lifecycle, from initial planning through to go-live and post-go-live stabilisation. Here is what that actually looks like in practice.
Programme planning and governance. Before a single line of code is configured, the ERP PM is responsible for defining how the programme will be structured and run. This means establishing the governance framework — who makes decisions, how issues are escalated, what the reporting cadence looks like, and how scope changes are managed. A well-governed programme with a mediocre system will outperform a poorly governed programme with an excellent system. Almost every time.
Workstream management. Large ERP implementations are not a single project — they are a collection of parallel workstreams. Finance. Supply chain. HR. Data migration. Integration. Change management. Testing. Each workstream has its own lead, its own timeline, and its own dependencies on every other workstream. The ERP PM holds these threads together, identifies where they conflict, and makes sure that progress in one area doesn't create problems in another.
Stakeholder management. This is where a significant proportion of an ERP PM's time and energy goes — and where the role is most frequently underestimated. An ERP implementation touches every part of a business. The CFO cares about the finance module. The warehouse manager cares about inventory. The HR director cares about payroll. The board cares about the budget and the go-live date. The ERP PM has to manage all of these relationships simultaneously, often with competing priorities and very different levels of technical understanding.
Vendor and implementation partner management. Most ERP implementations involve at least one Systems Integrator (SI) — a consulting firm responsible for configuring and deploying the software. The ERP PM is the primary interface between the client organisation and the SI. This means reviewing deliverables, challenging estimates, managing the SI's resourcing, holding them to contractual commitments, and navigating the inevitable moments when what was promised and what is being delivered start to diverge.
Risk and issue management. An ERP implementation without risks is not an ERP implementation — it is a fantasy. The ERP PM is responsible for identifying risks early, assessing their likelihood and impact, and putting mitigation plans in place before they become problems. When issues do arise — and they will — the PM is responsible for owning the response: communicating clearly, mobilising the right people, and making decisions quickly under pressure.
Budget management. ERP programmes are expensive. Budgets typically run from hundreds of thousands to tens of millions of pounds depending on the size and complexity of the organisation. The ERP PM is responsible for tracking spend against budget, forecasting the cost to complete, identifying where budget is being consumed faster than planned, and flagging financial risks to the steering committee before they become crises.
Data migration oversight. Data migration is consistently one of the most underestimated and most problematic aspects of any ERP implementation. Moving data from legacy systems into a new ERP involves extraction, cleansing, transformation, and validation — a process that is technically complex, highly dependent on business input, and brutally unforgiving of shortcuts. The ERP PM doesn't do this work personally, but they own the timeline, the quality gates, and the go/no-go decision at cut-over.
Change management and user adoption. Deploying an ERP system is the easy part. Getting people to use it correctly — and to actually change the way they work — is the hard part. The ERP PM works closely with the change management lead to ensure that training is planned and delivered, that communication reaches the right people at the right time, and that resistance is identified and addressed before go-live rather than after.
Testing management. Before any ERP system goes live, it has to be tested — thoroughly. System integration testing, user acceptance testing, performance testing, regression testing. The ERP PM owns the testing schedule, manages the defect resolution process, and makes the critical judgement call on whether the system is ready to go live or whether a delay is the lesser of two evils.
Go-live and cutover management. The go-live is the culmination of months or years of work — and it is one of the most intense periods in the entire programme. The ERP PM owns the cutover plan: the precise sequence of activities required to switch from the old system to the new one, typically executed over a compressed weekend or holiday period with no margin for error. Once the switch is flipped, there is no easy way back.
What a Typical Week Actually Looks Like
There is no typical week in ERP project management, but here is a rough sketch of where the time goes during a live implementation phase.
Monday: Weekly workstream leads meeting. Review progress against plan across all streams. Identify blockers and agree actions. Update the programme dashboard for the steering committee.
Tuesday: SI governance meeting. Challenge the SI on two deliverables that are running late. Agree a revised schedule. Call with the finance workstream lead about a configuration decision that's creating a downstream issue in the reporting workstream.
Wednesday: Steering committee preparation. Draft the programme status report. Three RAG statuses that were green last week are now amber. Prepare the narrative, the options, and the recommended actions. One conversation with the CFO before the committee meets to make sure there are no surprises in the room.
Thursday: Steering committee. Present programme status. One difficult conversation about a scope change request from a business unit director that will cost six weeks and £80,000. Decision is deferred. Budget review with the finance team.
Friday: Data migration review. The latest mock migration has a 4% failure rate on customer records. Work through root cause with the data team. Testing update — UAT is running two weeks behind. Agree a recovery plan. End the week updating the risk register and sending the weekly summary to key stakeholders.
And somewhere in all of that: emails, escalations, an urgent call about a critical integration that's failing in the test environment, and a conversation with an SI consultant who is flagging that a key resource is being pulled off the programme next month.
How the Role Varies by Project Scale
One of the most important things to understand about the ERP PM role is that it is not a fixed thing. The job description looks significantly different depending on the size and complexity of the programme — and conflating the two is one of the most common hiring mistakes organisations make.
On smaller implementations — a single-site NetSuite rollout for a 200-person business, for example, or a mid-market Dynamics 365 deployment — the ERP PM is often a much more hands-on role. There may be no dedicated business analyst team, no separate change management lead, and no distinct testing manager. The PM picks up these responsibilities themselves. That means running workshops directly with business users, documenting process requirements, overseeing configuration decisions, and in many cases, personally delivering end-user training. The governance overhead is lighter, but the breadth of the individual contribution is significantly wider.
On larger programmes — a multi-site SAP S/4HANA greenfield for a 5,000-person manufacturer, or a global Oracle Fusion rollout — the picture is entirely different. Here the PM is leading a team of workstream leads, business analysts, change managers, data migration specialists, and test managers. The business analysts are doing the process redesign work. The change management lead owns the training and communication strategy. The PM's job is primarily one of governance, coordination, escalation management, and executive communication. Getting into the detail of individual workstreams is a sign that something has gone wrong, not a sign of good leadership.
This distinction matters enormously for hiring. A highly capable ERP PM who has spent their career on enterprise-scale programmes may struggle with the hands-on breadth required on a smaller project — and may find it frustrating. Equally, an ERP PM whose experience is primarily on smaller, leaner implementations may be genuinely unprepared for the political complexity, the stakeholder volume, and the governance rigour that a large programme demands.
Neither profile is better or worse. They are simply different. The right question to ask — in the job description, in the interview, and in the reference check — is not just "have you run ERP projects?" but "have you run projects at this scale, in this kind of team structure, with this level of stakeholder complexity?"
Platform Experience vs ERP Delivery Experience
A related question that often comes up in hiring — and is frequently answered too rigidly — is how much weight to give to experience on a specific ERP platform.
The honest answer is: it depends on the role. For some implementations, particularly those involving deep technical complexity, heavy customisation, or a platform the organisation has never used before, familiarity with that specific system is genuinely valuable. An SAP S/4HANA PM who has navigated the nuances of Activate methodology, knows what to push back on during fit-to-standard workshops, and understands the commercials of an SAP engagement is operating with a meaningful advantage over someone new to that ecosystem.
But many ERP project managers — and many ERP projects — are more platform-agnostic than this framing suggests. The core competencies of ERP delivery: governing a complex programme, managing a steering committee, driving data migration quality, holding an SI to account, and getting an organisation through the cultural upheaval of go-live — these are transferable skills. A PM who has delivered three full-cycle ERP implementations on different platforms brings something arguably more valuable than deep expertise on a single system: genuine perspective on what implementation success actually requires, independent of the software vendor's methodology or marketing.
For organisations mid-selection, or those replacing one system with another, a platform-agnostic PM can also be a deliberate strategic choice — someone whose loyalty is to the delivery outcome, not to a particular vendor's way of doing things.
The practical implication for hiring managers: before making platform experience a hard filter, ask whether what you actually need is someone who knows your chosen system, or someone who knows how to deliver programmes like yours. The answer will shape your candidate pool significantly — and may open it up in useful ways.
What It Is Not
It's worth being direct about what the ERP PM role is not, because the misconceptions are common and consequential.
It is not always a purely oversight role. On large programmes, the ERP PM operates primarily at the governance level — coordinating workstream leads, managing the steering committee, and escalating issues. But on smaller implementations, the same job title may involve personally running process workshops, configuring the system, and delivering user training. Both are legitimate — but they are very different jobs, and assuming the role looks the same regardless of scale is a mistake.
It is not a technical role — at least not primarily. The ERP PM does not configure the system or write integrations. They need enough technical literacy to have credible conversations with technical teams and to sense-check what they're being told — but their job is to manage the delivery, not to do the technical work themselves. On smaller projects this line blurs; on larger ones it is firm.
It is not a purely administrative role. The ERP PM is not a meeting scheduler or a document manager. The best ERP PMs are decision-makers, problem-solvers, and leaders. They need to be able to tell a CFO uncomfortable truths, challenge an SI partner on their delivery, and make fast judgement calls in a crisis.
It is not project management in the conventional sense. A software development PM, a construction PM, a marketing campaign PM — these are all very different roles from an ERP PM. The scale, the complexity, the organisational change dimension, and the risk profile are in a different category. Someone who has managed a series of smaller technology projects but has never led a full ERP implementation is not an ERP PM. They may become one, but they are not one yet.
The Skills That Actually Matter
Holding a room. An ERP PM regularly sits in rooms with CFOs, COOs, and board members. They need to be able to present difficult news calmly, answer tough questions confidently, and maintain credibility under pressure. This is not about charisma — it is about preparation, clarity, and the courage to say what needs to be said.
Reading the organisation. Every business has its own politics, its own power structures, its own informal decision-making hierarchies. The ERP PM needs to understand these quickly and navigate them effectively. An executive who appears supportive in the steering committee but is quietly blocking progress in their business unit is a real phenomenon. Spotting it early is a skill.
Knowing what to escalate and when. Not every problem needs to go to the steering committee. Not every risk needs to be in the board report. But some issues — left unescalated — become disasters. The ERP PM's judgement about what to surface, when, and to whom is one of the most important things they do.
Managing ambiguity. ERP implementations rarely go exactly to plan. Scope evolves. Requirements that seemed clear in the design phase turn out to be more complex in build. A key stakeholder leaves the business. The ERP PM has to keep the programme moving through uncertainty without either over-reacting to every change or ignoring signals that something significant has shifted.
Making the call. At critical moments — go/no-go for UAT, go/no-go for go-live, whether to accept a scope change, whether to escalate a vendor issue — someone has to make a decision. The ERP PM is frequently that person, or the person who frames the decision clearly enough that the steering committee can make it quickly. Indecision at these moments is its own form of failure.
How the Role Has Changed in 2026
The ERP PM role has evolved significantly in the past few years, driven by three forces: the shift to cloud-native platforms, the introduction of AI into ERP systems, and the compression of implementation timelines.
Cloud ERP implementations have changed the nature of the technical work — less infrastructure, more configuration and integration management — but they have also raised the stakes around vendor governance. When your ERP is a SaaS platform, the vendor's release schedule, their update cadence, and their SLA performance become critical programme dependencies that the PM has to track and manage.
AI is increasingly embedded in ERP platforms — in the tooling, in the reporting, in the user experience. ERP PMs who understand what this means for configuration decisions, user adoption, and change management are materially more effective than those who treat AI as someone else's problem.
Compressed timelines mean that the ERP PM is often managing more workstreams simultaneously, with less time between key milestones, and with a leaner team. The days of the 36-month ERP programme with a cast of hundreds are not over, but they are increasingly the exception rather than the rule.
Is It a Good Career?
For the right person, ERP project management is one of the most rewarding careers in enterprise technology. The work is genuinely consequential — a successful ERP implementation can transform how a business operates. The skills are transferable, highly valued, and well compensated. And the variety is real: no two programmes are the same, no two organisations are the same, and no two go-lives feel quite the same.
It is also genuinely demanding. The pressure during key programme phases is significant. The accountability is real. And the hours during cut-over are not for the faint-hearted.
The people who thrive in this role tend to share a few traits: they are calm under pressure without being complacent, organised without being rigid, and decisive without being reckless. They understand technology without being defined by it. And they genuinely enjoy the challenge of making complex things happen in complicated organisations.
If that sounds like you — or like the person you're trying to hire — you're in the right place.