Few organizations can install or upgrade an ERP system without the help of an outside consultant. ERP deployment projects are so complex, and involve so many aspects of the business, that they demand the experienced hand of a consulting firm or system integrator with a long history of success. But the wrong consultant can waste scarce project resources and build an ERP environment that doesn't work for the organization--and in some cases, bring it to its knees. Steve Phillips, a member of SearchManufacturingERP.com's expert advisory board, has experienced the consulting relationship from both sides. In chapter 6 of his new book, Phillips shares dozens of tips for finding the right consultant and making sure the arrangement benefits the organization.
This excerpt from
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
Seventeen Consultant Myths and Half-Truths
When many think of ERP success, they think of software consultants. At the same time, when many think of ERP failures and budget overruns, they also think of consultants (but not in such a favorable light).
Having spent the majority of my career in the shoes of a software consultant or an industry practitioner, I often wonder why many find it necessary to perpetuate the old myths and half-truths regarding the consultant/client relationship. Given the track record of ERP, we are not doing anyone any favors. We are causing more harm than good by setting the wrong expectations regarding what consultants are, what they are not, and what the organization should be doing.
My theory is these myths are self-perpetuating. Consultants want their clients to believe them (more billable hours), and their clients desperately hope they are true (even though deep down they know better).
Understanding the myths and half-truths can determine the level of consulting support required and the organization’s responsibilities during the project.
Myth #1: Consultants will make us successful.
Truth: Consultants can educate, suggest, coach, and do the tough tasks, but cannot make their clients do much of anything. For most of the ERP critical success factors, consultants have no direct authority or control over the outcomes.
Myth #2: Consultants should take the project leadership role.
Truth: Whoever leads also owns, and consultants cannot own your project even if you insist they do. In addition, there is a big difference between facilitating a project versus doing it. On many projects, the consultants do everything, and the project team learns nothing.
This does not go unnoticed by employees. Many consulting firms grab and run with the project, and then wonder why employees are not committed, are disengaged, or resist the proposed changes. The employee attitude becomes “Great, go forth, and excel! We will point out the landmines once you hit them!” It is amazing how many do not understand this basic concept of change management.
Myth #3: Consultants are all-knowing.
Truth: Just because you pay someone $200/hr does not mean they know everything. Many naively assume all consultants are geniuses and later find out they are far from it.
There are many inexperienced consultants out there, but even the best ones will admit they do not know everything about the software. In addition, since every project is different, the application of the software tool is not identical in all situations. Even if the consultant understands many aspects of the system, it is unlikely that he or she has experienced all potential usages.
Furthermore, no matter how much analysis consultants do, they will never know the business details and issues as well as your employees. When the project team is not fully engaged or not adequately trained on the software, the system design will miss the mark.
Myth #4: The more experts, the better.
Truth: Most projects do not need more experts—they need more solutions. It is not a good sign when, in the middle of a project, we suddenly need more consultants.
Too many consultants can crowd out or disempower the knowledge and experiences of employees that could play a larger role. Have you ever heard “No one is listening to my concerns” or “Joe seems to be clamming up”? When these statements come from creditable employees, this means that either there are too many consultants or they are not good listeners.
Myth #5:Consultants from expensive or prestigious firms have more insight.
Truth: The prestige of some firms might provide senior management with a good feeling and their consultants might be smart, but this does not mean they know anything about the software.
Myth #6:A consulting firm’s track record with other clients says it all.
Truth: A vendor’s record of accomplishment is important, but all firms have a few skeletons in the closet. At the end of the day, the only thing that matters is the knowledge and experience of the individual consultants working on your project—not someone else’s.
Myth #7: Fixed price and progress payment engagements are risk free.
Truth: Anything that makes consultants more accountable is good, and there are plenty of ways to do this. However, if you can get great consultants for a very low fixed price (as seen on TV!), with few contract loopholes and a clear definition of their responsibilities and deliverables, hurry up and hire them. But good luck in finding such a deal (and watch out for the pitfalls discussed later).
Myth #8: Consultants with the best price and fastest implementation must know something that other firms do not.
Truth: Often, the opposite is true. An excessively low quote never helped any customer even when their management insists on a lowball schedule and price. It is best to hire consultants with the right skill and experience, who set realistic expectations with management and can deliver on their promises.
Myth #9: Implementation tools and templates make for better firms and consultants.
Truth: We definitely need tools since anything that makes life easier is helpful. The problem is most tools do not address project tasks that are the true bottlenecks.
For example, the intangibles of discovery, decision-making, and issue resolution drive the timeline, not how long it takes to physically set up the software. Also, any significant amount of custom software development such as modifications, data conversions, or interfaces is usually on the critical path. Tools and templates are not much help in speeding up these activities.
It is common when implementation tools are impractical to apply, full of bugs, or in the hands of consultants who do not know how to use them. This may even delay a project, or the tool becomes expensive shelfware.
The availability of more tools has affected hiring practices within many consulting firms. There is a misguided belief that one can hire smart people off the street and turn them into instant application consultants. Unfortunately, for their clients, it does not work that way.
Myth #10: A software consultant is also a good business analyst.
Truth: Understanding ERP software is one thing, but knowledge of industry practices and how to redesign business processes is another. The key is how the software is used in conjunction with redesigned workflows, new policies, roles, etc. Again, there is no such thing as a turnkey solution.
Myth #11: Consultants will transfer software knowledge to the project team.
Truth: In spite of these promises, do not count on it. There are a dozen reasons why knowledge transfer may not occur and many relate to consultants.
Myth #12: We need more software consultants because we lack the internal knowledge and skills.
Truth: Maybe, but most organizations are capable of doing at least 30% of what software consultants are paid to do (much of which requires, little, if any knowledge of the system). With a knowledge transfer plan, most companies can do even more. This includes many of the software tasks traditionally performed by software consultants.
Myth #13: We need more software consultants because we cannot free up internal resources to participate.
Truth: Many consultants and managers too easily accept this as a rule; but if you look hard enough, get creative, and stop doing things within the company that add no value, plenty of internal resources may magically surface.One thing I discovered is when senior management really wants something to happen, they find ways to free up the right resources to make it happen.
Myth#14:Hiring new employees or training existing employees to fill application-consulting roles cannot be cost justified.
Truth: Not so fast. As mentioned before, the average time to implement ERP is one to three years. This is just the beginning since most companies will run their system another eight to thirteen years. Over this period, the cost of outside consulting support can really add up (if the goal is to support the system and users, and continue to leverage your software investment).
Myth #15: Once the project begins, the consultants will manage themselves.
Truth: Bad idea. Software consultants do not always operate with the correct assumptions about your business or make the right decisions, and sometimes they do things that are not in their client’s best interest. Consultants must be managed.
Myth#16:Consulting firm management will be frank and honest with your senior management.
Truth: The good firms will be honest, but some do not want to deliver any bad news to senior management for fear of falling out of favor.
Myth #17: If the project fails, we can always blame the software consultants.
Truth: Yes, consultants are punching bags for some (and at times for good reasons). But when it comes to ERP disasters, internal folks rarely get off the hook easily. Even if lucky enough to escape the initial political fallout, do not forget the “walking wounded”, whose careers are ruined.
Primary Service Provider
The primary implementation service provider is the firm selected for project management support and the majority of application consulting. This is the core of the consulting team, and they must be on the same page at all times.
On some projects, the primary vendor also manages other consulting companies and contractors involved. While all consultants must coordinate and play well together, the concept of consulting firms managing other consulting firms is never the best approach. Again, the internal project manager should manage all vendors.
As a general rule, the fewer firms and consultants to obtain the necessary expertise the better. Fewer vendors means fewer points of accountability, more consistent approaches, better communication, fewer hand-offs, and less finger pointing. This adds up to a project much easier to manage and with less built-in inefficiency.
Also, be aware that some firms use independent contractors to fill the need for application consultants. This is not necessarily a problem, but it is important to know the extent to which sub-contractors will be used.
A few independent application consultants are fine since many are well qualified. If you hire them directly (instead of through the primary firm) there are also cost advantages. Nevertheless, when the majority of the application consultants are sub-contractors, this amplifies all the risks noted above.
Another potential problem is that independents are more likely to be juggling other customer priorities outside the primary firm’s or your ability to control, possibly leading to the consultant not being available as planned.
Hiring qualified software developers/contractors from other firms is usually of minimal risk and saves money. For example, a cherry-picking developer from “body shops” or other sources is usually not an issue when they are brought in at the right time and properly managed. Unlike application consultants, these resources play a more limited role and focus on completing specific programming assignments.
Types of Consulting Firms: Pros and Cons
There are three basic classifications of primary service providers: 1) The ERP software vendor, 2) A “Big Five” type firm, and 3) A third-party independent firm that specializes in the package. These are usually small to medium sized “boutique” shops.
Again, a few independent contractors can be used to augment the consulting team, but by definition, they are not the primary service provider.
Of course, each firm and consultant should be evaluated on an individual basis. However, based on my experiences as a software consultant and working with various software consulting companies over the years, my opinion of potential advantages and disadvantages of each type of firm are:
ERP Software Vendor Consultants
• Single point of accountability for the ERP software and
• Well-developed implementation methodologies, processes, and
• More consistent level of application consulting expertise that
tends to be better than average.
• Ease of consultant access to technical support resources within
the vendor organization outside of formal support channels.
• More technical support resources.
• Dedicated training facilities, resources, and formal training
• Potentially will make unique software customizations for
their customers that later become part of the standard product
• Can be the only option available.
• Can be more expensive than third-party independent firms since
the software vendor is often viewed as the safe choice.
• Project management consultants are prone to be “generalists,”
perhaps providing less value add in application or technical areas.
Big Five Types
• More methods and tools for preparing consulting quotes, perhaps
leading to a more realistic quote.
• Usually, firm management is more experienced to provide project
oversight and guidance to the executive steering team and the
project management team.
• Typically, additional areas of industry and process expertise
within the firm (when truly needed).
• Well-developed implementation methodologies, processes, and
• Overall less experienced application consultants due to the
common practice of hiring college graduates with no previous
ERP software experience.
• Usually, much more expensive.
• Perhaps fewer technical resources available within the firm.
• Greater tendency to push additional services that are not required.
Third-Party Independent Firms
• Typically, software consulting for the package is the only goal
of the company (do not consult for other packages or develop
software-potentially diluting focus).
• Perhaps the best value, considering their level of experience and
• Project management consultants tend to be more hands-on since
many have application consulting experience.
• Greater propensity to lowball quotes for competitive reasons.
• Possibly less consistent use of implementation tools from project
• Fewer application consulting resources available (or heavy use of
Local Versus Non-Local
Many place too much emphasis on the desire to have local consultants. Early in the consultant selection process, do not exclude any firm from consideration because of potential travel cost (unless the distance is very unreasonable).
The first criterion is the quality of consultants available, second is the hourly rate, and third is travel cost. When a consultant is bad, it does not matter if he or she is local.
In addition, it is not always necessary for the consultant to be at your location to interact with the team or the system to complete important work. There are many ways to minimize travel costs; thus, local vs. non-local should only come into play when other factors are relatively equal.
The Consultant Selection Process
The search for a primary service provider should begin with the two package finalists. With some packages, there is not much of a choice other than the software vendor’s consulting resources.
In general, a subset of those evaluating the software should also evaluate consultants. In addition, during the evaluation, no consulting firm should have access to senior management until the team makes its recommendation.
Evaluating the Actual Consultants
The consulting firm’s track record does matter. But as said before, what really counts is the quality of the individual consultants that will work on your project. Selecting a consulting firm is a bottom-up evaluation starting with each consultant.
Beware of the pre-sales “window dressing”, where certain consultants are brought in to display the expertise within the firm. They may know best practices and the software, but it might be the last time you see them—the old bait and switch routine.
All too often, many companies do not truly evaluate the qualifications or other attributes of the consultants proposed. They assume consultants are consultants and, more or less, all are created equal. But this is usually not the case. Not only should you evaluate their knowledge and experience, but their soft skills can make a difference in how effectively they work with clients.
First, request the resumes of proposed consultants and review them as you would a candidate for an important employee hire. Make sure the resumes are specific in terms of experience, skills, software modules, and client successes. Many resumes presented by consulting firms are not really resumes, but profiles that read like sales literature.
Next, do an old fashion interview and ask the tough questions. Make sure decision-makers (the project manager, IT manager, and those on the project team that will work directly with each consultant) are involved in the interviews.
The firm should have a list of every account the consultant has worked on over the past three years. Start making the phone calls, and when possible, speak with their project manager or functional analyst that worked directly with the consultant.
Finally, recognize that consulting firms propose consultants for new projects based on their current availability. When not completely satisfied with the consultants proposed, insist on better ones, and not just those currently on the bench. There might be better consultants immediately available or soon to come off another project. In the latter case, perhaps the firm can make them available much earlier than planned.
Evaluating Each Type of Consultant
There are five areas to evaluate when selecting the primary services provider including the firm management team, project manager, application consultants, software developers, and technical support. In this chapter, the focus is on the first three.
Someone within firm management, a partner or practice leader, should periodically attend Executive Steering Team meetings. The responsibility is to work with senior management as a peer to help guide the project down the right path.
Consulting firm management must be able to quickly gain the confidence of executives and have the ability to provide solid direction, education, and coaching at that level (and with the project management team). A good consulting firm can maintain positive relationships with senior management while also recognizing the customer is not always right.
The next role is that of the project management consultant. The organization is ultimately responsible for managing the project, but likely needs at least some project management support from the outside.
Look for these qualities in any project management consultants:
1. Has extensive project management experience with the ERP package selected.
2. Has managed at least three other projects of similar scope and complexity.
3. Has previous experience as an application consultant for the package selected, indicating ability to get into the details when necessary. The PM consultant must be more than just a meeting organizer.
4. Possesses knowledge and experience with the implementation methodology, including the purpose of each phase and deliverable. If they cannot communicate this at a sufficient level, they cannot manage the project.
5. Understands the key techniques to control the project. (see Chapter 19).
6. Demonstrates knowledge and experience with organizational change management strategies. Ask for the techniques or examples used on other projects.
7. Has experience with knowledge transfer strategies. Beyond formal project team training, what is necessary to ensure that software knowledge is transferred to the team during the project?
8. Possesses the ability to effectively coach and mentor the client project manager and steering team.
9. Can work effectively at all levels of the company (senior management, project team, functional managers, and end-users).
10. Sets realistic expectations with senior management.
11. Has good interpersonal and communication skills.
Each application team requires a person to fulfill the role of an application consultant. Look for these qualities when hiring an application consultant from the outside:
1. Has previous consulting experience with the assigned module on at least three other projects of similar scope, level of complexity, and industry.
2. Has business analysis skills.
3. Is able to provide direction and leadership.
4. Views the transfer of software knowledge to the client team as a priority and can explain how it will occur.
5. Is familiar with the firm’s implementation methods and tools (or experienced enough to easily adapt).
6. Possesses soft skills including being a good listener, communicator, and coach. A consultant that does not listen may harbor preconceived solutions that are not the best for your business.
7. Fits the company culture. A software consultant should challenge the status quo, but not alienate people in the process.
8. Has some project management experience. An application consultant should know enough in this area to coach your project manager when necessary.
9. Has been certified on the ERP package, but actual experience is more important (certification is a plus).
A Real Methodology?
Any consultant who is experienced with installing ERP systems and understands the package can work with any implementation methodology. But it is always best when the firm has a consistent set of methods, tools and deliverables they use on every project. Time-tested implementation processes improves efficiency and communication within the entire team.
During the sales process, most firms present PowerPoint slides with a few bubbles and arrows that depicted their major software implementation phases, but for some this is about as far as it goes. Other firms sell their clients on the benefits of their implementation methodologies and tools, but then do not practice what they preach.
In either case, this is when the project management consultant later determines the actual implementation process. Depending on the experience of the consultant, the results can be somewhat unpredictable.
While there will always be some variation in approach, ask for examples of templates and deliverables used on other projects (with different project managers). These should be similar to the deliverables discussed in the next chapter. Also, have the firm demonstrate their tools, investigate these during reference checks, and ask each consultant if they have previous experience with the methods proposed.
Realistic Sales Quotes
Consulting proposals (quote, statements of work, engagement letter, etc.) contain estimates of project timelines and consulting costs. It is in your best interest to insist on realistic estimates since the organization has the most to lose if the numbers later prove to be severely underestimated.
Prior to selecting ERP software, we addressed the importance of documenting project-planning assumptions, risks, and constraints. Now is the time to refine this list since unlike software quotes, consulting bids are more subjective and driven by the experience of the person estimating. It is important that all firms bidding on the project have the same understanding of the project.
Estimates will always be just estimates, but perhaps equally important is that all planning assumptions should accompany all final quotes. No doubt, the consultants will ask questions and when bidding and uncover more assumptions to add to your list. But the organization is responsible for ensuring assumptions are valid and the same for all vendors quoting.
In addition, always investigate major differences in the final quotes since the project timeline and consulting hours should be fairly close. For each consultant, estimated hours should be presented in weekly buckets within each phase over the entire project (i.e., phase/consulting role/weekly hours). This requires the firm to link consulting hours with the timeline, and the type of role and work each consultant will perform during each phase.
For application consulting estimates, make sure the quote reflects their involvement in new software development. Application consultants are required to write programming specifications and test any type of custom development. Often, application consulting quotes fall well short of the time required in these areas.
The Fixed Price Game
Most consulting firms avoid fixed price and progress payment projects for valid reasons. First, most prefer not to get into the exhaustive contract wrangling required for these deals.
Second, once the project is complete, there is a good chance the software functionality delivered and the implementation cost will not meet their client’s original expectations. Finally, most firms do not want to assume the risks associated with a client that does not deliver on their responsibilities.
Even when consultants quote a fixed price, it must be realized that most are only fixed until further notice. This is because most firms are better than their clients are at writing software consulting contracts. No matter how well you dot the i’s and crosses the t’s, the verbiage is always open for interpretation, and debate, and scope creep is inevitable. The result is expensive change orders.
When it is possible to lock a firm into a price that is truly fixed, keep in mind that consultants are in business to make money. The fixed price probably has plenty of fluff, and you will not get a refund if the project requires less consulting hours.
The “not to exceed” clause adds little comfort. One thing is for sure, consulting hours will expand to fill all available space. When this occurs, you might have been better off going time and material.
In addition, most consultants are very good at making software function to meet the bare bones language of any agreement. There is a high probability that the functionality will be delivered, but not to the level required by the business.
Finally, ERP software is unforgiving. When we rush or cut corners to meet arbitrary dates or budgets, there is a price to pay later.
Of course, this is not to say fixed price or progress payments never make sense. They are tools in the toolbox but tend to apply more to projects of very limited scope. In no case are these agreements a substitute for taking ownership of your project, nor do they reduce the need to manage your consultants.
Implementation Services – Contract Tips
The following are a few additional tips when negotiating the consulting services agreement:
1. Firm partners and practice leaders are non-billable.
As mentioned, a partner or senior manager of the firm should provide periodic guidance to the executive steering team and project manager, not just make grand appearances and soak the customer for more money (their rates are much higher).
In fact, the time of a firm partner or practice manager should not be billable for this limited time spent on the project. One reason is some already receive bonuses or a percentage of billable hours generated from the account. Also, they are executives of the firm. Unlike application consultants, for example, firm management has a major stake in project success that goes beyond billable hours. Once the word gets out of a project failure, this can hit a firm partner right in the pocket book in terms of future sales.
2. Do not pay for consultant schedule changes.
Some vendors want a commitment for a certain number of hours per week for each consultant to ensure availability. They next want to charge you for schedule changes. Never accept this! If their consultants are not available, do not hire the firm in the first place.
Alternatively, work with the firm to develop a schedule for consultants based on your needs. Again, each consultant should have an estimated number of hours per week over the entire project as a starting point. However, the number of hours provided each consultant will vary by project phase and will change based on actual project needs. Of course, there should be an attempt to minimize changes once the schedule is firmed up and provided to each consultant, but it does happen. In fact, the consultants will probably change the schedule more than you will!
3. Do not pay for consultant learning curves.
For example, one may hire a strong application consultant who is not familiar with a new implementation tool to be used on the project. This is not necessarily a problem, if the company gets a reduced rate while the consultant is learning it.
In addition, tag-along consultants (shadowing other consultants for the sake of learning) are fine too, but the hourly rate for the primary consultant should be lower for a period to recognize the time spent teaching the other consultant. Also, the trainee consultant should not be billable when in learning mode. When a tag-along consultant is productive, their rate should be lower to reflect less experience.
4. Expect accurate time reporting.
We want accurate billing, whether this means more hours billed or less. Consultants should bill by rounding their time to the nearest tenth of an hour. Many round up to the nearest quarter hour. This may not seem like a big deal, but do the math. If four consultants for twelve months are billing just one extra hour a week because of rounding, this will cost the company at least $35,000.
5. Off-site work must be pre-approved.
A project like ERP cannot be successful if the consultant is mostly working long distance. The majority of consulting time should be on-site to enhance focus and communication. Of course, there are times when a consultant does not need to be on-site to be productive, so take advantage of these opportunities when they arise to reduce travel cost. Any work to be performed off-site should be approved in advance by the client project manager. We want to void invoice surprises.
6. Define what else is non-billable.
In addition to the items previously mentioned, be specific in the contract regarding other consultant activities that are not billable. Non-billable time should include travel time, breaks/lunches, and any communications with other clients while supposedly working on your project (watch out for this one).
7. Place reasonable caps on travel expenses.
Place a reasonable limit on travel and living cost including airfare/trip, hotels, meals, and rental cars. The project manager must approve any deviations to these limits in advance. In addition, negotiate discount rates at a good hotel nearby, to reduce travel expense.
8. Do not agree to the administrative fees.
Never agree to pay an invoice mark-up to cover the firm’s “administrative time and supplies costs” while working on the project. This is the firm’s cost of doing business, and their consultants will probably use mostly your materials and supplies anyway!
9. Retain the right to terminate without termination charges.
The company should have the right to terminate any consultant at any time and for any reason with no termination charges. A few weeks advanced notice is reasonable.
10. Additional considerations for fixed price or progress payments.
On any project, the sooner we get into the project details the better information we have to make decisions. But when a fixed price or progress payment agreement is the right choice, go much deeper into the project assumptions earlier and incorporate them in the contract. This means more analysis and consensus on all the project planning deliverables before signing any contract.
This is not to say one should shortcut these items for time and material projects. In either case, we want good estimates to avoid major surprises. But on time and material contracts, it is acknowledged by all parties that the true time and cost “is what it is.”
On fixed price or progress payment projects you will get something for the price or progress, but it is important to understand what something means. It is all about what is to be delivered for the cost incurred.
Therefore, pay special attention to all areas of the project scope, especially the list of software features and functions and any custom software development included. Equally important, are the list of deliverables for each phase, what each should look like, and who is primarily responsible for each (consultants or the company).