My Worst Project Ever

Several years ago, I was brought in to implement a new ERP system for a small international business. The client had already selected their solution, and my role was to implement it.

It sounded straightforward enough.? I knew the client's industry segment and was familiar with their selected solution, having implemented it many times before. It was these two factors that gave the client the confidence that I was the right partner to work with them.

What I didn't know - because it wasn't documented anywhere and I didn't ask - was that their entire infrastructure was serverless, running purely on Microsoft 365. This critical detail would soon turn into a project-killing issue.? Whilst this setup is quite normal now, back then in the early days of 365, it was still quite new.?

I knew the selected ERP system wasn't a true SaaS solution and would require server infrastructure, but the client didn't. They thought they'd bought a cloud solution that would slot right into their serverless environment. Neither the vendor nor the client had discussed or documented this fundamental architectural requirement. By the time this misalignment became apparent, we were already deep into the project.

The result? A dispute, damaged relationships, and an incomplete project. A painful and expensive lesson for everyone involved.

The frustrating part was this entire disaster could have been avoided with one simple step:

Properly documented business requirements.

Not just the functional requirements (what the software needs to do), but the crucial non-functional requirements.

Here's what I learned the hard way:

1. Requirements aren't just a wish list - they're your project's foundation. Without clear, documented requirements, you're essentially building on quicksand.
2. Non-functional requirements are often overlooked but can be project-killers. Things like:
3. Never assume anything about a client's environment. What seems like a basic technical detail to one person might be a critical constraint to another. Every requirement needs to be explicitly documented and verified.

The most valuable lesson?

As a project manager, it's not enough to accept what you're told. Even if you're engaged after key decisions have been made, you need to do your due diligence.

Ask the uncomfortable questions.

Challenge assumptions.

Document everything.

I should have identified the requirements right at the start, before the business was engaged in configuration and process workshops.? In the end, all this effort came to nothing when the client ultimately cancelled the project.??

If you're not sure how to do this, check out this blog on my website which goes into more detail on the subject of defining business requirements.

Remember, in last week's article, I quoted the statistic that 80% of enterprise-scale digital transformation projects fail to deliver their intended benefits.

In my experience, at least half of these failures can be traced back to poorly defined requirements - especially those "obvious" technical requirements that everyone assumes are understood.

Don't let your project become another bad statistic.?

If you're starting a new project now or struggling with an existing one, let's talk. I've learned these lessons the hard way, so you don't have to.

And sometimes, as a Project Manager, it really does feel like you are expected to be a magician, able to pull the impossible out of a hat!

And if you didn't grab it last week, download my free Project Health Check Tool.

>>> Ultimate Project Health Check Tool

Reply to this email if you'd like to discuss your project challenges.

Sometimes, an outside perspective is all it takes to spot issues before they become insurmountable problems.

Next week I'll talk about the other main reason I see projects go wrong - a poor business case.