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.

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.

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.

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.
  

How to listen and hear nothing at all

Courage is what it takes to stand up and speak; courage is also what it takes to sit down and listen. (Winston Churchill)

This post extends upon a previous post (Make sure it's not you) covering the topic of listening skills. More specifically, how to identify when you are listening but not actually hearing what people are saying. I strongly believe that listening (recognizing the words) and hearing (thinking & understanding) what people say are two entirely different things.

For example, you can introduce prejudices that influence how you interpret the actions and words of another person in either a good or negative fashion. However, you are introducing distortion and potentially negatively affecting your relationship by doing this. Suppose, I listen to you with rose-colored glasses (e.g., I take everything in a positive light), I may not realize I need to deliver a strong message to you such as, "I don't think that idea will work because it does not address your core need." On the other hand, I don't think you'd like it if I merely gave you lip service and didn't even consider your arguments seriously. So how can you tell if you aren't hearing what people are saying? Here are some indications:

1. Are you constantly interrupting people? Do you finish their sentences?
2. Are you unwilling to even listen to anything that doesn't fit with your thinking?
3. Do you think the issues facing others are trivial before you even speak to them?
4. Do you feel you know what people need before they even discuss it with you?
5. Do you roll your eyes when others are talking to you?
6. Do you enter a conversation with a preset position? Does this position distort what you hear?
7. Do you start side-conversations with other people rather than always being attentive to the speaker?

These types of behaviors can be indicative of a listening (I mean hearing) problem. The hardest part is realizing that you are listening but not hearing. However, you can resolve this problem with a few simple steps:

1. Before you enter a discussion, divest yourself of any preconceived judgments and notions.
2. Let people talk to you in their own words. Don't put words in their mouths or lead them.
3. Use active listening to play back what you understood. Clarify any miscommunications.
4. Ask probing questions to fill in the gaps.

After taking these simple steps you'll have a more unbiased and objective perspective. Furthermore, your clients will know you're listening and interacting with them.

The strangest things

Sometimes as a business analyst you'll hear some of the strangest requests. Things that will make you do a double take. "Excuse me, did you just say...?"

Some of the most odd requests I've heard are:

• "I want you to put a little lightning bolt in the top right corner of the screen that indicates the application is still processing." At the time we were working on a web-based application, so we asked, "You mean like the little symbol that twirls in the browser?"
• "In the older application, when I hit the ENTER button it tabbed to the next field. I want the new web-based version to do that as well." Of course my web developer looked at me incredulously and proclaimed, "I didn't build the damn thing (the browser!) So if ENTER is pressed to tab, what is the TAB button for?"
• "I want you to run a pharmaceutical patient compliance program. We get the pharmacists to contact the patients and talk to them about the importance of refilling their medications. Oh yes, because of privacy concerns we cannot identify the individuals. You'll get an unique index for each person, but it is only unique within the same store." Needless to say at the end of the day, our data was very useless.

The important thing is how would you handle these requests?

1. Suppress the urge to laugh out loud no matter how funny you think it is.
2. Make sure it's not you! Make sure you're listening properly.
3. Use active-listening techniques to see if that's actually what your client meant. Remember your objective is to foster understanding.
4. Your client has told you what they want. Make sure you ask, "Why do you want it?" What is the business justification?

The greatest ignorance is to reject something you know nothing about.

A practical guide to communication

When you are explaining something to someone, you may use a different approach based on your understanding of the other party's background, knowledge and areas of concern. Messages that work well for one person will be poorly received by others. The reason for this is simple, you need to be able to communicate to someone in a manner that resonates with them (see my earlier post, The why of business analysis.)

How does this play out in the real-world? Suppose you applied a patch to a database but something went horribly wrong (for the sake of simplicity let's assume there aren't any redundant systems) and the database is not longer available. Also, let's assume this database provided product information that was consumed by your website, IVR and agents. How would you express the problem?

When talking to the technical support staff, you may mention that the patch has brought the system down. Next steps may be to inform your clients of the outage, roll-back the patch, get the database operational and then contact the database vendor for support.
Now suppose you are talking to the business side, how would you express this outage? Would you use the exact same language? Probably not. The questions that interest the business are:

• What is the impact of the outage? Explain which systems are impacted and the extent to which they are impacted (e.g., It's taking the servers 3 times as long to respond.)
• How long will the outage last? How much money is this costing me? The system will be fully operational at ... In terms of lost sales opportunities, during that amount of time we would normally have 800 sales transactions.
• What can I do in the meantime? How can I help? Direct your consumers to use alternative channels or to contact you a little later.

Note the drastic difference in the responses between the technical and business people. Business users are very interested in the, "So what?" types of questions, not the details. When explaining something to people, put yourself in their shoes. What would they want to know?

So it's still not clear?!

Suppose you are driving down an unfamiliar street and you gaze out the window to see the following sign: Speed hump. What on earth do you do?

The inspiration for this post was a short presentation I gave on effective communication. It fits in well with some of my previous posts on ambiguity (Requirements & ambiguity and Bad Practices - Part I - Ambiguity.) To understand and counteract ambiguity it is necessary to examine its causes.

Differences in perception & context
People have different experiences, backgrounds and societal influences that affect how they interpret things. Sometimes when you are communicating a message the context of the message is lost. I remember watching a DVD called, An Evening With Kevin Smith. Kevin Smith is a movie producer and writer credited with movies such as Clerks, Chasing Amy & Dogma. Before that, he was a comic book writer who penned some issues of Daredevil.

Kevin was talking to a reporter friend about the Tim Burton remake of Planet of the Apes. At the end of the movie, the astronaut gets out of his spacecraft and is horrified to see a statue of a giant ape behind him. Kevin then showed his friend a copy of a comic he wrote a few years before the movie. In the comic, an astronaut turns around and sees a statue of a giant ape and is horrified. The reporter is shocked and asks Kevin if he has any comments. Kevin replied along the lines of, "Tim Burton plagiarized me! Ha ha ha! I'm thinking of suing him! Teeheehee!" Both of them laughed it up.

Later in the week, the journalist's article came out. It came across with a very serious tone. Kevin Smith accuses Tim Burton of plagiary... Contemplating legal action. Kevin ran to the phone and called his reporter friend, "What happened to Teeheehee!?"

That was a long story but you can see how the context of the joke was completely lost when transcribed to print. When you write things down (such as requirements) you cannot communicate the context effectively so you must be very careful or it may be misinterpreted.

Use of jargon
Suppose someone tells you he just got a red herring. What does that mean? According to Dictionary.com a red herring could be any of the following:

• A smoked herring having a reddish color.
• Something that draws attention away from the central issue.
• A preliminary registration statement that must be filed with the SEC describing a new issue of stock (IPO) and the prospects of the issuing company.

If you were working in the investment industry you might realize it is a statement about an IPO, but if you didn't, you might think something else. Furthermore, you may feel you completely understand when you don't. This is one of those times to use active-listening techniques to clear up miscommunications.

Extremely excessive overuse of verbosity
Be brief. Say a lot with few words.

Summary

Now that you know the sources of ambiguity, do your best to avoid them.

Asking questions and getting answers

In the old days ya could just wack a guy and be done with it. Now everyone's feelings are involved.

That quote is from the movie Knockaround Guys. Not a great movie (it's quite bad actually) but an interesting quote from John Malkovich's character. When you look from the perspective of a business analyst, one of the most important things a business analyst can know is the answer to the question, "Why?"

• Why is this important?
• Why do you want this?
• Why? Why? Why? Why? Why?

Some individuals take offense to this sort of questioning. They misinterpret the question to be a challenge to their statements rather than the educational exercise it really is. Understanding "why" will basically allow you to determine whether you are going in the right direction. How does this requirement align with what the project is trying to accomplish?

To avoid receiving a chilly response to your "why" questions, you can do two things:

• Prep your client as to the purpose of the "why" questions. Explain that understanding the rationale will allow you grasp the essence of their desires.
• Word your questions to be non-threatening (e.g., cater for people's feelings.). As suggested in this post from Tyner Blain, use "what" and "how" questions to answer the "why" questions.

Ultimately, you are trying to foster a strong working relationship with your client. Understanding how to question them and get the answers you need in an open environment is paramount.

It's the little things... Words that should make your ears perk up

I was commenting on a post on Tyner Blain called Top five ways to be a better listener, when I saw a comment by Scott that stated, "reliable and fast can be completely ambiguous terms, because they mean different things to different people." I could not agree more.

I am not sure if you recall my earliest posts, but ambiguity is one of the biggest requirement pitfalls. You can refer to the following: Requirements & ambiguity, Bad Practices - Part I - Ambiguity and Bad Practices - Part IV - Speculative & Vague Terms to understand the consequences of a miscommunication.Then I got the not so brilliant idea to start up a list of simple words that can be viewed as ambiguous within the context of business requirements. This list is by no means exhaustive:

• Reliable (from Scott)
• Fast (also from Scott)
• User-friendly
• Flexible
• Easy-to-use
• Never
• Intuitive
• Future-proof

What do these terms actually mean? Anytime you hear one of these words be prepared to call for a time-out and clarify exactly what your client means.

Basically, if you hear qualitative statements from your clients, these are areas where you may need to clarify things using simple techniques such as active listening. This may sound like paranoia but remember it is much cheaper to clean up a miscommunication early in a project versus later in the system development life cycle.
There is a great post on Tyner Blain called How to interview when gathering requirements that I suggest you read as it will give you tips on how to extract the information you need.

Requirements & ambiguity

There is a great post on requirements defined called, "The art and science of disambiguation," that illustrates how easily it is for ambiguity to find its way into requirements. Even the most simple of statements can be misconstrued due to differences in perceptions of people.

That post fits well with my own post called Bad Practices - Part I - Ambiguity. Ways that you can counter ambiguity include:

1. Use active listening techniques to rephrase (in your own words) what you have heard back to the individual providing the information. If your client agrees, there is no ambiguity. If your client does not agree, you have the opportunity to eliminate any miscommunication and misconceptions by additional probing or questioning.
2. Use a common lexicon or establish a common context that can be used so that both you and your clients start on the same page. This may include avoiding the use of internal acronyms. Also, no jargon please.
3. Improve your listening skills. This post on Tyner Blain provides some tips.

Bad Practices - Part IV - Speculative & Vague Terms

On speculation
Avoid using generalizations and speculative words such as often, normally and typically. A requirement must not include any speculation at all.

On dictionary.com, a requirement is defined as, "Something that is required; a necessity." On Wikipedia, the definition is, "a singular documented need of what a particular product should be or do." The common theme is that requirements define needs. When defining a solution to a problem, speculation has no place. It is either do or do not, there is no maybe (or try, as Yoda in The Empire Strikes Back would say.)

On being vague
One common mistake that people make when taking down requirements is to use informal and unverifiable terms. What do the terms: user-friendly, flexible, easy-to-use, fast, and intuitive mean to you? Do you think these terms mean the same thing to someone else? Generally, no! So when different people see these types of terms, people will generate their own interpretations on what they mean. The net result is that the requirement is not clearly understood.

Look at the picture below. What do you see? Do you think other people may see something different than you? If two people can see the exact same picture but come up with different interpretations of it, what would make anyone think that people can read the same requirement and (because of subtle vageries) come up with the same understanding?

No jargon please

Another suggestion I have is to avoid using the jargon of the company one is working with. While understanding the jargon and nuances of a specific company shows some level of understanding, one must realize that jargon does not mean anything to people who are not familar with the company. If a company employs a lot of contractors to help with projects, using excessive jargon increases the learning curve.

Bad Practices - Part II - Multiple Requirements

One of the things I have frequently mentioned in my previous posts is that requirements must be stated as simple atomic statements. I have shown how this simple practice enables one to readily verify that requirements have been met. Another positive consequence of atomic requirements is that overall modularity and traceability is enhanced.

Sometimes when trying to state a requirement, one actually states 2 or more within the same sentence. This happens because when people talk and write people tend to use conjunctions such as and, or, with, and also. Conjunctions indicate areas where multiple requirements exist. What one needs to do is ascertain whether eliciting the items separately allows someone to understand better.

For example, one can state the following,

• Articulation 1 - "The screw must be 4.5 centimeters long and must be able to withstand a temperature of 500 degrees Celsius."

Consider another articulation of the same information,

• Articulation 2a - "The screw must be 4.5 centimeters long."
• Articulation 2b - "The screw must be able to withstand a temperature of 500 degrees Celsius."

Let's look at how the articulation of requirements impacts the ease of verifying, tracing and overall modularity of the body of work. Consider two common situations:

• One aspect is met but the other aspect cannot be met. - The screw is 4.5 centimeters long but cannot withstand 500 degrees Celsius.
• One of the requirements has been changed. - The temperature the screw needs to withstand has been reduced to 400 degrees Celsius but the 4.5 centimeters length is still required.

For articulation 1:

• Part of the requirement is met and part is not. So is it 50% met or does it fail completely? How does one measure this?
• All requirements linked to this one must be examined to ascertain the impact of the change. If there are 5 children requirements, all five must be checked.

For articulation 2:

• The first requirement is met and the second fails.
• Only the requirements that are children of the second one must be examined to determine if changes are needed.

In both cases, articulation 2 yields better results. Now, the problems with having non-atomic requirements are clear.

Bad Practices - Part I - Ambiguity

I have been focusing on good practices to employ when gathering and articulating requirements. For the next series of posts I will be discussing things to avoid. The first bad habit would be to introduce ambiguity to requirements.

Requirements are intended to further understanding. Great care must be undertaken to ensure that their meaning is understood. What happens when they are not clear?

One can say, "To maintain the ecological & environmental balance within the facilities, when using transportation services ensure the facilities remain in a locked-down state.” Alternatively, one can say, “When you enter & exit the building, close the door.” By using excessive language, the underlying meaning can be lost or misinterpreted.

If one has to go over a requirement three, four, five or more times; the requirement is most-likely unclear and ambiguous. Even worse, what if everyone thinks they understand but their interpretations are all different? What is the consequence of this to a project?

My tips for reducing ambiguity are:

1. Be brief. Revise. Rewrite. (Sounds familiar - See my post 3 simple rules for business writing.)
2. Try to view the requirements from the perspective of someone else.
3. Review with different users.

The acid test for understanding - Can someone who has no knowledge of my project understand what is going on by reading my requirements?

Good Requirements - Part III - Be Clear

If one is ambiguous and confusing when articulating requirements, there is almost no chance that an optimal solution can be reached. After all, the goal of requirements is to clearly articulate the needs of a system. If one does not have clear requirements, what exactly is being developed?

Being clear may sound easy to do but understand that people may interpret the same thing in different ways. Simple terms such as cold, hot, small, tall, fast and easy-to-use mean different things to different people. 10 degrees Celsius may be cold to one individual yet hot to another.

One may not even realize that a lack of clarity exists because everyone thinks they understand a statement perfectly. So how does one ensure that there are no misunderstandings?

1. Use exact terminology and language. Some examples of clear requirements are, "The screw must be 4.5" long," and, "The screw must be able to withstand 450 degrees Kelvin." Note how much more clear those two statements are than the following one, "The user interface must be user-friendly." What does user-friendly mean exactly?
2. Use short sentences and simple language. Writing requirements is not like writing prose. In fact, requirements do not even have to be complete sentences!
3. Hold informal and formal review sessions with the providers of the requirements and the recipients of the requirements (i.e., business & IT groups.) Go over all of the requirements, including the ones that look blatantly obvious.
4. Be anal! If there is even a remote chance that someone can misunderstand a requirement, they will!
5. Clear up any issues ASAP.

The goal is effective communication. This means no misconceptions, misrepresentations or misunderstandings.