How is this applicable to you?

ERP failure happens when critical expectations within a user company are not met. Critical expectations go unmet when they are not the central points around which ERP projects revolve. Critical expectations are not the central points around which ERP projects revolve when they are not documented prior to project initiation. And critical expectations are not documented prior to project initiation if they are never elicited at all. They remain the often conflicting private opinions of key people throughout the company – right up to the moment that they are seen to not be met, which is also the moment that failure becomes apparent.

When the critical expectations that will determine the success or failure of an ERP project are unknown to the parties responsible for the implementation, the project team must work toward other goals. These other goals, which are usually expressed as checklists and metrics, become surrogates for the company’s unexpressed critical expectations throughout the project. They become the measure of the project’s progress. They become the measure of the project team’s performance. When we tell ourselves that we are practicing something called "risk management" because we have a "risk management plan", we are talking about a plan for meeting our chosen bundle of surrogates for our own unstated critical expectations, not for meeting those expectations themselves.

The antidote to this common scenario is to apply the practices of business analysis to uncover and systematically document the actual critical expectations the company holds for its new or modified system – before any attempts to design (let alone begin) the implementation project have happened. This activity belongs to the business analysis function because requirements elicitation belongs to business analysis, and there are no truer requirements than the critical expectations that must be met if the system is to succeed.

This critical activity – eliciting critical expectations and documenting them as requirements – is missing from a great many ERP-related projects: it is simply never performed, and the purpose of the project is misstated as some variation on "to implement the XYZ system here at the ABC company."

When that happens, the true focus of the project is also misstated – "implementing the XYZ system here at the ABC company" becomes the project’s goal, instead of "implementing and learning to use the XYZ system to meet the specific and possibly unique business requirements of the ABC company."

We offer detailed instruction that teaches companies to elicit and reconcile their own critical expectations, to use the techniques of business analysis to document them so that outsiders cannot fail to understand what the system will be expected to do, and to incorporate this understanding into all phases of the implementation project itself – up to and including contracts for hardware, software and, especially, consulting.

This education is the product we sell, in the form of two connected, one-week workshops.

This first workshop is an in-depth look at ERP failure.

We explore examples of the most frequently described symptoms of ERP failure.

We show how they can all be restated as failures to meet critical expectations. We discuss just whose expectations they were, and suggest why they were ignored until it was too late to meet them.

In other words, what was the unexpressed critical expectation that the project failed to meet, who held that expectation, and why wasn’t it met?

For each failed expectation we discuss, we invite the members of the class to explore the equivalent expectations within their own companies. In particular, who “owns” the expectations in each student’s company? That is, who will come forward to declare the project a failure if those expectations aren’t met? How will we identify these people?

Next, we explain what usually happens instead of eliciting expectations and expressing them as project requirements. Using our own experience as ERP sellers and implementers, we explore what happens when the user company does not take control of the project and define it in terms of its critical expectations:

How the sellers must then assume control (and how we used to do that).
How they substitute surrogate requirements of their own for the genuine requirements they haven’t been told about.
How meeting these surrogate requirements has almost nothing to do with meeting the critical expectations that will ultimately determine whether the project succeeds or fails.

At the end of this workshop the student will be able to listen to any tale of ERP woe and explain fairly precisely exactly what probably went wrong, where – in the company and in the project schedule – it went wrong and why it went wrong.

The second workshop continues this theme, this time from the perspective of preventing failure.

Using detailed examples, we show how all critical expectations are elicited by using the techniques of business analysis to construct an abstract model of the desired ERP system, a model which:

is entirely based on the solicited input of the owners of the critical expectations concerning the system;
is rich enough to describe each expectation in adequate but not superfluous detail;
and is translated into common business language – English and diagrammatical – so that all stakeholders and project participants thoroughly understand everyone’s expectations in the same terms.
This model is ultimately put into the form of a Statement of Work,
which is then incorporated into all solicitations, contracts and into the project plan,
thus becoming the measure of performance for the project as a whole and for each individual part of it.

We show when this must be done (well before ERP projects are normally deemed to begin) and why.

We show why responsible system vendors and implementers welcome this approach, so long as it is in place when their involvement begins.

At the end of this workshop the student will understand the general process very well and will also take away samples of all the tools and templates needed to create a similar process in any company that is a genuine candidate for an ERP system.

This education is the only product we sell. We do not attempt to perform the business analysis function ourselves because we believe that it is something companies have to do for themselves, something that outsiders just never get right (which, in a nutshell, is our entire message).