Tag: Elicitation

Since April, I’ve been writing a series of articles for this website about the basic competencies of business analysis. I’ve been doing this for a couple of reasons. First, I enjoy staring at my computer for hours on end and thinking about grammar. Secondly, and more importantly, the enormous influx of available information over the last several years has caused many business analysts to lose track of the core, basic principles of this vital discipline.

So far, I’ve written three articles, which have covered understanding your organization’s overall goals, creating a common vocabulary among your team and identifying the sources from which you’ll extract requirements. For my fourth article, I’ll be covering elicitation techniques.

A Pre-Elicitation Meeting
In articles like this, writers often make things seem easier than they actually are. Therefore, let me caution that there are a number of complications inherent to elicitation. For starters, your customers and stakeholders, with all due respect, likely won’t understand the process that you’re taking them through. Furthermore, because each stakeholder is most interested in his or her individual needs, that individual will be less conscious of the many interdependencies that exist between requirements. To combat this, it’s a good idea to look back at the stakeholder categories you’ve developed (see the third article in this series), sit down with the groups-either virtually or in real life-and walk them through your goals and expectations regarding elicitation. This is an excellent time to establish individual roles and to let them know that you’ll be coming back to them soon, when it’s time to talk validation.

Four Elicitation Opportunities
I recently saw an infomercial for a machine that sorts change.  Simply dump your bucket of mixed-up coins in and it organizes them all into neat, coherent little piles.  I immediately thought of business analysis-particularly requirements elicitation.

Say a client comes to you and says, “Let’s build a rocket!” Immediately after determining that this client is sane, you’d find yourself with a big bucket of mixed-up questions and ideas. What color will the rocket be? Where is a good place to buy rocket fuel? How far into space should the rocket go? Do rocket scientists get paid by the hour? As a business analyst, it’s your job to use the practices we’ve already discussed and requirements elicitation to sort all of those random questions and ideas into neat little piles of requirements that can be used to meet your ultimate goal. Here are four opportunities for elicitation and a look at some of the techniques to consider for each:

1. Enterprise Analysis
Enterprise analysis can help you develop a vision for your potential product or solution. Staying with our rocket-building theme, it’s where you’ll begin to get a sense of what your rocket is going to need to be able to do. Two useful techniques at this stage are brainstorming and surveys. When dealing with a group of experts, brainstorming sessions are effective because the group will have an inherent understanding of logistics and the reality of the situation. Conversely, if you’re dealing with a group of, say, non-rocket scientists, consider conducting surveys. This will help to limit tangents and hone ideas based on the questions you choose to include.

2. Requirements Definition
When defining your requirements, consider joint application design (JAD) sessions. Like brainstorming sessions, JADs work best when dealing with a group of stakeholders who have a high level of subject matter expertise. However, unlike brainstorming sessions, they may run for days at a time and follow very specific agendas. A detailed agenda lets you ensure that all uncertainties are unearthed and that no miscommunications occur.

3. Requirements Analysis and Documentation
Here, as you begin to go deeper into determining the needs and conditions required to build your rocket, analysis becomes vital-as in gap analysis, root-cause analysis and force-field analysis. Gap analysis enables you to identify the “gap” between where you are and where you want to be. Root-cause analysis, which is perfect for the neurotic among us, considers all of our problems and identifies the “root causes” of those problems. And, force-field analysis, which derives from the social sciences, identifies the “forces” that influence progress toward a goal-both positive and negative.

4. Solution Assessment and Validation
With your solution and its requirements in sight, it’s essential to circle back to your stakeholders for validation. As obvious as this may sound, startlingly often, business analysts fail to ensure the validity of the requirements that they’ve elicited. Multi-voting and prototyping will help you build consensus and demonstrate how your solution will materialize, going forward. Criteria-based grids and impact/effort grids are effective, too, as they weigh requirements against formal criteria and rank them in terms of importance and feasibility. 

Next Time – Choosing the Best Modeling Technique
Tune in next month for article number five of five. In this, the exciting series finale, we’ll bring all of the back-to-basics practices together and close out with a discussion of modeling techniques.

---

Glenn R. Brûlé, Director of Client Solutions at ESI, has more than 18 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. These engagements focus on understanding, diagnosing and providing workable business solutions to complex problems across various industries. Glenn was formerly a Director at Large for the International Institute of Business Analysis (IIBA) where he was responsible for forming local chapters of the IIBA around the world.