How can I give a good presentation to important, non-technical stakeholders?

Question

At the end of the month, I have to give a presentation on a software project that I've been working on by myself that will basically decide whether or not I will get a full-time job at the company I'm a temporary hire for now. I will be giving my presentation to the president of our department, and two VP's. The president has less programming knowledge than the other two VP's and is ultimately the person I need to impress.

What are the most important things I need to convey in the presentation? I've already been told by my manager to emphasize the following things:

1. I am steering this project in the right direction and am in full control of everything.
2. I am completing this project on schedule.

What other things should I focus on during my presentation to make myself appear as hire-worthy as possible? I'm thinking of highlighting the efforts I'm making on a design level to reduce risk and uncertainty in the software (two things I imagine are very important to the higher-ups).

One thing I'm particularly worried about is finding the right balance between technical and non-technical details in the presentation. If I don't include any technical details, the president of our department won't know about all of the "under the hood" features that are in the software, but if I'm too technical, he might get lost and not understand important points in the presentation.

Any tips would be appreciated.

Answer 1

Know Your Audience.

You've already conquered the number 1 rule of public speaking - you've assessed the technical expertise of the people you'll be speaking to and your presentation should be tailored accordingly. Don't worry about blinging out your presentation with lots of techno-garble and leet-speak.

A big temptation when facing the big wigs is to really try and WOW them with your impressive dictionary of technical concepts, theories, and applications. The idea being, of course, that if you've sufficiently befuddled the boss, then of course you must be qualified for this job!

This will even work, probably, in the short term of getting you the full-time position you're looking for. The president, however, will undoubtedly walk away from the meeting thinking, "I have no idea what that guy was talking about," and you can bet your life that will be the impression he has of you for the Rest of Your Life.

Why is that bad? In the business world, CEO's, presidents, etc. look for people who they can communicate with. Yes, its important to have highly capable, technically advanced geeks in the trenches who can debug C code that interfaces with a custom serial port but guess what? They don't care. All they care about is that you are in control and that they can trust you. The most sure-fire way into the inner-circles (promotion, money, glory, spoil) is effective communication with the higher-ups.

Here is the advice: focus on your accomplishments with the company to date. Don't dig into the nuts and bolts and wiring - their eyes will glaze over and you'll be Just Another Programmer to them. Spend time talking about things that they can understand and have your bosses walk away from you with the confidence to say, "I trust this man to get the job done."

Answer 2

One of the most important things you should keep in mind is to not oversell. Presenting too much information, especially when it comes to a technical project being presented to non-technical personnel, will quickly lose your audience. Do your best to make sure that every topic you discuss is significant to the "big picture".

As to the "big picture", non-technical management generally tries to translate technical discussion into terms of cost, time, and quality.

With that in mind, you can mention major decisions you've made in the project, and highlight the benefit of those decisions in terms of cost, time, and/or quality. Try to pick out 3-4 key decisions, and keep your discussion of those decisions brief. If they want more information, they'll ask (just be prepared to answer!).

I would also highly recommend that you run your presentation by a non-technical friend before hand, and get their opinion. It is very easy to think that you are being non-technical when in fact you are still using far too much jargon. The less technical your friend is, the better. Try to find someone who can barely turn on a computer, let alone program. If they can follow the gist of what you are saying, you are in good shape.

Answer 3

I've found that most technical people (including myself) have a tendency to be too technical. Odds are that you will be surprised at how little of the technical stuff they can follow. For example, if you are going to explain that you are reducing risk and uncertainty, make it very clear that all projects have risk and uncertainty, not just yours, because it isn't a slam dunk that they know this.

If the risk and uncertainty stem from non-technical issues and management is concerned, or at least aware, of them, then by all means include what you've done.

Also, emphasize the positive, since they will take away at least as much from your tone as anything you say. So don't spend a lot of time on risk and uncertainty. If you need to bring this up to cover yourself later for things beyond your control, you might want to cover what you will need from other people to complete the task on schedule. Since for most projects other people not doing what they need to in a timely manner is a real possibility, this reduces the chance you are blamed for it.

Although technical people will realize the key importance of "under the hood" features, non-technical people won't. You probably can't do more than say that this project has some technical issues that were important to spend time on, like foozbars, whatsits, and blah blahs, but you are doing all that and things are on schedule.

Answer 4

Well, the description of your project is very vague, but I'll try.

I imagine the application you built is either a replacement to a different application or a tool to automate a process that was or still is carried out manually.
Make a case analysis for different scenarios comparing the workflow before and after the introduction of your software. Things I would like to see:

• show how you streamlined very common scenarios
• show versions, that had flaws in the user experience and how you enhanced them. show how you implemented feedback given to you.
• show some numbers or tables comparing time, productivity, features, etc. before and after. Here is what I hear "By the use of static noise and more static noise we decreased the time needed to do X by Y%"

Personally, I don't care for what's happening under the hood and your managers care even less (I do in fact spend a lot of time on it and enjoy that, but I know that I don't generate value by messing with things nobody will ever see). A software product (component, library, framework or application) needs to be usable (robust, fast, flexible, predictable) and reasonably future-proof.

If I hired you, I want to be convinced, that you value these qualities. I would like you to explain me by which means you try to achieve them and why you chose those means. I want to see that you use good tools. Show me the statistics of the projects tracker. Give me an overview of the development methodologies you use, explain them and their advantages briefly (for about every thing on earth, there is a fancy-shmancy two liner that makes it sound convincing). Show me how working with you will be pleasant, how you will be able to react to my ever changing needs and how communication with you is very pleasant, because you don't just throw technical details at me, but offer solutions, that of course are implemented on a technical level, but that you will be able to represent in terms that I understand and that are relevant to me.

Answer 5

Consider structuring the preso like a newspaper story: important stuff first (plan to start late, and get cut off early), and cover the who, what, why, when, where and how. I like the One Minute Manager single-page templates, they force me to get things boiled down nicely.

Re presentation style:

• Script it, and practice ahead of time. Make a video of yourself, watch it the next morning. Practice again.
• Go at your own pace (some people work better if they pause and swirl their coffee, but can you imagine a slow Robin Williams?), but do incorporate some planned pauses and restatements for important points. Timing ... it's hard, it needs practice.
• don't, don't, don't make some PPT you stand there and read. Don't make a PPT you could stand there and read, because then that's exactly what you'll do. Use the PPT to display graphics, to show just the key word or two. You want them focused on you, not the preso. The 10/20/30 Kawasaki recommendation is good.
• Practice ahead of time :) so you have a few spare cycles for making eye contact, watching for clues to adapt to, and so you know what you're dropping if they start to pull you off-track.

Re content:

• After the newspaper summary, cover the requirements - and include some deferred requirements (things you learned but don't fit in the scope of the current effort) ... include some things you considered as requirements at first but were able to shed as you investigated.
• State key risks in business terms - they won't care about the risk that "RDF data won't shard well", they care that you considered the risk "data model scaling will require rework if we get increasingly complex customer data" and that you have a response for every risk: how will they know if the risk event is happening (what's your metric) and what have you already done about it, what will the team be able to do about it if it happens.
• It could be that a risk is still not well defined, is under-handled, or is catastrophic and unfixable if it occurs - say so. How far you go into the risk pile depends on the subject (medical? games?) so this is an area where your judgement will show.

Subtext: You've been working by yourself and that is always a bit scary for management - so, make sure you include indicators of how you kept others apprised of progress, how you learned the stated and the real requirements. Management believes the tech part is tedious and needs clever people, but is ultimately always doable ... companies seldom succeed or fail based on tech skills, and they know that, so don't try too hard impress them with that, don't try to teach them technologies. Rather, impress them with how well you investigate and frame a problem, catalyse a discussion, communicate your progress.

Answer 6

The two major concerns don't require anything technical for the direction and timeliness of your progress. Get feedback from other people who have been involved. You don't want any surprise questions or concerns during the presentation.

Focus on the direction of the project. They may need a refesher on what this is all about or they may not have been involved in any of the planning. Gives examples of how you are fulfilling this.

Present milestones of the project and your performance. Mention any specification changes that may have altered the timeline.

Don't avoid mentioning any problems in the project. The key is how you've been able to over-come them. This should give them insight into your ability to handle future challenges.

Talk slow. Be calm. Don't forget to breath.

Answer 7

While you can highlight the decisions made, technologies used, and problems overcome, upper management is typically going to be focused on bottom line issues:

• Implementing this project, this way, helps us do business faster, better and at a lower cost...
• The estimated cost of this project is X, the short-term savings are Y and the long-term savings are Z. (You can get away with X being greater than Y, but it better be less than Z)

Some of the best points will be if as you were working on the project you found ways that increased the savings or performance when compared to the original project design. We can hope/assume that the project wouldn't be started unless management thought they were going to make/save money... if you increased the bottom line that is even better.

These kinds of metrics are important because one thing they are looking at is the cost of keeping you around, and wondering if the benefit of doing so is going to add to or subtract from the bottom line.

Answer 8

The 10/20/30 Rule of PowerPoint from Guy Kawasaki would be my suggestion if you do use PowerPoint in your presentation as the principles he outlines are pretty good about having just 10 slides, 20 minutes, etc.

Answer 9

A few things you may also consider:

Entertain them. Don't be a clown but a little passion or humor will make them pay more attention.

Slow your speech down and add pauses for emphasis.

Make eye contact with everyone in the room, not only the decision maker or boss, since others may have influence to the boss as well...

Try to have some stories.. Tell them about funny things that happened to you during the project, or even the bad ones.. Make them live the mood with you...

Summarize, summarize, summarize... Always keep them up with you...

A good hint: Stress on the technical issues that they can follow up with.. Make them feel they understand the technical part as well.. It'll give them good feeling...

Use statements like That's a good question as much as you can...

Answer 10

You wrote,

"One thing I'm particularly worried about is finding the right balance between technical and non-technical details in the presentation."

Garr Reynolds is one of the leading experts on the art of presentation, and in one of his blog posts from 2005 (still timely), he compares the presentation styles of Steve Jobs and Bill Gates. Even if you don't read the insightful article, you can get a hint from the screenshots comparing Bill's slideshow and Steve's slideshow as to which presentation is more compelling and which one is more likely to put the audience to sleep (hint: the one with all the bullet points and over-done styling).

http://presentationzen.blogs.com/presentationzen/2005/11/the_zen_estheti.html

Since 2005, Bill has improved his presentation style, and Garr covers Bill's improvements in a blog post from 2010.

http://www.presentationzen.com/presentationzen/2010/08/the-naked-transformation-of-bill-gates-the-presenter.html