How an ERP Project Manager Keeps Large-Scale Programs on Track

An ERP Project Manager: The Conductor Behind ERP Delivery

Tanya Last describes the ERP project manager as the conductor of an orchestra. The role is not about doing every task personally or being the deepest technical specialist in the room. It is about knowing what good looks like, understanding who needs to do what and when, and keeping the whole programme moving in the right direction.

For Tanya, that role starts much earlier than many organisations assume. It begins at the point where the organisation decides a finance, HR, procurement, or other core system needs replacing. That is when someone needs to challenge assumptions, shape the plan, assess whether the team has the right skills, and help steer procurement and partner selection properly.

She also makes it clear that the role should not stop at go-live. In her view, project managers who leave immediately after launch take important delivery knowledge with them at exactly the moment the organisation still needs it. The ERP project manager should stay close through stabilisation until:

• Post-go-live issues are being resolved
• Business-as-usual teams are comfortable
• Managed services are operating properly
• The target operating model is stable

Why ERP Programmes Really Drift

Tanya’s view of ERP failure is more nuanced than a simple on-time versus late judgment. She explains that different organisations define failure differently. One programme may be considered a success if it goes live safely, on time, on budget, and with training complete. Another may be judged much more harshly if stakeholders feel there was not enough consultation or engagement, even if the technical outcome was strong.

She also pushes back on the idea that extending timelines always means failure. In practice, once design begins, organisations often discover more complexity than expected, especially around:

• Data migration
• Integrations
• Process variation
• Stakeholder expectations
• Scope versus what the product can realistically support

At that point, the project manager needs to lead pragmatic conversations. Tanya’s point is clear: adding time is sometimes the responsible choice if it improves quality and supports a safer go-live.

When asked whether programmes usually derail because of technology or because of how they are run, Tanya leans strongly towards the latter. In her experience, ERP is difficult because organisations are trying to adapt an off-the-shelf platform to their own reality while managing stress, pressure, and competing stakeholder needs. Drift starts when decisions are delayed, when design becomes overly convoluted, or when leaders are not prepared to choose between options quickly enough.

How ERP Project Managers Keep a Large Programme on Track

When a programme starts to feel loose, Tanya looks first for ambiguity. Her instinct is to tighten the basics quickly. That means bringing clarity to:

• Who is responsible for what
• What is happening and when
• How concerns should be escalated
• Which documents, meetings, and actions belong to whom
• What are the expected timelines for decisions and follow-up

For Tanya, governance is not there for show. It is the framework that allows teams to spot issues early, package them properly, escalate them to the right people, and get them resolved fast. Once that structure is in place, the project manager can focus attention where it is needed most and move the programme forward with confidence.

After go-live, success is not just about the system being switched on. Tanya looks for signs that the ERP Software has genuinely landed, including:

• Smooth issue resolution after launch
• Confident business-as-usual ownership
• A stable managed service
• A working target operating model
• Users adapting to the new system in practice, not just in theory

Why Change Management Has to Start Early

One of Tanya’s strongest practical points is that change management should start as early as possible. She has seen too many programmes bring change managers in too late, expecting them to “sort out training and comms” near go-live. By then, they are already behind.

In the strongest programmes she has worked on, change managers were embedded before or at the very start of mobilisation. That gave them time to:

• Understand the wider organisation
• Identify key stakeholders
• Assess change impacts
• Compare current and future processes
• Build business change champion networks
• Prepare comms, training, and engagement properly

Tanya links this directly to post-go-live success. Where strong business change champions were in place, they helped calm anxieties, reinforce training, and continue carrying the message after the project team had stepped back.

A Real-World Test: Managing Complexity in Local Government

Tanya’s local government case study brings the discussion to life. Reflecting on the Royal Borough of Kensington and Chelsea programme, she highlights three sources of complexity:

• Moving away from a shared service environment
• Operating to strict deadlines and a burning platform
• Managing multiple stakeholders across more than one borough

In that environment, the disciplines that mattered most were not exotic. They were the fundamentals, applied well:

• Strong governance
• Multiple governance bodies
• Clear sponsor support
• Senior leadership backing
• Quick escalation and decision-making when issues emerge

Tanya is especially clear that project managers are not magicians. They can identify the path back to green, but they cannot make that happen alone. For a programme to stay on track, the project manager needs the right support around them and leaders who will act when problems are escalated.

On go-live readiness, Tanya describes a robust approach built around readiness criteria, gateways, regular temperature checks, dry runs, and a detailed cutover plan. She argues that no programme is ever perfectly ready. The key question is whether the solution is safe, the organisation is ready, and the concerns that matter have been heard and resolved.

After launch, Tanya and the change team stayed close for a period of post-go-live support. That allowed the organisation to ask questions as people started using the system “in anger”, while the managed service and target operating model were mobilised properly.

Tanya’s Practical Advice for ERP Project Managers

When asked to distil the role down to a few priorities, Tanya highlights three areas:

1. Keep the plan moving and monitor it closely
2. Pay attention to the mood and pressure levels across the team
3. Make sure the system integrator is delivering to the expected quality standard

For anyone stepping into the role for the first time, her advice is practical:

• Work alongside someone experienced, if you can
• Reuse proven templates rather than creating everything from scratch
• Stay close to the detail, even when it feels daunting
• Ask questions and learn the shorthand
• Do not bypass governance just because the programme is under pressure
• Escalate slippage early rather than hiding it

Her wider message is that good ERP project management is not about looking busy. It is about creating enough structure, visibility, and control that a complex implementation can move safely from mobilisation to stabilisation.