The Change Management Reality When Integrating Project Portfolio Management and ERP

TL;DR

Most integrations between Project Portfolio Management platforms and ERP systems fail due to adoption, not technology. The API works. The data flows. And then nothing changes because the people who were supposed to change how they work have not been given a compelling reason to do so. This post covers the change management work that determines whether a Project Portfolio Management and ERP integration actually delivers its intended value, and why it is consistently underestimated, underfunded, and started too late.

Consider the scenario when the technical implementation went well. The project team was experienced. The integration connected the Project Portfolio Management platform to the ERP on schedule. Purchase order commitments flowed through. Invoice status updated in real time. The reconciliation engine matched transactions automatically. The go-live was declared a success.

Six months later, the finance team was still running their monthly reconciliation in spreadsheets. The project managers were still pulling budget reports from their old tracking files. The ERP team had added the new integration to their support queue and largely forgotten it existed. The dashboards showing real-time commitment data had been viewed by four people in the last ninety days.

The technical integration had not failed. The behavioral integration had never started.

This is the most common outcome of Project Portfolio Management and ERP integration programs. The technology delivers exactly what it was designed to deliver. The people it was designed for continue doing what they have always done. The integration produces data that nobody acts on, and within twelve months the organization is evaluating whether the investment was worth it.

The answer to that question is almost always no. Not because the technology failed. Because the change management program that should have accompanied it was either absent, underfunded, or started six months too late.

“The biggest challenge in digital transformation is not technology—it’s organizational change”

George Westerman

 

Key Takeaways

• Most Project Portfolio Management and ERP integrations fail in adoption, not in technology. The API works. The data flows. And then nothing changes because the behavioral integration was never properly designed or resourced.
• Project Portfolio Management and ERP integration is a harder change than most because it crosses organizational boundaries, changes who owns what in ways that feel like a loss to someone, and creates an asymmetry where executives benefit most but project managers and analysts bear the most change burden.
• The five most common implementation plan assumptions that produce adoption failure are: training at go-live is sufficient, executive sponsorship is a one-time endorsement, resistance is a communication problem, shared data produces natural alignment, and change management is a phase that starts after technical delivery.
• The three resistance types, territorial finance team resistance, workload project manager resistance, and technical sovereignty IT team resistance, each require a different response. Treating them as a single problem produces interventions that work for one group and inflame another.
• The most effective integrations run technology delivery and change management as a single program with parallel milestones, where every technical milestone has a corresponding change management milestone that must be met before the technical milestone is declared complete.
• The single greatest determinant of whether an integration sticks is whether the old workarounds are decommissioned at go-live. Keeping parallel processes running as a backup is not risk management. It is adoption prevention.

Why Project Portfolio Management and ERP Integration Is a Harder Change than Most

Every technology implementation requires some degree of change management. But the integration of a Project Portfolio Management platform with an ERP is harder than most, for three reasons that are specific to this kind of integration.

1. It crosses organizational boundaries in ways that other implementations do not.

A new ERP module affects the finance team. A new project management tool affects the project team. Integrating the two affects both teams simultaneously, introduces new data flows that neither team fully controls, and creates shared accountability for outcomes that were previously managed in separate silos. Boundary-crossing change is harder to govern and harder to sustain.

2. It changes who owns what in ways that feel like a loss to someone.

When commitment tracking moves from an ERP-only process to a shared process visible in the project management tool, the finance team loses exclusive ownership of financial data. When project managers gain real-time payment visibility, they gain accountability for financial outcomes they could previously attribute to system limitations. Both of these feel threatening to the people experiencing them, even when they represent genuine improvements for the organization.

3. The benefits are not immediate for the people doing the most work.

The people who benefit most from real-time project financial visibility are portfolio executives and CFOs. The people who bear the most behavioral change burden are project managers and financial analysts who must adopt new processes, learn new tools, and give up workarounds they have spent years perfecting. This asymmetry between who benefits and who changes is the root cause of most adoption failures.

Project financial management solutions that reduce complexity rather than add to it.

That principle applies directly to change management design. Every new process, every new data entry requirement, and every new approval step added to the integration increases the change burden on the people who were not asking for the integration in the first place. Change management that reduces the net complexity of daily work for both project and finance teams is the only kind that sticks.

What Most Implementation Plans Get Wrong About Change Management

The gap between what implementation plans assume and what actually happens is consistent enough to be predictable. Here is what it looks like across most organizations.

What most implementation plans assume	What actually happens
Training at go-live is sufficient. Users will adopt once they know how to use the system.	Training at go-live teaches button clicks, not behavioral change. Users revert to old habits within weeks unless the new process delivers a clear daily benefit over the old one.
Executive sponsorship means the CEO sent an email endorsing the project.	Executive sponsorship means senior leaders actively reinforce new behaviors, reference new data in decisions, and hold their teams accountable for using the new system. Visible, repeated, behavioral sponsorship.
Resistance is a communication problem. Once people understand the benefits, they will adopt.	Resistance is usually a rational response to a real cost. The people resisting have something to lose: ownership, simplicity, autonomy, or job security. Addressing the communication without addressing the underlying cost does not resolve the resistance.
The project team and finance team will align naturally once they share data.	Shared data surfaces disagreements that previously went unnoticed. The first months after go-live often produce more conflict between project and finance teams, not less, because they can now see each other’s assumptions clearly for the first time.
Change management is a phase that starts after the technical build is complete.	Change management that starts at go-live is already six months too late. Stakeholder analysis, resistance identification, and early adopter engagement must begin at project initiation, before a single line of integration code is written.

The Three Types of Resistance You Will Encounter and What to Do About Each

Resistance to Project Portfolio Management and ERP integration is not monolithic. It comes from different places, for different reasons, and requires different responses. Treating all resistance as a single problem produces interventions that work for one group and inflame another.

1. The Finance Team’s Territorial Resistance

The finance team will often say, “We already have all of this in the ERP. Why duplicate it in another system?” On the surface, it sounds like an efficiency concern. But what they are really worried about is losing control. They do not want financial data fragmented across tools, approval authority diluted, or accountability pushed onto them for data they do not fully govern. The way forward is not to push harder. It is to involve them earlier. Give finance governance authority over integration rules, system-of-record decisions, and data quality standards. When they become architects of the shared financial process instead of passive recipients, resistance drops significantly.

2. The Project Manager’s Workload Resistance

Project managers will say, “This is just another system I have to update.” And they are not wrong. Every new data entry point adds friction to their day. Many have seen tools launched with excitement and then quietly fade away. Their skepticism comes from experience. What changes the conversation is proof using their own project data. Show them how the new system reduces reconciliation calls, prevents late payment surprises, and provides visibility into committed spend they previously lacked. When the benefit feels personal and directly connected to their daily challenges, adoption becomes practical rather than forced.

3. The IT Team’s Technical Sovereignty Resistance

IT teams often say, “This integration will create a maintenance burden we cannot support long term.” This is not an obstruction but an operational reality. They are thinking about the late-night failure at the end of the month that they will be responsible for fixing, especially if they did not design or fully document the integration. The solution is partnership. Involve IT in architecture decisions from the beginning. Give them ownership of monitoring standards and exception handling processes. Build the integration to meet their support requirements, not just the implementation deadline. Their buy-in determines whether the solution lasts.

Running Technology and Change Management as a Single Program

The most effective integrations run technology delivery and change management as a single program with parallel milestones, not as sequential phases where change management starts after the technical build is complete.

The principle is straightforward: every technical milestone should have a corresponding change management milestone that must be met before the technical milestone is declared complete. A working API is not a go-live milestone. A working API with trained users, documented processes, and confirmed adoption in a pilot group is a go-live milestone.

Phase	Technology Milestone	Change Management Milestone	Success Indicator
Discovery	Systems audit: identify data flows, integration points, and technical gaps between platforms	Stakeholder analysis: map who is affected, what they stand to gain and lose, and where resistance is likely to concentrate	Stakeholder map completed. Resistance hotspots identified. Executive sponsor briefed on change risk profile.
Design	Integration architecture defined. System of record designations agreed. Data mapping completed.	Process redesign workshops with project and finance teams. New role responsibilities documented. Change story developed and tested with early skeptics.	Both teams have contributed to and signed off on the new process design. Early adopters identified.
Build	Integration built and tested in development environment. Data quality rules configured.	Early adopter group established and briefed. Training materials developed with real organizational data. Resistance response playbook prepared.	Early adopters can use the system confidently. Training materials reflect actual workflows, not generic scenarios.
Pilot	Integration lives in pilot environment with selected projects. Performance monitored.	Early adopter feedback collected and acted on. Quick wins documented and communicated. Resistance from pilot group addressed individually.	Pilot users report net reduction in administrative workload. At least one concrete financial outcome attributable to the new visibility is documented and shared.
Go-Live	Full rollout to all projects. Monitoring and exception handling active.	Executive communications reference new system data. Old workarounds formally decommissioned. 30-day adoption check scheduled.	Old spreadsheet reconciliations discontinued. Finance and project teams using shared data in governance meetings.
Sustain	Integration performance monitored. Exception volumes tracked. Enhancement backlog managed.	90-day adoption review. Reinforcement actions for teams not meeting adoption targets. Success stories documented for organization-wide sharing.	Reconciliation effort reduced measurably from baseline. Financial visibility gap closures documented and reported to executive sponsor.

The One Thing That Determines Whether the Integration Sticks

If there is one determinant of whether a Project Portfolio Management and ERP integration delivers its intended value, it is this: whether the old workarounds are decommissioned at go-live.

This sounds obvious. It is almost never done.

When a new integrated system goes live and the old spreadsheet reconciliation process is kept as a “backup” or a “transition measure,” two things happen. First, users continue using the old process because it is familiar and they do not trust the new one yet. Second, the existence of the parallel process signals that the organization does not fully believe in the new system either. Both effects compound.

Within three months, the new system is used for reporting and the old process is used for actual decisions. Within six months, the new system is updated less frequently because its data does not match the old process anyway. Within twelve months, the integration is described as having “data quality issues” and a remediation project is scoped.

The data quality issue is not a data quality issue. It is an adoption issue that was baked in at go-live when the organization tried to run both processes simultaneously.

Decommissioning old workarounds at go-live is an act of organizational commitment, not an act of technical confidence. It tells users that the new system is not optional. It forces the investment in making the new system work for daily use rather than just for monthly reporting. It is the hardest change management action to take and the one that most determines whether the integration investment returns its value.

The Parallel Process Trap

Keeping old spreadsheet reconciliations as a backup is not risk management. It is adoption prevention. Every day the old process exists alongside the new one, the incentive to invest in making the new process work is reduced. Set a firm decommissioning date at the start of the program, communicate it clearly, and hold to it. The discomfort of the transition period is shorter and less expensive than the slow drift back to the old state.