February 17, 2011
Tips for better consulting
I’ve recently had occasion to reflect on what seems to make for better consulting projects – how the process is structured, how to communicate during it, and how deliverables are created. Many of the points here have been learned collectively in conversation and through experience so these insights are hardly my own, but hopefully they’re of some help. Here are the top 10 that came to mind first, in no particular order:
- Understand how the client makes decisions – You need to structure the process to work with how decisions are made (or mutually agree with the client that you’ll be doing things differently), otherwise decisions may not be correct or timely. For instance, when dealing with a leader who’s a real delegator, you can’t ask for lots of decisions on the spot, since she’ll need to check with her team
- Mock things up to begin with the end in mind – Most projects go off the rails because either people have a different vision of the outcome/deliverable or they don’t match the time or resources available with the outcome – or both. The best way to avoid this is to create a rough mock-up early on of whatever you’ll be delivering in the end to be sure it’s something achievable and there’s a shared expectation.
- Don’t get enamored with the data you’ve collected or the work you’ve done – it’s tempting to want to show all the hard work that’s been done and all the information that’s been gathered, analyzed, and visualized. However, this can get in the way of telling the right story and making the right case. Don’t be afraid to throw out or put into an appendix the findings that are no longer relevant.
- Assume no one understands you until you give an example – there are more jargon and acronyms every day and words are abstract, meaning that people will interpret them differently. So, every other sentence (just about) should be an example explaining the previous one so that you can be sure people understand what you mean.
- Say what things mean, not just what they are – You can’t assume that anything speaks for itself; context, interpretation, and judgment will always be needed. For instance, if you’re showing a graph, don’t just describe the data/values, tell people what those data mean – are they good or bad? High or low? Similar or different? Surprising or as expected?
- Work top down and bottom up – throughout the course of a project, it’s often best to approach it from the top down (the strategy and the leadership’s goals – e.g.: a new service model) as well as the bottom up (the details and tactics – e.g.: the roles and responsibilities, schedules, etc) so that you can use each to validate and refine the other.
- The problem changes as you work on it – Beware of linear, “stage-gate” problem-solving. The problem you are trying to solve at the beginning is rarely what you end up addressing in the end because things change as you gather information, understand constraints etc. So, you need an iterative process that involves testing, feedback, mock-ups etc and a recognition that this will happen.
- Keep the goals, evaluation, and recommendations in mind at all times, even as they change – Every project has a set of goals that represent what you want to achieve, a set up findings comparing the present situation to the future goals, and recommendations to address the gaps. Even though these may change, you need to be able to state them in a sentence or two at all times.
- Always have some way of knowing whether or not you’re right – Even the most open-ended projects need some mechanism along to way to judge them and know whether or not you’re on the right track. This could be through comparisons, accepted benchmarks, pilots and prototypes or other means, but something is always needed.
- Don’t confuse means for ends – It’s very tempting to develop a bias for something that’s worked well in the past and begin to treat a means as an end; for instance, pursuing a new technology for its own sake or creating a mobile workplace simply because that seems to be the trend. Instead focus on the goals and recommend only what’s needed to achieve them, even if it’s not cool.