My apologies for the sarcastic tone above, but it is extremely unlikely that this scene will play out like this. And, even harsher-sounding: This is really just your ego talking. And you should not let it. Here is why:

Why surprises are a problem

1. The first question you cannot answer will ruin everything.

It may be just a trivial question that you have not really looked up, or forgot in the sea of data you are trying to hold on to. Something innocuous, like: “Who did you get the information about the launching date of this device from?” Or it could be something substantial, like: “Does your analysis here include the total investment requirement?” And it is possible this was not asked of you to do, but the person in this particular meeting does not know that.

Now, in either case, a “Don’t quite recall“, or “No, we did not do an investment analysis“, is going the deliver a serious blow to your credibility, right our of the gate. With a couple of questions like this, it will be all uphill from there. Why? Because this group may hardly remember you from the initial meeting, have not heard from you for a few weeks or months, and has no idea what obstacles you overcame, or what great material you have for them in the next few slides!

You have a minimal relationship with them, they have not seen your process so they can come to trust you. They also have had no time to absorb and process your research.

All these questions – in fact, ALL questions, need to have been answered in previous discussions with the team, to the fullest. This final presentation only needs to deliver the final, polished document and supporting evidence to a broader team. But you already have the understanding and the agreement of the key team members to your work. In this scenario, the client is likely to answer the question for you, (“We did not include the investment request because we know it will be in our range”).

The only way to have a nice surprise at the end, is to have no bad surprises. And they are all bad surprises if you have not been communicating substantively and quite massively during the process.

2.You will probably not get to the heart of the issues.

Most problem statements are not crafted very accurately at the fisrt meeting, so your follow-on work will probably miss important issues. The first meeting is only the beginning of the conversation, not the end. Depending on the complexity of the issues involved, and the depth of understanding of both teams, it will likely take some time to surface the deeper problems. And these are the ones that will trip you up at the end if you don’t resolve them. It could be something technical, e.g. “We actually failed three previous tests of this process”; or organizational, e.g. “we will not likely get any cooperation from the overseas team”; or external, e.g. “these two potential partners are at serious odds with each other”.

Unless you get to the point where these issues come up, you solution could be irrelevant, or marginal in the end. To get to these issues, you need to practice your ‘probing’ skills – asking why, what, when, where, how, who etc, until you shed light at every little corner of the problem. You need to catch body language, hesitations, incomplete answers, that hint to a hereto-forth unexpressed concern.

These discussions will allow the consulting and the client team to think deeper, remember history, circumstances, etc that may not be readily connected to the problem in everyone’s mind. Or may not be easily admissible, or even be controversial. Nevertheless, unless you do that, you will not have the correct issue statement.

Obviously, you also need to get the basics right, e.g. the main objective (short-term, long-term), the criteria you must observe etc See “Why you can’t crack this problem”).

Take your time setting up the problem, with all the elements needed. If it does not happen in one meeting, request more. And be diligent to keep checking all these assumption though the entire initial period – things can change as people come to know you, and as more information from others is added to the mix!

3. No one can absorb a massive amount of data in one sitting.

Learning takes time. The more complex the problem, the more time you will need – not to solve it, but to educate the consulting and the client team about the issues. The key is depth. You need to present the deepest reasons why something is a fact, and you need to allow them time to process, and come back with questions, or with agreement.

It’s not enough to say: “this pricing will not work in Brazil”. The client must know if it is because of the competition (in that case, can we change our value prop?); or because of our own costs; or because, the price ceiling is actually set by the government!

Only then, can you actually know how firm that constraint is. “will not work” has many shades of grey. Is it 10% or 100% or something in-between? How much can we change the assumptions to make it work?

So, for people to absorb all the nuances, and be convinced beyond a shadow of a doubt, it takes time, and many iterations. For all the cornerstones of your recommendations, this complete clarity must be established. And, I would suggest, clarity must be achieved for every single piece of evidence you present.

The final presentation is not the time to have these questions come up. People must know, and believe, and have had a chance to ‘sleep on it’, over a long period of time.

Learning is an iterative process, founded on repetition, and reflection that allows connections to be build. You will not raise institutional knowledge in a final presentation. Make sure you enforce a regular communication with substantive Q&A to make that happen.

The intended scenario in a final presentation is that there are no surprises whatsoever - everyone is already in informed agreement.

In fact, your best possible result in a final presentation is that there are no surprises whatsoever, everyone agrees on every point, and all nod enthusiastically at the end, and go off, already having launched the implementation of your recommended solutions! Isn’t that the target outcome anyway?

Why is that, and how do you make this happen?

How to win the war, not just a battle

1. Setup the project slowly and carefully.

Take the time to review the project, as initially defined, and set up your questions properly. Define everything.(“Define that“).  Develop a clear goal (See here) that you all understand and agree with. Consider all stakeholders, all time frames etc. etc. This initial setup of the problem will reveal new angles, that you would otherwise have left out of your analysis.

2. Allow time for learning.

Learning takes time. And I mean the actual comprehension of everything you have uncovered and everything you are suggesting – not merely the reading or knowledge of the facts. Real comprehension of all the complexities, the interconnections, the intended and unintended consequences, takes time. The brain needs time to build these new proteins, to connect the right neurons. You will never do justice to your work in a 2-hour meeting!

3. Give trust a chance.

Acceptance of your analysis and results is highly dependent on the trust the team has in you. It is impossible for an executive team to process everything you present in its full depth. There will be some key questions, and then some spot-checking. The rest will go on trust. Trust-building also takes time. You will never look like a hero in a surprise final presentation, if they have not come to trust you over a long period of time while you are chiseling away at the problem.

I hope you see why the long-way there, with frequent discussions, updates, brainstorming and sharing of information is the way to a successful outcome. Trust and learning demand time, and you must be solving the right problem too!

Think about how you might handle the next project differently.