Adaptive Growth: Who We Are

Who We Are. We are business advisors for project management. Adaptive Growth’s business is to provide our clients with dense packages of highly specific knowledge about mapping strategic business objectives to business technology. Our approach provides for planning and managing projects to achieve some highly specific goals:

  • To develop and document market focused strategies
  • To integrate market focused strategies in an approach to acquire and implement business technology—especially ERP systems.
  • To develop Internet marketing strategies

Our emphasis is on project planning and project management, because we think that the success of these activities depends entirely on the successful planning and execution of projects designed to make them happen.  Our approach is to show our clients how to plan and manage these projects themselves; we provide direct project management services only to the minimum extent possible.  We are not consultants (though we have been).  Rather, we think of ourselves as advisors of project management, in that we only provide value added knowledge transfer and leave when that is done.



What is a Business Advisor for Project Management?

As business advisors for project management Adaptive Growth provides subject matter expertise and selected project management training to its client, in pursuit of a specific project. It differs from project management consulting in that the client manages the project; the advisor provides only the minimum of knowledge transfer that the client lacks. The benefits of this model are primarily economic.

Consultative project management is essentially a "burn rate" type of task, where the consultant bills the client for the duration of the project. Contracted project management is often the most expensive component of projects managed by consultants. After the fact reviews of such projects usually show that some of the consultant's activities are far more valuable than others. Furthermore, the proportion of valuable time provided tends to shrink as the overall project duration increases. The business advisor for project management model is designed to address this defect in the consulting model.

The business advisor for project management model is designed to provide only this valuable minority of time, with the client doing the non-value added work that is normally provided by the consultant. The advisory services provided always include subject matter expertise in areas that are at least somewhat unfamiliar to the client. In our case, we provide services related to market focused strategies, business technology and Internet marketing. Every such project is as unique as the individual client, but these projects do tend to take on a few general, high-level patterns. This allows us to start an advisory job with a significant body of tools and templates already in hand. We may also contribute knowledge and information about the practice of project management itself, but only if the client feels a lack in this area.


Back to top of question

Who we were.  Our backgrounds are in what is now called the ERP industry, in sales, in implementation project management and in development.  We've been doing this since the mid '70s, and if we could claim to never have made the same mistake twice, our powers would now be bordering on the supernatural. We've been directly involved in more than three hundred major software implementations in manufacturing and distribution companies.  We've been on the edges of many more, and software we've developed has been implemented in many times that number.  During these 30+ years we've seen many aspects of the industry change utterly, and just as many stay the same as they ever were.

 

What we've seen.  We've seen great successes, disastrous failures and everything in between.  Over time we've come to notice something that took us a while to focus on, just because we never expected to see it.  This is the simple fact that success or failure didn't seem to depend very much on which product was being implemented (even when it was ours), nor on who was hired to implement it (even when it was us).  Success seemed to depend, more than anything, on how the company that was paying the bills managed the entire process, from conception through final implementation.  And we've drawn some conclusions from this, which have led us to where we are today.  

 

What we’ve seen as a very significant change in the last thirty years has been the passage from single source solutions, where the (only) seller bore significant risk if the project failed for any reason at all, to today's environment, where

  • the buyer assumes all risk because
  • no seller is ever responsible for making the system work as a whole

 

What we’ve not seen change significantly in the last thirty years is the process to acquire and implement business software (especially for ERP systems).  Recent studies by the Standish Group show that 85% of all ERP implementations fail to some degree and 25% fail totally.  A significant number (60%) of the failures are mainly due to failed expectations.

 

We know why this has happened, and are happy to explain it.



The buying process has changed. 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 usWe 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 which means the precise definition of a company’s strategic business objectives integrated  to the business technology to be acquired.  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 top of question


The point is that some projects used to succeed, simply because sellers couldn't afford to let them fail, where now they are just as likely to fail, because no individual seller has either the wherewithal or the responsibility to make them succeed.

 

What that's led us to.  This has led us to re-examine the reasons why some projects succeed and others fail, and to do so in light of what has become well established in many quarters about how project management should be done.  We've found that it is possible to effectively reintroduce the responsibility for success into a project to acquire and implement business software and especially ERP systems.  In doing this we have invented nothing, but we have gathered quite a few things together that have been well understood for years and we have packaged them as deliverables of knowledge transfer that are now our stock in trade.  We'd be delighted to tell you more.

We believe that ERP implementations get into trouble because a few well reported causes of failure (that is, a few well discussed risks) often go unmanaged; we further believe that they go unmanaged because the kind of project management that has evolved over the years specifically to manage and contain risk is frequently ignored in ERP implementations.

At the highest level, the published surveys indicate that troubled (or “challenged”) ERP implementation projects fall into four rough categories:

  • The project is abandoned with nothing accomplished (25%)
  • The project is over budget.
  • The project is late.
  • The system is implemented with reduced functionality.

Symptoms as reported by users are most commonly:

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

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 – and it is the failure to discuss them as preventable risks that ensures that they aren’t prevented. Indeed, 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 them, we need to take an entirely different view, one that looks at the problem of preventing failure as an exercise in risk management.

The modern practice of project management incorporates the well-understood mission of risk management, which includes:

  • Identifying the risks to be managed (in the case of ERP implementation, these would be the commonly reported causes of failure listed above).
  • Planning to deal with them from the very outset of the project.
    • Prevent those that are preventable (a surprising number are entirely preventable)
    • Plan to mitigate those that may not be preventable
    • Identify the proper response to each of them, should they become likely to occur (up to and including early termination of the project)
  • Continuously monitoring them at every step.
  • Adjusting the project plan to cope with them if and when they first show signs of occurring.


Back to top of question


In Summary:
Since the single source purchase model, a single vendor who assumed responsibility for the whole project, no longer exists the process to acquire and implement business software, especially ERP, had to change significantly.  Unfortunately it hasn’t. It is for this reason that so many business software implementation failures are attributed to expectations that are not met after an implementation project has gone live.

We have determined that a significant reason for failure of a business system to meet enterprise wide expectations is the buyer lost control of the buying process because strategic business objectives were not defined and integrated into the business software acquisition process as the first step. If you would like to learn more about Adaptive Growth’s Approach to insure how business software expectations can be achieved using a unique (not newly discovered) process please click on the Contact Us tab. 

Background of Adaptive Growth’s Principals


Contact Adaptive Growth today.


Adaptive Growth, Inc.
2021 Midwest Road
Suite 200
Oak Brook, IL 60523
(630)443-7790 Office
(630)443-7796 Fax
jfrano@adaptivegrowth.com



Our Market:

Manufacturing and Distribution Companies



Overview • Market Focused Strategies •  Business Technology • Internet Marketing • Adaptive Growth Library

What We Do • Who We Are • Who We Serve • Pricing • Blog • Contact • Sitemap

© Copyright 2008 Adaptive Growth - All Rights Reserved.
Web Services by dcosgrove@adaptivegrowth.com