ERP Project Pitfalls: Why ‘Boiling the Ocean’ Leads to Chaos

Every project has its share of challenges, but few experiences shaped me like navigating ERP project pitfalls for the first time.

My journey began with my first Microsoft Dynamics NAV implementation – a project that taught me some of the most valuable lessons of my career.

The client team had sky-high expectations, joking that the implementation would fix everything, even the air conditioner.

It was one of my first times running an ERP implementation and I was young, optimistic, and determined to meet every expectation.

What I didn’t realize was that trying to tackle everything at once – boiling the ocean” – would lead to chaos.

By go-live day, the cracks in our approach were undeniable, and I was about to get a crash course in what not to do when managing an ERP project.

Reality hit hard on go-live day. Of the 800 orders placed, only one shipped successfully. One.

“In poorly run projects, problems can go undetected until the project fails. It’s like the drip… drip… drip… of a leaky underground pipe. Money is being lost, but you don’t see it until there is an explosion.” — Joy Gumz. FOUNDERJAR

Eventually, the project started reaping rewards, but those first few days did not have to be so difficult.  The experience was a wake-up call that taught me invaluable lessons. Here’s some things that went wrong and what I learned from it:

Focusing on the Wrong Priorities:

The go-live day challenges weren’t the result of a single misstep—it was a culmination of several critical mistakes.

One of the first challenges we faced was a misplaced focus.

While Dynamics NAV was the ERP solution we were implementing, integrating a Pick-to-Light system would revolutionize the client’s warehouse operations.

Focusing on integrating this technology would have solved many of the client’s issues immediately.

A Pick to Light (PTL) system streamlines the order-picking process.

  • In a warehouse, shelves, bins, or storage locations are equipped with light modules.
  • When an order is received, the ERP system sends picking instructions to the PTL system.
  • Lights illuminate at the specific storage locations where the items are stored.
  • The picker is directed to the locations with illuminated lights.
  • After picking the item, the worker presses a button or confirms the pick through the system.

Instead of centering our efforts on this game-changing system, our focus drifted to less impactful areas. This lack of prioritization diluted our efforts and stretched our resources thin.

Postponing Critical Tasks:

A lack of focus on critical preparatory tasks, like thorough testing, set us up for even more trouble on go-live day.

The client team put off critical tasks like thorough testing until the very last minute.

When go-live day arrived, we were scrambling to resolve issues that should have been addressed weeks, if not months, earlier. Testing isn’t glamorous, but it’s vital.

Scope Creep Galore:

In addition to delayed testing, we faced another all-too-common issue in ERP projects: scope creep. What started as a focused implementation gradually became a never-ending list of tweaks and additions.

Throughout the project, the client provided a steady stream of ideas. Many of them were great ideas that sounded simple and harmless. “Can we just tweak this?” “Wouldn’t it be great if we added that?”

Each idea seemed manageable in isolation, but together they introduced layers of complexity, requiring additional testing and rework. We didn’t account for this in our timeline, and the project dragged on as a result.

Insufficient Boundaries:

Scope creep was a symptom of a larger problem—insufficient boundaries.

I wanted to please the client and keep the team happy, but without proper boundaries, the project grew unwieldy.

The absence of a structured framework to prioritize and manage suggestions created chaos.

The Results:

Despite the eventual go-live, the project gave me insight on how to manage it better. Reflecting on this experience, I identified key lessons that I learned:

  • Maintaining a change log
  • Enforcing deadlines for critical tasks
  • Scheduling regular progress reviews

“Why do so many professionals say they are project managing when what they are doing is firefighting?” – Colin Bentley FOUNDERJAR

Planning First – Leaving No Stone Unturned

I learned the hard way that attempting to execute without proper planning is a recipe for failure.

Project management is a structured process that involves initiating, planning, executing, managing, and controlling a project—always in that order.

Detailed planning minimizes risk for both sides – for the client and my team.

Sticking to the plan means I am not going to please everyone right now.

To this day, I know that I don’t want to cut off ideas from the client team.

I manage them, so everyone gets heard.

To achieve success, I am now prepared to make tough decisions to deliver results. Trying to make everyone happy is fuel for chaos.

Communication

“The single biggest problem in communication is the illusion that it has taken place.” — George Bernard Shaw FOUNDERJAR

I can confidently say that communication is the cornerstone of success in any project.

It’s my job to ensure clear and open lines of communication between my team and stakeholders so that everyone is aligned on goals, expectations, and tasks.

I’ve seen firsthand how good communication fosters trust, builds collaboration, and keeps everyone motivated toward a common goal.

On the flip side, I’ve also witnessed how poor communication can lead to confusion, missed opportunities, and even conflict—derailing an otherwise promising project.

Together we decide what is essential and what could wait. Execution is phased so we can address core needs first and additional features later.

Asking the Right Questions

One of the mistakes I made was relying on assumptions.

Sometimes, I assumed that when out-of-scope requests were made, they were critical to the business processes.

I also at times assumed the changes were necessary when the client could have relied on other approaches that would have solved their issue but maybe not exactly in the way they outlined. I learned to stop assuming and start asking questions.

That means digging out the details about their expectations, timelines, and priorities.

I have since learned to ask thoughtful, meaningful questions that align everyone—clients, teams, and yourself.

Avoid questions with obvious answers but never shy away from seeking clarity. The right questions can mean the difference between project success and failure.

Time, Cost, and Quality: The Reality Check

One of the impactful lessons I learned is that clients often want it all: a perfect system delivered in no time, at minimal cost, and with the highest quality.

If I had asked the executive team to choose which was more important, they would have said all three.

But the reality is that these three elements – time, cost, and quality—exist in constant tension. To achieve one, you must compromise on another.

The key is setting realistic expectations and focusing on what matters most.

In this project, failing to balance these constraints led to an overambitious scope and missed deadlines. A clear understanding of these trade-offs is crucial for keeping the project grounded and manageable.

Lessons Learned:

  • Prioritize Core Needs: I now focus on the foundational elements that drive immediate value. Fancy add-ons can come later. These should be defined with an executive team prior to the design phase.
  • Respect the Testing Phase: I know that testing is not optional. It’s the backbone of a successful implementation. I even communicate this in the sales cycle; it’s not very salesy but it is important to communicate often.
  • Manage Scope Creep: I balance being open to ideas while maintaining control over the project’s scope. Not every idea needs to make it into the initial release.
  • Communicate and Set Expectations: I clearly outline what the client can expect and align with them a shared vision of success.

My Most Valuable Lesson:

The lessons I learned from that first project were invaluable, but if I had to choose the single most important takeaway, it’s this: don’t try to boil the ocean.

“Boiling the ocean” perfectly captures the chaos of trying to do everything at once without a clear focus. It’s like being so caught up in solving every possible challenge that you lose sight of what really matters, wasting time, energy, and resources.

Imagine diving into a project, assuming you need to deliver a massive, all-encompassing solution, only to realize later that the client only cared about a few key priorities.

Sound familiar?

Instead of overwhelming yourself and your team, the key is to narrow your focus, tackle what’s most important first, and build from there.

By resisting the urge to “boil the ocean,” you can keep things on track and deliver meaningful results without drowning in unnecessary complexity.

Today, I look back on that first implementation project with gratitude. It was a tough initiation into the world of Dynamics NAV, but it taught me lessons that I carry into every project I manage.

For anyone embarking on their first implementation journey, remember: mistakes are inevitable, but they’re also invaluable teachers. I encourage you to learn from them, adapt, and keep moving forward.

About Mike Stallmann

Photo of Mike Stallmann the Chief Geek Juggler at OZTERA, INC.

Meet Mike Stallmann, Director of Product and Business Development, Co-founder at Oztera, and the original “Chief Geek Juggler.” With decades of ERP innovation under his belt and over 200 successful deployments, Mike’s involvement with business technology is extensive.

From wineries to agriculture and beyond, Mike and Oztera specialize in solving complex, industry-specific challenges. If you’re looking to leverage technology for growth and efficiency, our experience is your secret weapon.

For insights and actionable advice, connect with Mike on LinkedIn and discover what tech-driven business transformation looks like.