TREEAS

Twelve months into your ERP implementation, you notice something troubling. Your CFO is spending less time in project steering meetings. Your supply chain manager keeps pushing back on availability for UAT testing, citing “urgent operational issues.” Your HR director has handed off the HR customization work to an associate and is focusing on her day job. Your IT team is exhausted—people are talking about looking for other jobs after the project is done. These aren’t signs of commitment waning as the project winds down. They’re red flags that your organization doesn’t have enough resources to run both the project and the business simultaneously, and something has to give.

Resource constraints are among the most common—and most preventable—causes of ERP project failure. Most organizations underestimate the internal effort required. They think about implementation cost (the vendor invoice) but underestimate the opportunity cost (what your team is not doing while they’re focused on the project). As that opportunity cost accumulates, pressure builds to reduce project engagement. When that pressure grows strong enough, project quality suffers.

Signs That Your Team Is Under-Resourced

The first red flag is that your key functional leaders are splitting their time between the project and their operational role, and the project keeps losing out. Your CFO is supposed to be leading financial process design but is spending 30 percent of her time on month-end close instead of the committed 50 percent. Your supply chain VP is supposed to be defining inventory processes but keeps getting pulled into urgent supplier issues. This isn’t a character flaw in your leaders—it’s a signal that your business can’t afford to have those people fully focused on the project. You need to either hire backfill for their operational role, or you need to adjust project scope and timeline to match the resources you can actually commit.

The second red flag is increasing reliance on one or two people. Someone emerges as the ERP guru—the person who understands the system, knows how to solve problems, and gets asked to weigh in on every decision. That person becomes essential, overloaded, and exhausted. When you reach that point, you’re in dangerous territory. If that person leaves or burns out, the project stalls. That’s not because the person is uniquely talented (though they may be), but because knowledge is concentrated rather than distributed. A well-run implementation builds knowledge across a team rather than concentrating it in one expert.

The third red flag is external staff being asked to fill internal resource gaps. You don’t have enough internal people to do UAT, so your vendor provides an extra consultant to help with testing. You don’t have enough technical depth to configure integrations, so you hire a specialist contractor. While contractors are useful for specific tasks, overreliance on them suggests your internal team is understaffed. At go-live, when you need to transition knowledge to internal staff and start maintaining the system independently, you’ll discover the gaps.

The fourth red flag is when project timing gets deferred because your team can’t commit capacity. Your implementation partner wants to run a two-week intensive workshop to design your supply chain processes, but your team can only commit one week. Rather than add more people from your team, the workshop gets stretched to three weeks. That seems like a compromise, but it’s actually a warning sign—your team is so resource-constrained that you can’t dedicate focused time to knowledge work. Design work done part-time and stretched across longer periods is lower quality than intensive, focused work.

The fifth red flag is that post-launch support is still being handled by already-overextended people. You go live and realize your team has no spare capacity to fix issues, train users, or deal with the inevitable glitches. Your CFO is back to 100 percent on fiscal close. Your supply chain manager is fully engaged with actual supply chain work. You’ve got no one focused on troubleshooting the new system. When that happens, problems that should be fixed within days languish for weeks because no one has time to address them.

The Costs of Under-Resourcing

Under-resourcing creates a cascade of problems. First, engagement suffers. People who are stretched thin don’t have mental energy to be creative or proactive. They’re just trying to keep up. That leads to lower-quality contributions to design sessions, abbreviated testing, and inadequate training preparation.

Second, timeline slips. Work that’s supposed to take a week but gets done part-time across three weeks doesn’t save time—it creates delays. Every transition between focus areas has overhead. When people are juggling the project and their day job, those transitions are frequent, and the overhead compounds.

Third, quality problems emerge later. Testing that’s rushed or incomplete misses edge cases. Design reviews that are abbreviated because people don’t have time miss important questions. Training that’s abbreviated because no one’s resourced to do it well results in poorly prepared users.

Fourth, team retention suffers. People asked to work 60-hour weeks for an extended period get burnt out. They start looking for other jobs. The people most likely to leave are your best people—they have the most options. The people who stay are those who weren’t fully engaged anyway. You’re left with less-capable resources carrying forward the implementation.

Addressing Resource Constraints Early

During your implementation planning phase, build a detailed resource model. List every role needed (finance architect, supply chain lead, data analyst, testing coordinator, change manager) and estimate the time commitment each requires for each phase. Then compare that against your available people and their current commitments. If the math doesn’t work—if you need 500 person-hours but you can only allocate 300—you have choices: hire permanent staff, hire contractors, reduce project scope, or extend timeline. What you can’t do is ignore the gap and hope people will somehow absorb it.

Have an explicit conversation with your executive team about what it means to commit people to the project. If your CFO is leading the financial design work, what operational work will she not be doing? Who will cover that, and what will that cost? If you don’t surface those trade-offs explicitly, they’ll play out in hidden ways as the project runs, with people pulled between conflicting priorities.

As your implementation progresses, monitor actual utilization against the plan. If people are allocating less time than planned, surface it early. If someone’s unavailable for a two-week workshop because of operational priorities, escalate it. Don’t just shuffle the workshop to fit around people’s availability. Escalate to the steering committee and ask: are we truly committed to prioritizing this implementation, or should we adjust timeline? A steering committee that’s honest about resource constraints can make adjustments. A project that tries to ignore the constraints will suffer.

During your implementation, your team will be stretched. Digital Heroes Co brings implementation experience into resource planning. A veteran implementation team will challenge your resource plan and help you identify gaps before the project starts, not mid-stream when adjustments are painful. Ask your implementation partner during vendor selection how they approach resource planning and how they flag under-resourcing risks.

Finally, invest in post-launch support staffing before go-live. You can’t stand up a system and then improvise support. Decide before go-live who owns what—who’s the technical point person for systems issues, who owns user support, who handles change management for post-launch evolution. If you wait until you have problems, you’ll be scrambling.

Under-resourcing is often driven by genuine budget constraints or competing priorities, not by lack of commitment. But if your budget or priorities don’t allow you to resource the implementation adequately, you need to make that explicit and adjust scope or timeline accordingly. Projects that try to run on insufficient resources consistently underdeliver or overrun. Those that resource appropriately, even if it means smaller scope or longer timeline, deliver better results and operate more smoothly post-launch.