"If more business books were as useful, concise, and just plain fun to read as THE MCKINSEY WAY, the business world would be a better place." --Julie Bick, best-selling author of ALL I REALLY NEED TO KNOW IN BUSINESS I LEARNED AT MICROSOFT.
"Enlivened by witty anecdotes, THE MCKINSEY WAY contains valuable lessons on widely diverse topics such as marketing, interviewing, team-building, and brainstorming." --Paul H. Zipkin, Vice-Dean, The Fuqua School of Business
It's been called "a breeding ground for gurus." McKinsey & Company is the gold-standard consulting firm whose alumni include titans such as "In Search of Excellence" author Tom Peters, Harvey Golub of American Express, and Japan's Kenichi Ohmae.
When Fortune 100 corporations are stymied, it's the "McKinsey-ites" whom they call for help. In THE MCKINSEY WAY, former McKinsey associate Ethan Rasiel lifts the veil to show you how the secretive McKinsey works its magic, and helps you emulate the firm's well-honed practices in problem solving, communication, and management.
He shows you how McKinsey-ites think about business problems and how they work at solving them, explaining the way McKinsey approaches every aspect of a task:
How McKinsey recruits and molds its elite consultants;
How to "sell without selling";
How to use facts, not fear them;
Techniques to jump-start research and make brainstorming more productive;
How to build and keep a team at the top its game;
Powerful presentation methods, including the famous waterfall chart, rarely seen outside McKinsey;
How to get ultimate "buy-in" to your findings;
Survival tips for working in high-pressure organizations.
Both a behind-the-scenes look at one of the most admired and secretive companies in the business world and a toolkit of problem-solving techniques without peer, THE MCKINSEY WAY is fascinating reading that empowers every business decision maker to become a better strategic player in any organization.
Amazon.com Review
The McKinsey Way , by former McKinsey & Company associate Ethan M. Rasiel, provides a through-the-keyhole perspective on the way this worldwide consulting institution approaches--and solves--the myriad professional problems encountered by its high-powered clientele. His goal, Rasiel writes, is simple: to communicate "new and useful skills to everyone who wants to be more useful in their business." He then does so by explaining the highly structured, fact-based proprietary methodology that McKinseyites are taught to employ with their Fortune 100 clients, complete with details on the entire process from first considering the basic situation at hand through finally selling a solution to the appropriate powers that be.
All of the critical steps (assembling a team, managing a hierarchy, doing research, conducting interviews, brainstorming) are broken down into specific actions and fleshed out with applicable examples that Rasiel has gathered through interviews with dozens of other former McKinsey employees. The concluding sections on surviving the mythically grueling pace at the organization, known simply to insiders as "the Firm," are designed to help readers successfully tackle the similar challenges and obstacles they regularly face in their own work environments. --Howard Rothman.
From the Back Cover
Penetrate the McKinsey mystique and learn the secrets of the world's most sought after consulting firm.
Praise for The McKinsey Way :
"If more business books were as useful, concise, and just plain fun to read as The McKinsey Way , the business world would be a better place."Julie Bick, Best-selling author of All I Really Need to Know in Business I Learned at Microsoft
"Enlivened by witty anecdotes, The McKinsey Way contains valuable lessons on widely diverse topics such as marketing, interviewing, team-building, and brain-storming."Paul H. Zipkin, Vice-Dean, The Fuqua School of Business, Duke University
"Apt to become the reference book on business management. With the help of The McKinsey Way , managers can approach issues they face as if they had a McKinsey expert beside them. It will certainly help those of use who cannot afford McKinsey!"Mord Weisler, Chairman, PRI Automation, Inc
"The closest thing to getting three years of consulting experience in three hours."John Alsop, President, Progress Software
" The McKinsey Way describes a course of analysis that is very powerful, well-written, and effective."Peter A. Brooke, Chairman, Advent International
About the Author
Ethan M. Rasiel joined McKinsey & Co.'s New York office in 1989 and worked there until 1992. While at "the firm", his clients included major companies in finance, telecommunications, computing, and consumer goods sectors. Before working at McKinsey, he worked as an equity fund manager at Mercury Asset Management in London. He has also worked as an investment banker. He has a bachelor's degree from Princeton University and an MBA from the Wharton School at the University of Pennsylvania.
Like all things McKinsey, the Firm's problem-solving process has three major attributes. When team members meet for the first time to discuss their client's problem, they know that their solution will be
• Fact-based
• Rigidly structured
• Hypothesis-driven
In this chapter, you will learn exactly what these attributes mean and how you can apply them in your business.
FACTS ARE FRIENDLY
Facts are the bricks with which you will lay a path to your solution and build pillars to support it. Don't fear the facts.
Problem solving at the Firm begins with facts. On the first day of an engagement, all members of the team comb through stacks of articles and internal research documents to gather enough facts to illuminate their piece of the problem for the first team meeting. Having drawn up an initial hypothesis for the problem, the team then races to gather the facts necessary (when put through the appropriate analyses) to support or refute it.
At the start of your time at McKinsey, gathering and analyzing facts is your raison d'étre. As one former SEM observed:
When you strip away a lot of the high-minded language with which McKinsey dresses up its problem-solving process, it comes down to very careful, high-quality analysis of the components of the problem combined with an aggressive attitude toward fact gathering.
Why are facts so important to the way McKinsey does business? There are two reasons. First, facts compensate for lack of gut instinct (see "... But Every Client Is Unique" in Chapter 2 ). Most McKinsey-ites are generalists. They know a little about a lot of things. As they gain experience and move through the ranks, they may come to know a lot about a lot of things. Even at this point, however, they will still know less about, say, inventory management practices for perishable foodstuffs than the folks who have been running the distribution operations of Stop & Shop for the last 10 years. Gut instinct might tell those folks the solution to an inventory management problem in 10 seconds (although they still would be wise to check the facts); McKinsey will go to the facts first.
Second, facts bridge the credibility gap. When she joins the Firm, the typical associate (at least in the United States) will have graduated near the top of her college class, spent two or three years working for a large company, then received her MBA from a top business school. She will be in her mid- to late twenties. On her first engagement she may have to present her analysis to the CEO of a Fortune 50 company, who will not give much credence to what some newly minted, 27-year-old MBA has to say—unless she has an overwhelming weight of facts to back her up. This is just as true for a junior executive presenting a proposal to his boss.
Despite (or possibly because of) the power of facts, many businesspeople fear them. Perhaps they are afraid that if they look too closely at the facts, they—or someone above them—might not like what they see. Maybe they think that if they don't look, the nasty facts will go away—but they won't. Hiding from the facts is a prescription for failure—eventually, truth will out. You must not fear the facts. Hunt for them, use them, but don't fear them.
FEEL FREE TO BE MECE
To structure your thinking when solving business problems (or anything, for that matter), you must be complete while avoiding confusion and overlap.
MECE (pronounced "me-see") stands for "mutually exclusive, collectively exhaustive" and it is a sine qua non of the problem-solving process at McKinsey. MECE gets pounded into every new associate's head from the moment of entering the Firm. Every document (including internal memos), every presentation, every e-mail and voice mail produced by a McKinsey-ite is supposed to be MECE. Ask any number of McKinsey alumni what they remember most about the way the Firm solves problems and they will tell you, "MECE, MECE, MECE."
MECE structures your thinking with maximum clarity (hence minimum confusion) and maximum completeness. MECE starts at the top level of your solution—the list of issues making up the problem you have to solve. When you think you have determined the issues, take a hard look at them. Is each one a separate and distinct issue? If so, then your issue list is mutually exclusive. Does every aspect of the problem come under one (and only one) of these issues—that is, have you thought of everything? If so, then your issues are collectively exhaustive. Suppose your team is working on a study for that famous American manufacturing firm Acme Widgets. The problem you face is "We need to sell more widgets." Your team might come up with a list of the following ways to increase widget sales:
• Changing the way we sell our widgets to retail outlets.
• Improving the way we market our widgets to consumers.
• Reducing the unit cost of our widgets.
If this list looks rather generic, that's fine; we will talk about moving down a level of detail in the next section. What matters is that the list is MECE.
Suppose you add another item, say, "Reengineering our widget production process." How does that fit with the three issues you already have? This is certainly an important issue, but it isn't a fourth point alongside the others. It falls under "Reducing the unit cost," along with other sub-issues such as "Leveraging our distribution system" and "Improving our inventory management." Why? Because all these are ways to reduce the unit cost of widgets. Putting any (or all) of them with the other three issues on the list would cause an overlap. The items in the list would no longer be mutually exclusive. Overlap represents muddled thinking by the writer and leads to confusion for the reader.
Once you have a list in which all the items are separate and distinct (i.e., mutually exclusive), you have to check that it also includes every issue or item relevant to the problem (i.e., it is collectively exhaustive). Go back for a moment to "Reengineering our widget production process." You put this under "Reducing the unit cost." Now one of your team members says, "We should think about ways to improve widget quality through the production process."
She's right. Does this mean you should go back to having reengineering as an issue in its own right? No, but you should refine your list to include, under "Reducing unit cost," the subissue "Reengineering the production process to reduce unit cost," and, under "Improving the way we market ...," the subissue "Reengineering the production process to improve widget quality." Now you have something that looks like this:
• Changing the way we sell our widgets to retail outlets.
• Improving the way we market our widgets to consumers. –Reengineering the production process to improve widget quality.
• Reducing the unit cost of our widgets. –Reengineering the production process to reduce unit cost.
Suppose your team has come up with some interesting ideas that don't fit under the main issues. What then? You could ignore those points, but that wouldn't help Acme. You could make them issues in their own right, but then you would have too many issues. A good McKinsey issue list contains neither fewer than two nor more than five top-line issues (of course, three is best).
There is a solution to this dilemma—the magical category "Other Issues." If you can't figure out where to put those two or three brilliant ideas, there is always Other Issues. There is a caveat, however. Avoid using Other Issues in your top-line list—it looks out of place. It's fine lumped in among a bunch of subissues, but on the first slide of a big presentation, it sticks out. So try a little harder to fit those brilliant ideas into your top-line issues. Chances are you can. Still, if all else fails, Other Issues will help you stay MECE.
SOLVE THE PROBLEM AT THE FIRST MEETING—THE INITIAL HYPOTHESIS
Solving a complex problem is like embarking on a long journey. The initial hypothesis is your problem-solving map.
The initial hypothesis (IH), the third pillar of the McKinsey problem-solving process, is the most difficult to explain. To make the explanation easier for you (and me), I will break this section into three parts:
• Defining the initial hypothesis.
• Generating the initial hypothesis.
• Testing the initial hypothesis.
DEFINING THE INITIAL HYPOTHESIS
The essence of the initial hypothesis is "Figure out the solution to the problem before you start." This seems counterintuitive, yet you do it all the time.
Suppose you have to drive to a restaurant in a part of town you don't know. You know you have to make the third left off Smith Street and then take the first right; it's just after that corner. You know how to get to Smith Street; you'll just follow your directions from there. Congratulations, you have an initial hypothesis.
Solving business problems is more complicated than finding a restaurant, but the initial hypothesis works the same way. It is a road map, albeit hastily sketched, to take you from problem to solution. If your IH is correct, then solving the problem means filling in the details of the map through factual analysis.
Let's return to Acme Widgets from the last section. You and your team must find a way to increase sales at the widget business unit. After you've brainstormed using your knowledge of the widget business, but before you've spent a lot of time gathering and analyzing the facts, you might come up with the following top-line IH:
We can increase widget sales by:
• Changing the way we sell our widgets to retail outlets.
• Improving the way we market our widgets to consumers.
• Reducing the unit cost of our widgets.
As I will show in the next section, you would then take each issue down to another level or two of detail to determine which analyses you need in order to prove or disprove each hypothesis.
Remember that a hypothesis is merely a theory to be proved or disproved. It is not the answer. If your IH is correct, then, a few months down the road, it will be the first slide in your presentation. If it turns out to be wrong, then, by proving it wrong, you will have enough information to move toward the right answer. By putting your IH down on paper, and determining how you can prove or disprove it, you have set up a road map that you can follow to an eventual proved solution.
GENERATING THE INITIAL HYPOTHESIS
The IH emerges from the combination of facts and structure. Therefore, as the first step in generating an IH, you must start with the facts. Remember, however, that you don't want to do a lot of digging around for information before you know where to dig. One former McKinsey SEM had a good approach for generating IHs:
At the start of an engagement, I would just try to digest as much of our fact base as possible. I would sit down with the trade publications in that industry for an hour or two—not so much to gather facts as to absorb something of the flavor of that industry: what the jargon is, what the current industry issues are. I would especially seek out people in the Firm who knew about this particular industry. That was the quickest, most efficient way to get up to speed.
When generating an initial hypothesis, you don't need all the facts, just enough to have a good overview of the industry and the problem. If the problem is in your own business, you may already have the facts in your head. That's great, but facts are not enough. You have to apply structure to them.
To structure your IH begin by breaking the problem into its components—the key drivers (see "Find the Key Drivers," in Chapter 3 ). Next, make an actionable recommendation regarding each driver. This is extremely important. Suppose your business's profits are greatly affected by the weather; in fact, it is the key determinant of profits in a given quarter. "We have to pray for good weather" is not an actionable recommendation. On the other hand, "We must reduce our vulnerability to changes in the weather" is an actionable, top-line recommendation.
For your next step, you must take each top-line recommendation and break it down to the level of issues. If a given recommendation is correct, what issues does it raise? Consider the likely answers to each issue. Then go down another level. For each issue, what analyses would you need to make to prove or disprove your hypothesis? With a little experience, and a lot of debate within your team, you should get a good sense of what is provable and what is not. This will help you avoid blind alleys.
In the Acme Widgets problem, suppose your team decided that the key drivers were the sales force, the consumer marketing strategy, and production costs. You then came up with a list of actionable, top-line recommendations as your initial hypothesis:
We can increase widget sales by:
• Changing the way we sell our widgets to retail outlets.
• Improving the way we market our widgets to consumers.
• Reducing the unit cost of our widgets.
Let's begin with a closer look at the sales force. It's organized geographically (Northeast, Mid-Atlantic, Southeast, etc.) and sells primarily to three types of retail outlets: superstores, department stores, and specialty stores. The team believes that the sales force ought to be organized by customer type—that's one issue.
What analyses could prove or disprove that belief? You could break out the sales by customer type for each region. If penetration of superstores in the Northeast is higher than in any other region and higher than for the other types of retail outlets, find out why. When you talk to the Northeast sales reps, you might find that they have a better feel for superstores than any other sales team. What if they were put in charge of all superstores across the country and achieved the same penetration? What would that mean for widget sales?
The end product of this exercise is what McKinsey calls the issue tree. In other words, you start with your initial hypothesis and branch out at each issue. The result looks like the figure below.
When you've completed your issue tree, you have your problem-solving map. That's the easy part. The difficult part will come when you have to dig deep to prove your hypothesis.
ISSUE TREE FOR ACME WIDGETS
TESTING THE INITIAL HYPOTHESIS
Before you take your problem-solving map out on the road, you want (forgive the mixed metaphor) to kick the tires on it. Test it. Is it the best possible hypothesis you could devise, given what you know about the industry and your client or company? Have you thought about all the issues? Have you considered all the drivers of the problem? Are all your recommendations actionable and provable?
When I discussed generating an IH, I used the phrase "your team" rather than "you." My experience at the Firm (and that of the many McKinsey alumni I interviewed for this book) taught me that IHs produced by teams are much stronger than those produced by individuals. Why? Most of us are poor critics of our own thinking. We need others to pick apart our ideas. A team of three or four bright individuals is an excellent vehicle for that.
So when your team meets to come up with an IH let a thousand flowers bloom. Everyone should have his or her own ideas and initial hypotheses. Everyone should be prepared to push a teammate's thinking and test each new idea. If you are the team leader, you should try to be the thought leader too. Try to take a different approach from whatever has just been said. Ask, "What if we change this? What if we push that? How about looking at it this way?" The process involves shooting a certain amount of bull. That's OK, have fun—as long as it pushes your thinking. (For more ideas and techniques to push your team's thinking, see Chapter 9.)
Chapter Two
DEVELOPING AN APPROACH
Just knowing the essence of the McKinsey problem-solving process does not mean you can now go forth and conquer the business world by being fact-based, structured, and hypothesis-driven. No two business problems are identical; you must figure out how to approach each problem in order to devise the best solution for it.
In this chapter, I will explain how McKinsey-ites approach business problems and apply the McKinsey problem-solving process to maximum effect.
THE PROBLEM IS NOT ALWAYS THE PROBLEM
Sometimes a business problem will land on your desk and you will be told to solve it. Fair enough. But before you go rushing off in any particular direction, make sure you're solving the right problem—it may not be the one you were given.
A McKinsey alumnus with a scientific background told me that business problem solving is organic and complex, like medicine. A patient will come into a doctor's office and say that he thinks he has the flu. He will tell the doctor about his symptoms: scratchy throat, achy head, and runny nose. The doctor will not immediately trust the patient's conclusion. She will take the patient's history, ask some probing questions, and then make her diagnosis. The patient may have the flu, or a cold, or something more serious, but the doctor will not rely on the patient to diagnose himself.
Description:
"If more business books were as useful, concise, and just plain fun to read as THE MCKINSEY WAY, the business world would be a better place." --Julie Bick, best-selling author of ALL I REALLY NEED TO KNOW IN BUSINESS I LEARNED AT MICROSOFT.
"Enlivened by witty anecdotes, THE MCKINSEY WAY contains valuable lessons on widely diverse topics such as marketing, interviewing, team-building, and brainstorming." --Paul H. Zipkin, Vice-Dean, The Fuqua School of Business
It's been called "a breeding ground for gurus." McKinsey & Company is the gold-standard consulting firm whose alumni include titans such as "In Search of Excellence" author Tom Peters, Harvey Golub of American Express, and Japan's Kenichi Ohmae.
When Fortune 100 corporations are stymied, it's the "McKinsey-ites" whom they call for help. In THE MCKINSEY WAY, former McKinsey associate Ethan Rasiel lifts the veil to show you how the secretive McKinsey works its magic, and helps you emulate the firm's well-honed practices in problem solving, communication, and management.
He shows you how McKinsey-ites think about business problems and how they work at solving them, explaining the way McKinsey approaches every aspect of a task:
How McKinsey recruits and molds its elite consultants;
How to "sell without selling";
How to use facts, not fear them;
Techniques to jump-start research and make brainstorming more productive;
How to build and keep a team at the top its game;
Powerful presentation methods, including the famous waterfall chart, rarely seen outside McKinsey;
How to get ultimate "buy-in" to your findings;
Survival tips for working in high-pressure organizations.
Both a behind-the-scenes look at one of the most admired and secretive companies in the business world and a toolkit of problem-solving techniques without peer, THE MCKINSEY WAY is fascinating reading that empowers every business decision maker to become a better strategic player in any organization.
Amazon.com Review
The McKinsey Way , by former McKinsey & Company associate Ethan M. Rasiel, provides a through-the-keyhole perspective on the way this worldwide consulting institution approaches--and solves--the myriad professional problems encountered by its high-powered clientele. His goal, Rasiel writes, is simple: to communicate "new and useful skills to everyone who wants to be more useful in their business." He then does so by explaining the highly structured, fact-based proprietary methodology that McKinseyites are taught to employ with their Fortune 100 clients, complete with details on the entire process from first considering the basic situation at hand through finally selling a solution to the appropriate powers that be.
All of the critical steps (assembling a team, managing a hierarchy, doing research, conducting interviews, brainstorming) are broken down into specific actions and fleshed out with applicable examples that Rasiel has gathered through interviews with dozens of other former McKinsey employees. The concluding sections on surviving the mythically grueling pace at the organization, known simply to insiders as "the Firm," are designed to help readers successfully tackle the similar challenges and obstacles they regularly face in their own work environments. --Howard Rothman.
From the Back Cover
Penetrate the McKinsey mystique and learn the secrets of the world's most sought after consulting firm.
Praise for The McKinsey Way :
"If more business books were as useful, concise, and just plain fun to read as The McKinsey Way , the business world would be a better place."Julie Bick, Best-selling author of All I Really Need to Know in Business I Learned at Microsoft
"Enlivened by witty anecdotes, The McKinsey Way contains valuable lessons on widely diverse topics such as marketing, interviewing, team-building, and brain-storming."Paul H. Zipkin, Vice-Dean, The Fuqua School of Business, Duke University
"Apt to become the reference book on business management. With the help of The McKinsey Way , managers can approach issues they face as if they had a McKinsey expert beside them. It will certainly help those of use who cannot afford McKinsey!"Mord Weisler, Chairman, PRI Automation, Inc
"The closest thing to getting three years of consulting experience in three hours."John Alsop, President, Progress Software
" The McKinsey Way describes a course of analysis that is very powerful, well-written, and effective."Peter A. Brooke, Chairman, Advent International
About the Author
Ethan M. Rasiel joined McKinsey & Co.'s New York office in 1989 and worked there until 1992. While at "the firm", his clients included major companies in finance, telecommunications, computing, and consumer goods sectors. Before working at McKinsey, he worked as an equity fund manager at Mercury Asset Management in London. He has also worked as an investment banker. He has a bachelor's degree from Princeton University and an MBA from the Wharton School at the University of Pennsylvania.
Excerpt. © Reprinted by permission. All rights reserved.
THE McKINSEY WAY
Using the Techniques of the World's Top Strategic Consultants to Help You and Your Business By ETHAN M. RASIEL
McGraw-Hill
Copyright © 1999 Ethan M. Rasiel
All right reserved.
ISBN: 978-0-07-053448-3
Contents
Chapter One
BUILDING THE SOLUTION
Like all things McKinsey, the Firm's problem-solving process has three major attributes. When team members meet for the first time to discuss their client's problem, they know that their solution will be
• Fact-based
• Rigidly structured
• Hypothesis-driven
In this chapter, you will learn exactly what these attributes mean and how you can apply them in your business.
FACTS ARE FRIENDLY
Facts are the bricks with which you will lay a path to your solution and build pillars to support it. Don't fear the facts.
Problem solving at the Firm begins with facts. On the first day of an engagement, all members of the team comb through stacks of articles and internal research documents to gather enough facts to illuminate their piece of the problem for the first team meeting. Having drawn up an initial hypothesis for the problem, the team then races to gather the facts necessary (when put through the appropriate analyses) to support or refute it.
At the start of your time at McKinsey, gathering and analyzing facts is your raison d'étre. As one former SEM observed:
When you strip away a lot of the high-minded language with which McKinsey dresses up its problem-solving process, it comes down to very careful, high-quality analysis of the components of the problem combined with an aggressive attitude toward fact gathering.
Why are facts so important to the way McKinsey does business? There are two reasons. First, facts compensate for lack of gut instinct (see "... But Every Client Is Unique" in Chapter 2 ). Most McKinsey-ites are generalists. They know a little about a lot of things. As they gain experience and move through the ranks, they may come to know a lot about a lot of things. Even at this point, however, they will still know less about, say, inventory management practices for perishable foodstuffs than the folks who have been running the distribution operations of Stop & Shop for the last 10 years. Gut instinct might tell those folks the solution to an inventory management problem in 10 seconds (although they still would be wise to check the facts); McKinsey will go to the facts first.
Second, facts bridge the credibility gap. When she joins the Firm, the typical associate (at least in the United States) will have graduated near the top of her college class, spent two or three years working for a large company, then received her MBA from a top business school. She will be in her mid- to late twenties. On her first engagement she may have to present her analysis to the CEO of a Fortune 50 company, who will not give much credence to what some newly minted, 27-year-old MBA has to say—unless she has an overwhelming weight of facts to back her up. This is just as true for a junior executive presenting a proposal to his boss.
Despite (or possibly because of) the power of facts, many businesspeople fear them. Perhaps they are afraid that if they look too closely at the facts, they—or someone above them—might not like what they see. Maybe they think that if they don't look, the nasty facts will go away—but they won't. Hiding from the facts is a prescription for failure—eventually, truth will out. You must not fear the facts. Hunt for them, use them, but don't fear them.
FEEL FREE TO BE MECE
To structure your thinking when solving business problems (or anything, for that matter), you must be complete while avoiding confusion and overlap.
MECE (pronounced "me-see") stands for "mutually exclusive, collectively exhaustive" and it is a sine qua non of the problem-solving process at McKinsey. MECE gets pounded into every new associate's head from the moment of entering the Firm. Every document (including internal memos), every presentation, every e-mail and voice mail produced by a McKinsey-ite is supposed to be MECE. Ask any number of McKinsey alumni what they remember most about the way the Firm solves problems and they will tell you, "MECE, MECE, MECE."
MECE structures your thinking with maximum clarity (hence minimum confusion) and maximum completeness. MECE starts at the top level of your solution—the list of issues making up the problem you have to solve. When you think you have determined the issues, take a hard look at them. Is each one a separate and distinct issue? If so, then your issue list is mutually exclusive. Does every aspect of the problem come under one (and only one) of these issues—that is, have you thought of everything? If so, then your issues are collectively exhaustive. Suppose your team is working on a study for that famous American manufacturing firm Acme Widgets. The problem you face is "We need to sell more widgets." Your team might come up with a list of the following ways to increase widget sales:
• Changing the way we sell our widgets to retail outlets.
• Improving the way we market our widgets to consumers.
• Reducing the unit cost of our widgets.
If this list looks rather generic, that's fine; we will talk about moving down a level of detail in the next section. What matters is that the list is MECE.
Suppose you add another item, say, "Reengineering our widget production process." How does that fit with the three issues you already have? This is certainly an important issue, but it isn't a fourth point alongside the others. It falls under "Reducing the unit cost," along with other sub-issues such as "Leveraging our distribution system" and "Improving our inventory management." Why? Because all these are ways to reduce the unit cost of widgets. Putting any (or all) of them with the other three issues on the list would cause an overlap. The items in the list would no longer be mutually exclusive. Overlap represents muddled thinking by the writer and leads to confusion for the reader.
Once you have a list in which all the items are separate and distinct (i.e., mutually exclusive), you have to check that it also includes every issue or item relevant to the problem (i.e., it is collectively exhaustive). Go back for a moment to "Reengineering our widget production process." You put this under "Reducing the unit cost." Now one of your team members says, "We should think about ways to improve widget quality through the production process."
She's right. Does this mean you should go back to having reengineering as an issue in its own right? No, but you should refine your list to include, under "Reducing unit cost," the subissue "Reengineering the production process to reduce unit cost," and, under "Improving the way we market ...," the subissue "Reengineering the production process to improve widget quality." Now you have something that looks like this:
• Changing the way we sell our widgets to retail outlets.
• Improving the way we market our widgets to consumers. –Reengineering the production process to improve widget quality.
• Reducing the unit cost of our widgets. –Reengineering the production process to reduce unit cost.
Suppose your team has come up with some interesting ideas that don't fit under the main issues. What then? You could ignore those points, but that wouldn't help Acme. You could make them issues in their own right, but then you would have too many issues. A good McKinsey issue list contains neither fewer than two nor more than five top-line issues (of course, three is best).
There is a solution to this dilemma—the magical category "Other Issues." If you can't figure out where to put those two or three brilliant ideas, there is always Other Issues. There is a caveat, however. Avoid using Other Issues in your top-line list—it looks out of place. It's fine lumped in among a bunch of subissues, but on the first slide of a big presentation, it sticks out. So try a little harder to fit those brilliant ideas into your top-line issues. Chances are you can. Still, if all else fails, Other Issues will help you stay MECE.
SOLVE THE PROBLEM AT THE FIRST MEETING—THE INITIAL HYPOTHESIS
Solving a complex problem is like embarking on a long journey. The initial hypothesis is your problem-solving map.
The initial hypothesis (IH), the third pillar of the McKinsey problem-solving process, is the most difficult to explain. To make the explanation easier for you (and me), I will break this section into three parts:
• Defining the initial hypothesis.
• Generating the initial hypothesis.
• Testing the initial hypothesis.
DEFINING THE INITIAL HYPOTHESIS
The essence of the initial hypothesis is "Figure out the solution to the problem before you start." This seems counterintuitive, yet you do it all the time.
Suppose you have to drive to a restaurant in a part of town you don't know. You know you have to make the third left off Smith Street and then take the first right; it's just after that corner. You know how to get to Smith Street; you'll just follow your directions from there. Congratulations, you have an initial hypothesis.
Solving business problems is more complicated than finding a restaurant, but the initial hypothesis works the same way. It is a road map, albeit hastily sketched, to take you from problem to solution. If your IH is correct, then solving the problem means filling in the details of the map through factual analysis.
Let's return to Acme Widgets from the last section. You and your team must find a way to increase sales at the widget business unit. After you've brainstormed using your knowledge of the widget business, but before you've spent a lot of time gathering and analyzing the facts, you might come up with the following top-line IH:
We can increase widget sales by:
• Changing the way we sell our widgets to retail outlets.
• Improving the way we market our widgets to consumers.
• Reducing the unit cost of our widgets.
As I will show in the next section, you would then take each issue down to another level or two of detail to determine which analyses you need in order to prove or disprove each hypothesis.
Remember that a hypothesis is merely a theory to be proved or disproved. It is not the answer. If your IH is correct, then, a few months down the road, it will be the first slide in your presentation. If it turns out to be wrong, then, by proving it wrong, you will have enough information to move toward the right answer. By putting your IH down on paper, and determining how you can prove or disprove it, you have set up a road map that you can follow to an eventual proved solution.
GENERATING THE INITIAL HYPOTHESIS
The IH emerges from the combination of facts and structure. Therefore, as the first step in generating an IH, you must start with the facts. Remember, however, that you don't want to do a lot of digging around for information before you know where to dig. One former McKinsey SEM had a good approach for generating IHs:
At the start of an engagement, I would just try to digest as much of our fact base as possible. I would sit down with the trade publications in that industry for an hour or two—not so much to gather facts as to absorb something of the flavor of that industry: what the jargon is, what the current industry issues are. I would especially seek out people in the Firm who knew about this particular industry. That was the quickest, most efficient way to get up to speed.
When generating an initial hypothesis, you don't need all the facts, just enough to have a good overview of the industry and the problem. If the problem is in your own business, you may already have the facts in your head. That's great, but facts are not enough. You have to apply structure to them.
To structure your IH begin by breaking the problem into its components—the key drivers (see "Find the Key Drivers," in Chapter 3 ). Next, make an actionable recommendation regarding each driver. This is extremely important. Suppose your business's profits are greatly affected by the weather; in fact, it is the key determinant of profits in a given quarter. "We have to pray for good weather" is not an actionable recommendation. On the other hand, "We must reduce our vulnerability to changes in the weather" is an actionable, top-line recommendation.
For your next step, you must take each top-line recommendation and break it down to the level of issues. If a given recommendation is correct, what issues does it raise? Consider the likely answers to each issue. Then go down another level. For each issue, what analyses would you need to make to prove or disprove your hypothesis? With a little experience, and a lot of debate within your team, you should get a good sense of what is provable and what is not. This will help you avoid blind alleys.
In the Acme Widgets problem, suppose your team decided that the key drivers were the sales force, the consumer marketing strategy, and production costs. You then came up with a list of actionable, top-line recommendations as your initial hypothesis:
We can increase widget sales by:
• Changing the way we sell our widgets to retail outlets.
• Improving the way we market our widgets to consumers.
• Reducing the unit cost of our widgets.
Let's begin with a closer look at the sales force. It's organized geographically (Northeast, Mid-Atlantic, Southeast, etc.) and sells primarily to three types of retail outlets: superstores, department stores, and specialty stores. The team believes that the sales force ought to be organized by customer type—that's one issue.
What analyses could prove or disprove that belief? You could break out the sales by customer type for each region. If penetration of superstores in the Northeast is higher than in any other region and higher than for the other types of retail outlets, find out why. When you talk to the Northeast sales reps, you might find that they have a better feel for superstores than any other sales team. What if they were put in charge of all superstores across the country and achieved the same penetration? What would that mean for widget sales?
The end product of this exercise is what McKinsey calls the issue tree. In other words, you start with your initial hypothesis and branch out at each issue. The result looks like the figure below.
When you've completed your issue tree, you have your problem-solving map. That's the easy part. The difficult part will come when you have to dig deep to prove your hypothesis.
ISSUE TREE FOR ACME WIDGETS
TESTING THE INITIAL HYPOTHESIS
Before you take your problem-solving map out on the road, you want (forgive the mixed metaphor) to kick the tires on it. Test it. Is it the best possible hypothesis you could devise, given what you know about the industry and your client or company? Have you thought about all the issues? Have you considered all the drivers of the problem? Are all your recommendations actionable and provable?
When I discussed generating an IH, I used the phrase "your team" rather than "you." My experience at the Firm (and that of the many McKinsey alumni I interviewed for this book) taught me that IHs produced by teams are much stronger than those produced by individuals. Why? Most of us are poor critics of our own thinking. We need others to pick apart our ideas. A team of three or four bright individuals is an excellent vehicle for that.
So when your team meets to come up with an IH let a thousand flowers bloom. Everyone should have his or her own ideas and initial hypotheses. Everyone should be prepared to push a teammate's thinking and test each new idea. If you are the team leader, you should try to be the thought leader too. Try to take a different approach from whatever has just been said. Ask, "What if we change this? What if we push that? How about looking at it this way?" The process involves shooting a certain amount of bull. That's OK, have fun—as long as it pushes your thinking. (For more ideas and techniques to push your team's thinking, see Chapter 9.)
Chapter Two
DEVELOPING AN APPROACH
Just knowing the essence of the McKinsey problem-solving process does not mean you can now go forth and conquer the business world by being fact-based, structured, and hypothesis-driven. No two business problems are identical; you must figure out how to approach each problem in order to devise the best solution for it.
In this chapter, I will explain how McKinsey-ites approach business problems and apply the McKinsey problem-solving process to maximum effect.
THE PROBLEM IS NOT ALWAYS THE PROBLEM
Sometimes a business problem will land on your desk and you will be told to solve it. Fair enough. But before you go rushing off in any particular direction, make sure you're solving the right problem—it may not be the one you were given.
A McKinsey alumnus with a scientific background told me that business problem solving is organic and complex, like medicine. A patient will come into a doctor's office and say that he thinks he has the flu. He will tell the doctor about his symptoms: scratchy throat, achy head, and runny nose. The doctor will not immediately trust the patient's conclusion. She will take the patient's history, ask some probing questions, and then make her diagnosis. The patient may have the flu, or a cold, or something more serious, but the doctor will not rely on the patient to diagnose himself.
(Continues...)
Excerpted from THE McKINSEY WAYby ETHAN M. RASIEL Copyright © 1999 by Ethan M. Rasiel. Excerpted by permission of McGraw-Hill. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.