What is a "SMART" Problem Statement at McKinsey?

Aligning on the problem statement is the first step in McKinsey's approach to structured problem solving.  It is considered best practice at the Firm for these problem statements to be "SMART".  In this post I'll explain some of the characteristics of good problem statements...

What is a problem statement?

Put simply, the problem statement clearly defines - in a concise but comprehensive way - the key business problem that needs to be solved.  Even though it's called a problem "statement", it's usually in the form of a question.  The engagement team's goal is to find the most impactful answers to that question.  Problem statements are most often addressed and solved through the use of hypothesis-driven issue trees.

Why is the problem statement important?

If the team and client are not aligned on the key problem that needs to be solved, there will be a lot of wasted time, effort, and resources.  Imagine what would happen if you spend weeks, days, or even hours solving a tough problem only to learn that your client or McKinsey boss was actually expecting you to solve a different problem.

What does it mean for a problem statement to be "SMART"?

As you can see from the first exhibit, SMART is an acronym for Specific, Measurable, Action-oriented, Relevant, and Time-bound.  A good problem statement should be all of those things.  The challenge is to balance being thorough with being concise.

Some examples from problem statements that are not SMART:

• Not specific:  "better manage the business..." - this is too generic and doesn't suggest where the greatest impact might be, how, or by when to capture it
• Not measurable:  "reverse our deteriorating performance..." - without specifying what metrics (or KPIs - Key Performance Indicators) best reflect "performance", it's impossible to assess whether or not we've made progress
• Not action-oriented:  "increase sales and decrease costs..." - while these are both appealing goals for any company, they have to be actionable to create impact
• Not relevant:  "increase profits by raising prices..." - this sounds good, but not if the client is selling a commodity that sells at market prices.  The problem statement has to be relevant to the client and their key problem(s)
• Not time-bound:  "eventually increase profits by 10%..." - a specific deadline is needed to motivate people to action, hold them accountable, and know if the project was successful

What else should inform a problem statement?

Even if a problem statement is SMART, it does a client little good if it isn't realistic for them.  So, a good problem statement also takes into account the relevant, critical factors that your client is facing.  While SMART is intended to be a comprehensive list, the factors providing important context can be endless, so it is important to focus on the vital few that are most relevant and have the greatest impact.  Some examples include:

• Business context - what's going on at the company, in the industry, or with customers?
• Criteria for success - what are the clients' goals for the project and more broadly?
• Stakeholders and decision makers - who will approve the project, assess it success, and/or be impacted by it?
• Constraints - what limitations might prevent your client from achieving a solution?
• Risks and appetite for risk - what are the downside implications for the client, how likely are they, and how does that make them react?
• Scope - how much work can your client take on, how far across or deep into the organization can it go, and how long do they have to do it?

Do's and Don'ts for Being Hypothesis-Driven at McKinsey

Image from keepcalm-o-matic.co.uk

When problem solving at McKinsey, it's considered best practice to use hypotheses to guide your thinking and work.  Your McKinsey boss will often ask you to be more "hypothesis-driven".  If you are interviewing for a job at McKinsey, your interviewer will expect you to be hypothesis-driven when solving the case interview.  In this post, I'll explain what that means and also provide some tips on what to do and not do when being a hypothesis-driven consultant...

What a hypothesis is and is not...

The hypothesis is your best, educated guess of what the answer is to a given problem.  It is not a shot in the dark - instead, it should be informed by background information, preliminary data analyses, and input from Firm experts.

It should not be based on conjecture or solely on opinion.  Early in an engagement there might not be many concrete facts upon which to base the hypothesis.  But the further you get into a client engagement, the more fact base there should be supporting your hypothesis.


The hypothesis should be considered a living document that is constantly revised and continuously improved as it is tested and new information and/or insights come to light.  It is not permanent and it is not the final answer.   It is definitely not thinking that you know the answer at the beginning of a client engagement - that attitude is what gives consultants a bad name and creates perceptions that they are arrogant know-it-alls. 

What does it mean to be hypothesis-driven?

A hypothesis-driven consultant develops a hypothesis of the answer to a problem early, then focuses on testing and revising that hypothesis over the course of the engagement.  This is also known as "having a perspective on the answer" and considered to be superior to the alternative of searching for an answer in a vacuum.  The hypothesis is used to inform what data needs to be collected, analyses will be performed, and insights must be gained in order to arrive at a final answer.

Important things to do when being hypothesis-driven...

DO:

• Be sensitive to the fact that most non-consultants are not comfortable working this way
• Inform your hypothesis with all available information including situational context
• Involve others - especially your team - in developing and revising your hypothesis
• Test and improve your hypothesis constantly as new information becomes available

Important things to NOT DO when being hypothesis-driven...

DON'T:

• Wait until you have every fact you are seeking - you might be waiting forever
• Waste time trying to make your hypothesis and supporting analyses perfect
• Forget that your hypothesis should be a living document that is continuously improved...
• Fail to question your hypothesis
• Defend your hypothesis blindly
• Adjust data to fit your hypothesis

What does it mean to "Trim an Issue Tree" at McKinsey?

As covered previously, issue trees are used to solve complex problems by breaking them down into their component parts.  Your McKinsey boss might ask you to prioritize efforts by trimming an issue tree.  In this post, I'll explain what that means...

What does it mean to trim an issue tree?

Once the issue tree has been developed, the team will develop hypotheses on which issues and sub-issues are likely to drive the most and least impact.  The vital few, high-impact issues will get prioritized and low-impact or irrelevant items should be cut.  Extending the tree metaphor, cutting issues and sub-issues is often referred to as "trimming" or "trimming branches from" the issue tree.

Why is this important?

Any team only has a finite amount of time, effort, and resources to dedicate to problem solving.  Trimming less promising branches from the issue tree allows the team to prioritize and focus their work on the vital few issues and sub-issues that are expected to create the greatest impact.

How does a team determine what to trim?

Building and trimming issues trees are hypothesis-driven exercises.  Background information, preliminary data analyses, and expert opinions can be used to inform and update these hypotheses.  Rarely, as the problem solving and analyses continue, new information could result in issues or sub-issues being reconsidered and added back to the issue tree.

Issue Tree Trimming Example

An example of an easy branch to trim would be an issue tree dealing with how to increase the profitability of a client company.  One way to increase profits is to increase revenues by increasing prices.  But if the client is selling a commodity good, prices are set by the market, so they will have no control over pricing.  So, the "increase prices" branch is irrelevant can be trimmed from this particular issue tree.

4 Reasons Issue Trees are Used for Problem Solving at McKinsey

"Issue Trees" are especially useful for solving problems - especially large, complicated ones.  In this post I'll cover what they look like and some reasons why they are the preferred problem-solving approach at McKinsey

What is an Issue Tree?

Issue trees are used to solve problems by breaking them down into their component parts.  That makes them particularly useful for addressing large, complicated problems.

They are called trees because they are narrow at the top - starting with the problem statement - and wider at the bottom as the problem is broken down into increasingly wider levels of issues and sub-issues.

Why are Issue Trees used?

Issue trees are a preferred method of problem solving at McKinsey because they...

1.  Break down a problem into manageable parts

Most problems faced by McKinsey teams are complex and difficult.  Breaking them down into issues and sub-issues results in smaller problems that are easier to solve.

2.  Enable solving the larger problem by solving the right component parts

Because the sub-issues and issues build up to the problem statement, addressing the right ones will solve the overall problem.  Proper prioritization allows teams to focus on the issues and sub-issues that drive the greatest impact and contribute most to solving the larger problem.

3.  Align the team on nature of the problem and path to the solution(s)

The issue tree provides a shared understanding of the issues that comprise the problem.  By aligning on the most impactful issues and sub-issues and how to solve them, the team will also have a shared vision of how to solve the problem statement.  This understanding can be increased by having team members participate in the creation of the issue tree.

4.  Provide insight into missing issues and sub-issues

As the team strives to make each level of the issue tree MECE, it will become apparent if elements are missing.  That will allow the team to investigate areas of potential impact that might have been missed if an issue tree had not been created.

What Does It Mean to be "MECE" at McKinsey?

Working at McKinsey (or for a McKinsey boss) often requires dealing with large amounts of information.  There is a strong preference for organizing that data in a manner that is "MECE".  Your McKinsey boss might also ask you to be "more MECE" in your problem solving approach.  If you're applying for a job at McKinsey, your interviewer will be looking for MECE frameworks during your case interview.  In this post, I'll explain what that means.

What is MECE?

The term "MECE" (pronounced "MEE-see") is an acronym for "Mutually Exclusive and Completely Exhaustive".  It usually refers to how information is organized - often in the context of issue trees, a topic that will be covered in a separate post.  Information - ideas, topics, issues, solutions, etc. - should be organized into MECE "buckets" or groupings of like items.

Mutually Exclusive

This means that any idea can be placed into one - and only one - bucket.  If you can come up with an idea that could potentially go into more than one bucket, your approach is not MECE. 

For example, let's suppose you are trying to organize pizza toppings.  You decide to try the following buckets or drawers in the refrigerator:  "meat", "vegetarian", and "vegan".  Those buckets will seem mutually exclusive for many ingredients, but you will soon come up with a topping that could fit into more than one bucket.

• Pepperoni:  Meat - yes.  Vegetarian - no.  Vegan - no... OK!
• Cheese:  Meat - no.  Vegetarian - yes.  Vegan - no... OK!
• Mushrooms:  Meat - no.  Vegetarian - yes.  Vegan - yes... NOT OK!

So this would not be MECE organizing system because someone looking for mushrooms wouldn't know whether to look in the "vegetarian" or "vegan" drawer.

Completely exhaustive

This means that your buckets cover the entire universe of possible items.  If you can come up with an example that does not fit into any of your buckets, your approach is not MECE.

Let's continue with the pizza topping example.  Suppose after failing the test for mutual exclusivity, we've relabeled our refrigerator drawers as "meat", "vegetables", "dairy".  This system works better for our previous test items, but it could be missing a category...

• Pepperoni:  Meat - yes.  Vegetables - no.  Dairy - no... OK!
• Cheese:  Meat - no.  Vegetables - no.  Dairy - yes... OK!
• Mushrooms:  Meat - no.  Vegetables - yes.  Dairy - no... OK!
• Tomato sauce:  Meat - no.  Vegetables - sort of.  Dairy - no...  Maybe?
• Pesto:  Meat - no.  Vegetables - sort of.  Dairy - no...  Maybe?

It is possible to make your current system MECE by specifying that "vegetables" includes all things veggie-based, like pesto and tomato sauces.  Similarly, a dairy-based sauce like Alfredo can go in the "dairy" drawer.  But are you comfortable splitting sauces across drawers?

We can also see from this test that there might be potential to add a "sauce" drawer.  Or do you think your users would expect to find all sauces together?

As you can see, even for the simplest lists, creating a MECE framework can be challenging!

EXAMPLE:  The easiest MECE framework

Anyone preparing for a consulting case interview should be familiar with at least the first level of this issue tree.  Your client wants to increase profits - where are the most promising areas to look?

The two MECE buckets for increasing profit are 1) increasing revenues and 2) decreasing costs.  Those two buckets have no overlap (ME) and cover all possible options (CE), so it's with good reason that this framework comes up over and over.

The first couple of levels of this issue tree are so obvious that these can be some of the most challenging case interview questions to do well on.  Because it's hard to set yourself apart in your initial framework, you need to really show some deep and quality insights in the rest of the case to differentiate your performance from others'.

Why is MECE important?

The pizza example is probably not the best way to illustrate this, but being MECE is critical to effective problem solving.  It reflects thinking that is:

• Clear - Because mutual exclusivity means overlap is eliminated, it is easy to understand where things belong, making them easy to find and, if necessary, edit
• Thorough - A completely exhaustive approach means every possible idea can be raised and considered
• Logical - Ultimately, a MECE approach yields an elegant yet comprehensive solution that can be easily understood and followed.  It also highlights for your McKinsey boss or interviewer that you can organize information effectively and efficiently

These are all traits that Firms, teams, and clients look for in their consultants.

Why Doesn't McKinsey Recruit at My School?

Image from NYTimes.com

McKinsey sends droves of consultants to the world's best undergrad, MBA, and other programs in search of new talent and future consultants.  It can be frustrating if you're an intelligent, hard-working, high-performing student who does not go to one of those programs.  In this post I'll explain why McKinsey focuses its recruiting efforts at certain schools...

It's a Numbers Game

Even though McKinsey is a large Firm with thousands of active consultants, it can only send interviewers to a finite number of schools each season.  For interview days at big MBA programs that send many graduates to McKinsey (e.g., HBS, Wharton, Kellogg), the Firm will send dozens of consultants, often at the expense of client engagements.  So, the Firm fishes where the fish are.  In other words, McKinsey focuses its efforts on the programs that are likely to have the best candidates and the most potential hires as a percentage of candidates interviewed.

Track Records of Success

Performance in past years can inform how much attention a school gets from McKinsey.  Schools that have candidates who do well in interviews, accept their offers, and do well at the Firm can create a virtuous cycle.  Those successes can then encourage McKinsey to return to campus to recruit more candidates who will go on to do well at the Firm, encouraging more interviews, and so on.  This results in a robust pipeline of talent that can be relied upon to provide good hires year in and year out.

The reverse can also happen.  While I was at the Firm, a McKinsey office complex dropped a certain Top 5 MBA program from its list of "core" schools after too many that b-school's students accepted McKinsey WCO job offers, then reneged.

Pre-screened Candidates

Most companies, including McKinsey, benefit from the de facto pre-screening that top schools provide via their admissions process.  First, they only admit high-potential, high-performing, high-character applicants - the kinds of students who could make great McKinsey consultants.  Second, only the brightest, hardest-working students - grade inflation aside - will earn the kinds of GPAs that will earn invitations to interview.

The Firm knows there might be great candidates at less selective programs.  We also see plenty of bad candidates at good schools.  But, overall, the caliber of candidates we see at the best schools is incredibly high, which encourages a recruiting focus.

Performance Matters, Not Pedigree

Although the Firm tends to focus on programs with sterling reputations, it's because of the quality of candidates, not the name of the school.  I was pleasantly surprised to see how little McKinsey consultants, engagement teams, and leadership seem to care about where someone went to school.  For example, during staffing, I have never heard of a McKinsey Partner or Engagement Manager asking where a potential engagement team member went to school - the questions are always about what their strengths and opportunity areas are and what their semi-annual review ("SAR") ratings have been.

As long as you have what it takes to "clear the bar" during interviews, and are diligent about getting into the interview process at the right time, you can a) can pass the resume screen, b) do well on your interviews, and c) get a job offer strictly based on the merits of your performance, regardless of where you go to school.

McKinsey Interviews - Not All Advice Is Created Equal

Image from peanuts.wikia.com

As McKinsey candidates prepare for interviews, they eagerly seek out information and are often bombarded with advice from a variety of sources.  However, it's important to remember that not all interview prep advice is created equal.  In this post I'll discuss which sources are more or less valuable and why...

Focus on Advice from Assessment-Trained Consultants...

The biggest driver of quality and reliability of McKinsey interview advice is whether or not the source has been "assessment trained".  The Firm requires a constant and robust flow of new consultants, so the recruiting, interviewing, and hiring processes are designed to be consistent as they are selective.  Therefore, every consultant who interviews candidates goes through an assessment training program to teach them the McKinsey method for evaluating applicants. 

...Who Have Interviewed Candidates For McKinsey

Assessment-trained consultants understand the process and theory of how candidates get evaluated and hired.  However, unless they have actually conducted interviews and participated in post-interview "decision meetings" for McKinsey, they won't fully understand or appreciate the behind-the-scenes realities and details of how candidates are assessed.  It's the difference between taking a Driver's Ed class and learning by driving, even if it's just with a learner's permit.

Take Advice From Anyone Else (Except Recruiters) With a Grain of Salt

Anyone giving you McKinsey interview advice likely has the best intentions and wants to help you do well.  However, if they haven't been assessment trained and interviewed candidates for the Firm, they really don't know what they're talking about (unless they are McKinsey Recruiters - see the next section for information on advice from Recruiters).  They simply will not know how what they did during their interview process maps to why they got a job offer.

Consider the advice you could give to someone applying to your school (assuming you're currently in business school, APD, or undergrad program).  You know a) what you did, said in interviews, and wrote in your application and that b) got you accepted.  However, unless you've volunteered for your school's admissions office, you don't really know which specific things you did made a difference in getting that acceptance. 

For those reasons, do NOT put too much faith in interview advice you get from the following:

• Business Analysts (BAs)
• Former BAs
• Returning Summer BAs (SBAs)
• Returning Summer Associates (SAs)
• Early-tenure Associates who have not been assessment trained

Go To Recruiters With Questions About the Interview Process

Recruiters are the most knowledgeable sources for information and advice on the interview process - topics like how to apply, when to submit your resume, or how to participate in networking events like coffee chats and the on-campus company presentation.  McKinsey Recruiters also facilitate decision meetings so they know the types of things consultants weigh and debate when deciding whether or not to pass a candidate to the next round or make them a job offer.

Some Recruiters Have Interviewing Experience

Some Recruiters, especially the more senior ones, are former consultants and might have been assessment trained, conducted interviews, and attended decision meetings.  They will have valuable insights into all aspects of McKinsey interviews and the interview process.