I really love teaching. I guess that’s not surprising, given that I’m (at least) a fourth-generation teacher. This is a clip from the 1920 Wyoming Census. The first entry on this page, Gertrude Shaw, is my great-grandmother.
Widowed at 29 with three children to support, she taught in a one-room schoolhouse in Wyoming. Pretty cool, huh? But I digress…
One of the things I like best is hearing my about my students’ projects. Some of what I hear is amusing, some of it is encouraging, and occasionally, some of it is surprising.
I’m frequently surprised by my students’ comments about elicitation. Now, don’t shoot me for stereotyping…but I always think of BAs as people who are organized, methodical, and planned. As a general rule, I think that’s true. It’s pretty hard to survive as a BA if you’re not. So I find it interesting that a significant number of my students don’t actually make an elicitation plan. They call a meeting, pull a bunch of people together into a room, and start asking questions. Then they wonder why they’re so frustrated by the lack of progress made. I get all the war stories about arguments, conflicting agendas, and participants who get sidetracked and hijack the meeting.
I think they’re stuck in a rut. They’ve gotten in the habit of viewing meetings as the primary (or only) technique for requirements elicitation, and they don’t stop to think about their options. They also don’t think about their participants in enough detail. In other words – they don’t make an elicitation plan, they just dive in and try to get started.
Before you begin to elicit requirements on a project, you should think about three key things: determine what you need to know, where you can get that information, and what elicitation technique will work best.
1
Know What You Need to Know
Each elicitation session should have a specific objective. This is one of the differences between “eliciting” and “meeting”. Do you know what you need to learn during this session? The objective should be focused and well-defined, and everyone involved in the session should fully understand it.
By the way, having a discussion isn’t a goal. It’s a means to an end. If I’m reviewing your elicitation plan and it says your goal is to discuss something, I’m going to make you try again. Why are you having a discussion? What’s the desired outcome of the discussion? Are you making a decision, narrowing a list, proposing some alternatives, etc.? The desired outcome of the discussion can be a meeting objective, but you’re going to have to work hard to convince me that holding a discussion is a goal in and of itself.
Don’t try to learn too much in a single session — you and your elicitation partners will get overwhelmed. Interestingly, as I write this, I am part way through teaching a facilitation class. At the end of the day today, I asked the class to share one “lesson learned” for today’s session. Over half of them responded that they needed to be less optimistic about what they could get done in a given period of time, and that they needed to manage their time better.
2
Know Where You Can Get the Information
Information lives in lots of places – documents, systems, and of course, people’s heads. Where can you find the information you need?
Always remember that your SMEs are typically working on your project in addition to (not in place of) their “real” job. That means it’s important to use them wisely. Consider other ways that you may be able to obtain the information you need. Is there system documentation available? Training materials? Policy and procedure manuals? Contractual or regulatory write-ups? See what you can learn from these sources, and reduce the burden on your SMEs.
If you do need to involve human beings, choose your attendees carefully. Consider all the people who are available to you on your project, and identify which one(s) would be key for reaching your session objective. It’s a common mistake to invite all the project participants to every elicitation session. My rule of thumb for sessions is to make sure I have everyone I need, and nobody that I don’t.
3
Know Your Elicitation Technique Options
Version 3.0 of the BABOK® recognizes 18 different methods for elicitation, up from 11 in v2.0. I’ve grouped them here to make them easier to review:
Research-Based Techniques
- Benchmarking & Market Analysis
- Document Analysis
- Data Mining
- Surveys & Questionnaires
Collaborative Techniques
- Observation
- Interviews
- Focus Groups
- Brainstorming
- Requirements Workshops
- Collaborative Games
Visualization Techniques
- Business Rules Analysis
- Data Modeling
- Mind Mapping
- Process Modeling
- Concept Modeling
- Interface Analysis
- Process Analysis
- Prototyping
That’s quite a list! So am I saying that you should use all of these techniques on each of your projects? No, of course not. They’re tools you should have in your toolkit. As a BA, you should know the strengths and weaknesses of each of these approaches. When you need to plan for a project, you can intelligently select appropriate technique(s).
If you take a close look at the differences between the elicitation techniques listed in versions 2.0 and 3.0 of the BABOK®, you’ll see that a number of “analysis” techniques now appear. Even though version 3.0 has been in place for a long time now, I wanted to point that out, because I think it makes an interesting point. Elicitation is an integral part of what we do in almost every aspect of our work as an analyst.
- Clarifying scope? Gonna have to elicit some information.
- Creating a business case? Gonna have to elicit some information.
- Stocking the backlog? Gonna have to elicit some information.
- Prototyping a screen? Gonna have to….see the pattern here?
Elicitation is wrapped around almost everything we do. Listing various analysis tools as elicitation tools really highlights the fact that they can be used to do both analysis and elicitation. That’s because the act of trying to create, analyze, and finalize a model exposes gaps in our understanding, and naturally drives elicitation of information. I love the fact that these tools serve a double purpose, and can help us be really efficient in our knowledge gathering efforts.
Parting Thoughts
I challenge each of you to take a moment and think the next time your finger is poised to send out a meeting notice. Have you picked the right people? Do you (and they) know the purpose of your session in detail? Have you planned a technique or combination of techniques that are well-suited for eliciting the necessary information? If not, take a moment, climb out of your elicitation rut, and build a better plan. Need some help? Take a peek at our Facilitated Session Template. It will help you think through all of these things before you click “Send”.
Elicitation Felicitations!
–K.
Editor’s Note: This blog post was has been previously published by B2T on our previous website. Due to its popularity, Kathy has updated its content to be more comprehensive and accurate for the state of today’s environment.
Kathy Claycomb
Managing Partner, Lead Expert
Kathy Claycomb brings over 35 years of experience to the classroom. She has participated in all phases of solution development using everything from agile to waterfall methodologies (and quite a few in between). Before joining B2T, her career spanned roles from application developer to Senior Director of Services at various organizations. Kathy has broad industry background including transportation, manufacturing, insurance, energy, healthcare, and banking.
Kathy’s first love is teaching, and throughout her career she has always managed to spend a portion of her time instructing. She has an engaging, highly interactive teaching style that ensures students leave the course with a thorough grasp of the material. Her students consistently praise her teaching abilities and her talent for drawing on her personal experience to enhance their learning.
Kathy served as the Technical Editor for Business Analysis for Dummies, 2nd Edition.
