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.

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

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