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.