Random thoughts on being service-oriented

Currently, I work in a support group in the IT department of my company. Our group assists other IT teams by scheduling, assessing impact and coordinating deployments to our production systems. In essence, these are the services we provide. For the purposes of this posting, this is my frame of reference when I say service-oriented.
Random thoughts on improving your customers' experience:

1. Think about things from the perspective of your customers. Perspective is everything after all.
   
2. Take your own medicine - go through the process yourself. Have you ever come across a user interface where you wondered, "What were they (the developers) thinking?!"
   
3. Don't be a cold heartless bureaucrat. It's important to your customer; make sure they know it's important to you.
   
4. Do things which provide benefit and value, not because you're following a checklist.
   
5. The process you steward can be a part of a much larger one. Never forget it. When someone asks for help but it's in another area, make sure you explain to them how the larger process works and your piece in it.
   
6. When you need to pass a client onto another service team, do it personally if possible. Make sure the transition goes smoothly.
7. Acknowledge the requests you've received and set expectations for completion.
8. Provide updates when you're running late and won't be able to meet the expectation.
9. Follow-up afterwards and ask for feedback.
10. People shouldn't use your services because they have to. Don't tell them that. People should use your services because they want to! Be ready to market the benefits in a tangible way.

WIIFM - What's In It For Me

I remember sitting through some of my directors' presentations listening to them talk about, What's In It For Me, or WIIFM for short (not to be confused with the Nintendo Wii - which I play but suck at.) The basic idea was while you worked hard on projects you were also learning, developing new skills and getting new experiences. WIIFM for everyone!

In a few of my blog posts I've written about how important it is to adjust your presentation and communication to your audience. In effect, you were telling them, What's In It For Them. It's all about creating a relevant experience to sell an idea, product or concept.

Now let's step back and examine this WIIFM concept applied to another situation. Have you ever worked on a project where you have an idea on how more success can be achieved if the project team were to work more collaboratively with other project teams and personnel? In my experience the typical project manager response is, "It's not my problem," or, "It's outside of my scope," or, "It's someone else's problem." Then you step back and watch the car crash in slow motion; the problem manifests itself and severely impact the project and company as a whole.

I liken this to Adam Smith's (the Father of Economics) "invisible hand."

As every individual, therefore, endeavors as much as he can both to employ his capital in the support of domestic industry, and so to direct that industry that its produce may be of the greatest value; every individual necessarily labors to render the annual value of society as great as he can. He generally, indeed, neither intends to promote the public interest, nor knows how much he is promoting it. By referring the support of domestic to that of foreign industry, he intends only his
own security; and by directing that industry in such a manner as its produce may be of the greatest value, he intends only his own gain, and he is in this, as in many other cases, led by an invisible hand to promote an end which was no part of his intention. Nor is it always the worse for the society that it was no part of it. By pursuing his own interest he frequently promotes that of society more effectually than when he really intends to promote it. I have never known much good done by those who affected to trade for the public good. It is an affectation, indeed, not very common among merchants, and very few words need be employed in dissuading them from it. (Adam Smith, The Wealth of Nations)

Basically, this means each individual acting in his (or her) own self-interest will lead to a better outcome for the society as a whole; or WIIFM but on a project-scale. The problem with this is simple. No one ever builds roads and the infrastructure to connect things because it's in no specific person's best self-interest; but that's not my problem. Is it?

I'm not saying expand a project's scope, merely understand how a project fits in with the big picture.

Someone else's shoes

Continuing from my last post, spending a day in another person's shoes will give you an appreciation and understanding of their point of view.
Try this simple exercise - Drop any preconceptions or notions you may have and pretend you are in the position of one of your clients or end-users. Do a little role-playing to increase your empathy.

• What would you want or need to be successful?
• Why would you want it? What would you do with it? What's the value?
  
• When would you need it?

By no means do I suggest you use this technique to gather requirements for a client, however, it will help you look at things differently and with a more open mind.

Change your perspective

Perspective influences how you view the world. It allows you to see things in a different light than another person, but it can also keep you from understanding their point of view. When you are gathering requirements from a client, having empathy enhances your ability to understand their needs.

Benefits of being able to view things differently:

1. Allows you to be open-minded, receptive and patient.


2. You learn to think like your client. In some of my engagements, I found my clients could not articulate exactly what they wanted. I needed to perform a lot of facilitation to help gather and define requirements. Being able to think like them allowed me to probe more effectively and determine the underlying objectives.


3. Because you understand your client's point of view, you can anticipate their next question. This is an excellent value-add to your ability to provide service.

Changing perspective isn't a foreign concept. If you have ever created user stories, you have in essence used an approach that incorporates the different perspectives of the people involved. User stories are easy for the different parties to understand -- clear communication is always the goal.

Make understanding your client's perspective a part of every engagement.

Building trust

A business analyst bridges the communication gap between different parties through precise communication and understanding. Part of this process requires the development of strong working relationships with clients, or more simply, client management skills.
Like any relationship, professional or personal, establishing trust, confidence and credibility is of the utmost importance. Here are a few of my suggestions:

1. Set expectations. Make sure your clients understand the necessary inputs and outputs from the engagement. Make sure they understand their own role.
   
2. It's all about execution. Do what you say you will do. Develop a plan and show your are executing against it. This improves your client's transparency into your activities as well as shows your accountabilities.
3. Present the good and the bad. By nature a lot of us will 'sugar-coat' the bad things or make them small footnotes. Present the bad news and its impacts however, provide options, alternatives and recommendations.
   
4. Be able to justify your work. Be prepared to run someone through your thought process. I remember one instance where I had prepared reporting showing assets under administration a few hundred million dollars short of the previous month. Naturally the lead accountant questioned my data. I walked him through the process of developing the report and after he saw the diligence and supporting numbers he agreed with my conclusion. Afterwards, he never questioned any of my work and was always satisfied with the results.
   

Whenever you are starting an engagement with new clients there is a feeling out process. This is your opportunity to set the stage and provide exceptional value-add service.

Tips for end-user acceptance

Any solution, no matter how well it has been conceived will not be successful unless it is embraced by its intended end-users. Here are some quick tips to help promote acceptance (though I don't guarantee it.)

1. Understand how end-users work: Find out why they do the things they do. If you show an interest in them, they will be more comfortable with what you're trying to accomplish.
2. Provide opportunities for feedback: This is particularly important when there are user interfaces involved. At regular intervals, let people see the development and direction and be willing to listen to suggestions and feedback.
   
3. Manage change: If something has to change let your customer understand the rationale. "Because it has too..." is not a useful response. If the change is meant to make things better explain how.
   
4. Make it seem familiar: People by nature are resistant to change. Perhaps there is opportunity to gradually phase in changes (smaller changes are easier to digest) or provide an interface that is similar to an existing one.
   
5. Enlist champions: End-users that can teach other end-users are a great way to provide support. It also gives the champions a sense of ownership for the adoption. Early adopters are good individuals to use as champions.
   
6. Teach don't point: When someone asks for help one of the worst things you can do is point them to a manual. Spend time to teach them how it works. Show them they're important.
   
7. Measure & report: If the new solution is meant to improve productivity, show them the gains that have been made over time as the end-users become more familiar and move up the adoption curve. This type of information shouldn't just be provided to the project sponsors and management.
   

Projects are usually justified quantitatively based on achieving benefit targets (e.g., gains in efficiency or increases in sales.) Maximum benefits will not be achieved if the end-users do not embrace the solution wholeheartedly.

Leadership styles

I remember taking a course developed by the Leadership Research Institute on leadership styles. The purpose of the course was to help identify the most appropriate way to interact with an employee given an understanding of an individual's:

1. Ability to perform a task.
2. Motivation level to perform a task.
   

Using these two factors to create a simple matrix you get a picture similar to the one below. For each quadrant a different approach is warranted for handling an employee.

1. High ability to perform the job but low motivation to do it. Convince the employee to persevere and outline the task's importance.
   
2. High ability to perform the job and motivated. Allow the employee to perform the task unhindered. There is no need to provide direct support or exert control.
   
3. Not able to perform the job and not motivated either. Basically you need to tell the employee exactly what to do to complete the task and monitor his (or her) progress.
   
4. Not able to perform the job but motivated to try. Provide support, feedback and guidance to help the employee complete the task.

These guidelines assume that you are able to determine the competence and motivation level of an individual.

Intuitively, this framework makes sense. When you understand how to perform a job well and are highly motivated to do it, you don't really appreciate someone looking over your shoulder, telling you what to do and asking for constant status updates.

The purpose of the course was to improve managing employees, however, I feel that these fairly simple guidelines can be used in any situation where you need a task performed by someone other than yourself.

How "bad" requirements can stifle innovation

A great way to curb innovation and creativity is to impose improper limitations.

Limits by themselves are not bad. Clearly a project needs to operate within a set budget, resource allotment and delivery schedule. These types of constraints can actually spur creativity and novel solutions.

But let's think about business requirements and how improper requirements can hinder the process of innovation. More specifically let's examine how requirements that are not design independent can unfairly constrain a solution to a business opportunity (or problem.)
Many times during my requirements gathering and elicitation engagements I have heard subject matter experts and clients tell me their requirements based on existing applications and functions. They assumed that the products delivering the new capabilities they desired would actually be enhancements to the existing applications. In truth, the eventual solution may be based on an existing one (particularly with software products), but this is not always the case.

Suppose our company designs cars. The newest set of requirements for the upcoming model year state the driver has the ability to:

1. Determine where he / she is (e.g., location) at all times.
   
2. Receive driving directions to a user specified address.
3. Interact with the system through the car's dashboard.
   

By themselves, these requirements seem fairly benign. Suppose our project advanced to the stage where we are developing a solution to meet these needs. Our team decides that a global positioning system (GPS) is required. Based on the third requirement, it is decided that an on-board system similar to Onstar is appropriate. Implementing this solution requires our company to purchase units of the GPS product and integrate it into our assembly (line) process.

Nothing appears terribly wrong with the proposed solution, but what if the car model in question is marketed to first time car buyers and students (people who want to be sporty but on a budget.) Large scale changes to an assembly line are costly. Acquiring GPS units and integrating them into a car's electronics are expensive. The cost of the new model will increase as a result.

Because of the third requirement we have ignored other solutions that may have been more optimal. Perhaps we could have offered portable GPS systems (e.g., Tomtom's) to people who purchased our vehicles. Our needs would be met in a more cost-effective manner.
The third requirement constrained our innovation and creativity to the point where a more optimal solution was missed. This is how a requirement that is not design independent can stifle innovation and creativity.

Understanding the goal

When gathering requirements, one of the most important things to understand is the answer to the question, "Why?"

The answer to this simple question will provide clarity and guidance to your requirements gathering efforts. This is because you will be able to evaluate whether the requirements you are gathering will solve your problem (or capitalize on the opportunity.) Thus, a business analyst should always seek to understand the underlying business objective.

Suppose a client receives five sets of different reports. The client is concerned because it takes him a long time to get the necessary reporting. His request is for his five reports to run faster so he can perform his analytics. The business analyst (doesn't probe any deeper and) works with the IT developers to optimize the SQL used in the reports, create database views to reduce the number of multiple-table queries and revamps the reports so they are more efficient. Finally, the business analyst presents five optimized reports. The client promptly looks at each report, takes two pieces of information from each and then creates a dashboard sales report for one of his customers.

If the business analyst knew that the goal was to prepare a dashboard sales report, could a more optimal outcome have been achieved?

Here are a few comments about what happened:

1. The requirements were not design-independent. It was pretty much determined to rework the existing reports and make them more efficient.
2. Ultimately, a useful result was obtained however, it may not have been the most optimal one. The business analyst also ran the risk of not achieving the goal at all because the business analyst did not probe deeply enough to uncover the underlying objective.

If the business analyst had used active-listening techniques and probed the client, both of these issues could have been avoided.

Getting past the fog

There was an interesting article on Yahoo! recently titled, A Guide to the Latest Batch of Corporate Buzzwords. It's a short piece and examines the usage of corporate jargon and lingo.

A new crop of buzzwords usually sprouts every three to five years, or about the same length of time many top executives have to prove themselves. Some can be useful in swiftly communicating, and spreading, new business concepts. Others are less useful, even devious.

Delayering, rightsizing, unsiloing ... What do these terms mean? Step back and think about how much terminology you use each day that an outsider would not be able to understand.

Using inappropriate language will only further confuse and obfuscate your message. Simplicity and clarity should be valued above all else.

Setting expectations

In the business world, a key part of communicating is expectation setting. Whether you are delivering a presentation or a set of requirements, not establishing expectations with your audience can lead to a few unfortunate outcomes.

1. Your material is perceived to be unsuitable. It may be too detailed or contain too few details.
2. People may require you to perform additional work to produce something more acceptable to them. You'll get comments like, "I won't sign-off on this unless I see... such-and-such in there."
3. Your work is not perceived to be relevant. You'll be asked to go back and start over.

In marketing, there is a saying that, "If you do not position your product, someone will do it for you." Likewise, when communicating, "If you do not set expectations, they will be set for you." Think of what happens when you watch a presentation (or attend a meeting) with 10 other people. How many of them say things like,

• I didn't get anything from that.
• That wasn't what I expected.
• There were no details, I need details.

If you hear these sorts of statements, it indicates that people did not have a clear idea about what to expect and why there were there. In other words, the individuals responsible for delivering and setting up the presentation (or meeting) did not clearly articulate their intentions.

In one of my previous posts, I wrote about expectation setting as it related to the development of requirements. What resources you'll need access to, what tools you will be using, how you will be providing status updates and the facilities to provide feedback (and ultimately sign-off.) The last part of this is to explain and outline what will be in the actual deliverable.

Before I start writing about expectations for deliverables, recall that there are many different phases to a project's life cycle and for each one, different levels of information and different audiences are present. For each, a different expectation needs to be established.

Spotlight: business analyst

Allan Hoffman recently posted an article on Monster.com, Career spotlight: Business Analyst.

He lists the main factors for requiring more business analysts as:

1. The increase in outsourcing patterns.
2. A continuous drive for improved efficiency.
   

Mr. Hoffman points out that the most important thing a business analyst can bring to a project is translation; or a furthering of understanding about what is required.

Kathleen Barret, president of the International Institute of Business Analysis (IIBA), says business analysts' ability to translate -- an ability that's difficult to offshore -- is crucial to succeeding in the role. "[Business analysts] need to be there with the business," she says. "It's very difficult to do a good job virtually."

This echoes my thoughts from an early post, The why of business analysis. The central role of the business analyst is to foster understanding throughout the business and IT groups to provide the best basis for success.

Step back for a second, think about how easy it is to misunderstand and miscommunicate. Think about the costs and consequences associated to some of these misunderstandings when they happen on your projects.

Unfortunately, they aren't as humorous as the following video.

Project prioritization goals

Continuing on from my post, Why prioritize projects?, prioritization is important because,

1. It provides focus to the more important initiatives. Companys can concentrate on what really matters to them and not be distracted by the latest fad.
   
2. Money, time and people are scarce resources. Proper management and effective use of these resources can only benefit a company.
   
3. In order to prioritize projects you much be able to compare them against each other objectively. This apples to apples comparison removes bias from decision-making.
   
4. Clear direction and visibility to everyone in the company, not just the main decision-makers. Everyone is on the same page. We all know what can happen when things are not clear.
   

Do you see what I see?

I've been goofing around with a Nintendo DS Lite trying to reduce my Brain Age (I'm hovering around 23-24 for anyone interested.) One of the more interesting exercises in the game is something called the Stroop Test.

The Stroop Task is a psychological test of our mental vitality and flexibility. The task takes advantage of our ability to read words more quickly and automatically than we can name colors. (University of Michigan)

The object of the test is to say the color not the word. For example, if you saw BLUE, your answer would be, "Red!" The Brain Age test is basically to answer 50 of these items as fast as you can.

This got me thinking about how this relates to business requirements and clarity. One party sees, "Red," while the other sees, "Blue," even though they are both looking at the same thing. Furthermore, both parties think they understand completely. Hence, techniques like active-listening need to be used.

Of course, the Stroop Test probably won't work if you have a condition called synesthesia, but that's another story. A common form of synesthesia results in an affected individual seeing letters and numbers in color.

Use the right presentation style to convey your message

Presentations are about selling. Whether it be a product or even an idea, you are trying to communicate your point and get people to buy-in. But sometimes your message isn't presented in a manner that connects with your audience. There are a few reasons for this:

• The contents of the presentation were not suitable. As a presenter you'll notice bewildered looks, the checking of watches and the occasional sleeper. Expectations need to be set! They should be set before you even start.
• Your presentation did not use an approach that related to the audience. Some people are convinced by facts, others want to know the end goal while other people want to see a plan. Know your audience!
• The presentation was not structured appropriately to convey your message. Even if you follow all the tips I've previously provided, a well thought out structure will be very beneficial.

This post will deal with providing the best template for your message depending on your objective. Its inspiration was a course I attended from Bina Feldman. Some of the material is derived from her work. As such, I will only go in-depth on a few of the templates.

First what are you trying to do?

• Present a solution to a problem?
• Share information?
• Sell a product?
• Recommend an alternative?
• Give bad news?

The key is to understand what you are trying to accomplish and then use a presentation template that aligns with your goal.

A template for "recommending an alternative"

For arguments sake, let's suppose you are trying to recommend one alternative versus others. A suitable presentation template would be as follows:

1. State the key decision.
2. Define the key selection criteria (e.g., "must haves" and "nice to haves.")
3. Rank the, "must haves." To quote George Orwell's Animal Farm, 'All animals are equal, but some animals are more equal than others.'
4. List the choices.
5. Eliminate choices that do not satisfy the, "must have," criteria.
6. Analyze the remaining choices against the, "nice to have," criteria.
7. Outline the pros and cons of each choice.
8. State your recommendation.

Notice the whole presentation style focuses on the recommendation and how it was reached. Everything works towards building up a strong case.

A template for "selling an idea (or product)"

1. State the purpose.
2. Outline the audience's needs.
3. What are the features of your idea (product)?
4. What are the benefits that your audience can reap?
5. What's the problem with the status quo? Why don't we want to do nothing?
6. Reconfirm the benefits.
7. Show how to achieve the benefits. What needs to be done to get there?
8. Ask for acceptance (e.g., complete the sale.)

Unlike the previous template this one focuses on illustrating the need for your idea and the benefits it provides. Create demand for your idea by stating the problems that are being faced.

Summary

I am only outlining 2 of the templates; in truth, there are many different ones (If you need some ideas feel free to contact me. Also, if you want formal training I suggest contacting Bina Feldman.)

Depending on the objective of your presentation, it is important to select a template that aligns with your goal. The use of an inappropriate template can render your presentation ineffective.

Simple process flow diagramming - Part 2

Let's expand a little on why initial process flow diagrams should be kept simple. Answer this question, "For a process, is it more important to know what or how?" The how question can lead you down a treacherous path.

Common Problems

• Effort becomes focused on specific details too early in the requirement gathering process. Eventually, the prototypical, "I can't see the forest for the trees," scenario occurs.
• Mysteriously, the to-be process looks eerily similar to the as-is process in terms of the different steps that are undertaken. Problems inherent in the as-is solution may still exist in the newer one. I can't tell you how many times I've encountered this problem. People are generally resistant to change. There is comfort in the familiar. Sometimes, people just don't know a better way to do something.
• We end up spending excessive time defining a to-be process that restricts our thinking and may not be used. In short, we are designing a solution.

To be or not to be?

Think of it from the perspective of a company trying to come up with a solution to a problem they are facing. Ultimately, there are a few different avenues: buy, leverage (what you already have), extend (enhance what you have) or build (from scratch). If I use a complicated process to evaluate vendor products, it is very unlikely that I will find one that meets my requirements to a tee. Instead, I may conclude that, "We are unique and as such no vendor product suits our needs. Thus, we must build a solution."

Think about how many companies you've encountered in your life that were truly doing unique things and compare this to the number of companies that thought they were doing unique things. A rose is a rose is a rose.

To me, this is the worst outcome. You have already, determined your path without realizing it (you have, in effect, not been solution agnostic.)

In Conclusion

• You may choose a less optimal solution path (e.g., build something that can be purchased.)
• You have not used your time effectively.

These things represent inefficient use of time, resources and money. And the ultimate solution may not be as efficient as it could have been.

Simple process flow diagramming - part 1

A picture says a 1,000 words... or so the saying goes, but do you really need 1,000 words to communicate a process? In truth, it depends.

Many times, on business analyst engagements, I've asked people to describe, in picture form, the basic processes that are important to their business. What I usually received was something that required a plotter to print... a huge, complicated process flow that took into account every single odd-ball anomally (even if it would only occur every 5th blue moon.) Why did this happen?

• Subject-matter-experts (SME) can talk ad nauseum about what they do.
• SME are detail-focused people; every detail is important to them.
• SME do not like to see their business processes trivialized into one or two little boxes on a process flow diagram.

My own learning point was to find another way of getting what I needed to know rather than ask this of the SME directly. When diagramming a high-level process flow I usually follow some basic guidelines:

1. Identify the initiator and actors of the process.
2. Be technology and system agnostic.
3. Understand what is required to move from one part of the process flow to the next.
4. Show the main process flow not the alternates.
5. Understand the goal of the process.

The time will come when more detail is needed and the process will be flushed out. But I do not feel you have to start like that. Simple and elegant always win out.

Improving clarity in communications

One of the most important skills you can master is to be able to communicate effectively and efficiently. In the past I wrote a few pieces on improving clarity for requirements and presentations:

• So it's still not clear?!
• 3 simple rules for business writing
• Be clear

I've decided to summarize the main points from these three posts into a presentation deck. As usual I've uploaded the deck to esnips.com so please feel free to access it (I've used high quality images so the file is on the large size.) The file is called, Clarity, and you can access it here. As always, any feedback is greatly appreciated.

INDEX for business analysis

Starting out:

• First things first; learn the skill: Understand how to structure and write requirements before you start using requirements management tools.
• Asking questions and getting answers: Learn how to ask questions to get answers to the important issues.
• Why you need good requirements: Some quick facts on project success and requirements. Presentation available.

Requirements:

• What are requirements?: A quick definition.
• Correctness: There are some things you just can not do.
• Completeness: Make sure that all of the, "what," questions are answered.
• Clarity: Requirements should be succinctly stated; using as few words as possible. Otherwise, ambiguity may occur. Excessive rambling, jargon & wishful thinking confuse readers -- avoid it. So it's still not clear?! Here's a short presentation deck recapping all of these items (the presentation is simply called Clarity.)
• Consistency: I hate it when people say, "Turn right. Your other right!"
• Testability: Prove to your client that the solution meets their needs. When a statement contains multiple requirements it's testability can be compromised.
• Traceability: What requirement led us to do this? How much work do we have left?
• Modularity: Update in one place and only in one place. Makes change management a lot less painful.
• Feasibility: Do you really think with enough time and money you can solve any problem?
• Design Independence: It starts with what and why. How comes later.
• Requirements vs. requirements management: Gathering requirements and managing them.
• Assessing requirement quality: How do you know if you have decent requirements?

The why of business analysis:

• The business analyst & the business systems analyst: What's the difference?
• The why of business analysis: What purpose and role do business analysts serve?

Running a business analysis engagement:

• Prepare thyself - make sure it's not you: Make sure you're mentally and psychologically ready and able to work. Eliminate any preconceived judgments and notions.
• Know the situation: Before you start an engagement take some time to grasp the nature of the project, it's urgency and the resources you'll need.
• Choose your tools: Decide what approach you will use. Will you prototype, interview, brainstorm or observe behavior?
• Set expectations: Ensure your role on the project is clearly defined and that you understand the roles of others as well.
• Time estimation: Estimate how long it will take you to complete your tasks. As you run through more projects your estimation skills will increase.
• It's the little things... Words that should make your ears perk up: Little words that your clients say that create headaches for you unless you clear them up now!
• New! How are your business analysts doing? Understand how to assess them.
• New! Understanding the goal: Knowing the objectives of your requirements gathering sessions helps you determine whether the requirements you are getting will actual help to solve the problem.
  

Project Bits & Bites

• How do you know you're done?: Use requirements management practices and traceability to see how much work you've done and how much you have left to do.
• Well-done or done well?: Use cost-benefit to determining where to invest your energy.
• System development life cycles & requirements: A very high-level overview of different system development life cycles and how this impacts requirements gathering.
• The project and the business analyst: Understand your role in a project and the activities you'll perform to support the initiative. Slides available!
• The sweet smell of success: Measuring success on a project ultimately boils down to meeting or exceeding targets established earlier in the project.
• Choose a methodology that suits your project: No one methodology will fit all projects.
• Testing & Validation: What are the different types of testing that occur as a project moves forth? Slides available!
• New! Requirements in an agile world: Understand that impact a different project methodology will have on requirements.
• New! Setting expectations: It's important that people know what you are delivering and why.
• New! How a "bad" requirement can stifle innovation: A lack of design independence in requirements can lead to a sub-optimal solution.
  

INDEX for presentation skills

This is an INDEX for my presentation skills postings. As new items are added I will include them in the list below. I'll make sure that this post stays near the top of my popular list. Remember, presentations are about communication. Communication is about getting people to understand and buy-in to your ideas.

The picture above is from Apple's 1984 Superbowl commercial.

Communication from the pros - This post is based on two articles: How to Wow 'Em Like Steve Jobs (by Carmine Gallo) and Speech Writing Secrets of President Bill Clinton (by Tomas Murrell.) It covers the styles of two of the foremost communicators.

*NEW* Use the right presentation style to convey your message - Depending on the objective of your presentation, it is important to select a template that aligns with your goal. The use of an inappropriate template can render your presentation ineffective.

*NEW* Improving clarity in communications - A short presentation deck providing some tips and common sources of ambiguity. You can find the deck (called Clarity) in my esnips.com folder.

Give each of them something - Some people want to see a plan. Others will listen to you after you've established a relationship with them. Still others will want to know your goals; they'll figure out their own way to get there. This post speaks on how to communicate with these different types of individuals.

Some more presentation tips - General tips for improving your presentations such as stopping side-conversations, using active listening techniques to respond to questions and using physical presentation aids.

Some tips on presentations - This post is one of the more popular ones on my blog. The basic parts are the pre-planning, slide design principles, and other prep activities that will help you make & deliver great presentations.

The soft-side of presentations - This post provides tips on the delivery aspect of a presentation rather than slide design. These tips include how to use gestures, to speak more slowly than conversation speed, and to change the pace of your presentation every 15 minutes or so (the average attention span.) A good PowerPoint deck won't mean anything if you can't sell your ideas.

Other resources & tips for presentations - Online resources for improving your presentation skills.

A walkthrough of the process I followed to make a presentation

• *NEW* Building a presentation - Part 1 - Who is the presentation for? Initial planning...
  
• *NEW* Building a presentation - Part 2 - Do a little digging to find clues that will help you make a more effective presentation.
• *NEW* Building a presentation - Part 3 - Assemble your material and choose an appropriate template to communicate.
• *NEW* Building a presentation - Part 4 - Version 1.0 is ready for a mock-run.
• *NEW* Building a presentation - Part 5 - A short run-through to make sure I'm on track.
• *NEW* Building a presentation - Part 6 - The morning after... Assessing how your presentation went.