Mastering the Techniques for Business Analysis: An Insider’s View

34539 Views
8 Comments
17 Likes

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?

Mastering the Techniques for Business Analysis: An Insider’s ViewWhile 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:

  •  Go beyond the scope outlined for techniques in the guide

  •  Develop expertise in techniques not described in the BABOK

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.”
 

Like this article:
  17 members liked this article
34539 Views
8 Comments
17 Likes

COMMENTS

ajmarkos posted on Thursday, May 24, 2012 9:38 AM
Hi:

Good article, but, regarding Swimlanes and BPMN:

Business systems are complex. Handling complexity requires effective decomposition. That is a decomposition that is logical and natural. Swimlanes, unfortunately, are a classic example of what is referred to as a forced, artifical partitioning. If one, for example, trys to create a data flow diagram of a significant part of a business partitioned by department (i.e., sales, purchasing, recieving, etc., etc.), the result is going to by a "rats nest" of interface complexity. So much so that the model is not useable. With Swimlanes, this interface "rats nest" is, of course, not formally captured in the model. But, as the real need in process related requirements elicitation is not so much to document the standalone processes, but to capture the interrelationships between them, our efforts become largely inefficient and ineffective.

BPMN, meanwhile, is sequence based. Unfortunately, systems, especailly complex business systems at higher levels of abstraction are very NON sequential. It is not possible to model a non sequential system using a sequence based technique.

Tony
wstolting posted on Thursday, June 28, 2012 2:21 PM
Minor typo; the T in SWOT is a threat not a treat. Interesting typo!

Enjoyed the article.
adrian posted on Friday, June 29, 2012 12:04 AM
Type fixed... :-)
dwwright99 posted on Monday, July 2, 2012 6:23 PM
Hmmm,... I fully understand when people tell me how they want something to work, but I don't believe in letting them have their piece and then questioning what they said to get to "what" not "how".

You see, some people see requirements as asking people what they want, but it isn't; that is an open ended question, and even if people can describe it, you can't be sure you got all the requirements.... and, of course, the question is often met with blank stares...

But if you ask people what they do, what is done, and what info they need to get it done, everyone will be ready to tell you that. Information Systems exist to make work easier, faster, more accurate, so defining the work is the key requirement. Get that, and the functional requirements can be derived from it.... I know I have probably added this comment to many articles, and hope it has been helpful to anyone who reads it.... I just find I have to keep making this comment, wondering when it will no longer be needed.... anyway, end of rant...
sanil posted on Wednesday, July 4, 2012 6:18 AM
Hi , I must say this is an excellent article! Great work ! But, can you give me an example of how to differentiate the how from the what ? I am still not 100% clear of the differentiation between the how and the what scenarios in the practical scenarios.

Thanks
Sanil

sgjohann posted on Thursday, July 5, 2012 10:46 AM
Sure. "How" is often represented by stakeholders by stating design details. How they want the solution to look. In a discussion stakeholders may begin by describing in great detail how a report interface should look, so they are describing the layout of the report. My point is that in an elicitation we need to understand the business reasons for such requests, such as the report needs to enable me to drill down into data to specific levels in order to answer key business questions. So we need to understand "what" they are trying to do with the data to help them answer business questions more efficiently. At this level we need to communicate to the implementation SME's what stakeholders are trying to accomplish with the solution, in other words describing "what" the stakeholders need to accomplish and not tell them "how" to design the solution. Those are choices/decisions the implementation SME's will make during the design phase.
sanil posted on Thursday, July 5, 2012 10:56 AM
Wonderful ! That makes it very clear . Thank you so much :)
sas81 posted on Tuesday, August 27, 2013 5:33 AM
This is a great article. Thank you for sharing your experience!! I could totally co-relate with all the examples and try to adopt similar solutions. For me the third example is especially helpful and I am going to try five whys in stakeholder interactions.
Only registered users may post comments.




Latest Articles

What’s Missing from Agile?
Oct 20, 2019
0 Comments
John Seddon launches an attack on the value of Agile as practiced and charts a better way to analyse and design for improvement, making information te...

Copyright 2006-2019 by Modern Analyst Media LLC