Adaptive Growth Infrequently Asked Questions

Answer: Because

• 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.

For more information, contact us.

Answer: There is no argument that an ERP implementation project is a project, and (somehow) should be managed as one.  There is very little argument that implementation providers should manage the day to day efforts of their own people from within projects that their own organizations manage.  But often there is a failure by the company with the most at stake – the company buying the system – to manage (and understand why it should manage) the overall implementation effort (including the implementation partner’s sub-project) as a single project that it controls.  When the company buying the system drops this ball, vendors don’t give up and go home: they move in to take control of the implementation in the only ways they can.

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.

For more information, contact us.

Answer: First, let’s consider two general properties of large scale, coordinated work:

• 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. (See question 8, above.)

Stand-alone implementation projects often start before essential terms of reference have been established. (See question 9, above.)

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. 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.

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.

For more information, contact us.

Answer: Once upon a time, major business software implementation projects were single source affairs, in that the buying organization selected a single vendor who assumed responsibility for the whole project, except for the pieces under the direct internal control of the buying organization.  “Responsibility” has many aspects, none of them unimportant, but of the first importance here is the matter of liability.  Back in that perfect world, not only were we young but we were unimaginably responsible by today’s standards – all of us – for one simple reason: a failed implementation meant personal disaster for us.  We were liable if the whole thing “didn’t work”, whatever that meant in any particular case; it said so in the contract – the one contract that defined the entire effort – and nobody was going to let us off the hook.

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.

For more information, contact us.

Answer: It is very wrong but very common to view the goal of an ERP implementation in terms of implementing software, or a particular brand of software, or a particular configuration of a particular brand of software.  This view is a recipe for disaster, because any ERP package worthy of the name can be implemented in countless ways that conflict with the interests, goals, processes and procedures of the company acquiring it.  By contrast, there are only a very few ways it may be implemented such that it advances any actual company’s combined set of  interests, goals, processes and procedures. 

A company’s processes and procedures can be documented independently of its interests and goals; they can be, though they often aren’t.  But it is hard to claim that a procedure is thoroughly understood unless we can also be sure we understand why we’re doing it.  Policies and procedures exist to advance goals and interests, not (outside of a purely bureaucratic world) for their own sake.  This becomes important in an ERP implementation when it is not entirely clear exactly how a particular current procedure is to be realized in the new software being implemented; it can be very difficult to choose between alternative methods when we’ve lost sight of the goals we’re trying to achieve.

A strategic plan is a statement of a company’s goals and interests that connects to the everyday world of policy and procedure.  If we don’t have such a statement, or have one but don’t use it when we plan an ERP acquisition and implementation, we will not be supporting the company’s best understanding of its goals and interests. At best, we will be serving one or more lesser purposes that turn out to be surprising empty when you try to squeeze their meanings out of them.  For example, at high levels of the project such stand-ins for genuine goals (sometimes called “bogies”) might include:

• Implement Orasap version 16.2
• Replace the current Accounts Payable process (probably while “upgrading Accounts Payable functionality”)
• Improve our access to our supply chain
• Leverage advances in technology
  
  

At the levels where most people are working, these high-minded aspirations are replaced by apparently more concrete targets that tie to no goal higher than themselves:

• Rewrite the AP492-D report for the new system.
• Map the current sales order maintenance procedures to the OE429F module.
  

Nobody is really in business to achieve such “goals”.  They aren’t really goals at all, are they?  But they’re all we have if we’ve lost sight of our own real goals and interests.

For more information, contact us.