This week, Heather Mylan-Mains and I teamed up for a follow-up on our last episode, Back to Business Analysis Basics. I wanted to get Heather’s opinion first on what she considers business analysis basics and then explain why each is important to the business analysis skill set.
Episode 18 | October 4, 2016 Business Analysis Podcast Transcript
Kupe: Hello all of you BA and tech fans out there. David or Jacqueline are not on this call today, so you have two guest hosts today, with me, Kupe, and I’m glad to be back with the #AskAnaAnalyst show we’ve been doing on Technology Expresso Cafe for some months now. We’re up to episode 18. I am thrilled to introduce you guys to our other guest host, and that is Heather Mylan-Mains. She is a BA leader out there. There’s no one more passionate more dedicated, more focused around this discipline/profession — whatever you want to call business analysis. Heather is out there doing the work every day as a consultant, and she also teaches at my company, B2TTraining. Welcome Heather!
Heather: Kupe, I’m thrilled to be here. Thanks for that heart-whelming introduction. I do have a lot of passion about this profession, this group of skills that makes up the complex business analysis landscape. Lots of great things when you talk about the basics, so I’m thrilled to be here.
Kupe: Awesome. Heather is coming to us all the way from Des Moines, Iowa. We are both on-location, or remote. I’m here in Decatur, Georgia, Heather is in the Des Moines area, and we are talking today about getting back to the basics. Jacqueline and I started a couple weeks ago. We started the first session around the idea of “back to the basics.” There are just some things, when it comes to analysis and the stuff that we do, that is core no matter what project team you’re on or what methodology you’re using, whether it’s the deepest depths of waterfall to the most agile of agile teams.
There are basics when it comes to analysis, and there are things that have to happen. Jacqueline and I talked a lot last time about scoping efforts to make sure people get on the same page with what the goals and objectives are. We also talked about team and individual interactions. I brought it up 2 weeks ago that interactions is probably a newer basic than some other things, especially with the way teams are being formed in companies and organizations today, where you need to focus on how you interact with other individuals and as a team. Before I let Heather chime in, and Heather is going to be doing a lot of the talking today, which is the reason I invited her to the show, so that you guys can hear her insight on what she feels are the basics of business analysis.
Heather, I talked a little bit about what our basics were, what Jacqueline and I talked about. What do you think? What are some of the things that are the basics for you?
Heather: It was a great show. I loved the conversation between you and Jacqueline and what you shared. I want to echo some of things you shared as far as the scope concept. The concept of scope and context in particular is so important as a basic. I’m a big fan of jigsaw puzzles, and to me, there’s only one way to put together a jigsaw puzzle: you do the outline first. Find the edge pieces, understand the size of your puzzle, understand pieces of focus you might start with while in the process of getting it done, but that edge is so critical. That’s the same concept with our projects.
What is the scope of what we need to accomplish? Too many teams skip that element of understanding requirement scope. Project management, typically speaking, has got the project scope, and there’s an element of that that’s important, but when we talk about the analysis-space, it’s critical that we start at the basics of context otherwise we will find ourselves diving into rabbit holes and getting lost in details that aren’t creating the most value for our teams.
I think one of the basic concepts is, in the last show you mentioned that it’s finding the problem, and that’s definitely one. Also, the context we’re going to be working in, the outline we’re going to use to solve that problem is a huge basic concept. I find teams skip that, and people go right into fulfilling the orders the team is giving them. We miss the opportunity to guide conversations and to actually break down our features, and more specifically, our context. That, to me, are the basics. I appreciated hearing that the problem is part of that context as well as what our goals and objectives are. That’s all part of that scope.
There’s a great technique, and you know I’m a big fan of this technique. I call it my business analysis superhero power. Because I’m in the consulting area, opportunity is this context-diagramming, and there are several flavors of it. A context diagram is a very simple scope technique that is such a mind-blowing visual when people see it and know what it represents. It’s a way for any team to quickly get a viewpoint of the inner and external agents and interactions that create the interface. That guides the scope and the context of what you’re doing. You can then break down your features, but you would be surprised, Kupe, and I’m interested to hear what you think about this. How many people don’t know about this technique? Are you finding that people don’t know it, too?
Kupe: Well, yeah. It’s funny you ask that because I was going to ask you a question based on something you told me a couple of years ago, now. You were speaking at a conference about this superhero technique, and you asked the 200-300 people in the audience about how many of them used the context diagram. How many people raised their hand? Do you remember?
Heather: I think it was less than a third of the room. It was like, wow. You’re practicing business analysis but you’re missing this opportunity to create value by simplifying the context. Blew my mind.
Kupe: I don’t know what the answer is. When you look around at all of the companies we teach at, a lot of people will say, “This is something we don’t do. Somebody else does it.” That might be a reason why they don’t raise their hand in that context, no pun intended. Even if you don’t do it, you have to understand what a good one looks at so that you can validate that, “We do have the right boundary.” I love your analogy with the puzzle. It’s like, “We do have the edges, and now we know where to focus.”
Some people might be like, “We’re not about scoping but we allow scope to come into our project,” and that’s great. Then the agilist might be too tight on the boundary. That’s fine. You still need to understand, when you get a story, if it fits into what we are trying to go after. If no and if it’s still an important story, then let’s see if we can go from a 1000-piece puzzle to a 1500-piece puzzle. We’re now going to expand our boundary, but it at least gives you that anchor. It gives you something to talk about and to use to be able to tell: do we bother with this thing or do we not, and how deep do we go with it?
Heather: You’re absolutely right. One of the basic value propositions of a business analysis or the business analysis skill set, profession, whatever your title is, it’s the concept of getting a conversation started. You’re right, that the context can change, and that’s ok. We allow for that, but it needs to be a conscious decision that one, it is changing and two, the impact of the change if we go from one size puzzle to a bigger or smaller size puzzle. We have to know what that means in the value chain of our work. How do I know where to focus?
I think one of the main frustrations of teams is this swirl. You feel like it’s so big that you don’t know what to do. You don’t know how to get started, and it’s too overwhelming. Well, a trained, skilled person with analysis says, “Alright. Let’s take this monster, let’s wrangle it together, let’s get an idea of where it starts and then start talking about what we want to do with it.” That context diagram technique is a simple technique in theory and in practice, and it can be applied in so many ways.
That’s why I do consider it my superhero skill set, because as a consultant, I go into organizations where I am so not the subject matter expert. Sometimes I’m working in industries that I only understand on the periphery, and within a few conversations, I can model out their business, concepts of a project, and quickly have enough of an understanding to start helping guide that conversation. So, everyone should do it.
Kupe: Yeah. I’m sorry I didn’t add ‘superhero’ to your bio when I introduced you. Next time I will make sure to say ‘superhero BA.’ This is a total aside, but I was in Minneapolis a few weeks ago, and last year when they had their professional development, their theme was superheroes. A friend of mine was wearing a cape, and he said, “This is from last year’s session.”
Heather: Yeah, and I was there.
Kupe: Ok, good.
Heather: I shared a different take on this superhero role, and I did a fun presentation about the business analysis Jedi master. That fit well with the superhero theme. It was so fun to see at that conference, the concept of BA’s as superheroes. BA’s are superheroes. A highly skilled, effective business analysis who actually knows all the basics that we’re talking about is a superhero to an organization, and once they see it, they know it, they understand it, and they want more of it. It’s very difficult to describe until you see the person wearing the cape and doing the stuff. Right?
Kupe: Right. That’s kind of a reason Jacqueline and I started talking about this and throwing around this concept of “back to the basics,” because people see you, they see how you operate, and they see how you’re able to take this monster, wrangle it, and get the team on track, and they’re like, “Heather’s great.” However, what is harder to see is, “Why is Heather awesome?” What are the things she’s doing? What are the core stuff, regardless of what team she’s on and what project she’s dealing with, whether it’s in-house development or commercial off-the-shelf?
Heather, you mentioned one of the key skills of a trained, superhero BA, which is getting a conversation started. Is that a basic thing or is that only in certain circumstances? What’s your take, if you can go deeper into conversation starting?
Heather: Yeah. I think that is a basic. One of the things that I think we need to be prepared for in our superhero roles — I like that theme, and I’m going to keep it going — is a BA has to have super thick skin. You have to be prepared to start a conversation, and even with a context diagram. I have created diagrams based on my understanding and the information available to me and have been told as I presented it that it was completely wrong. That feedback is helpful in the concept of, “Alright, let me get it right. Thank you for sharing that I don’t have this understanding yet. How do you help me represent this accurately?”
You have to be like a sacrificial lamb willing to put yourself out there and have yourself destroyed. You have to be like, “Ok. Thank you for that. Let’s move forward.” I think that is a basic skill, and when people are starting out, it’s difficult to gain that confidence. It’s hard, and you have to be willing to be wrong a few times and get some hard knocks to get yourself built up to see the value that that brings.
Kupe: Awesome. You definitely went at an angle that I think is critical for people that are playing this role. It’s important to get that conversation started and also be able to hear, “No, it’s not quite right.” That makes me think of where some people in this profession, though it’s less frequent these days, are still thinking documentation is a big part of our role. It might be, but to me, that’s an output of a conversation. The whole goal of using analysis techniques like the concept diagram is not to document what you heard, but it’s to validate and get a conversation started that this is what we’re talking about and did we miss anything. Do you agree?
Heather: Yeah, absolutely. That’s so true.The highest value that a BA brings, and we do need to get the requirements right. Let’s not downplay the importance of that, but the higher value is the person willing to dive in and start talking about what’s important. One of my favorite books growing up was a book of poems by Shel Silverstein, and there was a particular poem where there’s a little girl who has a whale. It’s about how you start eating a whale, and that’s by taking one bite. It shows her as a young girl, and then she’s very old, maybe in her hundreds by the time she finishes the whale. The whole idea is you have to start somewhere.
That swirl I mentioned is so common. For me, one of my strengths is an activator, which means I’m willing to sacrifice things earlier than other people, and that can be a problem. I have to manage that, too, because I’m like, “Let’s just start something. Let’s quit planning,” and the whole concept of agile and stopping the planning is so appealing, because you just have to start somewhere. That is a great value of a BA, probably even more so than the documentation, because teams need help moving towards that goal.
Kupe: Yeah. ‘Activator’ is another great term for what we do, and it even is a basic. When we’re talking about basics, we’re not talking about easy stuff. What Heather is describing, and you even said it, that it took time. It takes time to get thicker skin, to be able to do this, to be ok in how I approach things, and to be ok with people saying, “No, let’s try again.” Many people, luckily I’m not a perfectionist, but many people are, so they want to get things perfect. However, that doesn’t activate things, or it doesn’t get things started all the time. To really get moving and learn from it is to start something and get that conversation going. Let’s see where we are and what we know. That, to me, is a great basic.
Switching gears now, I know in our pre-show calls and emails, you talked about another basic, and I think you and I agree. Some people feel that when they have the context and know where they are, a great way to understand the business is by looking into the data, the attributes, and how the relationships between data is, but for you and I, our first go-to-thing might be different. What’s after the context piece?
Heather: You’re right. Once I understand the boundary, my beginning and end, I have to dive into what the process is. A very basic skill set or a basic tool for a BA is a rudimentary, it doesn’t have to be a detailed, fleshed out BPM, beautiful data-ready diagram, but some concept of what that business process is. Tell me what you’re doing today. Once you have that basic understanding, it really is foundational. And it is a basic. I’ve heard feedback from people saying, “I don’t have time to do it.” I say, “Well, I understand where you’re coming from and why you feel that way. However, I don’t think you have time not to.” Once that happens, it’s a foundation for understanding the rest.
One of the things that is a frustration for me that’s going on in our industry today is the conversations about business analysis on an agile team. These basics, you said it at the beginning of the show, it really doesn’t matter what your methodology is or how you’re organized. The concepts that we’re talking about are truly basic foundational skills for analysis, and you have to have an understanding of that process to enough of a level where you at least can see the exchanges between areas. It doesn’t even have to be detailed processes; it could be very high level ideas. Again, the basics are, “How do I get started?” Context is part of it: what my problem is and what my objectives are. Ok, now I have these processes that I know I need to dive into, and I do need to understand the data as well. But starting with that process diagram is going to give you such a great foundation as a basic skill, and it’s just something that blows my mind that people don’t do.
Kupe: Yeah. Especially in the large organizations there seems to be business process or process people. They’re business process analysts, and that’s what they focus on. I think it’s ok to a point. The BA role is pretty expansive, and depending on the type of work you have to do, maybe it makes sense that you have specialists even down to data. There are data scientists, now, down to the process down to what people would consider functional/non-functional requirements. They’re splitting those roles.
I don’t think we’re here to comment on that today, but regardless, people, no matter where they are on the team, they have to understand the process. Other than to get information about what’s happening today and seeing where you want to go, why is it a key, why is it a basic thing that you have to do, that you have to understand the processes?
Heather: I think it’s important to understand the processes to know where to dive deeper. One of the things that comes apparent to teams, and I think it’s great that there are companies that are focusing on business process analysis and process improvement. Part of getting that conversation started is, “Hey, I found this work we already have. Is this still valid?” Those are great ways to leverage a team and not rework. We don’t want to be reinventing things along the way, but we have to understand that process is a basic step to understand what might be changing. Many things might stay exactly the same as we consider what our problem is. It helps us create focus.
Going back to that jigsaw puzzle, if I’ve got my context, my outline, and my frame, then I understand the process, which could be different themes. I know when I do a puzzle, sometimes I focus on colors, objects, or features. There are all things that become apparent as we start to fill out our story. I consider the analysis process as an author of a story. I start with a title, which is a project, then I start to get a table of contents, which could be my context, and then I start writing chapters. Those process pieces become chapters in my requirements story.
Being able to look at it, it gives me the information to better elicit and to better target where I need to focus. It could even be the prioritization exercises that stems from the process. There are so many facets that could leverage the process understanding to help me be more successful and create value for the team throughout that exercise.
Kupe: That’s great. The one thing you made me think about as you were talking about that, and you actually helped me understand why I start with process before data. It’s because to me, it’s the human interaction part. Somebody is interacting or doing a process or is impacted by the results of a process. In the end, if you know what processes are impacted by the initiative that you’re working on, then you can start to think about, “How are people going to be impacted by this? Are people’s jobs going to change? Are different groups going to start doing something that maybe in the past they didn’t?”
If you understand where people are today and understand and see how they’re doing the work and then knowing that going forward, we have to improve it, then what’s life going to be like for them after? The earlier you can start thinking about that and getting people prepared that there is going to be a change, the more success you’re going to have as a team to implement that. I always say that it’s not good enough to build a really cool thing. Whatever your project is doing, whatever it’s trying to create, it’s not good enough to build something great with no users. If nobody uses it, then it’s a huge failure. I always felt it was important, but I was never able to put words to it. Thank you. That’s another superhero skill you have: to get people to understand themselves.
Heather: That’s awesome. I like that you said, too, that another basic skill is this is a people business. One of the funniest things I hear, and it’s a common saying. I’ve heard it through many projects, many different clients, and many organizations, even thoughts I’ve taught. It’s the phrase, “Well, the system will do that.” I contemplate that, and you wrote a great blog about the robot BA. Well, we’re not at that point, yet, that we’re robots. And by the way, someone needs to tell that robot how to behave, so we’re here to help that system know what to do. The system doesn’t do it automatically. It can’t take our spots and translate this code yet. Someone is working on that, I’m sure. Artificial intelligence.
But until then, we have job security because we have to have that conversation, but the concept is that the other power of process: it’s amazing as you work with people. I’ve done a lot of insurance work. Let’s say you’re at an insurance company and you have a person with a very specific role and they process a particular piece of business. They know their job inside and out. They don’t understand that maybe their job has input to an output down the line. Once you create that diagram, they start to see where they fit in the entire organization, which makes them feel more valuable. It also enables that conversation at a personal level, and that person realizes you care about them. You care about what they do specifically. When they’ve been having difficulty or frustrations, you’re finally listening to them. That is another basic skill, to realize that this is an impact to a person and it can change their job.
Sadly, sometimes we have to be involved in initiatives that end up in job changes, and maybe there’s a reduction in force. As you start the initiative, it helps you frame conversations to help everyone be ok with what that change might be in the organization. And change is a big part. That’s probably not a basic skill but more of the intermediate aspect: understanding change and how you can be a more effective change agent. Process helps with that, too, so thank you for helping me make that connection.
Kupe: Right. I think we’re saying the same thing. Being that change agent is part of the basics. Without that, things fall apart. I agree with you completely that this is not easy. It’s not like you wake up new to the role and you’re going to be good at this. I almost got fired early in my career because I didn’t understand how to help people along with changes. There was a project, and the right answer was to move a couple of people from one department to another department.
Well, I just announced that to the department head in front of her peers, and she lit into me. I wasn’t expecting it. I’m like, if you look at all the data and the facts, it’s the right thing to do. But I didn’t set the stage for her. Like most people, they’re like, “This is my area. Let me be part of the conversation. Don’t just come in here and say you’re moving people from my department to a different department.” It’s basic. It’s a part of the foundation that you have to have, that someone on the team has to have. It’s not easy. This is really hard because, like you said, we’re in the people business.
Heather: We are, and that’s so true. What a great learning experience for you, not that you almost got fired. Yes, I definitely agree that the change is fundamental, but you’re right that it doesn’t come day one. It’s going to take some time, and, in fact, it’s almost good when you have those experiences like you have because then you will remember. This leads me to another basic, too. The change is important and we’ve got to be able to lead our teams to discovery. Something else that can be frustrating about this role is we really aren’t the decision makers, and at times, we have to lead the team to see what we already see. I had a guy I was interviewing once. I’m not saying this to think this is even true of myself, but he said to me, “I think that sometimes you’re the smartest person in the room. How do you get people to know what you know once you know it?”
I do not think I’m the smartest person by any means, but I do think what I’m good at is making connections. I think I can very quickly make connections, and like you said, you saw the data and said what was going to happen. We see that earlier than other people, and the art is how you lead them to that discovery so that it can become their thought. That sounds a little deflating, but you also can’t have a big ego and be in this role, because again, you’re sort of that sacrificial lamb. You might know the answer or have come to some conclusion, so bringing people along is another part of our basic skills, right?
Kupe: Yeah. That is a great point. I’ve said this for other reasons, but when you’re working on a project, if you’re a skilled BA, you do start to connect the dots. Part of the reason, and this is why you need to be humble about it, is you’re thinking about this all of the time. You give your 100 percent; you’re dedicated to this. You’re writing up your diagrams, creating models, talking to people about it, thinking about it, driving home with it swirling in your head whether you’re consciously thinking about it or it’s in your subconscious; it’s there.
The people you’re working with, you have to understand: they’re not in this 24/7 like I am. They have other things, especially the people that are running the business and in the business. Their 24/7 is what’s happening today and taking care of the clients and customers. That’s what they’re thinking about 24/7 and not necessarily thinking about your initiative all the time, so you have to bring them along. You can’t assume that they have all the knowledge you do. You hear about oracles, that they can see the future. Maybe that’s what a BA is like, in a sense, because they can see the future before others, but only because they’ve been focusing on it a lot more.
Heather: That’s a great point. I think we can forget. It goes back to context. Our context, our success, is dealing with solving this problem and understanding it from every angle. One of my mantras is that business analysis is a thinking profession. I’m constantly thinking, like you said. You’re right: you drive home; you dream about it; you’re thinking about what else there is to discover and who else there is to talk to. What piece of the organization have I not uncovered? What rule have I missed?
All these things are going on in our mind, and we’re putting together our puzzle. We are kind of the master puzzle connector. Other people are not involved with every piece of that puzzle like we are. It’s true, and we’re trained to think that way. We’re not normal; we are superheroes or evil geniuses.
Kupe: You’ve said this probably a hundred times, and I say it all the time: it’s not a profession where you go through the motions. It is a thinking profession. Your brain is constantly working. I said this on either a webinar or a stakeholders analysis class the other day, that you’re always doing stakeholder analysis, whether it’s at the beginning of the initiative but you’re doing it down to the minutiae: thinking about who’s going to be in this meeting and how to better engage them. If you’re not always thinking like this and you’re not tired at the end of the day, then you’re not working as hard as you can. That thought process is very tiring.
Heather, you and I talk a lot outside of work-related stuff. We’re friends and also colleagues, so we talk all the time. Business analysis is usually part of the subject. You mentioned that this is a people business, so is there something that you would consider, in addition to what we already talked about — that it’s a people business with interaction and change. Is there anything else that you would say is core, is basic, to this discipline?
Heather: Yeah, absolutely. This deals with people, too. It’s funny: quite often when I do presentations, I might pose a question and the room is so quiet. I find that interesting because I think business analysts should be naturally curious. It’s almost like I would expect the room to be stumbling over each other to get a word in edgewise. It’s interesting how many people don’t necessarily like people that are in this profession. It fascinates me. I don’t know what their level of success is, but you have to like people and you have to always consider a user’s perspective.
Another basic, I would say, is we have context, we have the process, we have data involved: you have to be considering that someone is going to be using the system. We’ve got internal users, external users, and other stakeholders involved. Having that user perspective is really a basic and an important element. I love the user story aspect of personas. The reason I love that is because it can focus my attention on a particular user. As an external user who is a potential customer, I have that story in my mind like, “Ok, this is a potential customer. What would I be doing? What information would I like to see? What information do I need to see to make a decision about hiring this company, buying this product, or completing whatever my compliance request is?”
Whatever your industry or business is, you have to be considering who is interacting with your product and how they’re doing it. You almost have to become that person: be one with the requirement concept. That will change your elicitation, your process thought, it could change the data you might need, and it could even inform the strategy. It has so much implication of having that specific user perspective, and then fundamentally, I tend to focus on the QA person. Someone has to test us, so as that potential customer, someone is going to have to potentially test what I’m indicating in my requirements statement. I have to think about all that user perspective, and it’s complex; it’s not simple. It’s many layers, but that is an important piece of the basics of our role.
Kupe: Yeah. I wasn’t expecting you to go down this path of QA. You’re absolutely right. In this role, it’s not only the consumer or someone that’s impacted that’s going to use the solution, but it’s people that are going to use the stuff you’re creating. How do I help direct my team to do better at what they’re doing? That has to be part of the role. When you were talking about an external user using the system and elicitations, not only do some people not ask enough questions or are not as curious as they need to be, but they don’t get up out of their desks and go see how people are interacting with the solution or could interact with the solution. You learn so much more.
This is a total joke, but people are liars. When they talk about their process or how they do something, they often miss a lot of little pieces. Some of the classes we have, we do a thing around somebody pumping gas, and if you ask someone how to pump gas, half of them leave out that they take their seatbelt off. They say that they pull up to the gas station, they get out of the car, and then blah blah blah. It’s like, they didn’t take their seatbelt off, they didn’t tell you they put the car in park, that they took the key out. All these little things that we do. When I say people are liars, I don’t mean they’re being malicious, but we don’t remember those fine details. Going to observe someone and see them in their environment really gives you sense of how they’re using stuff.
There was a story. It wasn’t a project I worked on, but it was a project someone was telling me about. There were people out in the field, so out of the office, and their smartphones were too small and too difficult to do some of the updates. They wanted to roll out a new application that worked on tablets, which were a little bigger, so they got all these people iPads and created this application. All the iPads started breaking. Well, these people out in the field were actually on construction sites. They put their tablet down and a hammer dropped on it or a board dropped on it. If they went out to their location and saw where they would put the tablet down, maybe they might still be tablets but they might have super cases that might protect them. Just going to their location really gives you a sense of what’s happening.
Heather: So true. I would say it’s nearly 100% of the people that don’t remind you to take your seatbelt off. Being the analyst and saying, “Well, maybe you don’t wear seatbelts when you drive,” is possible. You could be breaking the law and taking a risk to get a ticket. I’ll give you that, but I love that analogy.
Observation is so important because we do not remember from day-to-day teaching your children or any other person to drive. It’s such a fascinating experiment, because you learn in driver’s education what the rules are, the things you do, but then you see someone who’s driving and no, you don’t stop the appropriate number of feet behind someone; no, you don’t remember the rules. You’re just like, “Yeah, that’s a guideline and not a rule.” We forget so many things, and in our system, observation is a great elicitation technique. It’s so important to see that user interaction, but there are other techniques as well that verify the user system interaction. Observation will help us see those, too.
I love process. You and I talked about it, and I share that viewpoint. I can do some very specific workflow diagrams to describe the decision points, the keys, everything. I can get that done until I feel very confident about it, but when I shift that thinking to the user perspective and I apply techniques such as the use case, which I know some people don’t like use cases. Whether you like them or not, the thinking is what’s important. My conversation here is you think about, as a user, I have an interaction. Now, that interaction requires a system response. Going through that dialogue is like the seatbelt.
As I’m teaching this in class, I get stuck with my seatbelt. I physically show the system can’t move further because you have constrained it by not taking off your seatbelt. I can’t physically get out of the car just like a system can’t move on its processing, because you haven’t indicated that the system should do it. Well, I haven’t told the system what it should do, yet. It helps you discover, from a user perspective, what you expect to have happen. What if this processing is not the happy path? Do I show an error message? A warning? Take it to a different screen? Those conversations are so important from that user perspective, and you have to consider that a human being will be interacting with the software. What kind of experience do you want them to have?
The requirement the system should be user-friendly is a horrible requirement and not specific enough, and yet that underlining principle requires us to have that user perspective to make it a good experience. We’re all going to be able to have jobs because they buy our products and services. You have to think about it, and you have to challenge people to consider that perspective.
Kupe: Yeah, and I like that you’re bringing up user perspective because I think this is where most conflicts come from as well. I know you may be able to talk about complex and how it’s part of our role, to not cause bad conflict but to work through conflict. It’s asking user or the stakeholder, the individual level, where conflicts arise. One need of one stakeholder could be different and maybe completely opposing to another.
The analogy, I like to use the house analogy for a lot of stuff because it works for a lot of the stuff that we do. If you’re going to buy a house, who are the key stakeholders that are going to be impacted by that? You have the family: the husband, the wife, who are the partners. There might kids and a dog. Dogs, even though they can’t speak, have needs. They’re going to want a big yard, but maybe the person responsible for keeping the yard up doesn’t want a big yard. Now you have conflicting stakeholder needs, or perspectives.
Back to your point: it’s about conversation. At least you see, “Ok, I have all these different perspectives. Where do they align? Where don’t they align? Let’s talk about it. Which one has more priority?” It might be the person paying for the house that wins out over the dog, but at least you had that conversation and you thought about it.
Heather: You’re so right. There are some things that can help with our basic conversation. In the last episode you talked about understanding the problem. Once we understand what the problem is, that can help us identify the stakeholder’s viewpoint. We also have objectives, so we can challenge. Our objectives in the case of the house may have been to buy a home in a safe neighborhood with this price by this time of the year or something like that. Ok, so we have price. That’s important to us. What houses fit our price with the different yards? It sounds so simple the way we describe it, but it’s not easy; it’s complex. Just like a puzzle, it all fits together.
It’s having that up front scope: understanding the problem, understanding the objectives, understanding the context that we’re working in — it helps us with those conflicts. I love the aspect of a stakeholder viewpoint, and if you can, I know it’s not always possible, but having the conversation beforehand when there are multiple stakeholder groups — and the context diagram will show you the multiple stakeholder groups as a visual. You can start talking about it, like, “When we come up to a situation where we have these conflicting requirements, do we have a viewpoint?” That’s the most important. For example, it becomes easy once it’s a compliance project.
Well, the compliance area and the rules need to take precedence over any other thing. The more we can do that up front, and not that it won’t change because things do change, but the more we can have that conversation up front and get an understanding, a foundation, for the project, we’ll be better off in resolving those conflicts. You know what’s best about that? Letting people resolve their own conflicts. Leading the conversation to address, “Ok, we have this conflict. I just want to remind the team that we agreed this is the problem we’re trying to solve, these are our objectives, so how does that help us in this conflict?” Leading people to that answer might be obvious to us. That’s another part of our foundational skills.
Kupe: Yeah. People say they need help in how to manage or work through conflict, and I’m of the belief that I try to do things to not even get to conflict. It’s a difference of opinion, but if you’ve done the legwork up front where everyone is clear on the objectives — to your point — if we do run into conflicting statements, who wins out. Kind of agreeing on that stuff earlier than later. Then, it’s not a conflict. It’s a conversation, saying, “We have opposing forces. We can’t do both. We can only do one or the other.” It should be an easier conversation.
Jaqueline, who couldn’t be here today, always says, “Let’s work this stuff out while we’re all getting along, and then there won’t be an issue down the road.” Because what happens on projects? If you don’t do what you’re talking about, you get to a point where now we’re at more of a time crunch, you have more eyeballs on it, everybody’s stressed, and then people get upset with each other, which becomes a problem. However, if you work it out at the beginning of an initiative when everybody’s happy, it’s a lot easier to deal with then than when tempers start to flare.
Heather: I love that. I’m going to have to adopt that phrase: let’s work this out while we’re all getting along. It’s so true. It’s like this ugly tide, and you can feel it. A tangible point. The project takes a turn, and there are fingers pointed. Unfortunately, many times it can be about the requirements of the business analysis. It’s unfair.
I did a presentation with Jared Gorai, a fantastic analyst from Calgary. The presentation was called “The Seven Habits of Highly Effective Business Analysts.” (I also wrote a blog post on the subject as well: The Seven Habits of Highly Effective Business Analysts) We talked about the habit of communication and collaboration and addressed it more specifically. We’re only as sick as our secrets; arguing isn’t a cure. We say that because once you start to withhold information and are not willing to collaborate, your team becomes sick. It becomes ugly. People start playing the blame game, and nobody wins.
One of the things Jared says is about the concept of “it’s my fault.” Like, “I caused global warming. I’m not sure how, but ok, I did it. Let’s move forward and start to solve the problem.” But, that concept is another way that a BA can just say, “Yes. It’s a problem, something happened.” Blaming somebody and being upset about it is not going to make anyone move forward, so we have to keep that conversation going and get our teams back to collaboration, which is what you mentioned. Collaboration is one of those basics.
Kupe: Awesome. Well, Heather, this happens to me all of the time and it happened to you before in our pre-show call. You were like, “I’m not sure I can talk about this for an hour,” but as you realized, the hour just got sucked up, and I knew we would have no problem chatting for 60 minutes on this topic. We have a couple minutes left before we wrap of the show. Do you have any final thoughts for our listeners?
Heather: I think the final thought I have is sometimes when I’m doing presentations, some of the things I’m talking about are maybe the softer skills, the artistic aspects business analysis. There’s a feeling that it’s too basic, that it’s not applicable to them, and I would challenge people to consider that there isn’t really anything too basic. It’s perhaps the basics that create the most value for our team. Just all of us be willing and open to the “back to basics” conversation and not necessarily think that it has to be the latest model or something else. It really is some simple, foundational things that’s hard to master but once you do, it creates that value that we want this profession to be known as.
Kupe: That’s awesome, and I think you’ve given the listeners a lot of great things to consider, like building the edges of a puzzle; understanding the edges and using a context diagram as a way to do that. Then, digging deeper and seeing who is impacted and where things are impacted by looking at processes, and using all this stuff to create conversations. That’s what it’s about. It’s also about thinking. You said something earlier, and I didn’t comment then, but it was when you were talking about the use case. Somebody said something that makes you think of, “How can you do that when you didn’t do this step first? Let’s talk about it.”
That’s critical thinking: always questioning and trying to figure out if that could be true. If it’s not, then what are all the other pieces around it, and let’s dig into it before we move on. It’s not about just going through the motions or having your list of questions then writing down what anybody says and moving forward with it. Heather, thank you so much. You’ve been awesome. We’re definitely going to have you back on the show. You passed. No, I’m kidding.
Heather: Thank you.
Kupe: It was great having you. Jacqueline and I do these shows regularly, but we love having other voices in the mix. Thank you so much. To all of our listeners, I just want to say B2TTraining is the group that has sponsored this #AskAnAnalyst radio show. Thank you guys very much.
If you have a question or comment, call 855-484-6837, leave a message and we’ll read it on our next episode. Also, please visit our Tech Expresso Cafe page on iTunes for this and other series!
Please enjoy our other episodes:
- Episode 1 | December 8, 2015: Podcast launch and general overview of business analysis today
- Episode 2 | December 22, 2015: 2015 in Review and Set Your Expectations for 2016
- Episode 3 | January 5, 2016: Your Business Analyst Career Path
- Episode 4 | January 19, 2016: Business Analysis Role Fits in Many Careers
- Episode 5 | February 9, 2016: Overcoming Business Analysis Project Failures
- Episode 6 | February 23, 2016: Good Business Analyst vs. Bad Business Analyst
- Episode 7 | March 8, 2016: Business Analyst FAQs
- Episode 8 | March 29, 2016: More Business Analysis FAQs
- Episode 9 | April 12, 2016: A Business Analyst Attitude for Success
- Episode 10 | April 29, 2016: Consider Your Business Analysis Thinking Approach
- Episode 11 | May 10, 2016: DiSC Assessment and the Project Team
- Episode 12 | May 24, 2016: Negotiation Approaches
- Episode 13 | June 7, 2016: Strategy Analysis and Strategic Thinking
- Episode 14 | July 5, 2016: Business Analysis Insight
- Episode 15 | July 19, 2016: The Remote Business Analyst
- Episode 16 | August 2, 2016: A Modern Agile Conversation
- Episode 17 | September 13, 2016: Back to Business Analysis Basics
- Episode 19 | November 3, 2016: Live from #BBCCon
- Episode 20 | November 15, 2016: Effectively Give and Receive Feedback
- Episode 21 | December 8, 2016: 1 Year Anniversary & 2016 Year in Review
- Episode 22 | January 10, 2017: Business Analysis in 2017
- Episode 23 | Janary 24, 2017: Is agile a methodology?
- Episode 24 | Janary 27, 2017: An Agile Mindset
- Episode 25 | February 7, 2017: State of Agile
- Episode 26 | February 28, 2017: Are BAs Becoming Obsolete?
- Episode 27 | March 23, 2017: Remote Agile Team Success