Deploying a Material Requirements Planning (MRP) or Enterprise Resource Planning (ERP) system is often hailed as a transformative leap for businesses. But let’s not sugarcoat it: the road is rocky, and failures are all too common. From ballooning costs to frustrated employees, these projects can go sideways fast. Here’s why it happens — and what you can do to prevent it.

1. Not Defining Requirements Early and Comprehensively

Let’s be clear: you can’t build what you haven’t defined. Companies often dive into system selection without a crystal-clear understanding of their high-level needs. The result? A system that may look shiny but doesn’t fit.

What to Do: Before evaluating vendors, nail down what the system absolutely must do, the business processes it supports and who is in a position to make the decisions around those psocesses. Skip the nitty-gritty for now; focus on the big “what” rather than the “how.”

2. Skipping Proper Vendor/Product Evaluation

Vendors can be persuasive, but charm doesn’t solve process misalignment. Picking a vendor without scrutinizing how their product aligns with your actual needs leads to customization hell. A few dozen checkboxes isn’t an evaluation, that’s just the initial screening, but it’s where many organizations stop and base their final decisions.

What to Do: Vet vendors rigorously. Insist on demos, references, and concrete point-by-point proof of alignment with your requirements. Detailed walkthroughs with your data and test cases are essential. Don’t discount a vendor because they can’t do it “your way”, but look at how feasible it would be to do it “their way”.

3. Leaving Out the Real Experts

Senior leaders often make the decisions, leaving out the people in the trenches who actually do the work. This disconnect guarantees overlooked details and unmet needs.

What to Do: Engage frontline employees early. They’ll pinpoint issues you didn’t even know existed.

4. No Neutral Contract Negotiator

When requirements are fuzzy, contracts turn into black holes of vague deliverables and runaway costs. Without an objective third party, it’s a battle of conflicting interests. The vendor doesn’t understand your business and you don’t understand the tool, so you absolutely need someone in the middle to help connect the dots. A third party who is an expert in the space can help set process, milestones and expectations that will protect both parties from costly overruns

What to Do: Bring in a neutral expert to mediate contracts, scope, and expectations. It’s money well spent. Be careful to plan and negotiate around worst cases and not just a blue-sky implementation.

5. Skipping “How Does It Work” Training

Most organizations jump straight into mapping gaps and customizations without first understanding the logic behind the system’s design. That’s like trying to remodel a house you’ve never walked through. The systems you’ve chosen has almost certainly been used by hundreds or thousands of customer before you without making your specific changes. Find out how. You might learn a better way.

What to Do: Train key stakeholders on how the system works out of the box. Learn its strengths and quirks before deciding what to tweak. Focus on how you can support your business with the OOTB system and not on how you need to change the system to support your business.

6. Dragging Legacy Baggage Into the Future

If you cram old data and outdated processes into a new system, don’t be surprised when it breaks or becomes a transformation nightmare.

What to Do: Bring only what’s essential: customers, suppliers, catalogs, inventory, GL balances. Run parallel systems temporarily to organically close out open transactions in the old system and phase out old workflows without chaos.

7. No Dedicated Implementation Team

Part-time attention yields part-time results. Delegating implementation to people already swamped with other responsibilities slows everything down and almost gaurantees a long drawn-out process. Competing priorities draw focus from fully analyzing and understanding the issues and impact fast decision making.

What to Do: Assign a full-time team with decision-making authority. Let them focus exclusively on the project.

8. Lip Service from Leadership

When a crisis hits, “top priority” projects can suddenly become afterthoughts. That sends a loud message: this isn’t really important. Additionally, changing business process will inevitably meet with resistance. You absolutely will need to change your business to be successful. Any customization that you allow will set a precedent for more customization and exponentially increase your risk of breaking OOTB functionality and impacting your upgrade paths.

What to Do: Leadership needs to walk the talk. Keep the team shielded from distractions and support them when business process changes meet resistance. Make the business work on adapting the business processes to the OOTB product and treat customizations as an absolute last resort. (see below)

9. Customizing Everything

Trying to replicate your old system in a new one defeats the purpose of upgrading. Customizations are expensive and risky and should be avoided at all costs. Full leadership support on this point is critical (see above)

What to Do: Start with out-of-the-box functionality. Test workarounds before jumping to customizations. Less is more.

10. Chasing “Best-in-Class” Tools

The “best” tool for every function often leads to a Frankenstein’s monster of disconnected systems. An MRP/ERP deployment is the perfect opportunity to centralize data and workflows under one umbrella and start to eliminate “one-trick-ponies” from your environment.

What to Do: Prioritize OOTB functionality and native integration. A “good enough” tool that fits seamlessly beats “best” tools that don’t talk to each other.

11. Micromanaging Vendors

You hired experts, not interns. Hovering over their work wastes your time and erodes trust. It also reduces your ability to hold them accountable when you don’t allow them to manage their own work and deliverables. Nothing will invalidate a fixed-price contract faster than micromanaging your contractors.

What to Do: Set clear milestones and hold them accountable. Then step back and let them deliver.

12. Too Many Cooks (or Vendors)

Multiple vendors mean more handoffs, miscommunication, and finger-pointing.

What to Do: Consolidate vendors wherever possible. Designate a single “general contractor” to manage the project and map out the lines of communication and accountability. Not everything needs to flow through you.

13. Treating Testing as a Formality

Rushed or superficial testing leads to faulty assumptions, wasted effort, and costly rework. Using “any available warm body” to do testing instead of trained/skilled testers will gaurantee that your testing is superficial. Testing is an overlooked professional skill and not something that everyone is capable of.

What to Do: Put skilled testers in charge of the process. Test early, often, and thoroughly. Validate assumptions at every stage.

14. Ignoring Data Quality

Bad data is like bad fuel — it gums up the works. Poorly cleansed legacy data leads to errors and inefficiencies.

What to Do: Audit, clean, and validate data before migration. In most organizations, this will be a significant effort. Make this a separate project if needed. Remember that a new system isn’t going to magically fix bad data.

15. Poor Change Control

Scope creep and endless revisions are the death knell of many implementations.

What to Do: Establish a solid change control process. Evaluate every change request for its impact and necessity. Track the reasons for the change request to better understand how to improve future requirements, product selections, testing and implementations

The Bottom Line

Deploying an MRP/ERP system is no small feat, but failure isn’t inevitable. By addressing these common pitfalls head-on, you can save time, money, and sanity. The key? Planning, communication, and a relentless focus on doing things right the first time.

What challenges have you faced during an MRP/ERP deployment? Let us know in the comments.

A consultant’s only asset with any long-term value is reputation.

Technologies fall out of favour. Business Processes evolve. Companies are bought and sold. Ultimately, the only asset that a consultant has is their reputation and ethics. Many consultants (and consulting organizations) forget this and focus on the short-term value of inflated billing, placing inexperienced consultants, under-bidding and then running over budget, working on poorly considered client projects, etc. While this short-term approach may be financially profitable, it results in unhappy clients, a bad “street cred” and can ultimately lead to the ruin of the consulting organization or even the client companies.

Communication is at the heart of every successful project

A team that doesn’t communicate well internally, with the customer and with the vendors will fail. The project may be completed, but the results will be less than optimal, the project will be more expensive than required and the ongoing support costs will ultimately be higher. Clients, Management, Vendors and the direct project team need to function as a unified whole to ensure success.

Technology has no inherent value

The only value that technology has is in how it can bring value to the business. Implementing technology for the sake of technology is not only a waste of time and money, but can ultimately be detrimental to the business. Some companies don’t need a web site. Many organizations don’t need to engage in eCommerce. Implementing a multi-million dollar ERP system for a company with $500K worth of revenues isn’t going to magically drop them into the Fortune-50. Regardless of what the “other guys” are doing, your projected ROI (return on investment) should be the main driver behind any new technology initiative.

ROI (Return on Investment) doesn’t always mean direct revenue or cost savings

Your “return” on a project is nothing more or less than “business value”. Laying the groundwork to be able to exploit future opportunities, increasing your organizational agility, improving employee or customer satisfaction are all incredibly valuable to sustaining and growing your business. Many companies destroy their agility and their own futures by not quantifying these “soft benefits” or considering them as important as the hard dollars.

Nobody ever knowingly makes a wrong decision

This statement replaces the traditional “The Customer is Always Right”. If there are two diametrically opposed approaches, chances are that somebody is working with incomplete assumptions or data. By acknowledging that nobody knowingly makes a wrong decision, open communication of the relevant information can uncover where the disconnect has occurred.

If it’s not measured, it’s not managed

Project Management is a science and not an art. Deliverables should be objective, quantified (or at least enumerated in some way) and tracked. If an objective is not measurable, it can’t be tracked or monitored. If it can’t be monitored, it certainly can’t be managed. In many cases, Project Managers encounter deliverables that they feel can’t be objectively measured. If that’s the case, then the deliverable needs to be broken down or redefined to provide a clear set of exit or acceptance criteria. Committments need to be either time-based or event driven. “Whenever” often becomes “Never” or results in a last minute rush with predictably poor results.

Costs should not exceed the expected benefits

A client should clearly understand the benefits of the project, the projected value of these benefits to the organization and the costs of implementation, training and long-term support. If the costs exceed the potential benefits (direct and indirect), the project needs to be restructured or abandoned. Implementing a solution simply for prestige, empire building or billing purposes is irresponsible and unethical and can lead to disastrous long-term results.

Excessive analysis/planning/requirements definition, etc. are as crippling as no analysis/planning/requirements definition.

Most people and organizations are familiar with “Analysis Paralysis”, the inability to make a decision without analyzing every tiny detail, facet, risk, etc. to the exclusion of any real work. The new trend is a form of “Methodology Fundamentalism”, the tendency of an organization to adopt a methodology word-for-word rather than applying it appropriately for the tasks/project at hand. It’s important for everyone to understand the steps and the processes required to manage a project, but it’s equally important to know when the effort required to carry out a task outweighs the benefits. When a team can communicate effectively, there is a natural tendency to want to work using a cascaded development approach. A linear approach is appropriate for some projects, but where a cascade approach is applicable, accepting and embracing it up-front will make for a much more efficient and predictable project.

People shouldn’t be “shoe-horned” into roles as a client “make work” effort or in an attempt to increase billing.

Everyone has their own expertise, knowledge-base, interests and abilities. It is the responsibility of the Project Manager to understand where the strengths and interests of each team member lie. Furthermore, it is the PMs responsibility to ensure that everyone is engaged to the best of their abilities and with the best long-term outlook possible. Using resources inappropriately wastes everyone’s time and effort.

Ongoing Documentation is essential

Everyone should be working with the ultimate goal of becoming redundant. It takes very little effort to document throughout the project and revise the documentation as necessary. However, it can be an overwhelming or impossible task to document retroactively.