Author: Carl Miller

(Courtesy of the School of Hard Knocks)

Numerous studies on the failure of IT projects has indicated that the lack of user involvement as one of the leading contributors. As Business Analysts we realize it is not only the quantity of involvement but also the quality of that involvement. Good questioning techniques allow Business Analysts to constructed the required models from which requirements are elicited.

One of the most frequently asked questions by new (and not so new) Business Analysts is about questioning techniques and what questions to ask. Here, in David Letterman style, is my top ten.

10. Be prepared. 

We ask questions to elicit information that allow us to construct and validate models. So make a list of questions:

• Where do you sit in the organization (org model)
• What are your inputs / outputs?
• Can you give me an example of them?
• What are the volumes
• What is the quality of inputs /of outputs? (i.e. what is the metric)
• What is the flow of work

These are at the information level i.e. getting the facts, figures, information. Being prepared will help completeness. With the information gathered, could you construct the models desired?

9. Ask open ended questions

Open ended questions i.e. what is the toughest part of your job? This allows people to as we say ‘walk in with their stuff’. It allows them to bring up what is important to them. .

• allow them to walk in with their stuff
• allow them to identify their issues
• don’t give them leading questions

Sometimes this unearths significant problems. True sometimes open ended questions lead down rat holes. My view? The user will talk about them or at least have their concern colouring their answers. Better to get them out on the table, deal with them and move on.

8. Follow the lead of the interviewee without giving up control

• You control the interview
• You do that by blending your agenda to their style
• It’s not a battle of styles – reflect the interviewee style
• Follow the lead of the interviewee but be prepared to re-direct as required
• The purpose of the interview is for you to get the info you need

7. Draw a picture…in pencil

• It’s an iterative process …let it be that
• Build models and let the user alter them
• Stretch and direct the users thinking

(thinking now of data flow…thinking now about inputs/outputs, thinking now about quality metrics) 

6. Talk to the consumer of your analysis document

• You are the liaison between the business and IT
• Are the consumers getting what they need to do their job?
• How do you know they are?
• There are standard modeling techniques derived for good reasons – use them
• Be part of making them even better – we are always in transition

5. Ask probing questions

• Why is it so important to you?
• What keeps you up at night?
• If you could change three things about the process what would they be?
• Make them think not just give you facts and process flows
• These are higher level questions than information gathering

4. Use active listening to ensure understanding

• Make sure you understand in a way the interviewee intends
• Ask clarifying questions
• Ask for examples
• Paraphrase and then ask ‘Did I get that right?’

Make sure you get a confident confirmation before continuing, otherwise try again until you do get it right from the user’s perspective. 

3. Talk to the horse as well as the trainer

• Everyone has a view of the problem
• All views are valid from their own point of view
• One point of contact is efficient but can you get everything you need?
• Ask questions they know the answer rather than questions they would have to speculate on the answer.

An executive is unlikely to give accurate process flow but may well know the intent. The reverse is true of the front line workers. 

2. Ask questions to validate answers

• Ask the same question in different ways and to different people
• look for metrics
• look for established methods and procedures to validate
• resolve discrepancies – when issues are in question attempt to resolve
• at the very least identify the discrepancy

It is a common error to assume we know more than we do, When we ask a question to which we already know the answer very quickly we learn otherwise and begin to validate information.

1. You are a leader in your organization

• You represent the interests of the business unit
• You match business needs to requirements
• You specify the requirements which satisfy a business objectives/achieve business goals and represent the executive level intent.

• If you do not represent the needs and interests of the project and executive intent who will?
  

Don’t forget to leave your comments below.