ERP Implementation With a PMO: How to Govern the Project

The ERP contract is signed, the integrator has a work plan and the vendor has a schedule. One question remains that no vendor document answers: who, on the company's side, is accountable for the project delivering what the committee approved in scope, time and cost.

This guide explains what a PMO does in an ERP implementation, which areas project governance must cover according to a vendor's public guide, who decides what, what tends to be cut first when the budget tightens, how the PMO's work is measured and what leadership must decide before signing.

What does a PMO do in an ERP implementation?

It governs the project. Microsoft's Dynamics 365 implementation guide defines project governance as the framework and techniques that help you map business goals to actions and measures, structure and plan the project, anticipate and avoid issues, detect and correct risks, and respond to change. In practice, that is the job of an external PMO on an ERP project.

The same guide stresses something worth bringing to the committee: an ERP project is not only a technical project, it is a business transformation project that affects, and is affected by, the processes and the people in the business. That is why governance must involve the business and not stay inside the IT team.

In our view, the practical difference is this: the integrator is accountable for delivering and configuring the system; the PMO is accountable to leadership for the project as a whole moving toward the approved goals, with a single place where risks, scope changes and pending decisions are recorded.

Which areas must ERP project governance cover?

Microsoft's guide lists six areas of governance that, according to the document itself, are relevant to any implementation methodology. Although it is written for Microsoft products, it works as a public checklist to review any ERP project:

Project goals: clear, measurable goals that give direction and focus, aligned with business objectives.

Project organization: the structure and roles that make the project efficient and effective.

Project approach: the methodology that fits the scope, complexity and constraints.

Classic structures: change, risk and issue management, and how effective they are.

Key project areas: solution design, testing and deployment, which the guide says often get technical attention but lack sufficient direction, planning and oversight.

Project plan: a well-structured plan that lets you track and improve progress and outcomes.

The guide recommends defining the governance model as early as possible, preferably in the initiate phase, because it determines the approach, oversight, resources and plan, and reviewing it throughout the project.

Who is accountable for your ERP project?

We act as an external PMO: planning of resources, roles, timelines, costs and scope, steering committee approval and execution follow-up with executive, operational and technical stakeholders.

• Project governance defined before signing
• Roles and scope detailed between the company and the integrator

Explore PMO and project management consulting

Who decides what: steering committee and implementation team?

Microsoft groups roles into two structures. The steering committee is a group of senior stakeholders with the authority to keep the project team aligned with the KPIs: as they monitor progress, they can make decisions that affect the overall strategy, including budget, costs and expected functionality. It usually consists of senior management and the leaders of the business groups included in the rollout.

The core implementation team does the actual execution. According to the guide, it includes project managers, business subject matter experts, solution architects, functional and technical consultants, developers, testers, trainers, adoption and change management advisors and user champions. The guide warns that the lack of availability of any of these roles may cause delays, an incomplete understanding of the processes and poor user adoption.

When there is an outside integrator, the guide asks that the statement of work (SoW) not stop at high-level activities: it should detail activities, assumptions, roles and responsibilities, and what is out of scope. It describes the risk this way: the customer assumes the integrator will handle an activity while the integrator assumes the customer will. The activities it lists include process modeling, data migration, integration with other systems, test strategy and execution, orchestration of user acceptance tests, security and role design, cutover planning and execution, and adoption and change management.

What gets cut first when the budget tightens?

Microsoft's implementation strategy guide says it plainly: as scope and timelines change, activities toward the end of the lifecycle are often cut to meet budget constraints, and it names performance testing, data validation testing, training and change management. It adds that this can significantly affect the quality and success of the implementation.

That is a concrete reason to have a PMO: someone with a mandate from the committee to defend those activities when the schedule tightens, or to document what was decided to cut and who approved it. To understand what else is worth budgeting, see how much it costs to implement an ERP and the costs that tend to fall outside the proposal.

How is the PMO's work measured?

Microsoft's guide asks you to agree, from the start, on concrete indicators of project success and use them to prioritize scope. It also asks for constant assessment of the variance between budget and actual cost throughout the project lifecycle.

Based on that, in our view leadership can ask the PMO for a short, stable dashboard with these items:

Milestones met against the approved plan, and deviations with their cause.

Variance between budget and actual cost, with the projection at completion.

Open risks, each with an owner, a date and an action.

Requested, decided scope changes and their effect on timeline and cost.

Availability of the process owners and user champions the plan assumed.

Status of the closing activities that tend to be cut: testing, data validation, training and change management.

Choose well before you implement

If you have not chosen the ERP yet, independent software selection organizes requirements, proposals and total cost before the project is committed.

• Comparable requirements and proposals
• Total cost over several years, not just the license

See independent ERP selection

What must leadership decide before signing?

Who chairs project governance and who sits on the steering committee. That the contract with the integrator details activities, assumptions and roles. What budget and timeline are protected for the end-of-project activities. Which indicators will measure success. And which methodology fits the company's culture: Microsoft's guide notes that organizations used to a traditional approach, such as waterfall, may need more change management planning to adopt an agile or hybrid one.

If you have not chosen the ERP yet, settle that decision first: the guide to the best ERP for mid-sized companies sorts the options, and the total cost calculator helps estimate the budget over several years.

How we can help

At Cyrrus we manage technology projects, including ERP, CRM and HCM, as an external PMO under PMBOK guidelines: planning of resources, roles, timelines, costs and scope; steering committee approval; execution follow-up with executive, operational and technical stakeholders; and continuous risk monitoring. If you first need to choose the solution, our independent ERP selection covers requirements, proposals and total cost.

To go deeper on related topics: what a PMO is, its functions and when you need one, and when to hire an external PMO.