Project Management Risks That Can Derail an ERP Implementation

By the time implementation is in full swing, most ERP projects feel complex. However, complexity isn’t what causes them to fail. Lack of control does.

This is the phase where decisions pile up, timelines get tested and competing priorities start to surface. Without clear governance, disciplined scope management and thorough testing, even well-planned projects can start to drift.

Here are five risks that come from daily project management and how small gaps in execution can turn into major issues at go live.

1. Weak Project Governance

Without clear ownership, ERP projects drift. Decisions get made by whoever shows up that day. The same issues cycle through meeting after meeting without resolution. Nobody knows who has final say on anything.

Good governance should be clarity, not bureaucracy. It defines who makes decisions, how issues get escalated and how changes to scope or timeline get approved. Without it, small problems compound into big ones.

Common causes:

• No steering committee exists.
• Project roles are unclear.
• Risks are discussed but not tracked.
• Change requests are approved informally.
• Department leaders are not held accountable for deadlines.

What to watch for:

• The same issues appear in multiple meetings without resolution.
• Nobody knows who has final approval on key decisions.
• Decisions are made but then reversed later.
• Local decisions create company-wide problems.

• Define governance roles at the start, including project managers, department leaders, data owners and power users.
• Use a raid log to track open issues.
• Establish a clear escalation path.
• Implement formal change control for scope, cost and timeline.

Example:  When purchasing wants one vendor numbering structure and accounting wants another, governance determines who decides and makes sure that decision sticks.

2. Scope Creep

Scope creep rarely happens because people are asking for unreasonable things. It happens because the system is new and exciting and everyone can suddenly see possibilities. Problems arise when teams attempt to complete all individual requests at the same time.

Every addition to scope comes with a cost: time, training updates, testing cycles and the risk that nothing gets fully finished. The manufacturers who activate a smooth go live are almost always the ones who held a firm line on what phase one actually meant.

Common causes:

• Departments add requests after seeing the system.
• Leadership wants advanced functionality before core processes are stable.
• The project does not have a strict change-control process.
• Nice-to-have items are treated as go-live requirements.

What to watch for:

• Go-live dates that keep sliding.
• Advanced features are added before basic transactions are stable.
• Training materials change repeatedly.
• Employees are unsure which processes and features will be live at launch.

What to do instead:

• Define the go-live scope clearly in writing and hold to it.
• Separate must-have requirements from phase-two improvements.
• Stabilize core areas first, including accounting, inventory, purchasing, order entry, production and shipping.
• Evaluate every new request for its impact on cost, timeline and training before approving it.

Example:  Launching finance, inventory, shop floor data collection, advanced scheduling, EDI, CRM and warehouse automation simultaneously is a recipe for an unstable go live. A phased approach lets users master the basics before adding complexity.

3. Unrealistic Timelines and Budgets

ERP implementation takes internal time, as well consulting hours. Your employees need to clean data, test workflows, make decisions and learn new processes while still running the business. When that reality isn’t reflected in the plan, shortcuts happen.

The most common shortcuts are rushed testing, incomplete data cleanup and compressed training. Those are also the three things most likely to cause a painful go live.

Common causes:

• The schedule is based on a target date instead of actual workload.
• Key employees are expected to implement ERP while doing their full-time jobs.
• Data cleanup is underestimated.
• Testing and training time are reduced to protect the go-live date.
• The budget does not include contingency for unexpected issues.

What to watch for:

• Subject matter experts consistently miss project deadlines because daily work takes priority.
• Testing and training are shortened to protect the go-live date.
• Team members assume unresolved issues can wait until after launch.

What to do instead:

• Build the timeline around true resource availability, not a target date.
• Identify who is needed for each phase and protect their time.
• Include contingency for unexpected technical and operational issues.
• Treat data cleanup, testing and training as non-negotiables, not nice-to-haves.

Example: If the one person who truly understands your routings is also responsible for daily scheduling, you need to give that person dedicated project time. Otherwise, routing cleanup will be incomplete and scheduling will suffer at go live.

4. Poor Fit with the Implementation Partner

General software knowledge and manufacturing process knowledge are different things.

A partner who can configure accounting workflows but doesn’t understand how a job moves through a plant is going to make decisions that look reasonable and perform poorly. Further, partner selection that focuses primarily on a low upfront cost often ends up more expensive in the long run.

Common causes:

• Partner selection focuses only on cost.
• The partner lacks experience with the manufacturer’s production model.
• Consultants understand accounting but not shop floor constraints.
• The implementation team does not ask enough operational questions.

What to watch for:

• The partner can’t clearly explain how the system supports your production model.
• Discussions focus on screens and features rather than process flow.
• Shop floor users feel like the consultants don’t understand their work.
• Configuration advice ignores capacity, routing, traceability or job costing.

What to do instead:

• Ask for references from manufacturers with a similar production model.
• Confirm the partner has hands-on experience with make-to-order, engineer-to-order or whatever model fits your business.
• Evaluate how they approach aspects of your business other than configuration, such as data quality, training and change management.
• Confirm they understand how work actually moves through your plant.

Example:  A manufacturer with lot traceability requirements, outside processing and quality holds needs a partner who understands those constraints before a single configuration decision gets made. 

5. Weak Pre-Rollout Testing

Testing individual screens is not the same as testing whether your business can run. You need to know that a complete quote-to-cash cycle works, that inventory balances after a job closes, that purchasing generates the right suggestions and that accounting closes cleanly.

The scenarios you don’t test are the ones that will break at go live, usually on the busiest day of the month.

Common causes:

• Testing focuses on individual screens rather than full workflows.
• Users test clean examples instead of real exceptions.
• Data migration is not tested at full scale.
• Integrations are tested too late.
• The team does not test peak transaction volume.

What to watch for:

• Users can enter transactions but can’t complete full business cycles.
• Reports don’t match expected results.
• Exceptions like scrap, returns or partial shipments have been deferred to after go live.
• Issues found during testing keep reappearing.

What to do instead:

• Test full end-to-end business processes, including quote-to-cash, purchase-to-pay, plan-to-produce and quality hold-to-release.
• Use real production examples, including messy or exception-heavy scenarios.
• Test exceptions, not just clean scenarios, including scrap, rework, shortages, partial shipments, substitutions and returns.
• Validate accounting impacts.
• Run more than one complete test cycle before going live.

Example: A quote-to-cash test should flow through quoting, order entry, material allocation, production, shipping, invoicing, receivables and reporting. If any step breaks, the business process isn’t ready. 

Strong execution keeps an ERP project on track, but it also sets the stage for what happens next. Because no matter how well a system is configured or tested, go live is where theory meets reality.

In the fourth part of this series, we’ll look at what happens during and after launch where system fit, rollout strategy and long-term accountability determine whether ERP becomes a true business asset or just another system to work around.