“What is the overall success rate of ERP implementation projects?”

“What are the symptoms of ERP project failure?”

“What are usually deemed to be the causes of ERP project failure?”

“What are the critical decisions I need to make for successful ERP acquisition and implementation projects? And when do I need to make them?”

“Why should ERP acquisition efforts be managed in a project?”

“Why should ERP implementation efforts be managed in a project?”

“Why does it make sense to view ERP acquisition and implementation as a single project?”

“Who used to be responsible for ERP implementation success? Who’s responsible now?”

“How does the lack of a strategic objectives imperil (add risk to) an ERP acquisition/implementation project?”

“In an ERP acquisition/implementation project, why does the failure to consult the company’s strategic objectives have the same effect as a conscious effort at sabotage?”

“How are ERP acquisition and implementation projects fundamentally different in large and small companies? Why does it matter so much?”

“What are the potential consequences to a project of leaving even a single known risk unmanaged? Why are some risks not managed?”

“Why is your company already largely capable of managing an ERP acquisition/implementation project, even though you may lack technical product knowledge or project management experience? How do you go about buying only the knowledge you lack, while not paying for what you already know and can do for yourself?”

“When and how do companies lose control of their own projects? How can they keep control?”

“What’s so bad about wish lists?”

“What’s so bad about RFPs?”

Share and Enjoy

The sales cycle/solution process I used started with a telephone call where I asked 5 qualification questions. If these questions were answered positively my next step was a first meeting to present my eight step sales cycle/solution process. This meeting was very important because when the qualified prospect agreed (90% of the time) to the process it gave me control of the entire buying cycle for our ERP system.

The sales cycle/solution process I insisted on using got me to my third step—the executive meeting. In my next blog I’ll explain/confess the strategy behind the executive meeting.

Share and Enjoy

1. 25% or so of all attempted ERP implementations fail entirely and are abandoned with nothing accomplished.
2. 60 to 70% are challenged to some extent in at least one of three ways:
   1. They are over budget and/or
   2. They are late and/or
   3. They are implemented with reduced functionality.
3. 30 to 40% are deemed successful in every respect.

Back to Table of Contents

Share and Enjoy

• Inadequate system performance
• Throughput (response time)
• Capacity
• System doesn’t match requirements
• Missing reports/queries
• Incorrect process/work flow
• “It doesn’t do it our way”
• Missing functionality
• System is too unwieldy
• Too many steps
• Ungraceful process
• Project was late
• Project was over budget
• Users have poor access to system information
• There are data integrity and/or data accuracy problems
• There were data conversion problems
• The system was too difficult to implement
• Too much demand on internal resources
• “They want us to shut the business down for how long?”
• “It just doesn’t work!” Or similar statements of abject despair.
• Overwhelming number of problems
• Couldn’t pass critical test(s)

One striking thing about all these symptoms is that they all appear after the fact: in a few cases, after an implementation is cancelled, in a few more when it is demonstrably struggling and in the rest after the system has gone live. That is, there are no early warnings on this list, nothing that suggests “we’re going to have a problem we haven’t felt yet if we don’t do something now.”
When asked for the causes of these symptoms, users and implementers typically list the following (the wording varies from survey to survey):

• The wrong software was selected (usually users).
• The software was configured incorrectly (usually users).
• The requirements/specs were incomplete or incorrect (usually implementers but users sometimes confess to this).
• Scope creep.
• Implementers: “They kept adding requirements.” This is the implementer’s universal first response to complaints about budget and schedule overrun.
• Users: “Then they said, ‘Oh, you want it to work? That changes everything.’”
• Inexperienced/inept implementers (users).
• “They lied” (both). “They” may be a third party!
• Lack of management commitment/support (both). This is the single most commonly cited general cause of failure, but often it is offered without an explanation of exactly what management should have done differently.
• Lack of user skill.
• Implementers: Many flavors (some unprintable), among them:
• “They wouldn’t let us train them.”
• “They have nobody who understands anything [in that department].”
• “They refuse to change how they work.”
• “We showed them over and over again and they just didn’t get it.”
• “5,000 companies use this module every day but they say it just doesn’t work.”
• Users: “We’re accountants/planners/buyers/etc, not IT people.”
• Resistance from users (usually implementers but not always).
• Buggy package (both!).
• Implementation task just underestimated or oversold (users).

Some rather surprising things emerge when we compare the list of commonly reported symptoms of failure to the list of commonly reported causes of failure.

• Almost any commonly reported symptom could be the effect of almost any commonly reported cause.
• There is nothing in either list that suggests how to avoid these results.

To restate the usual perceptions of failure in terms that can lead to actually preventing, we need to take an entirely different view, one that looks at the problem of preventing failure as an exercise in risk management.

Back to Table of Contents

Share and Enjoy

• The wrong software was selected (usually users).
• The software was configured incorrectly (usually users).
• The requirements/specs were incomplete or incorrect (usually implementers but users sometimes confess to this).
• Scope creep.
• Implementers: “They kept adding requirements.” This is the implementer’s universal first response to complaints about budget and schedule overrun.
• Users: “Then they said, ‘Oh, you want it to work? That changes everything.’”
• Inexperienced/inept implementers (users).
• “They lied” (both). “They” may be a third party!
• Lack of management commitment/support (both). This is the single most commonly cited general cause of failure, but often it is offered without an explanation of exactly what management should have done differently.
• Lack of user skill.
• Implementers: Many flavors (some unprintable), among them:
• “They wouldn’t let us train them.”
• “They have nobody who understands anything [in that department].”
• “They refuse to change how they work.”
• “We showed them over and over again and they just didn’t get it.”
• “5,000 companies use this module every day but they say it just doesn’t work.”
• Users: “We’re accountants/planners/buyers/etc, not IT people.”
• Resistance from users (usually implementers but not always).
• Buggy package (both!).
• Implementation task just underestimated or oversold (users).

This is how these risks are reported, and it is in these terms that they are commonly discussed; but note that they are not stated in terms that would let us manage them proactively.

We don’t think that it is very useful to think and plan in terms of these perceived causes.

Back to Table of Contents

Share and Enjoy

• What are we trying to implement?

First, some very common and very wrong answers:

• Software
• An ERP system
• A particular brand of ERP system
• A subset of a particular brand of ERP system configured in a particular way
• Any other name for the overall task that isn’t centered around the concept of running our particular business as we best see fit to run it.

The natural tendency to answer this question in terms of software is the original sin of business system implementations, and the root cause of a vast amount of failure, struggle and misery.
Nobody (at least nobody who isn’t in the software business to some extent) buys software just to buy software. They buy software to accomplish some particular purpose, and that purpose is what they’re implementing when they implement the software that they buy. The purpose of any planned ERP system is not an airy abstraction (á la “implement ERP” or such); it is a dense bundle of specifics about how the company does business and wishes to do business over the life of the new system. This dense bundle of specifics includes the company’s current operations but it also extends (or should) into the company’s future. Many things will happen during the life of the new system, and not all of them are confined to the way the company operates today. The company’s strategic plan will either be realized or not during the life of the new system. If that plan succeeds and the company’s strategic goals are met, the new system won’t be the only reason why. But if the new system is unable to support the company’s long term goals, that alone is all that is needed to defeat them: that alone is sufficient to defeat all the strategic planning the company could ever do.
The failure to frame the entire acquisition and implementation process in concrete, detailed business language that describes exactly what is to be accomplished – both in terms of present operations and future goals – is the first step toward failure.
So, the question “what are we trying to implement” leads to a couple of others:

• What are the risks involved, where do they lie and how will we manage them?

• How do we retain control of the implementation process?
• How is control usually lost?
• When is it lost?
• How do we avoid confusing knowledge with resources?

What does this even mean? In a nutshell, we often rightly perceive that we lack the knowledge needed to perform some task; in ERP projects, there will usually be many such tasks (often including management of the project itself). In every such case there is an implicit choice between learning the expertise required and renting it, but we can’t make this choice until we know we have it. All too often in ERP projects, missing knowledge is assumed to mean missing resources: we see ourselves compelled to rent people simply because we lack their expertise, ignoring alternative avenues of knowledge transfer. When we make this mistake, we often end up renting people who do (or at least charge for) far more than we actually need from them. Worse, we often turn over control of our project to the outside management of the people we rent (because how can we manage them if we don’t know what they’re doing?) This is compounded by three facts:

• Inevitably, some expertise must be rented in any ERP implementation project; meaning that we are already receptive to renting expertise and the people we rent it from are always willing to rent us more.
• Next, we do appreciate the very real costs and burdens (especially those of time and opportunity cost) of allocating and training our own people; we are reluctant to incur these costs and burdens because of

• the problems caused by making our own people available for what seems like optional work, and
• the apparently fleeting benefit of acquiring the missing expertise ourselves;

• and we don’t properly understand either the extent to which we’re renting more billable hours than we need or the full cost of renting expertise in the first place (especially in non-value added time purchased and the overall impact on the project in terms of risk and control).

Finally, we don’t know where or how to acquire the knowledge that we lack; often we don’t even know how to describe the knowledge that we lack.

• Who is going to do this work?
• What resources are required?
• What resources are we able to commit?
• What resources will we have to acquire?
• What absolute constraints in terms of budget and schedule are we going to impose on the effort?

Back to Table of Contents

Share and Enjoy

• Many of the things that ought to be done before most ERP acquisition efforts begin are deferred to the implementation phase, turned over to outside companies or never done at all.
• The goal of an ERP system acquisition (as opposed to an implementation) is often too narrowly perceived.
• The goal is seen as
• System selection
• Vendor selection
• Contract negotiation and signing
• Sometimes as implementation partner selection.
• Left out is the painstaking process of preparing for implementation success, which includes
• Defining what is to be eventually implemented in specific, concrete business terms that include
• Procedures
• Workflows
• Outputs (general as to format but specific as to minimum contact)
• Operating environment
• Transaction identification and definition
• Contractual responsibilities of
• The system vendor
• The implementation partner
• The company buying it all
• Anyone else
• Establishing continuity: capturing and preserving the
• Knowledge gained (by people who will continue on the project)
• Decisions made (and the reasons behind them)
• Promises made (and who made them) during the pre-sale activities, in a form that is not only available to the subsequent implementation phase but which is contractually incumbent on the parties involved in implementation.

A story that’s repeated far too often: a company diligently pursues an ERP acquisition. The selected vendor successfully acquires an understanding of the requirements and demonstrates, by means of a successful proof of concept event, its grasp of the requirements, its product’s fitness to fulfill them and its own abilities to configure the product. Contracts are signed and the implementation phase begins: but, somehow, the hard-earned agreements and knowledge acquired in the presale simply fade away. The implementation team fails to build upon the success of the presale proof of concept; often, indeed, it fails even to remember what was agreed or how that agreement was demonstrated. What went wrong was not what occurred in the presale phase: it’s what didn’t occur, which should have been a detailed, contractually enforceable plan of transition from acquisition to implementation. Continuity of purpose and understanding is not preserved by accident, nor by high hopes and good intentions; it is preserved by effective, contractually enforced mutual planning.
These are things that don’t happen unless managed in a coordinated way – which means, managed (1) as a project that (2) has the performance of these things as its predefined criteria for success.

Back to Table of Contents

Share and Enjoy

What will implementation vendors agree to, and when will they agree to it?

They will agree to just about any performance objective that they get to bid on, and that they believe they can achieve, but only before coming to terms; after an implementation project is contracted (and especially after work has actually begun) they will (rightly, in our view) perceive as intolerable interference any effort on the part of the buyer to direct activities and impose conditions of success. This is why every concrete expectation of the buying company should be expressed in detailed, unambiguous business terms in the form of a negotiated statement of work (SOW) that the implementation partner (1) participates in creating (an acquisition phase activity), (2) uses as the basis of their own quote and project plan and (3) agrees to be contractually bound by.

Vendors will agree to this – if it is declared up front as a requirement (to every potential vendor) for earning the business – because it protects them as much as it protects their clients. It protects them because it spells out (1) the precise definition of success and (2) the buyer’s commitments, especially in terms of (a) resources to be provided by the buyer and (b) the buyer’s obligations to pay for services received. Most of all, it relieves vendors of a responsibility that they don’t really want: the responsibility to decide how their client is going to do business, day to day. But vendors will only relinquish this responsibility when they recognize that their clients have firmly picked it up, and only require the vendor to meet precise targets that it agreed to meet before the deal was struck.

Back to Table of Contents

Share and Enjoy

• When a complex effort is split up, it’s no longer obvious in which piece any given task or concern should reside; it is normal for people to focus (focus is good, yes?), and to decide that, because we’re now focusing on something else, the concern that Charlie just brought up should be addressed elsewhere; but we can’t perform this evasion when there’s nowhere else to ship it off to.

To ignore any really difficult matter, however critical, all we need is even the provisional name of some other place to worry about it: but we’ll stop here, because this is beginning to sound like a web site 2.0 issue, isn’t it?

• In any complex effort, deferring the resolution of uncertainty from earlier to later phases of work will generally add cost and duration. It will do this for well known reasons that mostly relate to the question of “how much work do we have to do over when we finally realize that we have to change direction?”

Well, then:

• Any part of the whole ERP implementation effort that can be done early in the acquisition phase should be done early in the acquisition phase.
• But it won’t be if it’s already been relegated to a completely separate, subsequent project, will it?

Stand-alone acquisition projects often exclude activities that really should happen before any contracts are signed, usually by deferring them to the implementation phase.  Stand-alone implementation projects often start before essential terms of reference have been established.

Both these general evils come with many ill effects, but there is one that repeated time and again. A company diligently pursues an ERP acquisition. The selected vendor successfully acquires an understanding of the requirements and demonstrates, by means of a successful proof of concept event, its grasp of the requirements, its product’s fitness to fulfill them and its own abilities to configure the product. Contracts are signed and the implementation phase begins: but, somehow, the hard-earned agreements and knowledge acquired in the presale simply fade away. The implementation team fails to build upon the success of the presale proof of concept; often, indeed, it fails even to remember what was agreed or how that agreement was demonstrated. What went wrong was not what occurred in the presale phase: it’s what didn’t occur, which should have been a detailed, contractually enforceable plan of transition from acquisition to implementation.
We should address something here: we are often told that time is the enemy of any project, and for this reason many short projects are better than fewer long ones. This can be true, in more than one sense, but it is not a reason for separating ERP acquisition and implementation activities.

• We are discussing the entire effort involved in acquiring and implementing a new ERP system. If we split it into separate acquisition and implementation projects,
• In what way could the elapsed time of the entire effort be shortened?
• In what sense could the acquisition phase be deemed successful if the implementation phase fails?
• Time most threatens project success where work drags on without apparent results. One way to prevent that is to split up long projects, but well planned, publicly celebrated periodic milestones work every bit as well.

Finally, two last thoughts:

First, if you must fail, fail as quickly as possible. This is no less unpleasant than failing after months of false hopes, but it is a whole lot cheaper. So bring the hard work and the hard risks to the forefront and either learn the hard lessons as cheaply as possible or coast home to victory.

Second, whatever it costs and however long it takes to successfully acquire and implement a new ERP system in a single, coordinated project, after-the-fact review will never show that it could have been done more quickly, less expensively or with less disruption to operations if the effort had been split into multiple projects.

Back to Table of Contents

Share and Enjoy

We were all, buyers and sellers alike, expelled from that Eden in the ‘80s. Today nobody has anything like that kind of responsibility because nobody is expected to deliver anything like the entire project. Nobody’s expected to deliver it because nobody can. It is rare today even to see one party responsible for all the hardware (servers, network, workstations and critical peripherals). It is rare today even to see one party responsible for the application software, all the required modifications to it and all the contracted implementation services. Today it is unthinkable that the same vendor could be responsible for the whole combination of hardware, network, database engine, application software package and implementation, let alone for their coordinated performance.

If nobody is responsible for making it all work (that is, work together), then what are we responsible for?

Today we are all responsible for achieving isolated, individual performance targets; in most cases, we are responsible for living up to our own specs. But the sum of the individual specs is not a unified description of a successful system, let alone of a successful implementation project, and even if it were, which party, other than the buyer, could ever be held responsible for doing the summing up and making it work as a whole?
Is it possible to return to the era of single source responsibility (i.e., of meaningful liability)? No. How could it be, when no single company is responsible for all the pieces?

But that doesn’t mean that there isn’t an alternative to the usual current practice of holding vendors liable only for meeting local performance targets that are entirely independent of the success of the implementation effort for which their products and services are being acquired. This would require nothing more or less than the contractual linkage of vendor performance to project-specific, project-driven schedules and standards of performance. In fact, this is entirely possible, and in some places and in some kinds of projects it happens every day. It could also happen every day in ERP implementations if a few well-known principles and practices of project management were adapted, as they easily can be, in the acquisition phase of every ERP system.

Back to Table of Contents

Share and Enjoy