6 Basic Techniques for Successful Software Requirements Elicitation with Remote International Customers

In this global environment, there is rarely a project we work on that doesn’t have some set of customer users in a remote location, inevitably overseas. While we are typically eliciting requirements in English, we are always faced with ESL customers. So here are a few tips I shared with my team this week as we prepped for such a session with users in China.

1. Communicate their value. Help them understand how important they are to the success of your project. After all, you couldn't possibly understand their business needs as well as they do – with differences in business practices, culture, and preferences.
2. Talk slow. This should be obvious, but it always happens that we talk much too fast, so slow it down. Be very thankful they are willing to talk back to you in English! So whatever you need to do to remind yourself frequently through the discussion to talk slow, do it. Ideas I have include a post-it on the corner of your screen or a co-worker sitting beside you to remind you frequently.
3. Eyes in the room. Have someone in the room, if at all possible, to facilitate the discussion. If you cannot hear or clearly understand a comment (this often happens with large rooms of people and a speaker phone), that person can sit beside the phone and repeat it. Have a communication tool such as Instant Messenger open on a computer that isn’t projecting, so that person can communicate with you about body language – to tell you if you are going too fast or if people in the room look lost.
4. Visual is important. I like to prepare powerpoint slides with small bits of information on each slide pertaining to what we are talking about. So perhaps a screen shot or mock-up with a few features list on a slide. Diagrams and visual models are also extremely helpful.
5. Send materials ahead. As important as visual materials are, they are ten times more useful if you send them ahead. I know I have a better time reading foreign languages than I do hearing them, and this is the case for most. So if you send the materials ahead, they will have a chance to read them and more likely follow along with you during the discussion.
6. Open questions, not closed. Depending on the culture, some people are hesitant to ask questions or tell you something negative. So be sure to ask open ended questions. Instead of “are there any questions?” you would ask “what questions do you have?” – because we know they have some. Then call on people by name to ask what questions they have. Ask their leader what questions he/she has. If they say they are ok with you are presenting for requirements, then you really should ask “What are you concerned about?” or “What have we not captured that you need to have?” or “What are you not ok with” instead of “Is this ok?”.

Mission Elicitation - Phone Meetings

The site is security restricted, there are subject matter experts in other buildings, and the developers are in another country. Your mission, should you choose to accept it, is to gather the requirements for a gap analysis of your clients software implementation. Your meeting will self destruct in 3 days. You have a phone, a scribe, and a computer to complete your task, good luck.

I have a feeling that most meetings like this fail to meet their real goal, identifying the majority of gaps. A major implementation that requires gaps to be identified often have one big kickoff meeting where you were able to get all the important people to free their schedules. Of course, they couldn't be all in one place, so you have to meet over the phone. This can be disastrous. Not only does everyone over the phone lose context around presentations and discussions, but the people forget who is on either side of the phone. White boarding turns into phone charades. Scribes miss out on who said what. To-Dos are lost in the background noise.

Okay. Take a moment and breath deep. Think of pleasant things, like pre-existing documentation, SMEs that agree on the existing and future business processes, and meeting notes that make sense when you go back to read them.

Relaxed now? Alright, lets make sure we prevent as much of this as possible. There are several steps to mitigate as much trouble as possible. If at all possible, get a tablet pc for the meeting. If that is not going to happen, make sure you have access to a process mapping tool such as Visio. Secondly, make sure you have an online collaboration tool such as Go-To-Meeting, WebEx, or MS Live Meeting. If you don't have one of these tools, get a trial or find an open source (read: free) solution. The ones I mentioned would be ideal since your client will most likely have them already installed which means that there is less of a chance that the first 15 minutes of your meeting will be people discussing which button someone should have clicked instead during the install. Finally, find a scribe. If you do not have someone on your team who can help you, you might have to ask a participant to help you scribe while you try to facilitate and elicit.

Alright, you have your basic tools. First order of business, send out the meeting invite. Don't make this the standard meeting invite you see everywhere else, subject line and no description. Make sure that you include the objective of the meeting and the rough agenda. Step two, make sure everyone is introduced over the phone. Always good to go over who is in attendance and the role they are playing in the meeting. While introducing everyone, it is wise to have the meeting objective and agenda displayed on your projector and online screen sharing tool of choice. Make sure that you are located close to the phone so that you can repeat what was asked or stated and by whom.

While the meeting is going on, be sure to bring up a notepad or word doc on the screen to jot down any action items that come up. Be sure to write down who owns the task and their contact information if you do not already have it. Just having the task title isn't a nice thing to come back to and try to figure out, so add some context. Simply writing down "Get everyone's buy-in" is tempting, but please include the people involved in 'everyone and on what document/process the buy-in is needed on. At the end of each day, send out your notes to all the participants along with the list of to-dos to the owners. You might have to keep track of the to-dos and make sure their owners complete them.

When a white boarding session strikes, pull out your tablet pen or Visio program and start tossing up a copy so that everyone is involved. Much easier than describing which line connects to which box that resembles something more of a rhombus. Doing this will allow for the people over the phone to quickly understand the topic being discussed and add in their knowledge to the debate. True kudos if you are actually able to secure or setup a webcam that will allow you to broadcast the white boarding, removing the lost in translation possibilities.

These are just some basic pointers to holding elicitation meetings over the phone that can save headaches and money for your project. Do you have any phone elicitation pointers or standard operating procedures?

Live from RESFQ: Lessons Learned from Open Source Requirements Efforts

Paula presented a paper by her and Jane Cleland-Huang of DePaul University titled “Lessons Learned from Open Source Projects Facilitating Online Requirements Processes”. The idea behind her paper was to suggest that forums and wiki-style tools might be used to collect and prioritize requirements across a large volume of stakeholders. She looked at forums used in vendor-based open source software projects for this purpose, with the idea that the lessons learned good be applied to any type of distributed project.

Some of her observations about what is needed to make forums successful for this:

• Features need to be organized or grouped in some way so it’s not just a massive list of many feature requests. This would allow users to participate in discussions similar to the feature they are interested in.
• There needs to be high visibility on the status of feature requests so users understand if it’s low priority, not in discussion, or not looked at yet. This helps them understand what to expect.
• Analysts need to stay actively involved in the conversations with stakeholders and not let it be a passive process.

These things have something in common – they are all things you need to do in a typical requirements elicitation process too. I think that perhaps there are some things we can do to adapt this to large distributed teams contributing to the requirements, but it will by no means be an easy task. I think most importantly, you have to keep the community aspect of requirements gathering and not let it just be a text-based one-way conversation.

A 2-year old can do this

I was driving somewhere with my 2-year old daugther the other day when she started asking me questions. More specifically, she asked me one question, "Why are their no clouds today?" I quickly gave an answer, and (those of you with kids know where I'm going with this) she proceeded to follow up every answer I gave with, "Why?" It forced me to really get to the root of what we were talking about (and recognize the limits of my knowledge of cloud formation. :) However, I also realized that a 2-year old would make a great Business Analyst! One of the fundamental rules of elicitation is to ask "why?" Keep asking "why" to get to the bottom of whatever topic you are discussing with a SME, and you'll almost always find out what the real issue is. In addition, you will gain a deeper understanding of the topic being discussed. So if you ever find yourself at a loss for words when eliciting requirements, just remember to act like a 2-year old.

Just Call Me "Grumpy"

I've been called a lot of things in my time, most of which I don't care to repeat here (OK, OK ... some people have called me nice things). I like to think of myself as a nice guy who has a good sense of humor, but I'm acutely aware of the fact that I can often be a grump, or a grumpus, or just plain grumpy. And while being grumpy doesn't always help get things accomplished, there are times when it can be an effective tool.

For example, this week I was part of a discussion about terminology. Well, at the beginning I was a part of the discussion ... and then the debate started to go in circles. The group was talking about the subject, but we weren't making any progress. As I like to say, we were spending a lot of time and energy working in a circle, but we weren't making any forward progress. So, I took a back seat. And then I got tired of riding in the back seat and put on my grumpy hat.

I sent a message that effectively said "jeez, quit talking about it -- pick a solution, explain it, and move forward using it consistently." Was it the best way to approach the situation? Was it even a good way to approach it? You could certainly argue either way, and I'd probably agree with either answer. What I found, though, is that my grumpy reply may have been just the thing that the team needed to get back on track.

I've found that teams often get off track by trying to find the answer, rather than an acceptable answer. People often call the situation "analysis paralysis" or "going down a rabbit hole" on a topic. The fact that we have so many terms to describe the condition suggests just how common it is. And in these situations, I prefer to take an approach that I've heard called "satisficing" -- finding a solution that's good enough. And in our business, we usually don't have enough information to pick the answer, but we have enough to be directionally correct and keep moving in a productive way.

Some might refer to this approach as simply lobbing a hand grenade into the fray and then watching things blow up. And sometimes it might turn out that way -- so I don't recommend this approach in all situations. However, when your team is stuck and doesn't recognize it, the time might be right for a grumpy interjection. Just make sure that your grump is a relatively gentle jolt, not a hand grenade.

After all, it'll help wake up Sleepy, it might pull Bashful out of his shell, it'll make Happy happy, and if anything goes wrong, you can always call Doc.