In my previous life in corporate IT we engaged consultants on many different projects, so I thought I had a good handle on what it takes to make a consulting engagement work. Then about six years ago I made the jump from the corporate IT world to working as a consultant and many of my assumptions were proven to be dead wrong. Since that time I’ve delivered dozens of engagements as an individual contributor, and in the last year taken on leadership of Alfresco’s global consulting organization. Now that I have seen the consulting world from several angles, I have come to realize that there is quite a bit that the companies that engage consultants can do to get the most out of their time. A few do’s and don’ts:
- Make sure that your project team knows that the consultant is coming, and have them block off the time that the consultant will be engaged. Consultants bill for their time, and every hour that they are idle is wasted money.
- Ensure that you are prepared for their arrival. When you are planning the engagement, have a conversation about prerequisites. What system access is needed? Will on-premises resources be required? Do you need to set up shell accounts? AWS accounts? A good consultant can give you a checklist of things to have ready when they start the engagement so that you can hit the ground running.
- Set up stretch goals for the engagement. Good consultants do their best to make sure the time estimates for tasks are accurate. Sometimes things progress faster than expected, and it pays to have a few stretch goals in mind if you find yourself with extra time. Keep these off the statement of work though, and don’t add them to the engagement scope until it is absolutely certain that the original work is complete. Speaking of scope…
- Be diligent about the scope when designing the engagement and stick with it once the engagement is underway. Tangents can be productive, but they are often productive in the wrong areas. You consultant has likely done their engagement prep based on the scope defined in the statement of work, and shifting that scope will distract from the core work. If you don’t know what you don’t know, consider a shorter discovery engagement first and use the findings to build a more complete scope.
- Outline your documentation requirements and build in time to complete them. Is the work mostly code related? If so, the documentation might be in the form of comments and completed code created in conjunction with your dev team. Is the work architectural or more strategic in nature? A more formal engagement report and executive summary might be in order. Either way, make sure you and your consultant are aligned on expectations here and leave time to get it done.
- Entertain the idea of remote work. Eliminating travel can keep the cost of an engagement down. In addition, most consultants build in travel time for their on-site work. If you go remote you can use those hours to get stuff done instead.
- Train up in anticipation of the project. If your project involves launching a new software product or process, for example, it can pay dividends to do some self-study, online or in-person training to get a handle on the basics before your consultant shows up. If your team has some solid background knowledge on the products being used, your consultant and team can focus on the hard questions instead of spending time reviewing the core concepts. A little training also provides valuable context for the things that your consultant will tell you, making the puzzle pieces fit together that much easier
- Have a long term support and implementation plan post-engagement. How will you take what your consultant does and build on it? How will you carry on with long term support of things they help you build? How will you track your progress toward implementing the things they recommend? How will you know if it is time to bring them back for a follow up?
- Set up a separate internal email address for your consultant. They already have a perfectly good email address, and requiring them to check yet another inbox makes it more likely that something will get overlooked. Calendar invites and other features work across pretty much all mail systems, so there is really no good reason to make them use an internal email (barring extreme security requirements, etc). Requiring your consultant to use an internal email address also means that they will lose access to that mail history when they leave. Without access to this critical historical information, they won’t be as effective should you ring them up with a question or want to re-engage.
- Require the consultant to use a computer provided by your company if it can be avoided. Many consultants have a particular toolchain that they rely on to get their job done efficiently. If you require them to use a company provided desktop or laptop, they will need to recreate this toolchain, which may take some time that could be better spent solving the problems they were brought in to solve. In the cases where this cannot be avoided, get a list of software and other items that the consultant will need and make sure those items are set up ahead of their arrival.
- Hand off a list of tasks and then leave them to it. Consultants are usually brought in because they have some kind of specialized knowledge or expertise that is lacking in an organization. One of the most valuable things a consultant can do for you is knowledge transfer. Having them work closely with your team ensures that when the consultant leaves some valuable new knowledge and skills have been left behind.
- Let a small issue block the engagement. Servers down? Now is a good time to talk strategy. DBA out sick, can’t get a schema set up? Time for a Q&A session with the dev team. Part of managing an engagement is knowing when to punt and move on to other things to stay productive.
- Reschedule. Consultants live and die by their utilization. For short to medium term consultants, this means that we probably have a deep pipeline of bookings that are carefully choreographed to keep us busy . If a client has to reschedule, it can throw the whole schedule into chaos. If we are lucky we might be able to find a client that wants to switch weeks or one in the queue that is ready now. If we aren’t lucky, we end up on the bench and then have to scramble to find an available slot for the client that needs to reschedule, often much later than the client wants.
- Expect your consultant to circumvent normal support and escalation procedures. We can help you navigate support, and we know how to get things escalated to the right people, but we can’t just ring up engineering (in 99% of cases, anyway). Same goes for the product roadmap. We know it, we live it, but that stuff is planned months or years in advance. What we can do is help you build things that are aligned with the future of the product that will let you adopt new features faster and minimize rework that might come with change.
- Expect your consultant to know everything off the top of their head. We prepare for our engagements based on the defined scope, and questions outside that scope may take a little time to answer. On the bright side, when you engage a good consultant you don’t just get that one person. When we go into the field we have a lot of resources backing us up in the form of the other consultants in our practice, our extended professional network inside our company, support, internal knowledgebases, engineering tickets, and other tools. Rest assured we will use everything at our disposal to get you the right answer, even if we can’t hand it over on the spot.
This list is by no means exhaustive, and I will probably add to it over time. Consulting was one of the most fun jobs I’ve ever had, and today I’m humbled to get to lead such a skilled, dedicated global team. It also helps that we have great clients! Hopefully at least a few of these tips will help you to get the most value from your future consulting engagements. To any of the other consultants out there, what are your best practices for customers that engage your services?