How IT Can Give Better Presentations

Cut out jargon and focus on helping, not limiting, customers.

IT has long sought to be considered a partner to the other business leaders in our companies. It's all part of our pursuit of the holy grail of "having a seat at the table."

Naturally, getting there means we have to promote our ideas, explain technology concepts and communicate our plans. In today's world that also means we use a lot of PowerPoint presentations.

Sadly, IT doesn't have a reputation for giving great business presentations. In the world of death by PowerPoint, IT guys are ninjas.

A key to a good presentation is to tailor it to your audience. We have to recognize that the presentation we give to our business partners shouldn't be the same as the ones we give to our IT compatriots.

Too often we forget this. The presentation that wowed the IT folks fails miserably with our business leaders.  Here is my list of things you may want to avoid in your next presentation to the executive staff.

Too many slides. How often have you heard someone say, "Well, since I've only got 15 minutes to talk, I combined a number of slides and cut quite a few out and was able to pare my presentation down to just 67 slides." For a 15-minute presentation, six or seven slides, not 67, is a better guide.

The purpose of PowerPoint should be to act as a reinforcement to what you say and a stimulus to discussion, not a history of IT.

Business process swim lane diagrams. Although helpful for studying the details of a process, acting as a guide for technical specs and showing the responsibilities of the various groups involved, diagrams often send the wrong message in business meetings.

Our goal in process design is to simplify them and reduce the chance for error. Most processes typically have a path that is followed at least 90% of the time. This is what most people picture in their mind when they think of a process flow.

However, there are lots of alternate paths to handle exceptions, errors, reworks, etc., that add complexity to the overall process. The problem with the swim lane diagrams is that they show not only the most common path but also all alternates.

Showing all these various paths and lines going back and forth, it looks like we've added complexity instead of reducing it. It's much better to show only the major components of the core process in a simplified diagram to keep the discussion on point.

Technology stack chart. IT folks are proud of our technologies and how we tie them all together. These charts illustrate how the applications are tied to the application framework and the platforms.

The truth is that most people outside of IT don't care about this. They are, however, interested in what this technology will do for them, so stick to that topic.

The eye chart. How many presentations have you seen where the presenter puts up a slide with a lot of tiny text or a very busy diagram? This is usually accompanied with the statement, "I know this is something of an eye chart. Don't bother trying to read it. The key point is..."

Naturally, once you tell people not to try reading it, they of course do try to read it and they also stop listening to you while they're doing it. By the time they've given up trying to read it, you've already made your points (which they've missed).

Nobody came to a meeting to read your presentation. They came to see you and hear you present. It's much better to highlight the few key words or phrases and then talk about them.

Too many TLAs. IT is famous for our use of TLAs (that's Three Letter Acronyms, he said with no sense of irony). Our presentations are full of TLAs and tech lingo, and therefore our presentations are in a foreign language for people outside of IT.

An executive once told me that business folks are looking for IT people "that talk like the rest of us." Drop the tech lingo and use the language of your audience.

We use the wrong tone. Take a look at your presentation to see if it focuses more on the concepts of control, governance or limiting access, than it does on the concepts of benefits, return on investment or new functionality. People are more interested in learning what they can do and how you are helping them than they are in hearing about what you won't let them do.

It's not an IT project. Perhaps the best indication that you're really making an IT presentation is when you include a slide that proclaims, "This is a business project, not an IT project." All this does is highlight how much it really is an IT project, so I'd suggest you drop it.

You don't see HR, marketing, legal, etc., proclaiming their projects aren't HR, marketing, legal projects. They've learned their lesson and we should too.

   "Business Process Modeling Techniques in Software Development Liyecycle [sic]" photo by Ivan Walsh / CC2.0

This article is also posted on Forbes.com.  Feel free to join in the discussion either on this site or at Forbes.com

If this topic was of interest, you might also like these:

• IT's Business Lesson
• PowerPoint: The Good and Bad
• Leadership Conversations
• Or the posts in the "Strategy & Management"  category.

Comments

[Alec Sharp]

Hi - Just a quick note to strongly agree with your note about the tendency to clutter up swimlane diagrams with ALL the alternate and exception flows. In my consulting practice (and as I recommend in my book "Workflow Modeling") I always first identify the major "cases or variations" of a process. For instance, for the classic example "Fill Order" there might be three main cases - New, Repeat, and Standing orders. Typically, unless the variation between them is trivial, each of these gets its own process diagram. Commonly, I'll even do a couple of versions of each case, each illustrating a different scenario. Now, to the inexperienced, this sounds like more complexity - 6 diagrams instead of just one. In fact, though, drawing these six separate but simple diagrams is easier than combining them into one complex diagram. Most important, each of these "simple" diagrams is readily understood by all parties, and in my experience generates much deeper understanding of what's really going on, and therefore, much better improvement ideas.
I never understood why so many people insisted on the need to use BPMN and all it's associated gateways, events, and other widgets until I realized they were trying to depict ALL cases, exceptions, alternatives, errors, etc. on a single diagram. This is clearly necessary for implementation in an automated environment (e.g., a BPMS or workflow tool) but is also clearly fatal if you're trying to generate understanding and improvement.
At the moment, I'm writing my current BPTrends column on this topic, so I'll refer to your blog in the column, and probably just include this comment in my column. Thanks for the trigger! :-)

Alec Sharp

[Mike]

Alec,

Thanks for commenting. That's a great way to handle it the complexity. The key is in knowing your audience. The tech guys need the details as a way of documenting for code writing and configuration. The exec staff is only interested in the high-level overview. It's dangerous and counter-productive to try to be "efficient" by making the same diagram work for both.

Mike