Your company is about to embark on a large-scale technology implementation -- an implementation that crosses multiple business units and involves hundreds of users. A lot of dollars and resources are at stake. And you are the decision maker . . . I've been there, more than a few times. Expectations were high. I was in charge. But, I also recognized that I needed some advice and technical expertise. Upon deciding that I needed to hire a consultant, questions arose: Would the executive team be reassured by the name recognition of one of the Big Five? What about a smaller firm that specializes in chemical manufacturing? How long would they need to stay? And what would it cost? Sometimes it feels like you might need a consultant to hire a consultant. As senior global business process manager at Dow Corning Corp., I've worked with my share of services firms, and while I can't tell you which firm to choose (the best fit really depends on your unique situation), I can share some lessons I've learned along the way -- lessons that can help you spot pitfalls to avoid, as well as help you make more informed, strategic decisions that lead to a positive engagement.
- Be specific about what you really need. Have you clearly defined your goals, your budget and the time frame in which you will need to complete the project? I know this sounds like a no-brainer, but sometimes the root of customer-consultant conflicts is as simple as not being on the same page. You need to be as detailed as possible when you sit down with potential services partners. Make sure that both you and they truly understand the scope of what is being asked for -- and that expectations regarding results are documented. Moving forward, don't immediately assume that a consulting company understands all of your organization's acronyms, or that you both are speaking the same language when it comes to even basic terminology. For example, "inventory" may have different meanings depending on the company, or even across separate departments within the same organization. "Semantic" differences can cause big headaches down the road, so it's important to define terminology explicitly up front. Equally important is having a person on your team who can translate highly technical language into layman's terms, so that the business side of your team is as much a part of the process as the IT experts. Leverage those closest to the situation as key contributors, as you can lose meaning through translation.
- Look beyond a single talent. At Dow Corning, our systems landscape is SAP-centric. It's therefore critical that we hire consultants with a high level of expertise with SAP solutions -- but that's just a starting point. It is equally important that a potential services partner is able to understand the business processes and challenges unique to our business. A few years ago, Dow Corning was an early adopter of SAP's APO (advanced planning and optimization) solution for supply chain planning and optimization. We were in a situation where we needed to upgrade to the next version of the software within a very short time frame, and we talked to a bunch of consultants that had experience with SAP in general. We settled on a specialist consultant with expertise in complex supply-chain projects as well as an understanding of chemical manufacturing, in addition to its knowledge of SAP APO specifically. A good consultant brings more to the table than just a technical skill set or experience with a particular software package -- it is the combination of business acumen and IT expertise that wins the day.
- Beware of the octopus. Revenue is important to any business, that's certain. But look out for firms that focus on generating revenue above all else. These are the octopuses -- they'll use your project to get their tentacle in the door, then attempt to throw their limbs around any other revenue streams that might be available. Rather than focusing on the project at hand, their primary driver becomes "what else can I sell you?" Look around you. Is your internal project team dwarfed by the number of consultants? A 1:5 team member-to-consultant ratio might be a red flag. But how do you know if the services firm you are about to hire is an octopus? Check references. Seek the opinions of research firms. Talk to your colleagues out there, and learn from their experiences, good and bad. It also makes sense to establish some safeguards when you do hire someone. For example, build a penalty clause into your contract that measures progress against pre-established metrics and deadlines. That way, if key milestones aren't met when they are supposed to be, your service provider will "share the pain."
- Knowledge transfer: Learn to swim before you jump in the pool. The single most important thing your organization should get out of a consulting engagement is knowledge transfer. A good consultant is like a good swim coach: He doesn't toss you in the water and head for the locker room -- he shows you how to use your legs to kick and your arms to paddle. Consultants should be more than willing to work side by side with your internal team so that they can learn what they need to know to best leverage and troubleshoot the technology once the services firm is no longer on site. What you don't want are consultants that become part of the furniture, or that leave your team so dependent on them that they have to be called back to throw you a life vest every time an issue arises. And, be wary of "back room" solutions -- where consultants go off by themselves and re-emerge with the "answer" -- chances are the knowledge that got them there will be left in that back room! At Dow Corning, we've created incentive-based contracts that make it worth consultants' while to spend the time and effort required for true knowledge transfer to occur. These incentives involve time deadlines and require sign off from Dow Corning that we are satisfied with the result. Another method that has worked for us is to have the consultants write the documentation that supports the project. Then, we use this documentation to test that all procedures and processes outlined make sense, to walk our team through how to apply them, and generally make sure that everyone "gets it." Do this while the services firm is still on board. You don't want them to go on to another project where those final, crucial steps surrounding knowledge transfer get overlooked because your organization is "out of sight-out of mind."
- Relationships make all the difference. If I have a positive experience with a service firm, I'm going to call it again. It's that simple. Consulting firms that I remember fondly are those that followed-up -- not to sell us more services -- but to let us know that they'd discovered a new way that we could troubleshoot a particular application, for example, or just to make sure that everything was working well -- no invoices involved! I remember firms that were sensitive to my budget concerns and found ways to meet project goals without letting prices spiral through the roof. Firms that made finding a solution to the challenge at hand their No. 1 priority. But as in any good relationship, you also want to work with a consultant that is confident and objective enough to always tell you the truth -- even when it's something you might not want to hear. Sometimes the toughest advice to take might end up being the most valuable.
