The answer to the question "Which is best, consulting or training?" is clearly "Both."

MC Press Online Editor's Note: The following article was previously published by Klee Associates, Inc., publisher of JDEtips Journal and ERPtips Journal and ERPtips Express.  A sample issue of either journal may be requested by clicking the respective links. 

Klee Associates Publisher's Note: We asked CJ Rhoads, our CIO Corner writer, to explain the relationship between consulting and training in a "typical" ERP implementation. CJ's unique point of view should help clients get greater results from their investment in outside services.

Over the years, I have done thousands of training sessions and hundreds of large consulting projects. In this article, we'll go into the best practices for how and when to use these two valuable services; but first, allow me to define the difference.

What Is Training?

A training session has a set outline of topics to be covered. There are two types of training sessions: seminars and workshops. A seminar typically has one or more people with expertise speaking. A workshop is typically more participative with hands-on exercises and activities.

Training also has a set time period and location. Training typically lasts from three hours (minimum) to several weeks (maximum, though the weeks may be spread out to take place over several months).

What Is Consulting?

Consulting, on the other hand, does not have a set outline or time period. While usually focused on a domain of knowledge, consulting typically is not limited to a specific topic. Rather, consulting usually has a scope (how large or small) and a goal (what the client hopes to achieve). Then, within the consulting project, a plan is developed to achieve the goal. Resources are utilized as necessary.

Blurring the Lines

I make these distinctions and yet, throughout my entire professional life, I have blurred the lines between them. When I am hired to do a training session, I strongly resist any attempts on the part of the client to restrict what I cover during the session. I prefer to find out what the participants need in terms of knowledge, delve into my years of experience, and dynamically construct an outline of topics that will directly meet their needs.

Trainers who are also consultants tend to prefer working this way because it takes less preparation and gets them better evaluations (hence consultants are always in demand as trainers).

I also blur the line when I do consulting. Typically, I am hired on a retainer basis for year-long projects. But for the majority of those projects, I train my clients on many things; improving leadership skills, enhancing operational or marketing strategies, managing or aligning information technologies, etc.

Iterative Cycle of Training and Consulting

When should you choose training and when should you choose consulting? One item to consider is that the value received from each dollar of training is greater than the value received for each dollar of consulting when you take into account the number of people directly impacted. For example, one week of a consultant's time might cost $7,000. The consultant may interact with different people at different times. So let's say he or she is working with an average of two client employees at a time; in that instance, the average per person cost is $3,500 for the week. A week of training for 10 people might cost $15,000; the cost per person benefitting from the training is $1,500.

Be aware that training cannot identify a need. If you are not entirely sure what you need, consulting is a better choice. If you know what you need, training is more financially appealing because it provides better value.

Good managers in organizations consider training and consulting as an iterative, never-ending cycle. They hire a consultant to help them determine what they need. Then, if time permits, they use training to develop the skills to fulfill that need. Then they return to consulting to help identify what they need next.

Some companies have a tendency to rely entirely upon consultants for both diagnostic and training needs. That's not too much of a problem, although they may be spending more money than absolutely necessary. Other companies have a tendency to go from training session to training session without ever diagnosing the real need. For example, years ago I discovered that one of my clients had been sending their IT people to a course on programming in the language of their financial system (which at the time was PL/B). The general manager thought that by having the IT people trained on the programming language, they would be able to fix their never-ending problems with the inventory systems.

When I took a look, I found that the problem was clearly bad data (garbage in, garbage out--a common issue), not expertise of the IT people on the programming language. All of that training was wasted. The company would have been much better off focusing on cleaning up the database of inventory items and standardizing data entry for new items (which I recommended, of course).

Typical ERP Project

Let's take a look at the balance between training and consulting during a typical ERP project.

Initially, an organization really does not have any idea what they need regarding their ERP solution. They don't even know if they should consider an ERP system. If they should consider it, they don't know which ERP system they should look at. For those topics, they need a consultant. (Of course, they should be looking at an independent consultant, someone who is not associated with any one particular vendor or receiving referral fees from any vendors.)

Then, once the consultant has identified which system they should implement, it makes sense for the organization to learn more about the system before they bring in a team of consultants. Of course, most companies do the exact opposite; they hire the consultants and learn about the system from them. I recommend a different approach, one that is rarer but I think more productive. Once the system has been identified, the best option is to send the managers and IT staff to training classes. Yes, before they've purchased and started implementing the system. The client will learn the features of the new system and start making their list of issues/gaps to be addressed during the consulting phase.

Typically, corporations hire consultants to take the primary role in identifying business requirements and implementing the system, ostensibly because their own people are too busy to do so. The resulting lack of up-front client knowledge about the system is a primary reason that so many ERP system implementations fail. No matter how much industry and software expertise consultants have, they cannot possibly know all of the cultural and operational issues involved in the smooth running of your organization. The only people who know the operations are the employees who are currently doing the job. So it would be ever so much better, at that point in time, to either send the employees to training on the system that has been chosen or to bring training services onsite.

Once the employees (or rather the client's internal project team) are fully knowledgeable on the overall capabilities of the chosen system, then they are equipped to have knowledgeable conversations about the business requirements with the consultants. They will save many times the cost of the training because the consulting fees won't be as high. When working with knowledgeable employees, the consultants will be able to accomplish their goals in a fraction of the time usually needed.

Therefore, after training has occurred, it makes sense to hire experienced implementation consultants to document the business requirements and configure the new ERP system with the help of the client project team. The years of knowledge and implementation experience the consultants bring to the table cannot be duplicated by the client with a few weeks of training.

Once the system has been implemented, it's time to send the end user employees to training, this time to learn how to actually use the system on a day-to-day basis. At this point, training customized to match your day-to-day operations is much more productive than generic training in the system (which was fine previously, when there was no actual system in place).

Stages After Implementation Go-Live

The CEO for a prominent technology firm recently shared with me his description of the stages after installation of a new ERP system. Let's take a look at the table below. In the column titled Traditional: Consulting and Training Then Internal Support, I listed the CEO's description of these post go-live stages. Now, let's compare this side to side with my illustration of how these stages might look if the CIO had viewed the training/consulting/training as an iterative cycle.

Keep in mind that iterative projects cost less to implement because the training done before bringing on the consultants avoids time wasted by the consultants trying to find out what you need; you already know and can tell them in much less time.

Which Is Best?

The answer to the question "Which is best, consulting or training?" is clearly "Both." A good leader balances the two by bringing in expertise in order to identify the needs and then, when appropriate, bringing in training once the specific issues have been identified.

Training is involved in the iterative cycle both before and after consulting. Internal staff learn what they don't know and start thinking about how to use additional functionality. Then the consultants help the client team implement it. Ongoing training is conducted while the system is stable and internal staff are working on ways to improve it. And on and on and on. Clearly, it's the best of both worlds.