10 Effective Presentation Tips and Tricks

The other day I was helping a friend improve their presentation and figured I would share a couple of my thoughts in general for making effective presentations.

1. Know your audience! Make sure the presentation style suits the audience.

If they like money (and who doesn’t), talk about money, if they want their jobs to be easier talk about that. Target their interests, or use those interests to explain or improve your presentation/points.

I remember one of the harder presentations I had to do was convincing a group of people at a conference that the technology I was representing was fun and interesting. I played a fun game based on the ever loved Price is Right. The audience was involved, shouted their ideas of what was the right answer to a number of trivia questions and I had fun prizes such as a new car!… freshner, and all inclusive trips to Tim Hortons (gift cert and gas card). The key reason this game was effective was because it built right into the topics I was discussing and the audiences involvement was crucial to the presentations success. The entire presentation from that point on was a discussion of ideas and concepts. Try that with executives or people looking for heavy content/details and it would never have been as effective.

2. Know the goals of your presentation.

Try and keep it to one primary goal, and two secondary goals. Any more than that and you will struggle with trying to pass all that information on. Make your presentation represent these goals and try and set it up so your audience has motivation to meet these goals, or are just as interested as you are in them.

3. Show interest and enthusiasm!

Don’t act like you have done this talk, presentation, or dealt with this topic for years. Pretend this is the most exciting day of your life. People enjoy seeing energy and enthusiasm and YES it does rub off on the audience. Even if they never liked what you are discussing before they will start to associate it with excitement.

4. Always have at max 3-4 points on a slide. Simplify the slides.

Any more than this and the audience will lose interest. Never throw huge data intensive graphs or metrics in your slides if you are doing so, or are thinking, but I need these think about what you are trying to show and I bet you can summarize it in a much simpler fashion. This isn’t a report, or a document, it’s a presentation.

5. The slides are just a tool, the presentation is how you talk, move your body and interpret the audiences responses.

If they don’t seem to be understanding or listening to your presentation change it up, raise your voice, lower it, whatever you do try and keep it interesting and engadge their attention. I am a big fan of changing volume and tone for topics as well as interacting with the audience. One helpful thing to do is to talk quietly and pretend you are offering some secret or important advice, another is making a joke or stating something excitidely. Use the words, oh and I love this part, or This is really interesting etc to help garner the attention for what you are discussing.

6. The best presentations are those that are interactive.

If you cannot complete the entire presentation due to questions but are able to cover the key points that is one of the most successful presentations. The reason people ask questions and provide feedback is because they are interested in the topic. All good things.

7. Images are worth 1000 words.

Using the odd image to keep the presenation looking fresh, clean, or to subtly imprint images of joy, success, or happyness is important, but the real power is when you use an image that summarizes lots of words. Try and use images for points on a page. This helps with memory association.

8. Demonstrations are always better than slides if possible.

These change the monotony of the slides, and most importantly make what you are talking about seem tangible and easier to understand. Even if it’s a simple demonstration, these can really win more interest, and support from your audience.

9. Respond to questions, comments and concerns.

An effective presentation always brings up questions, comments and/or concerns. Try and deal with these right away, and see if you can relate them to what you have been discussing/presenting. If you think it might be de-railing the presentation (especially in large presentations) praise them for their input and let them know you will take their questions/comments at the end.

10. Follow up.

This one is missed so often. Follow up on a presentation. Send an email to your audience if you can saying thanks for coming and provide them with links to the content or something related. This helps keep it fresh in peoples minds and often can open up new opportunities. Even if you don’t know who attended approach one or more of the people who attended if you see them again and just thank them for attending and being so attentive/receptive.

Hope this helps someone else,
Richard Harbridge

Wordle of this Blog

I love this little site: http://www.wordle.net

Try it yourself! 🙂
Richard Harbridge

PDC 2008 – Windows 7, Office 14, Azure, and So Much More

I have to admit I am kind of on information overload. I think I have about 300 pages of information I want to still read through on Azure, the new Office 14 features and functionality, and play with Windows 7 more. I am extremely excited about EVERYTHING unvieled so far this year at the PDC conference.

I wrote a short post about Azure (http://sharepointkb.wordpress.com/2008/10/28/windows-azure-services/) and hope that in the next few days I have a chance to really summarize some of my high level observations and expectations. One thing that I can say for sure though is how friendly the future is and how the online, available anytime trend is just a wonderful thing that I am super excited about.

Anyways back to reading and managing time so that somehow I not only catch up on all this wonderful news, but also get to play Fallout 3 sometime this week 😛
Richard Harbridge

Touchless – Webcam Motion Sense SDK (Free)

The other day Michael Gannotti made a post about a very interesting SDK that popped up that helps enable developers create ‘touchless’ applications using webcameras.

Check out this short video clip here: http://communityclips.officelabs.com/Video.aspx?videoId=a89a217b-fc38-4a6c-87f8-ab59a2028391

Or try it out by downloading the demo here: http://www.codeplex.com/touchless/Release/ProjectReleases.aspx

I remember a plethora of applications like this that used to exist, but it was really hard to find a good SDK to help you get started or give you an area in the community to share ideas, and now it looks like things are moving in a good way. Especially as the cost of touch screen technology and multi touch technology is still far more expensive than a simple camera 🙂

It’s very cool stuff and I highly recommend checking it out: http://www.codeplex.com/touchless

Looking forward to the future,
Richard Harbridge

Project Management Processes, Phases, and Personal Notes

One question I am asked often is how I manage my SharePoint projects, what stages I go through and how I perform/manage each phase of a project. This is probably something you already do, but perhaps it’s good to see some examples of how other people manage projects, so feel free to read along.

Personal Note:

This is a high level summary of what I do in a typical project and is not every individual item. SharePoint is also mentioned throughout this article because it is the technology I most often use when working on projects and organizing information.

Before the Project Starts

Before I start a project I create areas to capture knowledge (KB, and lessons learned), following that I begin the process of the project itself. This is important to do right at the start because even during the pre-project phases you can come up with some interesting notes, concepts, or lessons learned.

Right now I always do this knowledge capture using SharePoint with a mixture of wiki’s and related concepts. So this area is already built and all I need to do is create a ‘project’ and ensure the ‘customer’, ‘client’, and ‘area of business’ represented is also within the knowledge area to ensure anyone who comes up with something new can create articles, upload documents and basically create content that will be associated to that project, client, or business area.

Personal Note:

I normally break a project down into the following phases. Every project, regardless of the size. The good thing is that I do NOT enforce specific templates for each phase. I love the idea of templates in that they can save you time and certainly have some that I can make use of, but it’s important to not force yourself to fill out a document and certain content placeholders just because ‘its part of the template’. This can often create confusing statements, is a waste of effort, and really can detract from the important parts of the document.

Definition Phase

Domain Analysis

I always start off with some sort of domain analysis. That is analysis of the current environment, configuration, and system that is in place. How do things interact with one another? What applications already exist? What version are they? How are they used?

The results of this analysis will should contain an overview of the current servers, third party applications, shared service providers, configurations, and web applications, and existing site collections. I personally like to use excel documents for this (I know I could use SharePoint lists and may consider doing so in the future). Once these have been identified and cataloged the next phase of work can begin.

Requirements Analysis

Based on the objectives and target audience a series of business requirements must be retrieved. These requirements can come from business stakeholders, potential administration, and end users. It may be necessary to hold requirement gathering workshops with various involved parties in order to better understand how people would like to use the eventual system and how the system can provide them the most benefit.

Important things to note from personal experience during the requirements gathering phase:

1. Involve every stakeholder in this requirements gathering. Even if it’s just to briefly talk about the requirements you have gathered from a high level. This will allow them to feel more involved in providing any input and requirements they might have and ensures that later when the system is being developed or implemented there are no significant surprises or missed requirements.
2. Ensure you document the motivational reasons for a requirement as well as the requirement itself. This can really help you or the individual drafting the technical specification determine the correct solution for that individual requirement. This sounds simple but you would be surprised at how many people just document Requirements 1A-200C and forget to explain why these requirements even exist. This also can help you if later down the road someone says why did we do this?
3. Prioritize the Requirements. Its important to identify ‘must have’, ‘would like to have’, and ‘if there’s time’ categorizations for every requirement. Its also a good idea to have further priority information. This extra priority information combined with the motivational reasons should make it clear where you need to spend most of your time, or make sure that the solution absolutely covers these areas.

Functional Specification

These requirements and the knowledge you have gained from the client now allows you to create what is often referred to as a functional specification. This outlines how the users expect to interact with the system, outlines their requirements and ensures that unanswered questions are resolved.

Some important points:

1. Only one person should OWN (and write) the functional specification. This is very important. This ensures one person is responsible, one person can be referenced for information, and that the creative ideas and concepts represented (while based on many peoples input) is written and communicated by one individual. If the project is very large and this doesn’t seem feasible for one person break it into two smaller projects and have each person write their own specification for a part of it.
2. Always have a developer or someone who will be writing the technical specification review your functional specification. This review should help point out gaps in the document, or knowledge so that you can interact with the client and retrieve answers without disrupting the technical specification process. (You don’t want the technical specification to start until the functional requirements have been hammered out if at all possible, that way you will not potentially need to redo some technical specification work if requirements change.)
3. There should never be a question mark in the functional specification. Everything written in here will be signed off on and it should be complete. Ensure if you aren’t sure about something that it is classified as out of scope.
4. The functional specification must not contain details on how it will be technically implemented. This is the kind of information that should be contained in the technical specification which is developed from the functional specification. The functional specification should contain a ‘from the user’ perspective.
5. If possible provide scenarios. Scenarios are one of the easiest ways for any reader to understand something. It gives a real world example for how something works and can provide addition insight into why, and how it could be done.
6. Make it READABLE. This one is very simple. If possible make it fun to read, or if that’s not possible ensure the language it is written in is to the point and easy to read. Never complicate it with business jargon or add extra adjectives to describe something just because you want to sound savvy or the document to seem ‘more professional’.
7. Include a sort of ‘executive summary’ or overview that is short, to the point and describes high level what the functional specification outlines in more detail. This will allow those who don’t need to read the entire thing to still understand the information it contains.
8. Include as much detail as possible. If you outline that there is a requirement for notification to be sent to a user make sure you write exactly what the notification will say, and identify any options or actions that can result from this notification.

Design and Architecture

Technical Specification and Architecture

Developer or Architect creates a technical specification or a ‘design doc’ as often I hear it being referred to as. Content contained in the technical specification can include how the solution will be built, what technologies will be used, what the server requirements and hardware requirements are, stuff like that.

Provide specific instructions for how things will work and if possible their dependencies. As an example if you know your end solution will most likely utilize a notification service that will require email provide this information in a clear manner so that upon sign off (or even before sign off) the analyst, consultant, or account manager assigned to interact with the client can begin getting you the things you eventually will need.

Graphic Specification, and Visual Design (or Screen Engineering)

With the technical specification complete we can now document how the screens, components, messages, and features will look to the end user. To be honest, I am not a graphic designer, or even really a designer. So my advice on this area is going to be limited in scope.

What I would recommend here are these few things:

1. Make a specific note that these are recommended screen designs but that the end result may differ slightly. The initial screen designs rarely capture every single aspect of the solution and do not get modified at some point. They are the guideline and really help clients, developers, and anyone else involved understand what to expect. Since this is setting their expectations make certain they realize that minor adjustments may be necessary to make it more functional or user friendly down the road.
2. Notify the client of any graphical changes. If you do make a graphical change or desire to make one after the client has signed off and the project has started in earnest, make certain you notify them. Get them involved even if it’s not an active role to make sure that it reduces potential trouble down the road.
3. Do not add extra functionality to make things look nicer. Keep in mind you have a limited amount of time for this project. The designs should mirror what is outlined in the functional and technical specifications. Often (by accident) a graphic designer may adjust something to make it look nicer but not realize the implications that adjustment can have. It’s important to think about everything that might be effected by visual adjustments.
4. Have technical staff review the design. Don’t just have the analyst, or consultant review the design make sure the developers also review it. They may point out inconsistencies or potentially better ways of presenting information or taking user input. They know the tools available to them, and in SharePoint as an example will know the effort required to style and adjust certain items, over others. (Example changing the way a list presents information as opposed to adjusting a master page.)

Development Plan, Communications Plan, Training Plan, Support Plan, Governance Plan, and Project Plan

Based on estimates for how long tasks should take and a logical rational breakdown of responsibilities create a project plan. I normally use Microsoft Project because it makes it easier to modify later, tell what’s on the critical path, manage resources across projects, and so on and so forth.

Important Note:Don’t forget your communication, training and support plans! These should be all elaborated on and clearly identified at this stage along with their time and associated cost. SLA agreements might be created here, or communication plans. So keep in mind that while I am only describing briefly the project plan and development plan that there are a great many other potentially required plans and agreements necessary before you should move beyond the planning stage.

Include clear identification of how the system will be governed in a governance plan. This is especially important for SharePoint deployments and is probably the single biggest thing I often see missed. Here is a TERRIFIC sample of a governance plan created by Joel Oleson and Mark Wagner: http://go.microsoft.com/fwlink/?linkid=92333&clcid=0x409

Create a development plan based off of the technical specification and the design specification. Ensure all estimates, times and tasks have been delegated under this plan.

Depending on the environment I like to use a RACI model for both plans.

RACI in this case stands for Responsible, Accountable, Consulted, and Informed. Basically for each developer/team member I make sure that it is clear whether they are responsible, accountable, need to be consulted, or need to be informed of each and every task. This is normally pretty easy to do, but it makes sure that everyone always knows who needs to be consulted with, informed of changes, or who is accountable for a task being complete etc.

Personal Note:

This doesn’t always make sense. There are some teams that may take offense to the concept, and it isn’t always the easiest thing to keep track of. However in important projects I believe this is an integral piece because without a RACI model implemented you cannot always determine what might have gone wrong, or how it can be resolved in the future. Personally I always use one and fill it out regardless, but it is best if each member has input and agrees to the RACI for each task.

One thing I also do is often use Project Server to really expand my capabilities in regards to being able to show the project plan, baselines, etc without actually requiring a user to download project. This is especially important because project can really be a scary big thing for most users upon first beginning to use it. It also saves lots of cost and some space on all the developer and related project personnel.

Specification and Project Plan Sign Offs

All stakeholders sign off on the functional, technical, and design specifications as well as the project plans. Everyone must be in agreement from the customers to the teams that will be implementing it. This saves time down the road, as it’s more costly to make changes to projects further into the project and ensures that all involved parties have been included and have taken responsibility for the solution.

Personal Note:

If there is trouble making the technical specification most of the time it is because the functional specification and requirements have not been fully identified. If the design specification has lots of trouble then it’s probably the functional or technical specification that might be at the root of these issues.

Development

The development phase is fairly straight forward. The technical specification has broken down the technical details. The design specification has broken down the look and feel. The development plan has broken down the tasks and responsibilities.

With all of those in place this is a smooth and easily managed phase of the project. It also has HIGH visibility of where things stand because you can always compare against the development plan, technical spec and visual designs.

Personal Note:

Standards are a wonderful thing but continue to evaluate them to ensure that they remain current, relevant, and useful. Keep things structured if possible as this helps you keep estimates more accurate. However do not crush your teams with impossible to meet standards. These provide no benefit and detract from the important of standards. Make sure all goals and standards are attainable and have clear indication of why they assist developers and team members.

Security Testing

One thing that I have seen over the past few years is a new more specific form of testing for security. In today’s world security is becoming more and more specialized and more and more important. To this end it might make sense to have a security team perform security tests, provide input on potential vulnerabilities, and often elaborate on ways to improve security for the code, application or system.

Unit Testing and QA Testing

There is unit testing and there is Quality Assurance testing. These are totally different things. In unit testing you will test individual components, and then STILL in unit testing you will test things integrated with one another often in a SIT environment. When all of this testing is completed and everything looks perfectly solid you move it to QA for testing. But only once you have fully tested the components.

QA will evaluate whether it matches the visual designs, and the functional specification. In some cases also the technical specification. Their job is more to just assure that the quality is there and come up with tests that the development team would not have thought of. Unexpected user inputs, or ways in which the user can use the system (still using the functional specification as a guideline) that maybe the development team missed.

Personal Note:

It is important to have a SIT (integrated testing area for all the individual modules and components) environment for development as well as a seperate QA environment. Keep in mind that all these environments should match as best as possible the client’s environment to avoid environmental issues and troubleshooting that might be needed down the road.

Deployment

Documentation

Before you deploy anything anywhere it should be clearly documented what you will do, what performance and outage’s it could result in, and how the changes you make can be undone.

Along with all of this you should also have any help documentation, user manuals, administrator manuals, and other documentation that is produced in your project complete or very clearly defined before implementing any solution on a client’s environment.

Lastly, document exactly what you do in that environment so that you can diagnose issues, or protect yourself from being blamed for unrelated issues.

UAT Testing

User Acceptance Testing is very important. This is where users review the solution in their own environment and ensure that their expectations have been met and that it is a usable beneficial system. Earlier in the plan it was important to note that any communication and training should be clearly identified. It is also important to note that if at all possible preliminary training at least should be done before UAT. This will ensure that your resources at UAT are not teaching people how to use the system as much as ensuring it meets or exceeds all of their expectations.

Personal Note:

For projects where the client doesn’t have the money or interest in training I normally expand the UAT cycle to account for the fact I (or my team) will also be training while performing the user testing.

UAT Fix and Testing Cycles

Taking any exceptions from UAT and ensuring that they are fixed and fully tested and then if needed ensure that the user has accepted the changes as well before moving on to the final deployment.

These cycles can often go back and forth more than once depending on how good communication with the client has been, how well client expectations have been managed, and how accurate the initial specifications and plans were.

Final Deployment

Your last deployment (aside from updates and new releases). This follows the same documentation rules as before.

Communication and Training

This is the full training, and communication phase. Often this could be workshops, webcasts, training sessions, assisting the organization with posters and improving internal user acceptance or user adoption etc etc.

Support and Feedback

SLA’s might contain what your support details are. Often this could be fixes, warrantees, upgrades, or even live support. It really depends on what you identified with the client. I also like to ensure that feedback is gained from the client. This provides a wonderful opportunity to create business references, case studies or other great marketing tools because the solution is new, exciting, and in (hopefully) most cases the client is very happy and satisfied.

Hope this helps someone or stirs some ideas for how to better manage your project through it’s phases,
Richard Harbridge

Microsoft Integrating jQuery with Visual Studio

Scott Guthrie over at MS made an announcement that the open source jQuery library will be integrated into Visual Studio. (http://weblogs.asp.net/scottgu/archive/2008/09/28/jquery-and-microsoft.aspx) This means they also treat it as a supported product with technical support contracts, and will use it to build controls for ASP.Net.

Edit: Microsoft isn’t necessarily ‘supporting’ it like they would their own proprietary technologies, but is more releasing it with their product and making it a part of the ‘offering’ for a developer. Microsoft doesn’t own jQuery at all or anything like that, it’s still under it’s own MIT license.

Awesome.

It’s always good to see the communities tools and voice being heard and integrated, and this is one of those tools (the jQuery library: http://jquery.com/) I use often,
Richard Harbridge

Identity Management and Federated ILM

I had of course heard the term Identity Lifecycle Management, and understood that it had something to do with centralizing and helping users manage identities across systems and all that jazz. Any IT jock or person involved in Technology should understand (and hopefully does) that Identity Management is probably the most integral part of any system. Hell, even with anonymous systems it still uses a form of identity management because these systems must be ‘administered’ by someone and that someone has an identity for use with that system.

So I decided to look a little more into it, and to say I am impressed by the solutions and ideas that people have come up with in relation to Identity Lifecycle Management solutions would be definitive understatement. I believe the best term for how impressed I am by this would be at the ‘totally freaking wicked awesome’ level. I know.. I am excitable, but seriously if you haven’t ever really read about or looked into Identity Management or Identity Lifecycle Management (which will be referred to as ILM from this point onward in this post) follow along with me here.

The concept of Identity Management is pretty simple. You have an identity. Everyone using any system of any sort uses an identity when they interact with that system. This could be an anonymous user (which uses an anonymous identity) or an identity that has information about who you are. The most common systems for this would be forms authentication running of a user store (let’s say… sql database for an example) or Active Directory if you are working with Windows, or whatever Linux and those other systems use for Identity Management.

So what’s the big deal? The fact that everything nowadays requires you to submit your identity. Think of the internet (big I know) and how you visit different sites and register or login (facebook, myspace are pretty popular so lets use them as an example). When you login it uses your profile information in a number of ways, presenting the information you want to see, who you are, who you might be associated with and other things. All of this of course comes down to being associated with your ‘identity’.

In a nutshell Identity Management provides you with more cability to manage identities. This can be in the form of policies, provisioning, workflows, or reducing ‘sign in’ needs.

So what’s cool? The whole federated identity management stuff and how far some groups have come with these systems.

So what is federated identity management? Exactly what the term sounds like unionizing, or bringing together these identity management. Let’s take a simple example. Your organization has AD and maybe an intranet. You login to the intranet and navigate to your benefits area. When you click on a link in the intranet to the benefits area it actually uses federated identity management to communicate who you are and (since your already authenticated) does not prompt you. The information it presents you with is based on your identity which has been passed onto and associated with the benefits system’s identity store.

This isn’t a new concept or anything, but what fascinated me was when I actually played with one of these systems (in my case Microsoft Identity Lifecycle Manager (the new beta)), it was how the interface was set up, and how it honestly was like something out of my dreams.

I have seen a great many different AD’s in my day and have wrote applications that integrated with PeopleSoft or other systems for identity management. Many of them had problems and issues, weren’t well maintained, or were structured poorly. This causes all sorts of issues when you are trying to implement systems like SharePoint 2007 because now you cannot rely on having organizational hiearchy (as an example) being available to you for audience targeting. Take that one step further and many of the clients I have worked with use many different user stores, or work directly with groups that have their own user stores.

It’s the way the world works, I evangelize and advocate SharePoint, another person sells their custom app and so on until there are a plethora of different systems that all use different identity stores.

With a tool like Microsoft’s Identity Lifecycle Manager it removes so many of the issues I would run into on a regular basis trying to either replace, or integrate the existing systems. That’s not to say you don’t have plenty of alternatives (single sign on is a good one), but seeing many systems so well integrated and being so easy to manage and synchronize made me fully understand the power (and obvious effort) these ISV’s and organizations solution’s provide.

Looking forward to learning more about the whole ILM marketplace,
Richard Harbridge

P.S – Here’s some examples of solutions which fall under Identity Management and ILM…

Management of identities

• Provisioning/De-provisioning of accounts
• Workflow automation
• Delegated administration
• Password synchronization
• Self-service password reset

Access control

• Policy-based access control
• Enterprise/Legacy single sign-on (SSO)
• Web single sign-on (SeoS)
• Reduced sign-on

Directory services

• Identity repository (directory services for the administration of user account attributes)
• Metadata replication/Synchronization
• Directory virtualization (Virtual directory)
• e-Business scale directory systems
• Next-generation systems – Composite Adaptive Directory Services (CADS) and CADS SDP

Other categories

• Role-based access control (RBAC)
• Federation of user access rights on web applications across otherwise untrusted networks
• Directory-enabled networking and 802.1X EAP

Standards initiatives

• Security Assertion Markup Language (SAML)
• Liberty Alliance — A consortium promoting federated identity management
• Shibboleth (Internet2) — Identity standards targeted towards educational environments
• Abriva — Free mobile identity management framwork

References: http://msdn.microsoft.com/en-us/library/ms996532.aspx, http://en.wikipedia.org/wiki/Identity_management, http://www.microsoft.com/windowsserver/ilm2/default.mspx

Exciting (for .Net/VS Developers) .Net 4 and VS 2010

Just wanted to point out that a few days ago Microsoft unvieled some information on the new .Net and Visual Studio enhancements they are preparing for 2010.

http://www.microsoft.com/presspass/press/2008/sep08/09-29VS10PR.mspx

That’s right I am super excited to play with the new stuff before I have even gone through every new feature released in the 2008 packages. (Personally one of the things I have been loving recently is the CSS and styling UI enhancements see Daniel Moth’s good screen cast of these here (if interested): mms://wm.microsoft.com/ms/uk/msdn/nuggets/v2_CSSinVisualStudio2008_Moth.wmv)

I really like many of the new focuses that Microsoft is putting forward and the way Team Foundation Server is improving the rate of process adoption in many development groups. The further they get with the enhancements the easier it is to develop and really focus on developing (if you are a developer) without being as distracted by the troubles of communication and tracking.

Even if you aren’t a developer this is still good news, because the more they work towards that UML approach and enhance the ways Business Analysts and Consultants can communicate their requirements and expectations to developers the more powerful the developed solutions will be.

Excited for the future,
Richard Harbridge

Google’s New Browser (What it really means.)

Yes Google has a new browser. Yes it is as fast as Firefox, and yes IE 8 is coming out soon and is also looking pretty enticing.

But the real thing here that is interesting isn’t the functionality that has been released for Google and IE 8’s browsers yet. The real interesting things are what will happen next.

Microsoft has been at this for a long time, and they have gotten very smart about it. The newer products like SharePoint 2007 and many of their online services work best with IE. That is: They have features that ONLY work in IE. This forces many users (especially in business) to use IE in order to get the full power out of their everyday applications.

Google’s new browser isn’t really about the features it has, it’s about the fact that now there is nothing stopping google from releasing features on google’s search engine, youtube, google ‘office’, and other google owned sites/applications that we use everyday that ONLY Google Chrome works with. Let’s face it if Google did make a move like this, then you would see a real upset in the browser wars. Because this means that Google now has some of the most popular and widely used internet resources (youtube and google search) advocating google chrome.

Microsoft has been keeping their work in this regard (works best in IE) limited to the business world for the most part. Google would be dropping that kind of concept right into the public domain.

To me, that is far more interesting than anything else about Google’s new browser,
Richard Harbridge

How to Handle Angry, Frustrated or Upset Clients

This sounds really simple.

It is simple.

At a glance everyone knows that when someone is angry, whether they are a client, co-worker, your boss, or your mom the way to handle it is with patience, by being receptive, appreciative and by being empathic to their needs. The hard part (I think) is finding a way to turn the situation into a positive one (and trust me, every situation can be turned into a positive or beneficial one).

So lets go over the ‘Steps’ for how to handle these kinds of potentially dangerous situations and provide some advice for how to turn it into an advantage.

1. EMBRACE THE ISSUE IMMEDIATELY

   Let the other person know you want to hear about it. Do not use any body language or say anything that could be interpreted as “I don’t want to hear it”, or “I don’t have time for this.”

   You would not believe how many people I see who pride themselves on their conflict and client management skills who immediately cross their arms (maybe subconsciously) when someone begins ranting about some issue. Your instinctual reaction is going to be to become defensive, protective, or try to avoid it. Crush this feeling and instead EMBRACE the issue.You  want them to immediately feel that they have a valid point and that you are there to help them. First appearances and reactions are often the cause for the most conflicts because even if you embrace the issue after, they will remember it took THEM to convince you that they were right.

2. THE ONLY WORDS YOU SHOULD SAY ARE WORDS OF AGREEMENT

   But what if the client or staff member is wrong? Don’t worry about it, if you know they are wrong you can convince them of it without ever taking an opposing stance. Phrases like “I can understand your frustration with that”, “Absolutely you have every right to be frustrated.”, “I would be frustrated if that happened to me…” etc all build on you agreeing with them. You cannot win an argument so never let it become one.

3. CONVINCE THEM OF THE MISTAKE OR RESOLVE THE ISSUE

   So now let’s say that now that you FULLY understand their issue (if you don’t then you should not try to convince them or resolve it) and you want to turn it into something positive.

   At this point the advantage is that you have created NO negative effects from this conversation. The best way to convince a person they are mistaken is to get them to convince themselves. The way I like to do this is simply to point out new ideas that they might not have thought of, but to do it modestly.Be confident. If it is a real issue make sure they feel like you not only understand it, but will also ensure that everything that can be done about the issue will be done. “We will do everything we can” may seem like a good phrase but most people (especially if they are interacting with you most) would prefer to hear “I will put all my attention on this immediately and make sure that we do everything we can to resolve this issue as soon as possible.” It’s exact, it’s confident and it provides PERSONAL assurance that not only do you understand the issue but that it’s IMPORTANT. After all, they would not have brought it up unless they thought it was important right?

4. GIVE THEM AN ESCAPE ROUTE (if you convinced them they made a mistake) AND COMPLIMENT THEM

   What’s important here is that as soon as the person realizes they are mistaken they will want to escape the conversation, or excuse their response. That’s why it’s important to give them escape routes with your words. “I wonder if we offer a solution like that… Let me check… Oh gosh, we sure do, what a silly place to keep that information, I could not even find it and I work here… I will make sure to talk to communications about this…” is an example of a phrasing that excuses them while providing value to the ‘complaint’ or issue so they don’t feel like they wasted their time.

   You can even do it so that it helps make them feel more appreciated. Phrases like “It’s people like you who help our business”, “You’ve really put a lot of thought and effort into explaining this, and I want you to know I really appreciate it.”, “This is great, now we can make sure we don’t run into issues like this in the future all because of the effort and time you have put in to help us resolve it…” etc etc

5. DON’T AVOID SPEAKING ABOUT IT
   

   If you followed the above steps there is absolutely no reason to ever avoid speaking about the time they were upset or try to convince them later that it was less important. Instead just make sure when it is brought up (because they won’t forget) that you talk about the good things, like how fast you responded, how you understand and emphasize with their issue previously and how you (or the resolver) personally dealt with it and put large amounts of effort into making sure the client received the best service possible.

Happiness is bliss, and everyone wants to be happy,
Richard Harbridge