Business Analysis Training – Elicitation Technique: Focus Groups

Elicitation Technique: Focus Groups

When it comes to discovering subjective information for your requirements, a Focus Group can be a great technique to use. In a previous post, I mentioned the use of Brainstorming as an Elicitation technique. The key difference between a Brainstorming session and a Focus Group is the type of information that they can be used to gather. In general, a Focus Group is use to gather subjective information. Use Focus Groups to find out your stakeholders’ attitudes, feelings, and beliefs about your solution. For this blog entry, I want to look at the ways in which you can use a Focus Group to help you with your elicitation activities.

The first thing you need to do is plan. If you want your Focus Group to be effective, you need to have a good plan in place. The first thing you might want to consider is the composition of your Focus Group. When you’re recruiting participants, think about the difference between a homogeneous group and a heterogeneous group. A homogeneous group includes individuals with similar characteristics and backgrounds. This makes it difficult to get differing perspectives. A heterogeneous group, on the other hand, includes individuals with differing characteristics and backgrounds. This might make getting information difficult if people from different groups are not comfortable sharing. Choose your participants thoughtfully to be sure to get the best results from your session.

Next, assign a good moderator/facilitator and a good recorder/scribe. Please keep in mind that is does not need to be the Business Analyst who does this. It can be; however, there might be good reasons for not performing these roles. In that case, the Business Analyst can be an observer in the session and can gather some nonverbal cues from the participants.

After deciding these things, you should create a discussion guide. This document will be used to ensure that all of the content is covered in a structured and consistent way. Be sure to include questions that will elicit the attitudes and beliefs about your solution—and ensure that your focus group stays on task.

Finally, schedule your locations, participants, and equipment for your session. Keep in mind that you may not necessarily need a physical location. You can effectively conduct a focus group in either a physical location or in a virtual location (or in some combination of both).

When it’s time to conduct your Focus Group, be sure to follow the discussion guide. This will keep the session on track and ensure that you get the results that you want. Also, during the session, you need to capture all of the comments and, if possible, the nonverbal cues. Capturing this data is an absolute necessity, so the use of a talented recorder/scribe is very important.

Once the Focus Group is finished, you need to spend some time reviewing the data. During this review, you should look for themes. Try to determine what was most common among the participants’ comments and feedback. Then, synthesize that data into a comprehensive report that is used for your requirements efforts. It’s also helpful to share your findings with the original participants to make sure that nothing is misrepresented.

Focus Groups can be great to use for eliciting subjective data about your solutions. Oftentimes, the attitudes and beliefs of your stakeholders can be just as meaningful as the more objective requirements like functional and non-functional requirements. Consider using Focus Groups during your future business analysis activities!

Business Analysis Training – Elicitation Technique: Brainstorming

Elicitation Technique: Brainstorming

Brainstorming is a great technique for accomplishing a variety of Business Analysis activities. Frequently, it is used as a way to elicit requirements from stakeholders. What makes Brainstorming so useful is that it promotes divergent thinking by harnessing the power of group creativity. The hallmark of Brainstorming is that a large quantity of ideas is generated; however, the quality of those ideas is not addressed during the brainstorming session—wild ideas are even encouraged! Although it has become a bit of a cliché, it is true: it’s far easier to tame a wild idea than it is to invigorate a lame idea.

There are several different ways in which to conduct a Brainstorming session. First, many business analysts will use Individual Brainstorming to come up with creative solutions. While this does not really take advantage of group creativity, it is a great way to start. Many Brainstorming sessions could benefit by having the participants each do a little bit of individual brainstorming before the actual session. This can be a helpful way to encourage participation from all of the participants. When individuals are given an opportunity to think about a topic for a bit in advance, they might be less intimidated to then contribute their ideas to the group.

Of course, the whole idea of Brainstorming is to use that creative power of the group. As such, the most common way in which to conduct a Brainstorming session is to get a group of people together to focus on a particular topic. Provided the team dynamics are good, ideas can be quickly called out to the group. A good scribe is a necessity in these sessions to ensure that ALL of the ideas are captured. A good facilitator (not necessarily the business analyst) is also a necessity to ensure that no one starts to evaluate ideas during the session; instead, the facilitator should continue to encourage new ideas and to build on ideas that were already suggested.

In order to ensure a successful Brainstorming session, it is valuable to conduct some pre-work. First, Brainstorming sessions work best when they are focused on a single objective. Be sure to clearly define what the session should be about. This will enable the participants to remain focused on that objective. Second, there should be a time limit on the session (but not a limit on the number of ideas!). While there is no ideal duration for a Brainstorming session (it depends on the scope and the number of participants), they usually last between five minutes and two hours. Be sure that your time limit reflects the scope of your sessions.

Third, you want to make sure that you have the right people in the session. Group dynamics are very important for a successful Brainstorming session. When choosing your participants, try to find those people who will contribute most to the session. Ideally, you want to find people who could be, literally, jumping out of their seats to participate. When this kind of group is not possible (or if your participants are somewhat reluctant to talk in a group session), you might have to modify your session to get their participation. In that case, use index cards or sticky notes. Have each participant continue to write down ideas individually and submit them to the facilitator to be called out. Several rounds of this can be as beneficial as the traditional Brainstorming session.

Once the Brainstorming session is finished, there is still work to be done! The business analyst needs to now look at how to evaluate the ideas that came out of the session. This could be done with the group or individually. Discuss and evaluate the ideas. Condense similar ideas. Rate all of the ideas. As the end of this evaluation process, be sure to distribute the results to all of the participants.

Brainstorming sessions are a great way to elicit a lot of ideas and encourage group thinking. As part of a longer meeting or workshop, they can also help reduce tension and change the tone of the meeting. Consider using a Brainstorming session as part of your future business analysis activities!

Business Analysis Training – Elicitation

Elicitation

In the world of Business Analysis, the value of elicitation cannot be underestimated. Elicitation is the process by which Business Analysts gather requirements from their stakeholders. While this is often done in an ad hoc manner, it does not need to be. According to the International Institute of Business Analysis (IIBA), there are four discreet steps that can be followed to effectively elicit requirements. IIBA calls these steps, “Tasks.”

The first task is “Prepare for Elicitation.” Think of this task as the planning step in the elicitation efforts. During this step, a Business Analysts needs to figure out all of the things that need to be done in an elicitation session–before the session actually happens. For example, the Business Analyst needs to have a thorough understanding of the Business Need, the Business Case, the Solution Scope, and the Stakeholders. With that in mind, the Business Analyst needs to select the best technique(s) to use for the elicitation session. Some common techniques include Brainstorming, Focus Groups, Interviews, Observation, Requirements Workshops, and Surveys/Questionnaires. (Please keep in mind that each of these elicitation techniques has its own unique preparation requirements, too!) At the end of the preparation, the Business Analyst should have two things: First, all of the resources (think of the people, places, and things) that are necessary for the elicitation activity should be scheduled. Second, all of the supporting materials (think of whiteboards, flip charts, etc.) should be collected.

The second task is “Conduct Elicitation Activity.” This is when the Business Analyst actually has the elicitation session with the stakeholders. This could be a brainstorming session, a focus group, etc. (Again, please keep in mind that each elicitation techniques has its own unique way of being conducted, too!) During the session, the Business Analyst (or an assigned Scribe) needs to document all of the requirements that come up. Oftentimes, there are attributes (e.g., the source, the risks, the priority, etc.) that also need to be documented with the requirements, and traceability should be considered for each requirement. At the end of the session, the Business Analyst should have a good collection of requirements as the result of the activity.

The third task is the lonely task: “Document Elicitation Results.” During this task, the Business Analyst goes back to work independently on bringing order to chaos. At the end of the elicitation session, the Business Analyst leaves with quite a collection of notes, whiteboards, flip charts, video/audio recordings, etc. All of this content needs to be transferred to a better format. Ultimately, the Business Analyst should start documenting the requirements in a format that will be easy for the solution designers to understand. Upon conclusion of this task, the Business Analyst will have two things: First, all the requirements should be in a format that can be easily understood. Second, if any concerns came up during the elicitation sessions, those should also be documented in a problem tracking database or in an issue log.

The final task is, sadly, often skipped. The Business Analyst must go back to the stakeholders and “Confirm Elicitation Results.” During this task, the Business Analysts needs to ask the stakeholders if the requirements have been accurately represented. This is a very important step in the elicitation process because it ensures that each requirement is represented as the stakeholder wanted. Once the Business Analyst has this confirmation, the requirements are considered “confirmed.” This enables the Business Analyst to move on to additional analysis of the requirements (e.g., prioritization, organization, modeling, verification, validation, etc.).

Now that we have an understanding of the four-step process, we should be able to do a much better job in our elicitation efforts. In upcoming blog entries, we’ll go over the techniques that we can use for elicitation.

Project Management Training – Scope

Scope

In Project Management Training programs (as well as in Business Analysis Training programs), the term Scope is bandied about quite frequently. People who have been involved with projects for a long time have a good sense of what the term means; however, it can be somewhat confusing to people who are new to projects. The reason for the confusion is that there are a few different meaning to the term scope.

The first meaning is Product Scope. This refers to all of the features, functions, and attributes of the product that is actually being built as part of the project. This is sometimes also called Solution Scope because you might not be creating a product, but a service or some other result from the project. The Product/Solution Scope is one of the first things that must be defined on a project. It describes what the end result of the project will be. Many times, it is the Business Analyst who defines the Product/Solution Scope.

The second meaning is Project Scope. This refers to all of the work that must be done to actually create the product/solution of the project. Once you know your product/solution scope, you need to create a list of all of the actual activities that will be required to create it. The project scope describes how the end result will be created. It is the job of the Project Manager to define the Project Scope.

Think of it this way: The Product/Solution Scope is the WHAT of your project. What will the end result be? The Project Scope is the HOW of your project. How are you going to create the end result?

Here is a simple example: Imagine that you are on a project to create a new Web site. The Web site (and all of its features, functions, and attributes) is WHAT you’re going to create. Now, you need to decide HOW to create it by defining specific activities, like designing the screens, writing the code, and testing the site in various browsers. Those activities make up the Project Scope.

Product Scope and Project Scope are both important aspects of any project. They are different from each other, yet closely related. You can’t have one without the other.

Business Analysis Training – Use Case Diagrams – Part III

Use Case Diagrams – Part III

In a previous blog, I walked us through the process of creating a simple Use Case Diagram based on the requirement for a Content Management System for my martial art organization (AmerROSS). Here was that requirement:

Requirement A.1

The Content Management System (CMS) will allow an administrator to create a new blog account, provided the personal details of the new blogger are verified using the AmerROSS Member Database.

Here’s what the Use Case Diagram looked like:

In addition to the Use Case Diagram, we also created the Use Case Narrative. In this blog entry, let’s build on this Use Case Diagram with additional requirements and other relationship types. Let’s add another requirement that is related to the first requirement and add it to the diagram:

Requirement A.2

The Content Management System will allow an administrator to create a new personal Wiki, provided the personal details of the applying author are verified using the AmerROSS Member Database.

Here’s what the new Use Case Diagram would look like:

As I am sure you remember from the previous blog entry, we also need a narrative for this Use Case Diagram. Here is what it might look like:

Have you noticed the repetition in the two Use Cases? They both have to check credentials! Instead of repeating this over and over again for as many Use Cases as we might come up with, we could just create a new Use Case that can be used by the others. Let’s add another Use Case called “Check Identity.”

That new Use Case needs to be connected to the Author Credential Database (and the prior associations deleted).  And we need a special way to connect our other two Use Cases to this one. That requires an <<include>> stereotype. Let’s add those two now…

To show the <<include>> relationship in your Use Case narrative, you need to remove the redundant steps from the Create a new Blog Account and Create new Personal Wiki Use Case narratives and instead use the Included Cases field and include::<use case name> syntax to indicate the use case where the reused steps reside.

Now you can create a use case description for the reusable steps within the Check Identity use case.

Finally, you might also want to extend your Use Cases to another Use Case if a certain event occurred. For example, you could extend your two Uses Cases with a new Use Case called “Record Application Failure” and draw two <<extend>> associations FROM the new Use Case.

So, there you have it! We have updated our Use Case Diagram with two special types of relationships (include and extend). Coming up in a future blog entry, we’ll continue our study of UML Diagrams with the Activity Diagram.

P.S. – For those of you who are curious, these diagrams were created using Poseidon for UML Community Edition 8.0. Support the community: http://www.gentleware.com/.