To that point, I’d like to refer you to one of my all-time favorite articles on customer interviews by Esther Derby. Below, I expand on a few of her key points on how to prepare for and frame an interview.

1. Have an objective for the interview.

Why do you need to interview the stakeholder? What do you need to get from the meeting? At what level of detail? In my experience, stakeholder interviews have been most productive for myself and, I think, for the interviewee when we have a clear objective in mind at the outset of the meeting.

Once you’ve answered those questions for yourself, it is critical that you share your objective(s) with your interviewee. When you invite the interviewee, tell them what you hope to get out of the meeting. When you begin the meeting, make sure to reiterate those objectives.

Per Derby, “Articulating a research objective sets the stage for a successful interview. A wandering, unfocused interaction will yield paltry results and frustrate the customer.”

2. Think of what questions you’d like to ask.

Again, according to Derby: “Once you have an objective, brainstorm a list of questions you might ask related to the topic. Then organize the questions into themes and arrange them to flow from general to specific and familiar to unfamiliar. The process of preparing questions help to identify key topic areas to cover.”

I’ve adopted my own way of doing this where I just open up a new word document, and start typing - it begins as a stream of consciousness/brainstorming-type exercise. Don’t pay attention to the order or flow of the questions at first. That’s the benefit of doing it electronically - you can always cut, paste, and reformat once you’ve exhausted yourself of ideas. Before finishing the exercise, I will sort the questions and categorize them.

3. During the interview, use prepared questions as a guide, not a script.

You may or may not want to even bring a physical list of questions to the interview. If you use an approach similar to mine for brainstorming and sorting questions, you may find that by the time you’ve gone through that process you’re familiar enough with the questions and the general gist of what you want to get out of the interview that you don’t need the printed list.

In fact, if you think having the list of questions in front of you might cause you to rely on it, it’s best not to bring it. We don’t want our progression of questions to be too constrained. To be a successful interviewer it is important to be sensitive to the flow of the conversation so you can adapt the line of questioning accordingly. This is something that may seem tough at first, but gets easier with practice.

Whether you have your questions in front of you or not, flexibility is the key. During the course of the interview you may need to ask certain questions at a different time or in a different way. Some interviewees are easier than others to keep on track. However, I find that as long as the discussion tracks well to the meeting objective and is flowing well, I’m in good shape.

In fact, I often I find that if I’m able to get the customer talking about the problem and the product, I can parse a fair number of requirements out of straight, ordinary dialog that may have otherwise been hard to “extract” by just happening upon the right question. You may miss those requirements if you’re just ticking down a pre-fab checklist of questions.

4. Know your “tools”.

There are lots of different ways to frame questions that elicit different types of responses. For example, open-ended questions are much better than closed (i.e. “yes or no”) questions at drawing out quantities of information and getting the interviewee to talk. Other times you will just want the straight yes or no.

And, of course, my favorite all time question when it comes to getting to the root causes of business problems and their objectives, is the simple - “why?” - repeated as needed.

And finally -

There is much more that can be said about the various types of questions, the types of responses they elicit, and in what situations they’re most useful. My original reason for this post, though, was to share a reference; not to write my own book on the subject. So, I’ll refer you to Derby’s article for lots more information on these and other types of questions that are useful in framing a discussion and drawing out specific types of information.

I bookmarked the article quite a while back - probably 2 or 3 years ago - and I still refer back to it from time to time for my own benefit, and to share as a primer for new business analysts that are looking to hone their elicitation skills.

What are some guidelines to successful interviews that you’ve come across in your experience? For that matter, what are some of your favorite articles on the basics of business analysis? I’d be glad to hear about either or both!

Copyright JonathanBabcock.com. View the original post or comment on

Preparing Questions for a Great Customer Interview

Jim Highsmith, in the book Agile project management : creating innovative products, thinks that the reason projects tend to have so much documentation and so few results is that:

[T]here is a fundamental flaw in many people’s understanding of documentation—documentation is not a substitute for interaction. When a customer and a developer interact to jointly develop specifications and produce some form of permanent record (documents, notes, sketches, feature cards, drawings), the documentation is a by-product of the interaction. When the customer sits down with a product manager and they write a requirements document that gets sent to a development group, then the document has become a substitute for interaction. In the first scenario, the documentation may be valuable to the development team. In the second, it has become a barricade to progress. Little knowledge is either gained or transferred. Furthermore, as interaction decreases, the volume of documentation often increases in a fruitless attempt to compensate.

Highsmith, James A. Agile project management : creating innovative products. : Addison-Wesley Professional , 2004.

I especially appreciate the point that no knowledge is transferred when “sending a document” takes the place of actual interaction. And it especially hits close to home as one of the key functions of the business analyst is to facilitate the transfer of knowledge. How successful can we truly expect to be by substituting thick documents for actual dialog?

I think I can safely say that my most successful projects (and best spec docs) have been jointly owned among business and technology stakeholders with me there – not to pass out completed documents, but to help elicit requirements and facilitate dialog.

Thanks for the insight, Jim. Good stuff.

Copyright JonathanBabcock.com. View the original post or comment on

Documentation is No Substitute for Interaction

We’ve all been there. You don’t agree at all with a decision being made, but you fear that you are in the minority - if not the only one - in disagreement. Instead of prolonging debate, and risking raising the ire of others in the group, you concede. Instead of expressing your true thoughts on the matter, you feign agreement without consideration for the future consequences of not speaking up.

A few months ago, while in a business analyst training course, I learned about an interesting phenomenon called the “Abilene Paradox.” The paradox was introduced by management expert Jerry B. Harvey and is illustrated by the parable below that is supposedly based on a personal experience of his.

On a hot afternoon visiting in Coleman, Texas, the family is comfortably playing dominoes on a porch, until the father-in-law suggests that they take a trip to Abilene [53 miles north] for dinner. The wife says, “Sounds like a great idea.” The husband, despite having reservations because the drive is long and hot, thinks that his preferences must be out-of-step with the group and says, “Sounds good to me. I just hope your mother wants to go.” The mother-in-law then says, “Of course I want to go. I haven’t been to Abilene in a long time.”

The drive is hot, dusty, and long. When they arrive at the cafeteria, the food is as bad. They arrive back home four hours later, exhausted.

One of them dishonestly says, “It was a great trip, wasn’t it.” The mother-in-law says that, actually, she would rather have stayed home, but went along since the other three were so enthusiastic. The husband says, “I wasn’t delighted to be doing what we were doing. I only went to satisfy the rest of you.” The wife says, “I just went along to keep you happy. I would have had to be crazy to want to go out in the heat like that.” The father-in-law then says that he only suggested it because he thought the others might be bored.

The group sits back, perplexed that they together decided to take a trip which none of them wanted. They each would have preferred to sit comfortably, but did not admit to it when they still had time to enjoy the afternoon.

Harvey, Jerry B. (Summer 1974). “The Abilene Paradox and other Meditations on Management”. Organizational Dynamics .

There’s also a great video version of the parable that also includes the paradox in some business scenarios - you can look at a preview, here.

The heart of Harvey’s message, in my view, may be summed up in the following points:

1. While the benefit of coming to decisions as a group is that more points of view will filter out the weakest options, groups sometimes reach incorrect decisions because of false consensus.
2. People will go along with what they perceive to be “the crowd” even if, in reality, there is no “crowd.”
3. People tend to have an impression - either warranted or unwarranted - that there will be repercussions to speaking out against ideas with which they don’t agree.
4. If we acknowledge that the paradox exists, we can be more conscious of it, and strive to avoid it.

So, there’s the Abilene Paradox. Have you ever failed to express your opposing viewpoint when your thoughts that ran contrary to what you considered to be the popular opinion? I know I have. No one wants to be perceived as contrarian. What if no one speaks up and the results - which could have been averted - are disastrous?

There are lots of layers to this paradox. First, it is management’s job to foster an environment where people are comfortable expressing their views, and challenging the perceived status quo. Second, it is incumbent on the various role players within an organization to take a true ownership stake in the success of the company. This means having the courage to speak your mind, when appropriate. Third, when you do have courage and an environment that is friendly to free-flow of ideas and opinions, you have to be careful to take the paradox too far in the other direction. We all know people who look for every opportunity to disagree on every matter, no matter how minute. No one wants to be that guy.

So, how does all of this apply to the business analyst?

Because business analyst’s are facilitators of knowledge transfer, and need honest assessments from all stakeholders, we need to manage the way we elicit requirements and facilitate project meetings with the paradox in mind. Here are just a few ideas:

1. If no one seems to be challenging ideas that come from the top, go ahead and play the devil’s advocate. As a BA, it is our job to ask questions and challenge assumptions to get to the true stakeholder need.
2. If some participants in elicitation sessions are too quiet, or appear to be “yes man” prototypes, then schedule one-on-one sessions with those individuals. Even if all participants have read all about the Abilene Paradox, it will still be difficult for some to speak up.
3. Get it right on the front-end. I am speaking specifically about projects, here. Sometimes a project’s business sponsor will want to implement a simple solution - and think they need to try to solve world hunger while he/she is at it. In many cases, no one will speak up and tell the sponsor otherwise. If you have the opportunity to work with the sponsor during the project’s inception, help them make sure that the business case is solid. Remind them that the goal is to address specific business needs (that you will help them identify) - and not world hunger. The quicker these discussions are held, the better.

Now, I am sure there are lots of other good ideas, but as I look up I remind myself that I set out this evening to write a quick blog post, not a book. What are your thoughts on the Abilene Paradox? Have you seen its effects? What are some other ways of averting the paradox? As always, I’ll look forward to your comments.

In case you’re interested, here are some additional links on the Abilene Paradox:

• Revisiting the Abilene Paradox: Is Management of Agreement Still an Issue? by Kathryn J. Deiss discusses ways we can know we are “headed for Abilene,” describes sources of the paradox and how to “break the cycle of wrong assumptions and fear.”
• Abilene Paradox, Wikepedia.
• 12Manage.com provides a description of the paradox and 6 characteristics of groups failing to reach decisions effectively.

Copyright JonathanBabcock.com. View the original post or comment on

Business Analysts and the Abilene Paradox

The intent isn’t to be particularly humorous, but as I read it, I couldn’t help but remember that funny “this is what she says, but THIS is what she means” e-mail poking fun at male-female communication. Now, I’ve never met Chris, but having read through this list, I’d almost swear we must have worked on the same projects with some of the same people!

Here are a few of my favorites:

It should work: this usually means that it doesn’t. It also means that it was probably not tested properly as the result is current[ly] undetermined. The word “should” should be taken out every developer’s vocabulary - it either does or it doesn’t.

Almost done: this is also a weasel word. When a developer tells you things are “almost done” ask for the specific tasks that are left over immediately. In addition, keep in mind that projects do not progress linearly - the last 10% is always about 40-50% of the work of the total project. I’ve seen projects that are chronically late be “almost done” for 3 months.

If things go smoothly: this I hear a lot, e.g. if we don’t hit any snags then we can be done by Friday. Guess what - you’re likelihood of hitting a “snag” by next Friday is probably high and given the lack of risk based management, the team has probably got no mitigation or contingency strategy. Then next week, you’ll hear the next phrase in our list, “Yes, it could have been done if it weren’t for that Snag we had”.

We’ll make up the time at the end: if you’re already late by the end of requirements, you’re likely going to be even later by the end if you simply keep going on the same track. In my experience, teams don’t dramatically faster as they hit their stride. Even if there is some efficiency, its nowhere enough to make up for lost time.

It Worked on my Machine!: programmers use this excuse to downplay a bug. The reality is actually the opposite - it means that you have an intermittent bug which is by far the worst kind of bug to have in your application. You want bugs to fail quickly and consistently - any variant such as “That’s Weird”, “That didn’t happen yesterday”, “That must be a data problem”, etc. is admitting you have a bug that cannot be easily duplicated.

Some of those are simply classic. If I had a dollar for every time….

To be fair, even though the title of the post is, “Developer Weasel Words”, I think a few of these may apply to BA’s and PM’s as well. I can think of one Business Analyst in particular that seems to love the “if things go smoothly” one, but I certainly wouldn’t want to name names. I’ll just say, “touché” and leave it at that.

Anyway, check out the actual post for the complete list as well as Chris’s recommendations that managers can use to reduce the occurrence - in essence, the need - for these types of “creative answers”. Great post, Chris!

Copyright JonathanBabcock.com. View the original post or comment on

You Know It’s Getting Deep When..

Weaknesses of e-mail communication:

• Effectiveness is solely dependent on receiving party’s dilligence in checking for messages. “But I e-mailed you the document last week, didn’t you get it?” Ever heard that or similar comments? E-mail is great as a form of follow-up communication, and possibly primary communication if you know for certain that the recipient checks their e-mail account regularly. However, you’re really taking your chances if you’re relying on an e-mailed message as the sole communication of a message of any importance.
• A close friend of mine recently mentioned that she was concerned as to whether an individual was going to show up for the engagement to which they’d been invited and agreed to attend several weeks ago. On the afternoon before the event, my friend sent out a follow-up e-mail and was panicked when she didn’t hear back 10 minutes later. It wasn’t until she finally realized it was useless sitting around waiting on an e-mail that may never come. She made a 2 minute phone call, confirmed the appointment and went on her merry way.

• It’s easier to ignore an e-mail than it is spoken conversation. E-mail makes it very easy to “tune out” messages that you just don’t feel like dealing with at present. A fair portion of e-mail is completely ignored. If you really need to get a message across, and need to be sure that it is received, pay a visit or pick up the phone.

• E-mail “conversations” often require days of back-and-forth whereas only a few spoken minutes would probably achieve at least as good a result. Despite its speed of delivery, you’re best off not attempting to use e-mail as a mean of real-time communication. If it can be covered via a phone conversation in a quick manner, don’t hold up the works by trying to carry out conversations requiring lots of back-and-forth interaction via e-mail. If you want to make sure that your conversation is documented and associated with a time, send out a quick e-mail summary of the conversation.

• Lacks the personal touch of spoken or face-to-face communication. Emoticons (i.e. “Smileys”) just aren’t de rigeur for business interaction (thank goodness). I’ve occasionally found my attempts to convey personality and perhaps a touch of humor are lost on the e-mail recipient. The drier the humor, the greater the chance that your one-liner will bomb. In a professional context, e-mail is great for communicating brief, informative messages but unless you try writing a full-length piece of e-mail literature (and even if you do), you likely won’t achieve the personal touch you want to convey.

• Potentially higher security risk or anauthorized disclosure of private information. Quick and easy? Yes. Private? Not so much. There are certainly privacy concerns in using e-mail as a corporate communications medium. Per Princeton University’s e-mail policy; “Often, pieces of confidential information find their way into a piece of e-mail with the sender giving such information little thought.” Of course there are ways of mitigating security risks through technology and policy, and, to be fair, no means of communication is 100% secure. Just bear in mind when e-mailing that the advantage of having a “paper” trail can also be a disadvantage.

• Trying to keep up e-mail can be a distraction. When you really need to get work done, it’s best to take communication offline.

Bottom line; much has been written on business e-mail etiquette, and this article is not meant to be exhaustive but simply to share some of my findings regarding e-mail use in a professional context from over the years.

As always, I’d love to complete the picture with your comments and feedback.

Copyright JonathanBabcock.com. View the original post or comment on

Weaknesses of E-mail Communication

This post is the first of a small series of writings on effective use of e-mail in a business environment. In the near future, I’ll explore the inherent risks and weaknesses associated with e-mail communication.

Below is a summary of some of the strong points of e-mail communication, with some emphasis on its use in the context of business communication.

Strengths of e-mail communication:

• Provides timestamped proof of an interaction. E-mail works well in that it provides the equivalent of a sales receipt for communication. It covers exactly what was said along with a time reference.

• Easy to archive for future recall. Most worthwhile e-mail applications provide searchability that can provide you with all your pertinent e-mail - often even sortable according to conversation threads - in return for a few entered key words.

• Contains details of correspondence. No need to rely on memory for facts of interaction. E-mail is great in that it allows access to useful information long after memory of it has faded. My policy (for better or worse, and this is debatable) is to never delete project-related e-mail because you just never know when you may need to recall its contents.

• Lower risk of making errant or embarrassing comments (putting one’s foot in one’s mouth). With e-mail, your communication can be edited and rephrased as much as is desired before it can be read by the recipient. One potential negative of this “strength” of using e-mail is that I’ve known individuals who consider themselves less gifted in verbal communication, or who don’t want to delivery a difficult message verbally rely on e-mail as a crutch to avoid a face-to-face or a phone call. I’ve probably even been in that boat once or twice myself. Mike Shaffner also points out that we ought to take a cue from Lincoln and avoid sending out that dreadful nasty-gram, as much as you may want to at the moment.

• E-mail is inexpensive. It allows you to send a message to a large number of recipients simultaneously for much less than traditional postal rates, and often much less than making a quick phone call.

As always, I welcome any additional advantages or different takes on the advantages of e-mail communication that readers may have. Feel free to comment below.

Copyright JonathanBabcock.com. View the original post or comment on

Advantages of E-mail Communication