Browsing articles tagged with " Presenations"

8 Tips for Presenting a Technical Recommendation

Aug 21, 2012   //   by Karen Lopez   //   Blog, Professional Development, Project Management, Speaking  //  4 Comments

 

BarbieEight

I’m asked do these sorts of “make a recommendation for a solution” presentations all the time.  I know how difficult it is.  These presentations are different than teaching moments.  They need to have a certain structure:

  • Problem statement / Challenges
  • Summary recommendation
  • Detailed recommendation (with the whys, too.)
  • Very brief recommendation of a path forward
  • Summary

So I have these tips for presenting your recommendations:

1. Make your material readable.  It sounds so non-technical and trivial to say that fonts and diagrams matter, but they do.  A recommendation that can’t be seen or read is less than useful.  Every Be The Next Microsoft Employee contestant struggled with this, some to the point that we weren’t even sure what was being presented.   Don’t let your presentation materials get in the way of presenting your ideas.  Handouts of key diagrams are always beneficial.  Using zoom features can help, too.  Buck had a great tip: put your laptop on the floor, then stand 3 metres away (okay, he said 10 feet) and see what it looks like.  If you can’t read it, neither can your audience.   If you are presenting on older projectors or without a proper screen, then stand back 12 feet.   If your slide looks like a blog post, you are doing it wrong.  Concepts go on slides, not documentation.

2. Don’t make promises you can’t keep.  All the contestants used words that could come back to haunt them later.  Words like guarantee, promise, for certain and warranty are things you can’t commit to as a vendor or presenter.  You don’t have the information you need to make these commitments, nor do you have any idea how your solution will be implemented.   Instead of making promises, case studies and well-qualified data can back up some assertions, but you will still need to use many qualifying words like may, might, and can to ensure that you aren’t making promises you can’t keep.

3. Know why are you are recommending something.  My mantra is every design decision comes down to cost, benefit and risk.  There is no one right answer for every organization, environment, team, culture or financial situation.  It’s not enough as an architect to say “this is the way that everyone does this”.  A professional architect knows that solutions need to be implemented in the context of cost, benefit and risk, including legal and organizational constraints.  Some people feel that costs and risks should not be addressed, but I have much more confidence in a recommendation when I can see that the recommender understands the trade-offs associated with everything they are proposing.  If your recommendation includes legal constraints, confirm, verify and reconfirm your recommendation.  Keeping your client out of jail is a good thing.  Context is King…and Queen.

4. Ensure that you address all the parts of the problem.  If a client asks you to solve their performance problem, all the solutions to address something else won’t make much of a difference if you don’t address the performance problem.  They may also suspect that your proposed solution can’t solve the problem in any manner.  Don’t forget the cost side, either.  Be ready with multiple levels of solutions to meet the financial constraints of the audience.

5. Ensure you don’t try to solve a problem you weren’t asked to. I’ve seen this before: a consultant has solved some brilliant problems in the past and spends all his time talking about how his solution will solve that problem…but not that was totally out of scope of the request.  Management may already have a solution in progress.  One of our contestants threw in a last second proposal to replace an ERP system, something that wasn’t asked for at all.  This would have been a real shock to everyone in the room and probably derailed the rest of the discussion.  Stick to the scope of the problem.

6. Be confident & positive.  Even if you aren’t.  I mentioned that all our presenters showed signs of nervousness. That’s to be expected.  But audiences really do want to see a confident speaker, one who speaks up and shows confidence in his or her solution.  The best way to do this is to be prepared and be confident in what you are presenting based on the resources you were given.  Don’t worry about the fact that you didn’t have enough time, that some things you wanted to demo you couldn’t get to work.  You can’t change that.  Go with what you have and do it well.  Be strong.

If you are there to provide a solution then you should be showing the meeting group that you think what you are presenting is a good thing.  Be serious, but even when you are talking about a problem or risk there’s no need to add drama to the situation.  The current environment and situation might have serious problems, but there’s no need to be negative about that.  In fact, I’ve seen consultants come in and mock the heck out of current situation and be totally oblivious that the people right in front of them built that solution and have done miracles trying to keep it going under changed demands.

7. Watch your time.  Don’t end too early nor go long.  Leave plenty of time for questions, comments and clarifications.  You can have some backup materials for anticipated questions.  I believe, though, the best use of time is for a discussion to ensure everyone understands what you have recommended and why.

8. Make your presentation about THEM.  It’s so painful to see a presenter that is clearly presenting about THE PRESENTER.  If you are saying I, my blog or my book too many times, you might be that guy.  If you are constantly pointing to yourself, you aren’t focusing on the solution.  If you are making a recommendation, it’s fine to say we recommend (if you are representing a group or organization), but you should be putting the client’s needs at the forefront.  Not yours.  One of the best ways to show that you are about them is to start your presentation with a brief understanding of the problem and the pain points of the organization.  Don’t spend too much time on it, just reflect what you’ve been told and show along the way how your recommendation addresses their pain points.

Recommendations need to have have the what, why, and how much questions addressed. They need to be clear and understandable.  I’d love to hear what recommendations you have for making technical recommendation presentations.

Are You Turbo Encabulating Your Presentations?

Jul 26, 2011   //   by Karen Lopez   //   Blog, Data Modeling, Professional Development, Speaking  //  1 Comment

I presented half of a training course a while ago and the other presenter was really big on keeping to the agenda and the times allotted to each topic.  I’m a stickler for ending on time, so I respect that.  However, the presenter was so committed to the plan that he at several points refused to answer questions from the audience, even when the questions were about the meaning of an acronym or one of the many buzzwords sprinkled throughout his slides and narrative.  At one point a woman in the audience insisted that he define the terms on one slide.  He cut her off and suggested that she get some outside training on the topic.  I was shocked.  These attendees were new to the topics.  There were no prerequisites to the one day course.  If this had been a one hour session at a conference, I could see wanted to defer some questions in the name of time. However, this was an on-site training course for a single corporation.  There were big bucks being charged and outcomes were expected in return.  This presenter, by insisting that he get through the material whether or not the attendees were understanding what he was saying, was not doing his job.

I thought of him as I was in the process of migrating posts from our previous blog and came across this video on the Turbo Encabulator.

 

The Turbo Encabulator – Is this what you sound like?

 

Thank goodness he was responsible for only 4 hours of presenting just like our man in the video.  By the time I got up to do my part, the audience was in a fairly unfriendly mood.  I had to work hard at establishing some trust with the group to ensure them that my role for the final 4 hours was to ensure that they understood what they were supposed to understand.  I encouraged questions, altered timelines when more explanations were needed and responded with ad hoc examples when the slides weren’t good enough to get the point across.  And you know what?  I ended on time and managed to cover all the material in my part of the agenda.  That’s because I had allocated time in my plan to take questions, go back over material and to test audience members to ensure that we were ready to move on to the next topic.

I work really hard when I present to business users to avoid the normal IT bafflegab / dujamakicey lingo, but I know that we all struggle with this.

When I present at groups like DAMA (dama.org), I sometimes get feedback that I’ve used a term, such as ERD or LDM that might not be clearly understood by everyone in the crowd.  This is a tough call, as I want to make some assumptions about the audience at DAMA meetings so as to balance time allotted against the desire to deliver content that is useful for data architects.  It’s very painful to have a presenter speak at a DAMA or IRMAC meeting and have him spend half the time explaining what a database is and what a data model is.

So while I do encourage attendees to ask if I use a term or concept that is unfamiliar to them, most won’t ask.  Remember to watch your turbo encabulators when collaborating with others.  We are all guilty of this.   I actively encourage audience members to ask questions during my presentations just so I know whether or not I’m being clear.  If you are a presenter who does not allow any questions, you need to assume that everyone in the room has an equal understanding of the terms and implications of what you are covering or you need to allocate time to explain more, talk less.  In a training course I believe there is no excuse for not taking questions at all during the course.

Some tips on ensuring you aren’t Mr. Turbo Encabulator:

  1. Review your slides for TLAs and buzzwords.  Prepare a glossary for them if you don’t want to define them.
  2. Find a way to assess the make up of your audience.  Either poll the attendees before you speak or ask the organizers who will be attending. It’s always better to poll the audience, though.
  3. Tailor your presentation (not necessarily your slides) to the audience.
  4. Don’t try to give the same exact presentation every time to every audience.  They are different.
  5. Don’t be condescending when you explain something that you think everyone should know.  Even if everyone should know it.
  6. Allocate time for questions. Not just at the end, either.
  7. When in doubt, offer a definition of a term.
  8. Learn how to be happy-perky when you ask that one guy who is bogging down the presentation with questions/comments to save them for after the session.
  9. Keep track of frequently asked questions. Consider adding explanations to your slides.
  10. Thank the audience for asking questions.  Nothing says the audience is not that in to you if they don’t ask questions.

Thanks to @ldbjorh for the link to this video.

This post contains some content from an earlier post dated 4 Nov 2009.

Subscribe via E-mail

Use the link below to receive posts via e-mail. Unsubscribe at any time. Subscribe to www.datamodel.com by Email


Categories

Archive

UA-52726617-1