Unlike many of my colleagues, I have never worked in management consulting or really spent much time developing a consulting skill set.  Rather than starting my career at McKinsey, Deloitte or Accenture, I spent my early years working in advertising.  My agency experience has given me a very deep understanding of the advertising industry, but has left somewhat of a gap when it comes to consulting skills.  To help close this gap, I sat down this week with several ex-consultants – who happen to be my current coworkers – to ask them what they learned working for big consulting companies.  I found their lessons to be quite interesting and thought I would share them this week.

Regarding the actual job of being a consultant, many of the people I talked to actually had mixed things to say.   One told me how consulting companies sell their employees on the vision of exotic travel and working with cool companies, but often times younger consultants get stuck going to unexciting places and working for less than glamorous companies.  Another described consulting as the “worst possible tradeoff between hard work and compensation,” because consultants have to work as hard as bankers, but don’t get paid nearly as well.  However, after the war stories were through, my colleagues all agreed that consultants do develop the skills to move organizations and drive change.

Unsurprisingly, due to high turnover at management consulting firms, the actual process for driving organizational change is rather formulaic – but not in the way I expected.  Below I’ve outlined the key steps for a typical consulting engagement.

1)   Identify the key stakeholders: Who are the people who need to be satisfied with the solution you come up with and who are the people who will provide key pieces of input during the course of the engagement?

2)   Define the problem: Make sure that all of the stakeholders are aligned and clear on exactly which problem you’re trying to solve.  To get clarity on the problem, you have to ask the stakeholders what they think the problem is and ask them what is broken.  The input here must come from the stakeholders directly.  It’s best to collect feedback on the problem in a small group, or 1:1 setting.  It’s important that people feel comfortable and can talk freely.

3)   Define the scope: Next, you need to look at the problems you’ve collected and clarify the scope of your engagement.  Chances are, Step One revealed more problems than you could possibly solve in one project.  To position the engagement for success you must narrow the scope of the project to something doable and make it explicit: what is inside the scope and what is outside the scope of the initiative.  You also need to make sure all the stakeholders agree on what is inside and outside the scope of the project.

4)   Define success: Now that you’ve collected all of the problems and narrowed the scope, you need to work with the stakeholders to define what success looks like.  What measurable, achievable results can we set as the goal of this initiative?  What is the end-state that defines the conclusion of the project?

5)   Define the work streams: Sit down and map out the current state and end states, and figure out what work streams need to be established in order to bridge the gap between these states.  Work streams should be “MECE” (mutually exclusive, collectively exhaustive), meaning that each work stream should be able to operate independently, while all the work streams together complete all of the project’s work.

6)   Get alignment and assign work stream owners: After you come up with the work streams, get alignment from all stakeholders and assign owners to each work stream.  It’s best if the consultant owns a minority the work streams herself – most of the work streams should be owned by the stakeholders or their delegates (which further ensures buy-in from your stakeholders).

7)   Communicate often: Provide regular updates on the progress of each work stream and overall progress of the initiative.

8)   Rev the deck: The ultimate deliverable of most consulting engagements is a PowerPoint deck explaining the results of the project.  This is usually a document that is developed over time and requires quite a lot of revisions (with the help of the stakeholders) before it is considered final.

I found the start of this list to be a little bit surprising.  I thought the first step would require conjuring up some exotic decision making frameworks, or starting to draw out possible problem solving approaches: but I was decidedly wrong.  Consulting is actually much more about people than it is about problems.  Therefore, the first step to any consulting engagement is all about finding the right people.  My colleagues mentioned that when they worked in consulting, somewhere north of 80% of their colleagues could do the intellectual work of crunching the numbers and finding the right answer to consultative problems.  However, a much smaller portion could correctly show all of the stakeholders that the solution they found is the best solution – or better, make the stakeholders feel like they were the ones who came up with the ultimate solution.

The reason the consulting process revolves so much around people is not because consultants are incapable of finding the answers on their own.  In fact, many consulting problems are actually rather straightforward.  However, without involving the key stakeholders throughout the consulting process the stakeholders won’t have the context they need to understand the value of the work you’ve done.  For a consulting engagement to be a success, the consultant not only needs to come up with the right answer, but also to be the tour guide that takes the key stakeholders on a problem solving journey.  If you don’t involve the stakeholders in the journey then they won’t know the research that went into the project, the opinions that were collected, the alternatives that were evaluated, etc.  Without that critical context, they won’t have confidence in the work you’ve done.

As it turns out, consulting, like many other things in life, is much more about the journey than the destination.

Taking a Consultative Approach to Problem Solving
Tagged on:         
  • I’d say an engagement begins with stakeholders recognizing that they have a problem, but not having the internal resources available to tackle the problem. This could be because the stakeholder spearheading the issue doesn’t have organizational access to those resources (surprisingly common), because those resources are currently dedicated to other things and just adding it to the list would lead to a solutoin 3-4 years out, or – much more rarely – the organization doesn’t have the internal capabilities to tackle the issue (this is rare because people usually don’t hire consulting companies that do work the stakeholders can’t understand. Think of it as a language barrier).

    It strikes me as more a shortcut, or a run-around the HR department and internal politics, than it does serious problem solving.

    Sure, serious problem solving definitely occurs, but I think it’s a minority (e.g. top X%, like 10%) of consulting engagements.

    So, I wouldn’t over-estimate the actual impact. What it *does* train you to do is (i) identify stakeholders, and (ii) identify what will make the stakeholders happy, and (iii) deliver that, though any means possible (even very non-standard ways). That’s a pretty good recipe for success, all told, but it doesn’t have much to do with the total net impact of the work.

  • > If you don’t involve the stakeholders in the journey then they won’t know the research that went into the project, the opinions that were collected, the alternatives that were evaluated, etc

    Well: maybe.

    My instinctive reaction is to criticize the loose epistemology, but that comes from my major (if you don’t have shared criteria for evaluating success/failure/evidence, it boils down to a confidence exercise – or a con game, for short).

    In practice, I think storytelling is rather important. You identify a story – the stakeholders provide start, let’s call it “Situation” and also the “Complication” that caused the consultant to be brought in – and the consultant provides the “Resolution” that will eliminate the complication. The consulting company needs to provide *sufficient* evidence to meet the epistemological demands of the stakeholders, but that’s rather less important than providing a story that “makes sense” to the stakeholders. If you come up with some they regard as unreasonable or crazy (easy to do, in many industries, since they can be quite traditional) they aren’t going to swallow any amount of “evidence” your provide. It needs to make sense, and it needs to make sense though the lens they already have. That’s a big reason of why it’s so damned important to consistently check back with the stakeholders – you need their guidance on what kinds of solutions actually make sense.

    Or you need to be prepared for a long, drawn-out battle with said stakeholders, in which you spend a lot of time insisting you’re right and they listen to you in direct proportion to how much you’re paying. If you get less than total buy-in, e.g. begrudging acknowledgement, be prepared for them to basically ignore your conclusions entirely and cherry-pick the bits they want to support their own agenda.

  • Fair enough. I think there is also something to be said for needing something done “right now” – rather than waiting to find, hire and train someone to do a significant task. In my experience, recruiting at a senior level can take at least 6-9 months (and often longer).

    I don’t much like the concept of “delivering what makes the stakeholders happy at all costs” – but i suppose to some degree that’s reality. It’s always best to remember who’s paying you – although, i like to think that sometimes people get actual value too.

  • Another important tid bit from my research: one of my friends said that the hardest part of any consulting job is changing someone’s mind. If one of your key stakeholders is dead-set on a specific way of thinking of a specific solution, it’s very difficult to sway them as a consultant.

    Also, I really like your point at the top:

    > If you don’t have shared criteria for evaluating success/failure/evidence, it boils down to a confidence exercise – or a con game, for short.

    That point resonates soundly with my personal experience as well and I really like the way you’ve praised it.

  • > I think there is also something to be said for needing something done “right now”

    Oh, absolutely – resource constraints (time included) can be quite damaging. And managing elapsed time vs. project time can be quite helpful.

    For making the stakeholders happy – the other consideration is that the stakeholders probably know their business a lot better than any consultant. They’re useful as a reality check. A consultant may have the best idea, but if it’s either impossible to implement or would take a completely retooling of the company, it’s not a good suggestion.

    I’m not saying value isn’t provided – I believe it is – but I’m unwilling to say that consulting is particularly good at driving organization change, or that it’s a good approach to *problem* solving (if the problems are difficult).

    There are exceptions, and particularly good consulting engagements can have a transformative impact. I just think that’s quite rare.

  • > one of my friends said that the hardest part of any consulting job is changing someone’s mind

    I’d certainly agree with that. I’ll also say that I know a few ex-McKinsey guys (including my father) and they’re all very good – and quite eager – to argue the point. To push back wherever possible. So it’s probably a pretty key skill, where possible.

    But in my experience, that’s actually applied less to the stakeholders than to people a little lower down the chain (whom you may be working with directly) who tend to be a little less flexible in some ways. You can – and need to – argue quite a bit inside the team you’re a part of to (i) pull out all the issues/objections, and (ii) persuade them to buy into it, so when the stakeholders says “go” it’ll actually be implemented.

    If you’re *seriously* butting heads with a stakeholder, that suggests that the initial project scope wasn’t outlined well enough. It could certainly be that the best course of action is one they are unwilling to pursue, and you need to change their mind, but I’m more inclined to attribute real disagreement to internal politics. e.g. someone brings the consultants in, and other execs react negatively. Handling that can be dicey.

    And thanks for the comment on my sentence! It’s a bit of a shame how much that comes up.