Hi!

I believe you need a very careful explanation of what a structure actually is. Frankly, what you have outlined above is not an approach towards answering the client's question. It is just a list of topics you want to look into (albeit a nicely structured list of course).

What most people don't understand (including most junior consultants by the way) is the following:

• The purpose of a structure is NOT to tell the client/interviewer what you want to look into! This is just a fallout of the structure.
• The purpose of a structure is to clearly explain, HOW you will answer the precise question that has been asked! And this is something completely different than saying "I'm going to look into four areas..." - this doesn't tell anything about how you will answer the question.

What I very strongly recommend is the following test:

• Is the structure referring back to the core question asked by the client?
• Does the structure have an inherent logic according to which this question can be answered?

For example, a structure like "I want to look into four areas: Market Outlook, Target Company, Acquiring Company and Risks" does not pass any of these tests. Telling the interviewer what you want to look into is not a good structure, but just a list of topics. But it lacks the underyling rationale WHY you want to scrutinize these topics, and what you want to test by looking into them, and how this test will inform your answer to the client's question.

A structure is a logic - the logic according to which you will answer the question at hand. It is ideally rooted in a top-down disaggregation of the client objective which underlies the core question.

So you need to do three things:

1. Distill the core question (should we do this acquisition move?)
2. Define the criterion to answer the question (--> the conditions under which the answer to the above question would be YES --> there are 3 conditions at the highest level: (i) does it make financial sense?, (ii) are we able to execute this?, and (iii) can we adequately cope with the potential risks?)
3. The central and most important condition is (i), so we have to deine the criterion under which it makes financial sense. By pure logic, it makes sense if the additional value (=profit) created by the acquisition significantly exceeds the investments that we need to put on the table over the course of our investment horizon. So there is three things we have to quantify: 1. Additional Profit, 2. Investment Time Frame, and 3. Investment Amount.

ONLY THEN you start to outline all these qualitative elements that you have outlined above. Becaus now, they don't hang in the air anymore, but they serve a clear purpose: the purpose of checking, whether these conditions are met! (--> Quantifying the additional profits that can be realistically expected after acquisition and checking whether they are high enough to outweigh the investment in a reasonable time frame | Assessing whether the required capabilties are in place | understanding which potential risks need to be mitigated) But these buckets are NOT the core of the structure. They are just the "fallouts". The heart and soul of your structure is the logice that I just explained.

Outlining this by means of a top down logic tree is something that would set you apart lightyears from essentially any candidate who comes up with the typical bucket thinking.

It is a skill that needs to be learned, but once you master the principles, "difficult cases" simply don't exist anymore.

Cheers, Sidi