Why should you believe us?

In a nutshell, because we’ve been around a very long time and we’re only telling you what we’ve seen.

There are only three ways in which the workshops we offer can be said to be original with us:

• The format of the workshops themselves.
• The concentration on the role of business analysis.
• The insistence that the process we describe must precede the ERP project itself.

Everything else is the common practice of companies that have succeeded in implementing ERP: companies that already know how to elicit their own expectations, embed them in their projects, and insist that the people they hire work only toward fulfilling them. These companies, of course, don’t need anything like this workshop, because they showed us how successful ERP projects have to work.

Why the concentration on business analysis? Because business analysis (and its predecessors) performs the role of translating business processes of every kind into system terms, making it eventually possible to express them in technical IT terms.

And the critical expectations that determine ERP success or failure are naturally expressed in specific (not general) business language: because they are about the details of operating a very specific business.

But ERP systems are implemented at a technical level, by technical experts who think and speak in technical terms.

In a failed implementation, the business people are lined up on one side of a chasm, and the technical people are lined up on the other side. Each group is urgently shouting to the other one but neither group understands the other, no matter how loudly everyone shouts. This ugliness happens when there is no shared description of the desired system that everyone can understand and talk about among themselves.

It is the role of business analysis to provide that shared understanding.

Why can’t this all be embedded in the usual ERP implementation project model? For several reasons, which are really just different ways of saying “By the time an ERP project starts, it’s way too late to be deciding what it’s intended to accomplish.”

• When an ERP project starts, systems and implementers have been selected and contracts have been signed. It’s far too late to go back and impose requirements about what the system will do and how the implementers will prove that it is being done.

• ERP projects run on tight schedules with high burn rates. They almost never start without a budget and a go-live date already cast in concrete. There is no place in them for preliminary discovery efforts that take as long as people need to get them done and barely involve most of the ERP implementation team at all.

Companies that successfully implement ERP know what they expect, and know how to demand it, before the first order is placed and the first consultant is interviewed.

We worked for several of them over the course of 35 years and learned from them how it’s done. That doesn’t mean that the specific practices we teach are shared by all (or any) of these successful companies. They aren’t. They all have their own internal styles of doing business, but they all accomplish the same thing in different ways: as does the variation we teach in our workshops.