Hi,

First of all - not all issue trees can and should be MECE. Very often it's not the case.

Secondly - there is a number of ways how you can approach in a MECE way:

1. If your structure works mathematically (e.g. Total time spent on cleaning operation = # of people x Frequency x Hours per cleaning per person)
2. If your structure comes from a formula (e.g. output rate = total number of people being served / time to serve one person)
3. If you are using the common industry drivers (e.g. revenues = # of customers x av. check) (e.g Passengers on the plane = capacity x Load Factor) or the industry revenue streams (Fuel revenues / non-fuel revenues for the gas station) or the functional drivers (e.g. for the problems in sales : Sales strategy / sales people and allocation / motivation / sales process)
4. If your issue tree is a real framework used by the consultants (e.g. the famous Bain Cap framework for PE due dills: Market / Competitors / Company / Feasibility of exit) (e.g. People / Process / Technology) (e.g. The famous McKinsey framework - People don't want to do smth / they can't do smth / smth prevents them from doing that)
5. If your structure is a well-known academically MECE framework (e.g. Product / Distribution / Price / Marketing (Also known as 4P))

There is no magic pill how you can learn to build the MECE issue trees. !!!! It comes with a lot of Practice and reflection and building proper industry and functional knowledge. !!!!

Best

Dear A,

in general a good structure can be evaluated by a certain depth and breadth. The “depth” should be at least 3-4 levels while the “breadth” should cover the entire solution space. You can cross-check this with the MECE principles (For details see respective article on Preplounge), but the CE (collectively exhaustive) part is basically defining your breadth.

Finally, make sure to check for inter-linkages in your structure and point them out.

Simon

You cannot learn a ton of frameworks and somehow hope one of them will be applicable. This is the main issue I have with 'Case in Point' by Marc Consentino: his frameworks are overly specific, designed with 20/20 insight, and are just very damaging to the average candidate. If you have the book, please only look at the market sizing chapter and trash the rest. It is useful to know a few general frameworks (Cs, Ps, Profitability...), but mostly just to help you build a framework specifically adapted to the case at hand. Think of them as building blocks you can chose to use or not.

As for being MECE... Vlad and I apparently disagree here, though I suspect it is mostly semantics. You need to think in a MECE way at the onset, when you are building the structure. If not, you risk missing a very large part of the case (remember: it is the beginning, you have very little information, and cannot know what the recommendation will be yet). Besides - I and just about every other consultant will fail you if you do not think in MECE terms. Does that mean the answer needs to be MECE? No, no it doesn't: A critical consulting skill is to be able to think in 80/20: you do not have time to analyze every possible solution, and need to zero in on the most likely factors. business sense, experience and industry/situational knowledge will help here. Don't boil the ocean, develop hypothesis to focus on the most likely solutions first

tl;dr: Do NOT learn frameworks by heart; DO be MECE; do NOT give equal weight and time to every possible solution as you go through the case