Browsing articles tagged with " risk"

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.

Bad Data Models / Database Designs Kill – Under Modeling

Jan 6, 2011   //   by Karen Lopez   //   Blog, Data, Data Modeling, Database, DLBlog  //  3 Comments

imageDr. Danielle Ofri has a frightening post about how data design can cause serious consequences.  She talks about running up against a 1000-character limit when trying to create a patient history for someone about to undergo a risky surgery:

I panic for a moment, fearful that the computer has frozen and that I’ve lost all my work — something that happens all too frequently. But I soon realize that this is not the case. Instead, I’ve come up against a word limit.

It turns out that in our electronic medical record system there is a 1,000-character maximum in the “assessment” field. While I’ve been typing, the character number has been counting backward from 1,000, and now I’ve hit zero. The computer will not permit me to say anything more about my patient.

If you’d done any database design, you know that even if you design a good, business-driven design, others who use the database might apply their own rules to the data on the way in or out of the database.

I remember designing a Point of Sale system database for an appliance retailer.  Our data model needed to support the selling of high-end appliances as well as bulk purchases for high-end appliances.  So our transaction amount columns were significantly large.  A developer on the application team thought our monetary field lengths were insanely large, so he enforced  a limit on a transaction of $9,999.99 for the total transaction.   To make matters worse, this system went all the way into production with that limit.  So on day one of the roll out, sales people couldn’t sell the most highest margin items such as a professional quality stove ($14,000) or sell to developers who were buying 100 low end stoves in one transaction.  Their orders had to be chunked up into tiny $9,000 mini-transactions.  Order completion was taking hours instead of minutes.  Credit cards were being rejected for too many large amount transactions back to back.  In other words, a nightmare deployment because organizations trying to spend tens of thousands of dollars were walking out and going to other retailers with “real systems” to make their purchase.

However, no lives were being lost (that I know of).  Some people may have gone longer without heat (furnaces) or with rotten food (freezers and fridges), but in the overall scheme of things the impact on customers was not life and death consequences.

If we get back to Dr. Ofri’s situation, though, she was faced with a terrible data dilemma: how to describe a complex patient history in 1000 characters.  This number probably sounded like a huge number when the project team was adding that “feature” to the system.  I’d even bet their own test data only went as high as 200 characters or so.

I’m also guessing that since this system is a fairly high-risk project that some expert user (or many) was responsible for approving the design of field lengths.  Perhaps he or she also thought that 1000 characters was enough.

In desperation, I call the help desk and voice my concerns. “Well, we can’t have the doctors rambling on forever,” the tech replies.

That response from IT (even if it a help desk tech who has no clue as to why there is a limit) makes me mad and afraid at the same time.  You’ve all heard it in your design reviews, haven’t you?

  • That’s way too long of a field.
  • It won’t fit on one window without scrolling
  • No one has an e-mail address THAT long
  • You are over modeling it
  • That’s ridiculous.  No one is going to sit there and type that long
  • 255 was good enough for the last 10 years, it’s good enough for the next 10 years
  • The indexes on that column will be too large
  • Go ahead and make the column that long; we’ll just truncate it in the application

The business users are frightened by the negative comments and agree that 25 is sufficient for e-mail address, not even realizing that some of their own e-mail addresses are longer than that.

As I blogged recently about Over Modeling, it’s only over modeling if it doesn’t meet the business need.  Sure, we might make concessions to technical feasibility (“make every column 2000 characters, just in case”), but our designs should be business driven.

Dr. Ofri ends her story by saying:

I’ve finally condensed my patient’s complicated medical conditions to exactly 1,000 characters. I quickly hit “save” before I lose everything. I wish him good luck on his operation, wondering if his surgeons will have to condense the entire operative report to 1,000 characters as well. What happens if there are complications?

For my next medical evaluation, I think I will use haiku.

I don’t know about you, but I wouldn’t want to read that about my own patient record.

Next up: What could we have done differently on our project

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