Many people view decision making as a tool in your toolbox; I view it as your role. Nothing happens without decisions. You can talk, talk, talk all you want and sound really smart, but who cares if a decision is not made and things don’t progress, right?! This scenario leads to an issue we all know well as analysis paralysis.
In the past, the role of a business analysis professional was primarily based around being the bridge, the translator and/or the documenter. Today, I see the role of business analysis professionals more as a facilitator, solution designer and trusted advisor. Where there used to be a formal requirements document, now there might just be a whiteboard (that gets erased…eek, overcome the panic!). However, the techniques, activities, processes and skills should not define what business analysis is. To use a common analogy all these things are the “What” of business analysis. But the list changes as techniques come and go, new stuff comes in…old stuff leaves. The “Why” of business analysis, which never changes, is to help teams make decisions that move the project forward.
In the IIBA BABOK® there is an underlying competency required of BA professionals called Decision Making. This competency area is defined as “providing a description of the behaviors, characteristics, knowledge and personal qualities that support the practice of business analysis.” However, I say the Decision Making competency doesn’t support what you do as a business analysis professional, it is what you do as a business analysis professional. Specifically, decision making should be viewed not as something that supports your work, but rather as the inverse – your analysis techniques and processes should support making decisions.
Let’s see…how can I explain this better? One of your main responsibilities as a BA is to help others make better decisions and to make decisions yourself. Think about your work. How do you decide on what tasks to do first on a given day? We all know that there is not enough time to do everything you want to accomplish; therefore, decisions have to be made on a daily basis of what activities you should or should not focus on. These decisions should be based on a balance of the work yielding the highest impact and the work that is most important to your stakeholders. But first, you need to know what is most important to your stakeholders and also, the related impact of that task. To do this, use supporting techniques and processes to help in your determination. Examples include problem and business outcome definition, Impact Mapping and Root Cause Analysis. These tools help to make your decisions; decision making does not support them.
Throughout a project there are many activities that support decision making. One of the key reasons for doing stakeholder analysis is to determine who the decision makers are and how they make decisions. Everyone does not agree on the top priority needs for the project so understanding who makes the final decision is critical. If you can’t get a group to decide on the best path, this key decision maker has to make the call so the project can move forward. The absence of a decision maker means that the risk of project failure increases. Now, take that a step further – once you know who the decision makers are on a project, you need to know their speed in decision making and what information they’ll need to make a decision. How do you find this out? Ask them. To help narrow down the speed of decision makers, put people into two buckets. The first bucket is for the person that does not want any information until the last responsible moment, and then they want it all. They have the ability to take in this information and make a decision fairly quickly. The other bucket is for those that want information over time. Even if the information is changing they like to get it so they can swirl it around in their head for longer periods of time. Then when they need to make a decision, they feel comfortable making the call. If you approach either one in the opposite way they will get frustrated. Stakeholder analysis supports decision making!
Elicitation is another activity that completely supports decision making. What? Elicitation is about drawing out information. Yes, that is true, but who cares if you draw out information and leave it there. The point really is to draw out information to help make decisions. Sometimes I think brainstorming is the most misunderstood activity because it commonly gets viewed as just a way to quickly come up with ideas, but there is so much more to brainstorming. After coming up with great ideas you have to finish things off by making decisions on how to move forward; like ordering features or stories in terms of importance. The beauty of brainstorming is that it allows for the best chance of buy-in. By having everyone share their thoughts and ideas openly, they are more likely to buy-in to a decision that moves the project forward. Their idea doesn’t have to be chosen, they just need to know their idea was heard by the group. (I wrote a blog post about buy-in if you want more information.)
The last technique I want to hit on today is importance of prototyping – the activity of drawing pictures of a system interface to help your stakeholder make decisions on how they want to interact with a system. Have multiple pictures and play the eye doctor role, do you like it better like this or like this…one….or two. This also helps the development team decide on the best ways to design the system or features.
Start thinking of all the analysis techniques and processes as supporting tools to facilitate decision making. Having this mindset will allow you to make decisions on what is most important. If the activity you are about to take on helps the team come to a good decision faster…do it.
I have decided that I have said enough!
More on Decision Making
- #AskAnAnalyst Podcast Episode 26: Are BAs Becoming Obsolete? - February 28, 2017
- #AskAnAnalyst Podcast Episode 25: State of Agile - February 7, 2017
- #AskAnAnalyst Podcast Episode 24: An Agile Mindset - January 27, 2017
- A Monthly Guide to Becoming a Better Business Analysis Professional - January 11, 2017
- #AskAnAnalyst Podcast Episode 22: Business Analysis in 2017 - January 10, 2017
- #AskAnAnalyst Podcast Episode 21: Business Analysis in 2016 - December 8, 2016
- #AskAnAnalyst Podcast Episode 20: Effectively Give and Receive Feedback - November 15, 2016
- #AskAnAnalyst Podcast Episode 19: Live from #BBCCon - November 3, 2016
- #AskAnAnalyst Podcast Episode 18: More Business Analysis Basics - October 4, 2016
- #AskAnAnalyst Podcast Episode 17: Back to Business Analysis Basics - September 13, 2016