Creating Technical Presentations

Making a technical presentation is like being interviewed. It is not a skill that you are likely to need often, but when you do, advice culled from experience can make all the difference to the outcome; and like successful interviews, successful technical presentations can really help your career!

I  vividly remember one of the early conferences that I attended as a SQL Server professional. It was a Professional Association for SQL Server conference (PASS) in San Francisco, California. I stood in awe as I looked around and saw the authors of many of the technical books I had in my collection. What a great place to meet the stalwarts of our community! And I was determined to get more involved in one way or another.

I had almost convinced myself that I could submit an abstract for an introductory level session the following year when I witnessed an exchange that changed my mind. I was sitting in a very good session by a well known author when someone politely interrupted the speaker with a question. The speaker apparently didn’t know the answer and fumbled around trying to satisfy the questioner. Then another well known and highly respected author that had been sitting in the back stood up and kindly offered input. She was followed by a Product Manager for Microsoft SQL Server who added to the response and provided insight into the direction of future enhancements in SQL Server.

If someone who had written a book that I regularly turned to for information could be so readily corrected in front of a room full of people, I reasoned, then I would have little chance of ever getting through a presentation unscathed. I solemnly resigned then that I would never volunteer to speak at a PASS conference or any other conference.

Common objections to speaking

The fear of speaking in public, or glossophobia, is one of the most common fears affecting the general population. It is believed to be more common than the fear of dying. As comedian Jerry Seinfeld once noted, “The average person at a funeral would rather be in the casket than doing the eulogy.”

As technical people, we are certainly not immune to glossophobia. In fact, we may even be more subject to it than the average person. As a result, it’s rather easy to find reasons why we cannot create a technical presentation to share with others.

‘I don’t know enough to share’

Looking back to that ill-fated session at PASS in the fall of 2000, I’m glad that I didn’t follow through with that in-the-heat-of-the-moment resolution. Since then, I’ve spoken at dozens of conferences in North America and in Europe and I receive a great deal of satisfaction in sharing my experiences.

And that’s a key point. I share my experiences. I don’t claim to be an expert in any particular area. I set out in each of my sessions with a mind set that I will share with the audience my experiences, the approaches I’ve taken, and the results that they’ve garnered. Taking that approach offers me the freedom to learn from the audience if there is a better way.

‘Someone else will do it’

Many technical communities, whether it’s .NET, SQL Server, or another technology altogether such as VMWare, have been fortunate in that there have consistently been people who are willing to freely share their expertise in one subject or another. Some of the these people, such as Technical Evangelists or Product Managers, consider this a normal part of the jobs. Many consultant consider speaking a form of marketing their services. Others speak for purely altruistic purposes. Regardless of their intentions, there has historically been a surplus of people wiling to speak at technical conferences.

That is certainly not the norm for smaller stages, however. One of the most difficult aspects of running a local user group is finding local people who can or will speak at a meeting. Finding a speaker can be extremely time consuming and frustrating for the group organizer. A lack of speakers is the underlying cause for the collapse of many technical user groups. When that happens, we all lose.

‘I don’t have anything interesting to share’

While many technical professionals like to learn and work with the latest and greatest technology available, the fact is that most of us are “stuck” using technology that is at least one revision old. How are many instances of SQL Server 2000 are still in production? How many lines of Visual Basic 6.0 are still being maintained?

Despite the fact that many of us feel relegated to using older technology, that doesn’t preclude us from creating technical presentations. Some presentation materials are almost timeless. For example, last month I gave presentation at DevLink just outside of Nashville, Tennessee, that highlighted tips and tricks for writing better queries. The information offered in the presentation was applicable to Microsoft SQL Server 7.0, 2000, 2005, and even 2008.

Other nearly timeless possibilities could include the basics of inheritance and troubleshooting poor performance.

‘I don’t know where to start’

The first time I sought to create a technical presentation, I did so with little input from others. I didn’t know where to start so I looked to prior sessions that I had once attended for guidance. I tried to figure out how many slides to include in the PowerPoint presentation, what the ratio of presentation and demonstrations should be, and how to best structure the presentation to so that it makes sense.

In retrospect, I made the process much harder than it had to be. Going it alone is generally not the best way to accomplish anything. That’s one reason I’m writing this article. I would like to provide to you some guidelines that I’ve found to be useful as I’ve created technical presentations.

I would also encourage you to solicit the advice and input of others; i.e. ask the user group leader for input and feedback.

Why you should make a technical presentation

Preparing a technical presentation takes time. Many of us already feel that we spend an inordinate amount of time doing the required work-related activities. We learn new technologies during our off-time; we’re on call during non-business hours; we are already overly committed as it is. Why should we take on the added, and perhaps unnecessary task, of creating a technical presentation?

If viewed as a competing activity to those already mentioned, you shouldn’t. But in reality, creating a technical presentation is less of a competing activity and more of a complementary activity.

Most of the aforementioned activities are actually designed to help us to our jobs better and to grow our  individual careers. Creating a presentation assists in that goal.

Practice your presentation skills

there is certainly
a perception outside
 of the technical
community that
most of us are indeed
socially challenged

Although most of us are far from the stereotypical characterization of a socially inept geek, there is certainly a perception outside of the technical community that most of us are indeed socially challenged. One old joke has an element of truth. How do you recognize an extroverted programmer, he stares at your shoes when talking to you.

The brightest person can be significantly hindered if he cannot adequately express his knowledge to those around him. Being able to succinctly take a complex concept and communicate it in a manner that is easy to understand by those less technical is truly a skill that is as highly sought after as the technology expertise itself.

Creating technical presentations is a great way to practice organizing your thoughts, speaking with clarity, and communicating effectively with others.

You’ll learn as you prepare

Learning a new topic or technology can be fun. We can explore new ways of doing things. We see how the new version helps to address some of the challenges we’ve faced in prior versions. We can take what we know and expand upon it.

But, when learning something new, we tend to focus on those aspects that seem most relevant to us. It’s natural to spend less time delving into areas we don’t find nearly as applicable. However, it may be that those other facets are exactly what we need in order to do our job better.

For example, when Visual Studio .NET first made its appearance in 2002, many developers were eager to adopt the and improved software development tools. But the new .NET environment made it easy to keep programming using the same techniques that were prevalent in Visual Basic 6.0. Until we stepped out of our comfort zone and began learning true object oriented programming techniques rather than continuing our object based programming practices of Visual Basic 6.0, we missed the true power of the .NET world.

One of the best ways to learn about a topic is to prepare to teach it. Preparing to teach compels us to learn aspects of the topic that we may not other wise feel the need to explore. Doing so may lead to not only a better understanding of the technology, but to being able to put the newly acquired knowledge to practical use.

Expand your social networking

Delivering a presentation puts you in front of people you probably don’t know, or at least you don’t know very well. Sharing your knowledges and experiences with them will help them to feel as if they know you, and will likely help them to feel a certain sense of appreciation for the efforts you’ve taken to create and present the information to them for their benefit. It’s a form of helping others.

Later when faced with technical challenges, that network may be strengthened as they contact you for input into problems they may face. And that communication doesn’t have to be unidirectional. You’ll develop a network from which you can draw when you’re up against a technical problem.

Additionally, in this era when many jobs are being exported to other, lower cost, areas of the world, it behooves each of us to get to know others in our technical community. When looking for another job, we’ll have a social network of friends on which we can lean to assist us in our job search.

Give back to the community

As one who has certainly benefited from the local and global technical communities, I feel a strong sense to give back in whatever meaningful ways that I can. I try very hard to spend time in the newsgroups and forums, writing articles, and yes, delivering technical presentations at various levels.

When the community is active and vibrant we all benefit. Being able to turn to a pool of resources who are actively willing to share knowledge in a very unselfish way helps us to all do our jobs a bit better. And that’s a good thing.

Preparing the presentation

Like many activities, preparing a technical presentation takes practice. The more you practice, the easier it gets. Let’s consider some of the tasks you’ll undertake as you put together your presentation and exercise your preparation skills.

Selecting an audience

One of the first things to consider is when and where you’ll make your presentation. If you’re a seasoned presenter and are comfortable with public speaking, most any venue is available to you. You can submit abstract for large public conferences like PASS or DevConnections, or you can target smaller and more intimate settings like local user groups or web casts.

For those that have less experience, I’d recommend starting in a more relaxed and less stressful environment, such as a local user group meeting or perhaps a company Lunch-and-Learn session. Starting in groups where you feel more at home will help you to build confidence and gain experience before tackling the more public opportunities.

It’s also important to consider your intended audience, as best you can, before creating the presentation. Knowing their expectations, their backgrounds, their experiences, and their technical bent will help to create the most applicable presentation for them and hence give you a better chance of having it well received.

How can you get to know your audience? In some cases, like small local user groups, you may already know many of the members. However in larger groups or conferences, knowing who may attend ahead of time is impossible. In those cases, take your best guess.

For example, when I am speaking about Microsoft SQL Server at a conference that is known to attract more developers than database administrators, I’ll adjust my presentation accordingly. I’ll also craft session abstracts that clearly state what the goals for the session are along with any prerequisites for getting the most out of the session. Don’t overlook this aspect as it can help you control to some extent who comes to your session.

Select technology you know

Many seasoned professionals can confidently step before a crowded room and discuss most any topic given to them with great poise and even an air of authority. However for the rest of us attempting to make a technical presentation, it’s better to stick with a technology with which we have a confidence and experience.

I generally speak about Microsoft SQL Server since that’s the technology I spend most of my working time using. That’s the technology I know best. I also use Linux for my desktop and VMWare for my virtual machines. However since I don’t feel that I have the technical expertise to put together a technical presentation for either of those two technologies I would tend to shy away from those potential topics.

Selecting a topic

Within the scope of a broad technology such as SQL Server or Visual C#, there are literally thousands of more narrowly defined topics on which a presentation can be built. Select a topic that is of interest to you since you’re likely going to have to research the topic as you prepare the presentation. Even if you’re presenting something that you’ve already done, i.e. how you addressed resource contention while developing a multi-threaded application, you’ll likely have to investigate some of the finer points before presenting.

Narrowing the scope of the presentation to something that can fit within approximately one hour is rather tricky. You certainly don’t want to run out of material, but at the same time you don’t want to tackle something too broad either.

As a general rule, the broader the topic the less in depth you’ll be able to go. You just won’t have the time to cover all of the aspects of the topics. For example, a presentation on Performance Tuning Microsoft SQL Server may only devote one or two slides on reading execution plans. Conversely, you could more narrowly define the topic and make the entire presentation about how to read the plans.

Creating the PowerPoint presentation

 PowerPoint can
 ruin an otherwise
 engaging presentation.

When Microsoft release PowerPoint many years ago, it, perhaps unknowingly at the time, changed the way presentations are created and delivered. When used effectively, PowerPoint can be a wonderful tool to help get a message across to the audience. When misused, PowerPoint can ruin an otherwise engaging presentation.

Don’t overuse some of the features in PowerPoint. Use the animations very, very sparsely. It’s better to err on the side of being overly conservative than to over-stimulate your audience with effects. For example, don’t use the sound effects of tires screeching as words come zooming in from the left or right. Those kinds of effects detract from the overall presentation.

A PowerPoint slide deck for a technical presentation should be used to augment the presentation; it should not become the presentation. Use the slide deck to help the audience follow along.

I’ve found that I can adequately speak to approximately 20 slides in one hour, including the introduction, agenda, addition resources, and thank you slides. Or put another way excluding those four slides, I typically have 16 slides worth of content per 60-75 minute presentation. That doesn’t sound like a lot of content. But I’ve found that if I don’t carefully budget my time I end up rushing through the final three or four slides at the end of the presentation.

You’ll want to keep the presentation engaging, and the slide deck can help in this regard. For example at one conference I was slated to speak in the last slot of the last day. I knew that most attendees by this point would be exhausted and would have seen more than their share of bullet-pointed slides. So, I decided to have fun with it. I told the audience up front that I had created an entire presentation without using a single bullet point. I tastefully used shapes and figures to create my presentation and to convey the information I wanted to present. That seemed to go over well. As a side note, I did include one slide about two-thirds of the way through the presentation that was full of bullet points. I did so as a joke. When I got to the slide, I told the audience that I knew they’d have withdrawal pains or would feel cheated if they didn’t have at least one slide full of bullet points.

Creating the demos

Technical audiences expect demonstrations. A presentation without demonstrations is usually received as marketing fluff. There are of course some exceptions to this generalization, but all in all it’s better to demonstrate the concepts you’re presenting.

I typically to make active demos approximately 40% to 50% of my presentations. People tend to accept and remember information better when it’s presented in a more interactive and illustrated way.

The specifics of a demonstration will of course vary, however there are some core elements that should considered when creating a demo.

Demonstrate an application of the concept

The best demonstrations illustrate an application of the point discussed in the presentation. For example, if you’ve discussed how to use conditional formatting techniques in Reporting Services, consider adding a demonstration that will illustrate the point by using the technique to alternate the background color for the evenly numbered rows in a report.

Noticeable outcomes

Each demonstration should have a noticeable outcome, something that the audience can readily use to see that the demonstration actually worked. As an example, if your presentation is Using Silverlight in Business Applications, it only makes sense to prove your point via a demonstration.

Script-based yet flexible

I always create a script for my demonstrations. Scripts are presentation notes that help me to remember the specifics of the demonstration. I typically include the slide number where the demonstration should occur, any points that I wish to emphasize, as well as setup and requirement notes.

I use the script to help prepare for the presentation. I typically read through it right before delivering my session and I keep it handy during the session as a fall back just in case something usually happens and I lose my place. Do not use the script as a crutch to carry you through the presentation. No one wants to watch you read through a scripted presentation. Use it to prepare, but not to deliver.

If your demonstrations include developing scripts or source code, I recommend creating a Starter, Demo, and Solution folder for each demonstration. The Starter folder contains the starting point for the demonstration. You will not modify this folder directly. It is primarily used to store a read-only copy of the starting point for the presentation. You’ll use this to quickly reset the demo code before your presentation.

The Demo folder initially contains an exact copy of the Starter folder. The Demo folder is the folder that contains the files you will modify during the demonstration.

The Solution folder contains the finished product for the demonstration; it’s what you are working toward in your demo. It can be used in an emergency. You can always open the solution should your demo get bungled to point of not being able to recover.

Preparing for the presentation

Once the presentation has been completed, it’s time to prepare to deliver it. Don’t overlook this part of the process.

Rehearse, rehearse, rehearse

As you gain experience making technical presentations, you’ll of course become more and more proficient at it. I have several good friends that can pull a presentation out of their repertoire and deliver it with only a moment’s notice.

Until you get to that point, however, it’s best to be well prepared. Go through the presentation until you know the order of the slides inside and out. Find transitions to help you ease the audience from topic to topic and slide to slide.

Make sure that you’ve experimented with the demonstrations enough to anticipate what may go wrong. There are few things more disheartening during a presentation than to not be able to get your demos to work properly.

Rehearse the timings of the presentation. Make sure you know where the halfway point is so you can better allocate time during the presentation. Knowing the subject matter and slides instills a sense of confidence as you progress through the presentation.

Setting the stage

Before delivering the presentation, review the script you’ve created. Make sure that you’ve reset the demonstration database and/or source files.

Adjust your environment for the presentation. Make sure your laptop’s screen saver is disabled. If your demonstrations include editing text, enlarge the font to 18 or 20 so that those in the back of the room can see it more easily. I also like to change the highlight color from blue to yellow.

Making the presentation

When the moment of the presentation arrives, relax. Prior preparation is the cure for worry and anxiety. You’ve prepared. You know your stuff. And you’re ready to share it with others.

Remember that those in the room want you to do well. They’re not there to shoot you down or to intentionally try to thwart your presentation. They’re there to learn.

As you go through your presentation, have fun. Try to interject humor where you can, even if it’s at your own expense. Do stay away from remarks that can be offensive or considered off color. There is no positive outcome from that.

When questions are asked, answer them as best you can. But don’t make up an answer. The attendees will know. It’s much better to honestly say that you don’t know or haven’t experienced that. Ask if someone else in the room knows the answer. If not, offer to find the answer for them if they’ll email you the question.

After the presentation

Once you’ve completed the presentation, it’s not uncommon for some of the attendees to come up to you afterward for specific questions. Hang around and enjoy this. They are coming to you for answers. Try to help them.

Get feedback

Talking with attendees after the presentation also affords you an opportunity to solicit feedback from them. Ask them about their likes and dislike regarding the presentation. Give them permission to speak candidly so that you can improve upon it for the next time. If evaluation forms were collected, try to gain access to those so you can see how you did. I most often find that I am much more critical of my own performance than those that are sitting in the audience are.

Get ready for next time

While the presentation is still fresh on your mind, it’s always a good idea to update the your presentation for the next time. Make adjustments to the slide deck, adding or removing slides as needed. Modify the demonstrations so that they go even more smoothly the next around. Revise the script, capturing important points that were not apparent beforehand but that became obvious during the presentation.

And finally, save the presentation for the next time.

Tags: ,

  • 24208 views

  • Rate
    [Total: 61    Average: 3.5/5]
  • Anonymous

    Awesom
    Hi Joe,

    First of all I would like to thank you for sharing your expertise through this article. I like the way you have explained about the presentors mindset and what our objective should be, this is like a real guide…

    I really like this part in your article “….And that’s a key point. I share my experiences. I don’t claim to be an expert in any particular area….”; This really motivated me.
    Thank you

  • Anonymous

    Powerpoint
    I’m highly surprised that anyone worth their salt still uses Powerpoint. It has many down-sides but the most damaging is that it deflects attention from the speaker. Bad move, if your presentation is an important one.

  • Phil Factor

    Surviving Powerpoint
    I’m not a fan of PowerPoint…
    http://www.simple-talk.com/opinion/opinion-pieces/survival-tips-for-powerpoint/
    … a PowerPoint presentation is difficult to get right, but speaking without PowerPoint presents its own difficulties, because it is a wonderful prop that makes it easier for the speaker. As this is a guide for inexperienced speakers, I think it is right and proper to cover its’ use, and Joe is careful to say ‘PowerPoint can ruin an otherwise engaging presentation.’ We’d all like to find a better way of illustrating our talks, but there is no obvious answer.

  • James Holland

    Props
    I’d like to take Phil up on his comment. I use memorable props in quite a few of my presentations because it makes the audience remember it better. I tried to use a live elephant to illustrate a point once but I ran out of peanuts.

  • Phil Factor

    re Props
    My best presentation happened when laptop failed and the projector failed and I had to demonstrate an application entirely by waving my hands, gesticulating, and describing an imaginary screen, in front of a blank white wall, as the application was ‘run’. I used different mimes for the menus, dialog boxes, buttons and so on. I even mimicked the Windows sounds. Fortunately I had a vivid recollection of the application, but it was a difficult presentation to do.

    I knew I had succeeded when I looked up just as I said the words, ‘and then a fascinating graph appears, showing the results of the analysis’ and saw the audience all staring transfixed at a completely blank wall.

    I have also used glove puppets to great effect, but I wouldn’t recommend them for one’s first presentation

  • Jack the DBA

    Local User Groups
    Local user groups are a great place to start. Get to a know the leaders and others then offer to speak. Here in Orlando the president of OPASS, Andy Warren, is trying to get more people to speak and offers the opportunity to do a mini-presentation (15-20 min) so you don’t have the pressure of being the featured speaker.

    The worst that can happen is that you make a few mistakes, just be willing to admit you don’t know it all.

  • Matthew Roche

    Great article, and great advice
    Thanks for the great article! I too speak at a lot of conferences and user groups, and in many ways the act of speaking is its own reward. That rush of adrenaline may not be for everyone, but for me it is the perfect balance to the day-to-day process of creating software.

    As far as the people bashing PowerPoint, I both agree that it is a crutch for the speaker and disagree that this is a bad thing. For me personally, I rely on PowerPoint to remind me what I’m supposed to talk about next, because otherwise I’m sure to forget something important. There are good and bad ways to use PowerPoint, however, and what I would never suggest would be to try to put all of your information on your slides. Instead just have enough detail to remind you what comes next, ideally with a little humor as well.

    Earlier this year I had the opportunity to speak in front of over 400 trainers (people who speak for a living and who tend to be very critical) but did not learn that I was going to be on stage until the last minute. Literally. I learned that I was up next when the audience learned it, and it was as much of a shock as you can imagine. This is where “being prepared” and “speak on topics you know well” comes into play – if I had not prepped for the possibility of being on stage that day (I was tentatively planned to present, but due to a communication breakdown I was never told that the organizers had gotten me the time slot) I would have been well and truly doomed.

    Hopefully people who read this article will feel inspired to start delivering technical presentations for their local user groups. it’s great when members of the community give back, because then everyone wins.

  • Rodney

    Presentations, Nerves, Nausea and SQL Versus .Net
    I have been speaking fairly regularly in the past 6 months. It is something that at one time I did not like to do. I dreaded it. I remember sitting outside of a hotel in Las Vegas, the Hilton as I remember, going through screen after screen of a presentation I had put together on Data Mining. It wasn’t rehearsing, it was assuring myself that it was going to be met with interest and knowledge would be transfered or at least understood.
    And finally, I could not do it without the love of my life, who loves SQL herself and who spurs me one and tells me that I did good with pointers like, “you need to speak up…”…’you were going too fast”…”that one part about GO 100…did you hear the excitement?”
    It makes it all worth the battle with the nerves and fear of falling short.
    As it turned out, no one really did understand what I was speaking about. That was a situation where the matter did not meet the audience. I trudged through it and had a beer after and played slots. It helped.
    Over the years, I feel less nervous and more confident in the subject matter and the audiences I present to. Even if it is a DBA-related topic to a crowd of 80% .Net developers, I know that a gap can be bridged.
    I tend to be interactive, asking many questions as I go through, say, the top 10 SQL Tips and Tricks for DBAs.
    “How many people use SSMS on a regular basis to develop queries?” I might ask. I await the response.
    “How many people have ever read a Profiler trace file with a SQL function?”…no one…”Great…this should be AWESOME, then.” I do not mind being poked fun at and will jump in and ridicule myself during the presentation if something goes wrong or unexpected. I make a spectacle out of it, a challenge. I like to challenge the attendees and myself as I relay what I think is “cool”. And it is ultimately the cool factor that I think sales the overall presentation. If I hear one “Cool” or “Nice!” then I feel I made the point.
    The best compliment I received was from my former boss and co-author for “Pro SQL Server 2005 Reporting Services”, whom I had worked for for the past 8 years. He saw the neophyte speaker so many years ago. Recently, at a presentation where I preceded Joe Healy of Microsoft fame, Jim said, “You really are way more confident now and it shows.”
    It DOES take time. And it DOES take confidence. And it DOES take a few beers prior. Ok..forget that last part.
    There is no more dread. It is now about wanting it not to be over. It goes too fast when speaking. But that is why there are so many events and opportunities for everyone to share their knowledge.

  • Rodney

    Hmmm…great editing
    I apparently typed my final thoughts in the middle of this entry. So…this would be the part where I mention I poke fun of myself.

  • Dr. Jim Anderson

    Ah, The Trick Is In How You Tell The Story…

    Joe, great posting. A technical presentation is one of the hardest to give because of the depth of the information that you need to share in a limited amount of time. This being said, the great communicators of our time can provide us with a few hints on how to do it well.

    The one thing that great technical presenters do that you didn’t mention was they use the power of a story. Just presenting a lot of technical info is ok, but how much of it will your audience remember after you stop speaking? If you can start out by telling a story “I was faced with an impossible problem, I needed to get more performance out of an older SQL DB because we had no funds for a hardware upgrade and the Christmas rush was going to hit us in just seven days…” and then proceed to deliver your technical info as part of your story, then everyone will remember what you said for days afterwards.

    – Dr. Jim Anderson

    Blue Elephant ConsultingThe Accidental Communicator Blog

  • JJEugene

    Speaking is Speaking
    While there are special aspects to technical speaking that are unique, I find that speaking in public is speaking in public. You could almost take the entire article written here and see the same points made in any other article on speaking in public. (This is not a criticism in any way about this well-written, helpful, and appropriate article. This is just to help make my next point.) Thus, one suggestion I have for others who want to give technical presentations is to do what I did several years ago, join a local Toastmasters club.

    Between Toastmasters and later being put in the position of needing to do public speaking many times for my work, I found that my public speaking skills had improved many, many fold and that I even got over the fear in most of the situations. Loosing that fear (being the one who would rather give the eulogy than be in the casket) only happens when you get confidence which usually only happens with lots of practice. Go get em.
    Thanks for the article.

  • If you’re not early, you’re late.

    Lee Potts
    All great points to remember, especially the ideas regarding adjusting the environment.

    I’d also like to suggest that the speaker should always get to the venue early to make sure the technical aspects are set up correctly. It’s very hard to give a great presentation if you get to the lectern 10 minutes late, flustered and out of breath after struggling with a projector that won’t project or a laptop that doesn’t have the right version of PowerPoint or finding the promised internet connectivity isn’t working.

    If you don’t mind, I’d like to point out a blog I recently started that specifically deals with the things that can go wrong while presenting and what can be done to prevent them. It’s called Breaking Murphy’s Law (http://www.breakingmurphyslaw.com). I try to focus on using real stories from folks who actually experienced Murphy’s Law while presenting or while providing support for someone else’s presentation.

    Thanks,
    Lee