I was recently working with a client who said that the life of a BA in his organization is complicated, primarily because very few people really understand what Business Analysts (BAs) do. I have felt for a very long time that perhaps our most compelling challenge is to change the organizational view of our role as primarily “requirements collectors” and to help stakeholders see the true value that business analysis brings to the enterprise. To address this issue as a BA practitioner, I try to keep the following questions top of mind as I practice the art of business analysis:
-
How can I add more value to the work I produce?
-
How can I create context on the output of BA tasks that I perform?
-
How do I place the correct amount of emphasis/importance/concern etc. to the issues that I uncover when communicating to stakeholders?
-
How do I best call out key issues that cannot be ignored as the pace of work output increases?
-
What can I do to create the right amount of attention among stakeholders when I uncover a problem or opportunity that is significant?
While considering these questions think about this: The key to providing the value that these questions demand lies in effectively using business analysis techniques to produce powerful, purposeful and creative output on the tasks we perform as business analysts.
Before further investigation of techniques for business analysis, it is necessary to differentiate between “tasks” BAs perform and “techniques” we use to produce our output. The BABOK describes a task as “an essential piece of work that MUST be performed as part of business analysis. Each task should be performed at least once during the vast majority of business analysis initiatives, but there is no upper limit to the number of times any task may be performed.” The IIBA describes 26 tasks across six Knowledge Areas in version 2.0 of the BABOK guide. This outlines a complete best-practices approach to performing the role of business analyst in the workplace.
This then begs the following question: What is the relationship between tasks and techniques when conducting business analysis? BAs use techniques to provide context when producing task outputs, and the application of a specific technique(s) may “alter the way a business analysis task is performed.” Therefore the output of a task may differ depending on the techniques used to develop work performed in a task. There is a (0…*) relationship between techniques and tasks; i.e., a task may have zero, one or many related techniques.
The IIBA states that the 34 techniques described in chapter nine, v. 2.0, of the BABOK guide* are a beginning point, and BAs need to understand that, if the situation dictates, it will be necessary to:
I interpret this to mean that BAs must be creative in application of techniques to tasks and be willing and able to bend, twist, combine etc. techniques if the situation encountered calls for such action. The reason I point to techniques as a vehicle to prove value to other stakeholders is because they create a common link for better understanding. Many of the techniques outlined in the BABOK guide are familiar to other business and technical stakeholders. They are familiar with these techniques because they use them to produce their own work outputs. A few examples of widely understood techniques from chapter nine include SWOT Analysis, Cost Benefit Analysis, Root Cause Analysis, Benchmarking, Brainstorming, Problem Tracking, Risk Analysis, Lesson Learned debriefs and Vendor Assessment. The key point I am making is that anytime you can put your work into a context that is easy to understand and relate to, you will create an opportunity to create buy-in and influence people. There is nothing more powerful than for a BA to be perceived as a key influencer in the organization because the work they have produced is of high value and is easy to understand.
The BABOK guide, in chapter 9, provides good general descriptions of 34 techniques that are widely applied across the tasks BAs produce, so there is no reason to go into general descriptions in this article. I would rather isolate a few of these techniques and demonstrate how I try to bend, twist and combine techniques to produce creative and powerful output to tasks to add dimension and understandability for stakeholders.
-
My first example to isolate and describe is SWOT Analysis. Typically a SWOT analysis is produced to assess the strengths and weaknesses (internally driven) and opportunities and threats (external to the organization) of initiatives that BAs evaluate as part of Enterprise Analysis activities. A SWOT Analysis in this context is produced as a group brainstorming activity to encourage stakeholders to discuss problems and opportunities from four perspectives. It is powerful because this technique ensures that the group will produce balanced information about the issues under investigation. Another approach to using the SWOT Analysis technique is to produce a “silent SWOT” for meetings you attend where important issues are under investigation. During the meeting, instead of taking notes, draw out four quadrants on a single piece of paper and label each quadrant with an S, W, O and T. As you take notes, classify the information from the perspective of Strength, Weakness, Opportunity or Threat. By compartmentalizing issues under discussion, two things will immediately happen: You will understand the issues better, and you will ask much better questions because they will drive from one or more of the four perspectives. This twist on the SWOT technique has been so helpful to me that it has become my primary note-taking method for meetings I attend. I ask better questions, take fewer notes (and therefore spend more time “actively listening” to the issues) and come away with a better understanding of the issues under discussion.
-
Process Models, particularly horizontal swim lanes, are a very powerful way to help stakeholders visualize ideas, processes, concepts etc. during both Enterprise Analysis and Requirements Analysis activities. However, too often the models we build are so complex that they are rendered ineffective because very few people can understand them. We try to read and interpret them and get lost in the complexity of the model!
My answer to this problem is to keep swim lanes at a high level of abstraction to provide a “mile-high view” of the information I wish to present. Second, I build models behind the high-level model to bring out the complexity incrementally and only to those stakeholders who wish to drive deeper into specific areas of the high-level model. My method is to start with the highest level of abstraction I can possibly produce in a vertical swim lane to create the “big picture” view. I can then break down the more complicated pieces of the model with models behind the first model. What I like best about this approach is that I have flexibility to use multiple modeling techniques to best represent my information—perhaps a UML state-transition diagram behind the high-level diagram of a process to show how a potential system may change states in one area of the process. If I try to represent this all in my swim lane it becomes very complicated and hard to understand. However, if I show the changing state of the system as a separate diagram, it becomes much easier for stakeholders to visualize and understand. We can then have a meaningful discussion and actually confirm that our approach is correct. Another example is to represent error routines and minor deviations as separate and simple process diagrams behind the “big picture” swim lane. This approach helps to cut down on the detail presented in the big picture view and ensures that stakeholders see and confirm what you want them to see first and then consider the alternative possibilities later in the discussion.
-
The last example I wish to provide involves, in my experience, one of the most difficult issues we face as business analysts. When we conduct elicitations to gather business and stakeholder requirements, we are asking our stakeholder subjects to describe what they seek from the solutions we create and build. However, business stakeholders often lead in to these discussions by describing how they would like the solutions to be built; in other words, they design the solution for us without telling what they are trying to accomplish. This is particularly dangerous at this level because it is simply putting the cart before the horse. The danger is that we end up with large gaps in the solutions we deliver, and stakeholders end up dissatisfied with the solution because it does not meet their true needs. BAs often respond by stating that the stakeholders were never able to describe what they wanted from the solution and because of time constraints they were forced to move ahead with poorly formed outcomes. Sound familiar?
My response to this common issue is to recommend that BAs need to be prepared for this problem with a technique that can help business stakeholders better articulate their needs. So here is what I do—I allow the stakeholder to fully describe their needs from the how perspective, and when they are through I ask a very simple question: Why do you want it designed that way? I then keep applying the “Five Whys” technique to get to the root cause of what they want from the solution until we are both satisfied that what is needed is fully formed.
The key to this approach is to understand that stakeholders lead in with how statements because it is easier for them to communicate their needs from the design perspective. If you shut them down by stopping them and trying to redirect them into describing what they need, they often get frustrated and shut down the communication. It is more efficient for you to let them go down the “how trail” and then redirect them with this variation of the “Five Whys” technique. Try it—you will be very happy with the results from your elicitations, and the positive relationships you develop with business stakeholders will make your job much easier.
The creative application of techniques to tasks will facilitate a change in the organizational view of the role of Business Analyst from that of “misunderstood project stakeholder” to “partner/consultant” to the enterprise. Stakeholders remember techniques and the individuals that make effective use of them. Mastering techniques for business analysis will change the perception of BAs from “requirements collectors” to stakeholders who can help the business solve problems and create opportunities that are aligned to the core values and strategic objectives of the organization.
Author: Stephen Johann, Founder and Principal, Evolve, LLC
With over 15 years experience in Business Analysis, Mr. Johann has over worked with a wide range of commercial and government industry sectors. Mr. Johann currently focuses on Business Analysis for Business Intelligence solutions for several clients through his Business Analysis consulting practice and is an Instructor for Learning Tree International, teaching the entire Business Analysis Curriculum.
* Note: The BABOK describes 34 techniques for business analysis in chapter nine. These techniques are widely applied to many tasks in the six Knowledge Areas outlined in the guide. There are an additional 15 techniques described and associated to only one task each in the BABOK guide. These singular techniques are only recommended for use when working in that specific task (an example of this is the RACI Matrix, which is a technique used to describe which stakeholders are Responsible, Accountable, Consulted and Informed; in other words, it describes the roles of those involved in business analysis activities). This technique is only applied when BAs are working in the task, “Conduct Stakeholder Analysis.”