Here's what stood out.
​
​Because here's the fight I'm willing to pick:

Most ERP projects fail because teams choose the technology first and figure out the rest later.


That's not a technology problem. That's a sequencing problem. And it's entirely fixable.

The Order You Do Things Is the Point

Bob's framework is simple. People. Process. Data. Technology, in that order.

Not the other way around.

He put it plainly: generally, the systems all work. The puts and takes, the fit, the compromises, those are real, but they're manageable. What isn't manageable is starting with a system when you haven't sorted your people, your process, or your data first.

Because once you engage the vendor, the meter is running.

Everything you haven't figured out yet, you'll now figure out on someone else's clock.

Don't Automate a Broken Process

This one hit me.

Bob described it like this: if you have a broken car and you speed it up, you just run it into the ground faster. If you have a process that loses you money and you automate it, you lose money faster.

Neither is progress.

The work of mapping your processes, really understanding every edge case, every exception, every upstream and downstream dependency, that work needs to happen before the vendor walks in the door.

Not because it's ceremonially correct. Because when you give a vendor 80% of the story, you get back a solution that's 80% right. And you find out the missing 20% in testing, near the end of the project, when rework is most expensive and trust is most fragile.

Imagine going into a vendor conversation with your processes already mapped, your data already clean, your team already aligned.

That's a different project entirely.

Your Best People. Not Your Available People.

Here's the mistake Bob sees over and over.

Organizations staff ERP projects with whoever they can free up. The available people. The ones who aren't too deep in something critical.

That's exactly backwards.

You want the people who know the entire organization. The ones you can't easily pull. The ones whose absence will be felt. And you want the same quality from your vendor, not just whoever fits their scheduling pipeline, but the people you've actually interviewed and chosen.

Bob's point on this: ask who will actually show up on site. The presales person you fell in love with isn't coming back to implement your system.

Use your hiring instincts. Cultural fit. Deep bench. Ability to flex if someone isn't working. Those aren't nice-to-haves. They are the project.

People is always first. Not because it sounds good in a framework. Because alignment is the only thing that creates execution speed.

The Hardest Decision Is the Go/No-Go

There's a moment in every project where someone has to call it.

Are we ready to go live?

Bob calls this the hardest decision on the entire project. Some portion of the team will always say they're not ready. Nothing will ever be perfect. Forcing that call requires good judgment, organizational credibility, and the courage to either press forward or pause, without politics making the decision for you.

He also makes a point that surprised me: it's okay to cancel.

His standard talk is actually called Cancel Your ERP Project. Not because implementation is a bad idea. Because sometimes the timing is wrong, the team isn't set, and the priorities aren't aligned. And no system can fix that.

Starting a project you're not ready for is not momentum. It's expensive drift.

The Aircraft Carrier Curve Is Real

Any system launch creates disruption. Productivity will dip at go-live. That's not failure, that's physics.

Bob describes it as the aircraft carrier curve: the plane drops toward the water before it climbs toward the sky. Totally normal.

The question isn't whether the dip happens. The question is how shallow and how short you can make it.

Training, change management, and realistic expectations determine that. And they're almost always the first things compressed when a project runs late.

That compression is expensive. Just later, and harder to see.

The Project Manager's Job Is People

One last thing Bob said that I haven't stopped thinking about.

The project manager's job, especially on large implementations, is people. Not spreadsheets. Not Gantt charts. Not status reports.

People.

The organizational tenure. The ability to drive alignment. The credibility to tell the steering committee when something isn't working. Those qualities matter more than having done an ERP before.

If your project manager is buried in a tracker, you might be missing the thing that actually moves the project.

Bob Wallace and I go even deeper on this in our full conversation. Watch the interview here [LINK]

​

Think about the ERP projects you've seen struggle.

Not because the software was wrong. Because the sequence was wrong. Because the right people weren't on it. Because the process work happened too late. Because the go/no-go decision was made on hope instead of readiness.

None of that is inevitable.

Bob's work is proof that these projects can be de-risked. The framework is real. The patterns are visible, once someone has seen them enough times to name them.

Your next project doesn't have to become a recovery story.

What would change if you started with people instead of software?

I help engineers speak as well as they design. If this resonated, or if your team is navigating a complex project right now and the conversations aren't landing, I'd love to hear what's getting in the way. Drop a comment or reach out directly.