A company decides to implement a new ERP system. The budget gets approved, the vendor gets selected, and the kickoff meeting happens. Then someone asks the question that often doesn’t get a clear answer: who is running this day to day?

The instinctive response is usually to hand it to the controller, the VP of Finance, or an IT manager who already has a full-time job. That decision, made almost by default, is one of the most common reasons ERP and systems transformation projects lose momentum after the excitement of kickoff fades.

The Resourcing Problem Most Companies Underestimate

Internal subject matter experts are asked to contribute to design workshops, review integrations, and test workflows, all while continuing to perform their day jobs. According to Panorama Consulting Group’s research on ERP project resourcing, this creates a hidden form of operational and technical debt, because the knowledge required to configure, test, and validate a system sits within the business rather than with the vendor.

The same research identifies overloaded internal subject matter experts, insufficient testing capacity, and a lack of ownership for cross-functional decisions as some of the most common staffing issues in ERP projects. The consequences do not show up immediately. They show up after go-live, when a workflow that “technically works” breaks down in real-world use because no one had the bandwidth to catch the gap during testing.

To address this, Panorama recommends organizations allocate 30 to 50% of select internal team members’ time for the duration of an implementation, with full-time dedication required for the most involved roles. For most mid-sized organizations, that level of dedicated internal capacity simply does not exist without a plan to backfill operational duties, and few companies build that backfill plan before the project starts.

Interim Technology Leadership Solves a Different Problem Than Staffing

There is a distinction worth drawing out here. The resourcing problem above is about internal subject matter experts having enough time. Interim technology leadership addresses a related but separate problem: who is accountable for the project as a whole.

A project of any complexity needs someone whose job is to run it, not someone doing it in addition to their existing responsibilities. That person needs to understand both the technology and the business context well enough to push back on vendor recommendations, make sequencing decisions, and keep cross-functional stakeholders aligned.

Alliance’s own guidance on this question notes that interim leadership tends to be the right model when a transformation is underway and the organization needs leadership with deep implementation experience for a defined period, particularly when a permanent search would take too long relative to the project timeline.

This is different from simply adding headcount. An interim CIO, CTO, or technology project lead brings pattern recognition from having navigated similar implementations before. That experience is difficult to build quickly inside an organization that has never run a project like this one.

Signs the Project Needs Dedicated Leadership

A few signals tend to show up before a systems project visibly derails:

No one can answer who owns a given decision

If a question about process design, data mapping, or vendor scope gets bounced between three people without a clear answer, that is a symptom of missing project ownership, not a communication problem to be solved with more meetings.

Internal staff are attending workshops but not reviewing deliverables

Attendance is not the same as engagement. If subject matter experts are too stretched to genuinely vet what the implementation partner is proposing, the vendor’s recommendations become the default, whether or not they fit the business.

The project timeline keeps slipping no explanation

Small delays compound. A project without a dedicated leader accumulates these delays because no one has the full picture or the authority to make tradeoff decisions quickly.

When Internal Ownership Is Actually the Right Call

Dedicated technology leadership is not automatically the answer for every systems project. A smaller-scope implementation, a single-module upgrade, or an organization with genuine internal capacity and prior implementation experience may not need outside leadership at all.

The more useful question is not “do we need to bring someone in” but “does the person we are currently relying on have the bandwidth, the authority, and the relevant experience to do this well.” If the honest answer to any of those three is no, that gap tends to surface as a resourcing crisis three months into the project rather than a planning conversation before it starts.

The Real Cost of Getting This Wrong

The financial exposure from under-resourced systems projects rarely shows up as a single line item. It shows up as emergency remediation after go-live, additional vendor support that wasn’t budgeted, and rework that dwarfs whatever was saved by not bringing in dedicated leadership in the first place. It also shows up in talent retention, as internal staff who were stretched thin during the project often disengage once it is over, taking system knowledge with them right when stability matters most.

Getting the ownership question right before the project starts is considerably less expensive than solving it after the fact.

Alliance places interim and fractional technology leaders who have navigated ERP implementations, system integrations, and digital transformations before, working alongside internal teams rather than replacing them.

Key Takeaway: ERP and systems projects rarely fail because of the technology itself. They stall because no one with the right experience, authority, and bandwidth is clearly accountable for running the project day to day. Deciding whether that role should be filled on an interim basis is a planning question worth answering before kickoff, not three months into the implementation.

Weighing whether your systems project needs dedicated leadership? Talk with our Human Capital Solutions team about what the role requires.

Frequently Asked Questions About Who Should Lead Your ERP Project

Implementing a new ERP system is only the beginning. Using and optimizing the ERP system is just as important. Here are some commonly asked questions about who should lead your ERP project.

Does an ERP implementation need a dedicated project leader?

Most implementations of meaningful scope benefit from having one person clearly accountable for the project day to day. Without that role filled, decisions default to whoever is available in the moment, which is rarely the person best positioned to make them, and accountability for the outcome becomes difficult to pin down when something goes wrong.

What’s the difference between interim technology leadership and hiring a permanent CIO?

Interim leadership is typically brought in for a defined period tied to a specific transformation, with deep implementation experience that a permanent hire may not need once the project stabilizes. A permanent CIO or CTO role is built around the organization’s ongoing technology needs rather than a single project’s lifecycle. Some organizations use an interim engagement to bridge the gap while they conduct a proper search for the right permanent leader.

Who typically owns an ERP project when there’s no CIO in place?

In practice, ownership often defaults informally to a controller, VP of Finance, or IT manager, none of whom were hired with ERP project leadership as their core function. That default can work for a narrow-scope project, but for a full implementation it frequently becomes the point where the project loses momentum, since the person is managing the project on top of, not instead of, their existing responsibilities.