Jacqueline and I are excited about answering some more of the business analysis frequent asked questions that we get on a regular basis. We were even able to get our instructor, Ali, to join us to provide some additional insight from her class experience! Let us know if you have a business analysis FAQ that we can answer in the comments section below!

Episode 8 | March 29, 2016 Business Analysis Podcast Transcript

Jacqueline: Hello. Good evening, maybe good afternoon, and maybe even good morning to someone out there. We usually say Dave and Jacqueline bringing you Technology Expresso Hot Topics. But tonight I can say Jacqueline, Kupe, Ali, Jovan, Celise, David…there’s a whole host of us bringing you the show tonight. Let me start by saying Hi Kupe. How are you?

Kupe: I’m awesome. I’m well-caffeinated and ready to go!

Jacqueline: Absolutely. We’ve got Ali joining us tonight. Hello Ali!

Ali: Hello Jacqueline! Glad to be here. Thanks for having me.

Jacqueline: Absolutely. This is episode 8 of our series. There are still questions coming in from the listeners and we are addressing them one by one. Our topic is Frequently Asked Questions of Business Analysis. Ali, like Kupe and I, is part of B2T Training family.

We’re going to companies, teaching and talking to business analysts. Some of the questions the students asks are very similar no matter where we travel, far and wide. All three of us — Kupe, Ali, and myself — are all practicing business analysts. Now and then we’re still scratching our heads, saying, “What is really going on?”

So tonight, We’re going to tackle some more of those Frequently Asked Questions. You’re going to hear our perspective, and we always welcome your perspective. We’re going to be reading back some comments we received from previous shows, so stay tuned, you might hear your name and your question or comments. We do take all that input in. It takes a village to unravel the mysteries of business analysis.


Jacqueline: Without further ado, Kupe, Ali, on your mark, get set, here’s our first question for the evening: “How do I know I’m not missing anything? How do I know I’m not missing any requirements?” Ali, since you’re our newest guest, I’m going to throw it to you, first. When someone throws a question like that your way, how do you address it?

Ali: Well, I have to tell you that you’re always missing something. That’s the first thing you have to know. You’re going to miss something along the way. However, if you do a good job up front, usually by the end you have all the pieces put together. How to know if you’re not missing anything really comes down to how to know what questions to ask. If you hit all the questions on “Why are we doing this?” “What are we trying to get out of it?” “What do we need in order to get that thing out of it?” “How are we going to do it?” “What does it take?” “What data do we need?” “What processes need to be adjusted to get there?”, then typically you’re going to get to the end and not miss anything.

Along the way you’re going to find that, “Oops, I didn’t fill in this little piece.” You’ll have to fill it in as you get down to the details. That’s actually OK that it gets filled in later rather than sooner, as long as by the time you get to the end, you have all of the pieces put together. That’s my take on it.

Jacqueline: Excellent. Kupe, how do you feel about that?

Kupe: Ali said something about the big pieces. It made me think of this YouTube video about a professor whose talk relates to missing requirements. He talks about if you have all this stuff and you put in the little pebbles first, you’re never going to get all the other things in. He talks about first putting in the big rock, and then you pour in the pebbles, and then you pour in the sand, and then you pour in water. That gets all the parts and pieces in this bucket which you didn’t think you could get in in the first place. I’m sure you guys have seen it. I’m not explaining it great.

I think to Ali’s point, you start with the big rock stuff. What are the major things that we’re trying to accomplish here? Then, you can drill down into the deeper stuff. I think too often people miss stuff because they go right to the water in that example, to the smallest particle. They try to nail all that, and eventually you figure out, “Wow, we’ve missed some major things, here.” I want to reiterate Ali’s point that you’re never going to miss anything; it’s just a total misnomer. Things are going to get missed, and eventually they’ll pop up. However, there are things that Ali and I are talking about that you can do to try to avoid it and make it less risky.

I looked up the video (link below) with the professor just in case you want to go back and look at that YouTube clip. He was talking about time management and “is your day full?” He put the big rocks in first and asked, “Do you think this bucket is full?” Then, he poured pebbles into it, then sand, and then water. In that case, it was about how you handle the major things in life that you have to deal with. If you focus on the minutiae, then you’re never going to get to the really important thing. I just thought that was a good analogy to this whole missing requirements thing.

Watch Video @  https://youtu.be/fmV0gXpXwDU

On the last call I talked about trying to do things in smaller chunks and focusing on things in smaller pieces, and then for that piece itself, you won’t miss anything. That’s some of the beauty of the agile mindset. If you’re thinking about a room in your house and just focus on that, you could probably get all the minor details for that room. Breaking things into chunks and having the right people involved in the discussions will help avoid missing things.

Ali: That’s a great point, Kupe, and I think it all goes back to scoping, which is really what you’re talking about when you talk about starting with the big rock. Go back to scoping and make sure that you understand those big chunks, and then as you detail into them, they will help you identify the smaller chunks. It will also help you identify how to test those, which oftentimes as you’re thinking about testing the solution you come out with, you realize that you’ve missed a detail and that you’re going to have to go back and pull that in. If you are interested in more on scoping and managing change, check out Jacqueline’s recent blog post: Scope Creep’s Impact on Analysis.

Jacqueline: Exactly. Something else that often comes up, too, and Kupe, you talked about having the right people, is that requirements is a team effort. Don’t go it alone. When you say, “How do I make sure I don’t miss anything,” well, use all the resources at your disposal to take a second look, to bring in their perspective, and to look at it from different angles to make it a team effort, because someone might remember something from a previous project. There’s a lot to be said about the right people.

Kupe: If I could just reiterate. I’ve been talking a lot about design thinking: it’s about collaboration, getting the right people in the room at the right time and thinking about who has the information. This brings me to the point: someone asked me, and I might’ve mentioned this before, “I’m not allowed to talk to the Subject Matter Experts on my project. What do I do?” and I said, “You need to run, hand in your badge, and get off that project.” You’re not going to be successful. You’re going to make stuff up, and the team is going to make stuff up. The risk is way too high. You might get lucky, but there’s a greater chance that you’re going to miss the mark.

Ali: That’s amazing how much you hear that in the BA world, that the BA is not allowed to talk to the people who they need to talk to in order to get what they need. You have to push on those buttons and expose the risk of that. I’m hoping that that will help you get to the right people and get them involved.

Jacqueline: Absolutely. I know the question was “How do I know I’m not missing anything,” but we talk about, often, about how one topic leads to the other. The one thing is we can talk about things that you can do as a business analyst, but you also have to be in the right environment that is supportive of, like you said, some of the concepts of what is really necessary to help the BA reach their full potential. There are a lot of tools and techniques that we can teach them, but going into an environment that underestimates the amount of time and expects them, in a short amount of time, to come up with these things, to limit their access to people — the environment is really undermining the BA. Maybe that’s a different episode, but there are things beyond the business analyst; the BA can’t be put into isolation then come out with perfect requirements. Is it just me that finds this odd …

Ali: It’s not just you.

Jacqueline: Kupe, do you want to comment on that?

Kupe: No. I think you nailed it. You’re not alone, and we’re all on the same page.

Jacqueline: Just something that I wanted to throw out there and see if Kupe or Ali want to speak to it. Kupe, you have done this on some of our other calls: sometimes when people ask a question, sometimes I dissect the question and think about the context. In particular, when people ask this question, I take it back and I look at it, especially if they haven’t had a B2T Training class. What I find a lot of people do when they’re trying to find what they consider the requirements is they’re trying to come up with a list of features, functions, and that type of thing. They’re trying to brainstorm based on their SMEness aka their subject matter knowledge.

Kupe: Right.


Jacqueline: When people talk about missing requirements, what do you two think is the impact if you’re just relying on your SMEness vs. the true tools and techniques? — I’ll start with you, Ali.

Ali: Oh, yeah. You see that a lot, and you also see that they come from a perspective of “I have to fill in the BRD,” the Business Requirement Document or the FRD, the Functional Requirement Document. “I have to fill that out.” It’s not about the document. It’s looking at “What do I need to ask on this project to come up with the right solution, and to whom do I need to ask those questions?” As you start from scoping those big rocks and get down into those little pebbles, when we take the solution we’re coming up with through certain scenarios, what’s going to happen? You come up with those details and ask those questions, which is going to help you understand what you really need to get to.

You don’t have to rely on your SMEness, or, heaven forbid, on your assumptions. You really get the true answers that the business needs and get the results back that they need so you can solve their problems and not just throw solutions at them and hope they stick. It’s kind of like the toy my kids used to have when they were young. It was this sticky, spidery looking thing that you threw at the wall. Sometimes it stuck and sometimes it didn’t. You don’t want to do that.

Kupe: And when it got all dirty and stuff…

Ali: Right! That’s what happens. Your requirements get dirty. They get summed up with a lot of stuff you don’t need, and they don’t include what you do need.

Kupe: Right.

Ali: I think it really comes down to what Jacqueline said. You had a great point about coming at it from a structured approach, but also you can’t just follow a template or a methodology. You have to actually put some critical thinking behind that and really understand “for this project, for the SMEs that are on the project, and for the solution that we’re targeting, what do I need to get done?”

Jacqueline: Absolutely.

Kupe: The one thing we’re all saying is that, and I say this all the time, the day you leave the business, your SMEness declines. You’re not in there – day in and day out. Even if you were doing things for 10 years as a SME, when you come over to the BA role and you’re not doing that day in and day out, you can’t just have the attitude that you know the answers. You’re not there enough, and things change so fast that you must have that type of attitude.

The other thing and I’m with you Ali on the idea of not being structured for the sake of structured. You don’t do process for the sake of process just because it’s there. That’s not why we do business analysis, but I do think we have to be detectives. This goes to when Jacqueline said structured approach.

Thankfully I’ve never been questioned by detectives, but I just know from watching a lot of Law and Order: they ask the same questions over and over in different ways to try to find the truth and really know what is what. They’ll ask different people the same question, and they’ll have different detectives come and out and ask it a slightly different way. Why there are so many different techniques and why we get into trouble sometimes is because we use A technique or we have a question and get an answer and just go with it. We don’t ask a few other questions in different ways or ask the same type of question in the same way, which might expose something that opens everybody’s eyes.

You see the best people do this naturally. They use multiple techniques, they tie things together, and like you said Ali, they use critical thinking to make sense of all this stuff. It’s not just a conversation.

Another thing a lot of BAs get stuck in, not only not being able to talk to the people they need to talk to, but people don’t understand why. They’re like, “We had this conversation already. Why are we talking about this again?” They don’t understand the process you have to go through. They’re wondering, “I told you everything I know. Why are you coming back and having another conversation? It’s that detective-type attitude, mindset, or approach that I think people need to have to try to fill in the blanks.

Ali: I had a client ask me not long ago, “Do you like history/detective novels?” I said, “Actually, I do. Why?” He said, “Because you ask a heck of a lotta questions.” He actually didn’t say heck, so I won’t say it.


Ali: It is true that you have to ask a lot of questions, and you have to ask them in different ways because sometimes you get just enough of a different answer to make a difference.

Jacqueline: I want to chime in on the whole idea of the investigator, the detective. I remember early on there weren’t any workbooks on business analysis. The Business Analysis for Dummies book had not come along back then. I did find a detective book on how to interrogate a witness, and I read that. It showed me how they cross-examine. As a kid, I used to like Columbo. Remember him?

Kupe: Oh, yeah.

Ali: Yeah.

Jacqueline: With the crumpled rain coat. He would ask just that one more question, and everything…The interns have no idea what we’re talking about.

(Fun reference:  https://en.wikipedia.org/wiki/Peter_Falk)


Kupe: It’s funny that while we’re on this show, I have this whiteboard in my office. While other people are talking I have to write notes so that I remember what I want to say as I continue listening.


Jacqueline: We have some more great questions, so I’m sure we’ll come around to a lot of key points. We have Kupe and Ali with us, along with David and our interns. Thanks to all for joining us for Frequently Asked Questions of Business Analysis. Our next question is very similar but has a twist: “How much detail do I need to document?” I sometimes hear, “When do I know I’m done?” This is very interesting. I’ll throw it to Ali first to see how you address that question.

Ali: Yeah, that’s a great question. I get that question a lot. I’m going to try to quote as close as possible one of our B2T Training curriculum books. “You have enough detail when everybody agrees that that’s enough detail.” Well, what the heck does that mean? You have to get to a point where you’ve asked all those questions that we’ve talked about and you’ve gone from the big rocks to the little rocks to the water. Also, the business side or the SME side has to agree that “Yes, you’ve captured everything that I can thing of that would cover this particular solution.”

Furthermore, you have to go to whoever is in developing or is actually delivering the solution, whether it’s in house, a vendor solution, or a package. Make sure the consultants have enough information to get done what they need to get done. We talked earlier about collaboration within the project between the business and IT or whomever you’re delivering your solution to; you have to have them involved all along the way so that 1. those details are going to come out earlier, better, and more structured and 2. when you get down to the end everybody can look at it and say, “Yep. We think we got it. We can do this.” What do you think, Kupe?

Kupe: Yeah, it’s a team sport. A lot of times when I’m on panels and stuff without BAs, I like when we don’t agree all the time because it gets some good things out. It’s no surprise that the 3 of us work so well together  and we’re in line with a lot of stuff. The area I wanted to touch on, and this reminded me of a question I got once when someone came to me and said, “Kupe, I got this project. Here’s the scope/vision. Do I need to do use cases?” I look at that question like this one, “How much detail do I need to document?” I was like, “I have no idea. Do the people you’re working with need use cases to do their work?” It’s exactly what you’re talking about, Ali.

I’d like to sum all this stuff up in thinking about your job or thinking about business analysis as helping to facilitate decisions. It’s in the same vein, Ali, that you’re talking about but with a different twist. If you think about it, all the things on your project are a decision. You have to decide what the problem is that we’re going to go after or is that problem worth going after. You have to figure out the scope and the people who need to be involved. There are all these decisions that have to be made. Your developers have to make a decision of “how am I going to design a solution to meet the need?” QA needs to know “how should I test this thing? What’s the highest priority and what can I let go of?” There are all these decisions people have to make on a project.

The question isn’t really about documentation, so let’s throw that out. With documentation, you document with a purpose. If it needs to be documented, if you need to use this stuff for later, and if those decisions have been made by the team, then go crazy with documenting. That was another question someone asked me, “We want to get our documents down to 50 pages.” I was like, “Are you crazy? You’re focusing on the wrong thing.” I didn’t actually say that, but you’re focusing on the wrong thing because a document, in my mind, can be 1000 pages, if it’s needed. If it helps the project and/or the business, it can be a million pages. On the other hand, there could be no documentation. Everything could be written up on a flip chart and we’re done. Don’t think about it as a number. It’s not “a 50-page document is good, a 100-page document is bad.” That’s not focusing on the right initiative.

Back to decisions: if you’re thinking about your job as helping those decisions, then with every decision there’s criteria people use to make that decision. Understanding that criteria then communicating back that information so people can make a decision is what you have to document. Ali, you joked about when everybody can agree that it’s enough, stop. I used to say, “Do just enough analysis.” People would ask, “What’s just enough analysis?” I’m like, “I’m sorry. I have to go. Good talking to you.” It was a really hard question to answer, so I tried to avoid it.

When you keep thinking, you know there has to be an answer to what “just enough” is, and I felt that decisions are what helps you get there. If a decision can be made, if people decide “we’re all in agreement, this is the problem we’re going to solve,” then stop; move on; go to the next piece. You might have to revisit, but don’t overanalyze for the sake of overanalyzing. If everybody’s agreed to it, let’s move forward.

Jacqueline: I’m going to add the twist for the evening. I agree with both of you, trust me. The one thing that I think when I think about real-world scenarios, where some BAs get caught up is that they’re in an environment where they have different stakeholders, and different stakeholders want different documentation. In that case, on the one hand you’re trying to be lean as much as possible and do just what’s needed. I’ve seen this in agile when the developers say, “I just need the user stories,” but you have the testers that may need something more detailed. Then, you may have some compliance requirements for documentation.

You are in an agile environment where you’re lean and minimal, but at the same time, the BA still finds themselves have those other responsibilities as far as the documentation. I’ll see what your thoughts are and if you guys have seen anything similar to that, where we’re talking the talk of lean but there is still so many different expectations of the BA and of what’s documented. Is anybody else finding that, or is it just me?

Ali and Kupe: Absolutely.

Ali: Yeah, this will be my last statement before I jump off the call. This kind of feeds into a question I think we might have coming up later, so I’ll try to be relatively brief. It really goes into “what do I need to get done for this particular project?” What I like to do is once I understand the scope and all the stakeholders — all of the people on the project, the business, the development, from IT, from process engineers — once I know who that set of stakeholders is, and hopefully that doesn’t change too much across the life of the project, I will get with them and talk about “what do you need in order for you to do your job on this project?”

I’ll try to guide them towards what they need, and I’ll also ask the question “Why?” Sometimes they’ll say “because I always have to have that” or “because we have to fill in the spaces.” Well, that doesn’t always fly with me, because I want to know what you’re going to use this for, what decisions you’re making, if you’re a QA, how you’re going to test, and what deliverables you need out of this project for that. If you do that early in the project, that can really help guide and focus you on what needs to be delivered, and then it will help you understand how you need to deliver it.

I’ve seen BAs come out with pages and pages of use cases that nobody ever even looks at. That’s ridiculous. I hope if you have extra time in your day to do something, you’re not writing requirements that nobody’s ever going to read. I think starting early on a project to focus on that and understand everybody’s responsibilities and what they need in order to fulfill those responsibilities is going to help you understand how much detail you need and what deliverables are going to deliver that detail to the appropriate party.

Jacqueline: First of all, I want to thank Ali Ibarguen of BluePrintPM for joining us.

Ali: Thank you for having me!

Jacqueline: I hope you’ll come back.

Ali: I will come back. Thank you for having me and for sharing your thoughts. Take care.

Kupe: Good Night, Ali.

Jacqueline: To our listeners, Ali is also one of the instructors at B2T, so visit the website b2ttraining.com, look up some of those courses, and find out when she’s teaching. She could be your next instructor. Tell people at your company about tonight’s show, and maybe find an opportunity to introduce B2T in your organization. Ali, myself, and maybe even Kupe if you’re lucky might be your next instructor. We will keep going with our questions, Kupe. The show must go on. We will push forward, and we also have David on the line. He always mixes it up with us as well.

Kupe: Sure, Can I answer that last question?

Jacqueline: Go ahead!

Kupe: I liked Ali’s approach to it. The way you posed the question, it was almost like this is a problem that BAs are having. To me, I don’t see it as a problem; it’s reality. Like you said, this is real life. People want you to be leaner but they’re also requiring this stuff. It’s the same concept as “I want to pay nothing for a house, but I want granite countertops and four-sided brick.” It’s funny. I don’t know what has happened in our industry, but people want a lot more for less time and want better results. It’s a conversation. Back to collaboration around talking with the team: what is going to be used and what should I work on first?

The agile mindset of a project, when you think of value for a business, the team also has to think in that manner and say, “What’s the highest value? We all have X amount of time in a day, and we could all improve and do things faster. However, right now these are the skill sets we have. What is the highest value? What should I work on? Is it a higher value for me to work on the regulatory requirements, make sure things are documented, and show that we’ve complied to the regulation because if we don’t have that, we’re going to get fined a boatload no matter what solution we put out? If that’s the highest value, then you know what? I need to work on that. But, if it’s less value, then maybe it’s something that can be done post-project or post-release.” The other thing is, I hope people aren’t graded and being like, “Well, this stakeholder wants it this way and this one wants it that way.”

If you can get something that everybody can agree to, then that’s great. When it comes to communication, we need to have the attitude of what I call the “platinum rule,” which is do unto others as they want done unto them. Again, there’s a cost to that. If you can send one email and get everybody taken care of, that’s a lot easier than sending 5 different emails to 5 different groups and reorganizing things. That just takes long. There’s a cost to doing things the way everybody wants, but you must have that conversation, and teams have to have the attitude of “what makes the most sense for us?” I say this like it’s simple, just have the conversation; I know it’s not easy, but you have to keep fighting.

Jacqueline, you and I always talk about: fight the good fight. You have to keep going in the direction of trying to get the team in the mode of focusing on the value of the work that you’re doing. Look for those bright spots, and when there are positive things, highlight them and tell people, “Wow, that was great. That really worked. We should do that on the next initiative,” or, “We shouldn’t do that because,” like Ali said, “I put all of these use cases into the system and nobody looked at them. So, why are we doing this? Can we skip that next time?”

Jacqueline:  Kupe, you have a way of turning a phrase that really resonates. Something you said goes back to how we ended our last episode. Like you said, if somebody walked up to a builder and said, “I want a house, and I only want to pay $1,000 for it. I want it done in a week,” they’ll be like, “Have a nice life.” People all the time put these crazy constraints on us, but they want this excellent quality, great value; they want you to hit every requirement. It’s like, “What in your reality makes you think that that’s possible?”

There are plenty of instances to tell you that you have to invest in the requirements in order to see the quality, the value, well thought out requirements. It’s interesting that people are still throwing this our way. We can’t get tired, and we still have to advocate and keep building on our reputation. We have to take it step by step and use every opportunity to continue to prove our value.

Kupe: I know many people on the call know who Karl Wiegers is. He was one of the first to start writing…after Jacqueline read her investigator books, Karl Wiegers came out with some good stuff on this topic. He was speaking, and I went to see him speak in the mid-’90’s. I thought he retired, but he came back in mid-2000, 10+ years later, and was talking about the same stuff. I went up to him after and said, “Hey, Karl. I read a lot of your stuff. Thank you for the work you’ve done in the industry. I know you took a hiatus or semi-retirement, and now you’re back. The slides are update to be more modern, but the content is basically the same. What do you think is going on?” He said, “We’re still talking about the same thing. That’s the reality.”

A few weeks ago I met with the director of an IT shop. It was a fairly good-sized group, and he admitted, “I’m new to this. This requirements thing, this analysis thing, I’m learning. I realize at the highest level we have to do better, but I don’t know what that means.” You have people in these positions that are helping to guide teams that still don’t have the full understanding. That’s ok. That’s reality, and that’s what we have to deal with, but you have to keep finding ways to educate without getting too frustrated and walking away.

One thing I will say is it’s not greener on the other side. It’s everywhere. There are some groups that really get it and that are doing a great job, but I think the majority of organizations are in this middle ground. They get pieces but not the whole thing. It’s difficult. It’s not engineering, like you do step 1, 2, 3, and 4. It’s a difficult thing to wrap your arms around.

Jacqueline: Exactly. After the last episode, one of the things that came to mind, when you talk about what the developer does and what they bring to the table, people pretty much know what they do. If you talk about a tester QA, you know what they bring to the table and the value. The same goes with even project management. However, I remember when we first started defining the BA role and really getting our arms around the BABOK and that type of thing. We were excited and still I very much believe in us furthering that because it’s so important but progress and adoption of the role has been slow.

It’s interesting you mentioned Karl Wiegers, and I do remember reading him as well. He made a comment that we’re still answering the same questions. I’ve been working with someone, and they have a new CIO that’s coming in. They said, “We hope this one gets it.” Sometimes people at that executive level come from these great minds with creative and visionary ideas, which is great, and/or they came from a development background: they build, they code, they’re architects, but either way they fall short with how the requirements get defined (and all the stuff that goes on in between the idea and delivery of the solution)…

Kupe: Where the magic happens.

Jacqueline: Yeah, where the magic happens. They don’t get it. For whatever reason, they know when the project is over, and if something doesn’t go right, it’s a missed requirement. They always know that part, but they don’t know in the midst of it to ask, “Can you help me find any missing requirement?”

Kupe: Right. As you said, people know what developers do. People that build stuff or do something that you can see and touch, it’s easier to explain their professions. If I build or design cars, that’s pretty straightforward. I’m a baseball player, basketball player, soccer player. The results of what they do are very tangible: you can touch, you can see them, feel them.

However, what we do, we’re in that knowledge worker kind of space, and it’s really hard to explain what we do, how we do it, and why we do it. Even all the elevator speeches that I’ve tried to come up with, my wife is still clueless about what I do; well, not clueless, but she just doesn’t get it. It’s just a hard thing for people to understand. My parents don’t understand. I used to work for Turner Broadcasting, and my dad would just say, “Oh, he works for CNN.” That’s as far as it got. He just thought that was cool and I’m like, “Yeah, that’s good dad. I work for CNN.”

It’s just this intangible stuff that is happening with us day in and day out that there’s nothing to grab on to. If you’re a landscaper, then ok. I get it. You manicure lawns; you do hard landscapes and soft landscapes; you plant flowers. It’s easy to define a landscaper because you can envision and see what they do. You don’t see what we do. People are like, “Oh, look what the developers did. They built the solution.” Well, yeah, but without us it might not have been looked at.

Jacqueline: Exactly. You’re right. Even with conversations David and I have, and David is a project manager in IT. I’ll especially hear him comment on his experience when working with BAs on his project, like, “This BA didn’t know how to write a business case…” There is such an array of how BAs practice what they do and what they see as their scope of work. David has the image of the B2T BA and of our conversations that we have on the show. I feel that he finds sometimes when he’s out in the ‘real world’ and talking to people who say, “I want to be a BA,” – their definition is different from our definition. They don’t have that same skill set or breadth that we have and that we talk about so much.

Kupe: Yeah. There’s not a BA. You sent me an email with a comment from one of the listeners in an article that he wrote. Eric Provost wrote about the wide variety or different specialties of BAs. In the BABOK 3.0 version, they’re calling them “perspectives.” There are systems analysts, process analysts, agile analysts, data analysts, and more; there are all these different types of BAs, and there’s such a wide range of stuff. If you expect to look at 3 people who call themselves business analysts and get a similar type person, it’s not going to happen. I just wrote a blog on BA Times online magazine about how to find the right BA.

Part of the challenge is, for people looking for BA roles, they can’t go from company to company and compare. If you see a title for a senior business analyst at one company and a job for a senior business analyst at another company and assume that it’s the same thing, it probably isn’t. Sometimes senior BAs in different teams or different departments within a company are different. It’s the same thing when you look at titles of BAs and look at me and you and say, “Kupe’s a senior BA and Jacqueline’s a senior BA, so they must do the same thing.” No. We have different strengths. It’s tough, and it’s not that easy.

Jacqueline: We want our listeners to weigh in. You can follow us on Twitter. Jovan is tweeting and quoting us as we speak. That’s under @TechExpresso247 . Our hashtag is #AskAnAnalyst. Give us your perspective.

Here are some of the #baot and #askananalyst recent tweets.


Jacqueline: One thing I was about to say is I kind of have my own little ongoing protest going on about the titles of ‘Business Analyst,’ and ‘Senior Business Analyst.’ Titles come with a certain expectation, and I dare say, sometimes it’s a low expectation of what we really can bring to the table. I just made up my own title. I want to be a solutions analyst, but that’s just me. I’ve heard some other ones out there, too. What should we be called?

Kupe: That’s a good one. I’ve heard it used. A trend that I see with a lot of the people I talk to, some of the good ones don’t call themselves business analysts anymore because of that perception of a lower level, entry-level type initiative. There was a company that I saw the other day looking for Senior BAs and Lead BAs. A Senior BA had 2 years experience and a Lead BA had 4. That, to me, is not what a senior BA is. That’s what they might be calling a Senior BA, and you just have to look at the job description and see what it really means.

Even when I was Senior BA, and I was Senior for a few years, and I felt uncomfortable with my title. I had to challenge myself to see if I could really be what I believe a Senior BA is. Years help you get a certain amount of experience, but if you’ve been doing the same thing over and over for 6-7 years, to me that’s not the view of a Senior BA. That’s a whole other topic. To your point, you want the Solutions Analyst, but other people are like, “You know what? I’m not even putting analyst in there.” Some call themselves ‘architects’ because it might get viewed as a much higher level role.

Jacqueline: Exactly. I’m there with you. I’m curious of those who are listening, maybe you want to tweet or send us a message: how do you feel about the name, the title ‘Business Analyst?’ Do you think we should just keep trying to change the perception, or do you think that it has worn out its welcome and we need to look at something else that better encompasses what we do and what we bring to the table. We often talk about the tactical BA vs. the strategic BA. When you’re operating at such different levels but at every turn everyone is trying to keep you in this limited kind of scope, like I said before, you feel like you’re not being fully utilized and/or you’re spending a lot of money on note-taking.


Let me go into our 5th question, and this question comes up often: How technical does a business analyst (an IT business analyst) need to be?

Kupe: Yeah. I see a lot of these questions, and sometimes I like to look at the question behind the question. For example, why would someone ask how technical do I need to be? Why would someone ask how much do I need to document? Why would someone ask how do I know I’m not missing anything? I feel these questions come when a BA has been challenged, and I see on LinkedIn a lot people saying, “I’m in this type of industry. How should I document these types of requirements?” It comes down to the lack of collaboration and what teams need.

There really is no direct answer. I could tell the BA community that from a scale of 1-10, you need to be a 7 on the technical side to what your role needs, what your team needs, or what your organization needs you to be. Also, you have to define what you value. Do you like being technical? Do you like the technical side? Do you like to keep up with new languages and technical solutions? Do you like to know the latest and greatest thing?

I’m kind of stumped in the point of I can’t answer that question directly, but if your team needs someone to be more technical and help the team make decisions on things like the database, then be that person. If you look at data, a non-technical BA is going to be talking to the business about their business data and understanding the data needs they need to run the business. Now that we understand what the business needs, where do we actually store that data? What database do we put it on? What server is it on? All these things. A lot of teams, their technical staff – the developers and tech lead — handle all that stuff.

Other teams just want their developers to enter the information based on what you give them. I haven’t personally worked as a BA with offshore developers, and Jacqueline, I know you have, but some of those relationships are like “tell us exactly what you want done, and we’ll code it.” Then, you have to be really technical. If you don’t have that situation and your developer can handle that — in the end, it goes back to capabilities. What capabilities does your team need, and can you fulfill those capabilities? Sometimes I wouldn’t be a great BA if I needed to dip into the technical stuff. I wasn’t a developer. I understand enough to have the conversations and sound credible, but I can’t run SQL Queries. I don’t know any of that stuff, so I would not be a good BA for that team.

Jacqueline: Absolutely. Let me weigh in on this one as well. This question actually came up today, so it is not only a frequently asked question but a “RECENTLY” Asked Question. Most of the time when I get the question, it’s coming from someone that’s from the business side and/or a subject matter expert. Sometimes I find people who want to transition into IT and be a BA.

Today, I actually used the analogy, because we were talking about job shadowing, and I said that when we’re thinking about business and we’re trying to learn what the business does and how they do things, we recommend job shadowing. Go and observe them, ask questions, and that type of thing. It’s not that you’re ever going to do their job, but it helps you learn the language, appreciate the environment they work in, and so on and so forth. I then directed them to job shadowed their technical team as well: This is something I do regularly. The tech team would let me come to their design meetings, come to their desks, show me what it takes for them to code the requirements they gave me.

It’s been so long ago when I got my degree in Computer Science, but I learned enough in getting that degree to know that I didn’t want to be a coder. I just wanted to learn the language, and like you said, I do it because it gives me credibility and helps me build relationships with the technical team. I just want to sit there and glean something here and there that might cue me to ask a question and/or think about a way of approaching something. I think they respect that. I would say shadow the Business and the Tech team – give equal time to both, equal opportunity.  Not that you’re ever going to be a coder, but make friends with those coders, make sure you show an appreciation for what they do, and learn how to speak their language.

Do it because IT resources are your stakeholder and the solution you’ve built is based out of IT, it takes me back to a basic conversation with my dad. He would say, “If you’re going to drive a car, you need to know a couple basic things.” I feel the same way with building software. A BA needs to know a few of the basics. Does that make sense to you, Kupe?

Kupe: I completely agree with you. There was a guy I met for lunch last week, and he’s more on the PM side though he’s interested in the BA side of the house. He’s thinking about going into that within IT. He was a PM outside of IT, so he’s trying to be a BA in IT. He went to a Java class, and he’s like, “That stuff was way over my head. I could never code like that. I don’t want to code.” I’m like, “That’s fine, but what you need to get out of that class is enough to be credible to have conversations, to know what questions to ask, and to know what your developers are going to be up against.”

You have to know how to write the requirements and then communicate the requirements to help make their job easier. On the flip side, I know technical BAs. When you see roles that are systems analysts, those are more technical people who need to understand SQL Queries, databases, fields, and all of that more detailed stuff. If you’re not on the technical side, you need to know enough to have a conversation. I love how you stated it, and I’ve never stated it like that before: you give the time to the business, but if you’re an IT BA, you also need to give enough time to understand how the solution is being built, so shadow and observe your team; have conversations with them.

Jaqueline: Absolutely. These are real questions, and the space is tricky, so it does help to talk about it and talk through it. We see it all the time with our students, where sometimes it just helps them to hear that other people are still grappling with the same thing; no one has the perfect, out of the box answers to these questions. We are still picking up different sound bites.

Like you said, you’ve been trying to come up with your elevator pitches for your parents, your wife, and others. We’re still working it out together; we will work it out for sure.

Episode Comments

We are going to switch gears: Celice is on the line with us, and she has some of the comments that some people wrote in. Before we jump to another question, let me see if Celise has one of those queued up. Celise, are you there?

Celise: Yes, I am.

Jacqueline: How are you this evening?

Celise: I’m good. How are you guys?

Kupe: Awesome.

Jacqueline: We are great. Would you read one of our comments and questions? And then we’ll comment on the comment, and then I’ll have you read the next one.

Celise: It says, “In my opinion, business analysts should be themed as a continuum of responsibilities.” Building bridges between business and IT can mean a lot of things. I wrote an interesting article about this continuum a few months ago, which you might find interesting.” There’s a link to it from Eric the BA.

Kupe: Yeah, that’s Eric the BA. It’s funny that he’s Eric the BA, and my LinkedIn is Kupe the BA; a lot of people do it. I think that article is what I was talking about earlier, Eric Provost’s article about the multiple flavors of business analysis. We hit on this. I think I gave this comment a good talking to already, so I don’t want to add too much. One of the things he wrote there is “building bridges between business and IT can mean a lot of things,” and I want to hit on that portion of his comment because there was a point in time where that bridge was more like a ferry. A good friend of mine, Jefferson Davidson, does a great illustration of this. We were acting out the ferry-boat.

It was more viewed as a ferry where you would talk to the business, and then you would go on the ferry across the river to the developers and talk to them and translate. It was like you were talking 2 different languages and translating what is needed. I think the bridge, now, has to be a bridge where we bring people together and have conversations. I talked, on the last show, about not shying away from your business stakeholders. One of the questions was “how do I keep the business from going straight to the solution.” Don’t stop that.

The business now knows enough about technology; there’s so much technology in everybody’s pockets or hands with their smartphones that the businesspeople know technology. Don’t shy away from that. Developers are also starting to understand the business better. It’s not just a bunch of people sitting in a dark room coding cool stuff. They know enough about the business and the business knows enough about technology, so don’t be that go-between and be the one that wants to talk to both sides. Bring everybody on that bridge to have that conversation.

Jacqueline: Excellent. I agree with you. I have nothing to add. Well-said. Celise, why don’t you give us our next quote?

Celise: It says, “A lot [of what] I know as a BA in IT, I am responsible for ensuring the collection and analysis of business requirements. I know I’m responsible to liaise between the development team and business team and that my job will never fully describe what I’m responsible for.” This quote is from Brenda (Hill) Boon (@baboon_40). That sounds like everything you guys have just been talking about, with not having a set job title description but just kind of doing what you know needs to be done with what you’re doing.

Kupe: Yeah, it dovetails into what we just talked about, but it just makes me think that people view the role as a set of tasks. She said a “collection and analysis of business requirements” and the “liaise between the dev and business team.” A lot of people view the role as a set of techniques. You do these techniques. If you look at job descriptions out there, they’re like, “Do you do use cases?” “Do you do user stories?” “Do you know how to do workflow diagrams?” All that stuff is a means to the end, but that’s not what you really do. I mean, you do all the things we’ve been talking about on the show. That goes back to it not being a simple thing to explain what we do in this profession.

Jacqueline: Absolutely. The one thing I want to add, and good point Celise that it encapsulates what we’ve been talking about. Something that you said is key, Kupe. Referring this role to knowledge workers, and with that, the knowledge is also that critical thinking. We’re really thinking on our feet, and we talked about doing exercises where it’s the day in the life. If someone really stepped into our shoes and did a day in the life of the BA, I come in that morning, assess the situation, and figure out what I have to do and where I have to be for the success of the solution. That’s why I just crowned myself as a solutions analyst and/or architect; I might get a promotion after this call, but I’m not sure. I have to have a good talking to myself.


Jacqueline: One of those things is that you have to be thinking on your feet. There’s never just one thing, and that’s probably what I love most about the role, is that everyday I’m going to be challenged. I’m going to assess the situation, give it my best shot, and then the next day I’m going to try it all over again. It’s a constant mode of problem-solving and leaving yourself open and flexible to whatever it takes for the team and for the solution. That really separates from the good, and I’m not going to say bad BAs, but from those BAs that just want to make sure and take it to the next level.

Kupe: Yeah. What you said at the end, the good, to your point, there aren’t good or bad BAs, but people are doing what their management is asking them to do. That’s just natural. I do think the people who look at this role as a job…I don’t know if I’ve mentioned this before, but I wrote a blog about how business analysis is not a 9-to-5 job. You are problem-solving, and the answers to the questions you have or the analysis you’re doing don’t come to you just 9-to-5.

They come to you while you’re driving home. If you’re in Atlanta, then I know you and I both have some fun commutes getting home. You have a lot of time in the car. They come to you in the car, in the shower, and sometimes I wake up in the middle of the night. I ask BAs, “Do you have a notepad in your nightstand?” If people say yes, I’m like, “Awesome.” I wake up and I have an idea that I need to write down because then I’ll never get to sleep because my mind starts racing. You have to look at this as a profession, a career, a love. It’s not just a 9-to-5 job.

Jacqueline: So true. Let’s see if we can get one more of those comments in, Celise.

Celise: The next one says, “What do BAs really do? Lots of us guide the business to doing the right thing but most also focus on getting over the current fire.” That statement was by Paul Mulvey (@PaultheBA) who is also co-author of Business Analysis for Dummies. That’s the end of the comment.

Jacqueline: It goes back to what we said: it’s what their organization or that project is demanding at the moment. I find this to be true, that the role ‘Business Analyst,’ sometimes people are just in that firefighting mode.

We sometimes have those students, and they have never seen a project from beginning to end. I remember it being important to me that I wanted to take a project full life-cycle, so I looked for those opportunities that were starting something from scratch. That was something I gravitated towards. Some of those projects crashed and burned. I was around when the bubble burst, but I still had some great experiences where I was a part of projects from the beginning, taking a blank sheet of paper all the way through.

You said something earlier. You said if someone asks you to do something that’s impossible, get your keys and say, “Thanks for the opportunity.” Sometimes a BA has to say, “You know what? I’m not being challenged here. I’m not bringing out the best in me. I’m not growing.” You have to move past just the firefighting. I had some students that asked, “When should I leave?” Only you can answer that question, but I said to a person that was still early in their career, “It’s way too early for you not to be developing and learning at every opportunity.” We always talk about continuous learning. Don’t let yourself get too stagnant, because sometimes your work terminate you before you’re ready to terminate, and then you find yourself searching for a job and having stagnant skill sets. That’s my reaction to part of that. Anything you want to add, Kupe?

Kupe: Yeah. I love the honesty, because this is reality. Jacqueline, you and I did a presentation on that people know that business analysis is about stepping back and making sure we’re working on the real problem, but that doesn’t happen all the time. It goes into this firefighting mode. I think some people enjoy that firefighting mode. Back to Eric’s post about the continuum of BAs, there is a need for people to fight fires. We have organizations that have to keep the lights on, and we have to fight fires. You have to analyze what’s going on in order to make good decisions and help your team make good decisions on how to move forward.

There’s a need for EMTs, and there’s a need for ER doctors. Are those ER doctors thinking about long-term, what is right for this patient? No. They’re thinking “right now, how do I keep this person alive that fell really bad, hit their head and their bleeding? What do I need to do now to stop the bleeding and get them stable?” There’s a need in the BA space for those type of people. Companies need that. On the other hand, there are doctors thinking about long-term plans, “How do we need to change your lifestyle? What medication do you need to get over this hump?” They think about the right thing to do overall for your health. We need BAs to do that kind of thing, too.

To your point, Jacqueline, if you’re the type of person that likes firefighting, then ask those questions and try to find an organization that needs somebody like you. If that’s what you love to do, then find an organization that wants that, values that, and needs that. On the flip side, if you’re a strategic BA, as this person said, guiding the business to do the right thing, then look for organizations that value that and that wants you to do that. That’s my two cents.

Jacqueline: You’re absolutely right. I love the analogy of the ER doctor: very necessary, and nobody is looking at them as lesser. We need ER doctors; that’s a specialty, all of the things they have to do very quickly. Then you have that doctor that’s looking at long-term. I love the analogy, and you’re right. That’s why I backed off earlier. We shouldn’t look at a good BA and a bad BA.

I like that comment about the continuum. People are on different ends of the BA Career Spectrum and everything in between. To our audience, if you like where you are, then continue to cultivate that. If you’re looking for something different, there are a variety of opportunities out here. In my mind, there’s no need to not enjoy and feel passionate about what you do. Like Kupe said, it’s important for the BA role to look until you find that position that fits that area in you that brings out your passion.

Kupe: I think that’s the beauty of the role. You can look at it as a frustration. There’s no definition of a business analyst. Everybody has a different definition. Every BA is a little different. You can look at that as a negative, but I actually look at it as a huge positive.

I got out of the accounting field because accounting, even though there’s some variation, for the most part, accounting is accounting. The repetition of the work just killed me; I couldn’t do it. I’m so glad other people enjoy it because we need them, but it just wasn’t for me. With the accounting I was doing, there was monthly things we did, quarterly things we did, yearly things we did, and it was start all over again. Just keep cranking. It didn’t excite me.

In the BA field, if you look at that continuum from the firefighters to the long-range strategic type people, there are so many things in between that you can find things in the BA space that will fit what you’re excited about. Every organization, especially large organizations, have different needs. To me, it’s exciting. It’s actually better. We’ve been talking about keep trying to fight the good fight and get people to understand the BA, but I’ll throw this out there: maybe we’re talking about the wrong thing. Maybe we shouldn’t worry about that and we just keep going and figuring out who we are, where we are, and help organizations get better depending on what they need.

Jacqueline: Absolutely. Maybe that is the answer. I’m definitely open, and I think you and I, Kupe, discover things on this show as we’re pinging back and forth. Sometimes I do find those people going into the field or have been in the field frustrated, but maybe it’s about your perspective. I’ve been in it for many years and wouldn’t trade it. Like you said, I find those aspects of it that I like. A lot of people know, when I introduce myself, I say I love my job. I don’t like every aspect every day. There is always something on any job that you may not be crazy about, but I do love what I do. I’ve always been able to find a passion, which is, for me, problem-solving, solutioning, and being that liaison. You have to find what you enjoy.

Kupe, we’re about out of time, and you know whose voice I haven’t heard?

Jacqueline: To our audience, Kupe is one of the co-writers of “BA for Dummies,” and if you just want to learn some of the basics, just stick your toe in, the book is great exposure. It’s available on Amazon.com. Do you have anything else coming up soon, Kupe?

Kupe: What do I have coming up?  I’m going to do a couple of improv talks, one in Wisconsin and some other ones coming up in May. The most recent thing I’m doing next week is going camping at the beach with my family, so that’s what I’m excited about.


Kupe: Right before the show we were actually doing a little brainstorming session, requirements gathering of what stuff we need to take with us.

Jacqueline: Dave, are you with us?

Dave: Yes, I wanted to comment on the last line of discussion around naming conventions for BAs. I think there’s a strong parallel with business analysis and project management. There are some activities that overlap, however, I do want to say that the BA skill set is a totally different and defined skill set. I don’t mean to minimize the impact or what you guys do; it’s very much appreciated. I like to lean into that business analysis world a lot, because it helps me be a better project manager.

For project managers, there are different flavors for project managers, and you have to know where your comfort zone is. Right now, my comfort zone is in infrastructure and building architecture. That’s what I’m enjoying right now. It leans into software development as well, because architecture is, of course, a software. I enjoy leaning into that environment. I’m working with a lot of BAs in my department, now, that came from the financial side of the house. They hadn’t done a business case before and they hadn’t done a business case estimate before. There are a lot of activities within the business analysis space that you may not have done.

As a project manager, there’s a lot of type of project management that I have not done before. I have not done financial project management or other sectors around the industrial environment. You can’t just jump into an environment if you don’t have a certain level of expertise, you have to know how to ask the right questions. You have got to get into that space a little bit; step a toe in and get some exposure so you can ask the right questions.

Kupe: David, that expands on what Jacqueline was saying earlier when we were talking about how technical do you need to be. That question gets asked a lot. It’s not just the conversations with your developers or the business, but it’s with everybody you’re interacting with. As a BA, you need to talk to your PM, and as a PM, you need to talk to your BA. Connect all the pieces that are around you; that’s how we get better, that’s how we’re more credible, and that’s how we understand more, which goes back to your point, Jacqueline, about always learning. That’s the attitude that you have to have.

Part of it is, unfortunately, that you can’t do all of that, dipping your toe in, when you’re already on a project. If you go back to the people that have to fight fires, they don’t have time to talk to their PM or the developer about this kind of stuff, but they’re just trying to put out the fire. You have to find ways to have those conversations outside of your initiatives. Hopefully you get time for lunch. Go to lunch with your team members, have a coffee with them, and find ways to have conversations. By the end of the day, I’m always trying to meet new people and talk to people, so I don’t want to talk on the phone. At night, I’m done. I don’t want to talk on the phone because I’ve been doing it all day long. I think that’s how you need to feel coming out of your job.

Jacqueline: Absolutely. I want to piggyback off of what David said, too. We are always welcoming PMs to take some of the business analysts class because to David’s point, in their role to ensure a successful project, product, and helping to set expectations, they also find themselves asking questions and supporting the BA and vice versa. I can definitely say that I cross-train in understanding the PM. I’ve learned enough that I don’t want to be a PM, but I also learned how to support them and what a tough job they have. The cross-training is key.

Thank You – Until Next Time – April 12 @ Noon EST

I want to thank Celise Blackman. I want to thank Jovan Grant for tweeting her heart out; We have some good quotes out there. Thank you Kupe, once again. I look forward to talking to you in 2 weeks or so as we continue to unravel the mysteries and answer questions. Send in your questions everyone! David, thank you, of course, for joining in as well. Until next time. Thank you B2T for sponsoring this show. Bye everyone.

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:

About Kupe

“Kupe” Kupersmith, President, B2T Training, possesses over 18 years of experience in software systems development. He has served as the lead Business Analyst and Project Manager on projects in the Energy, television and sports management and marketing industries. Additionally, he serves as a mentor for business analysis professionals. Kupe is the co-author of Business Analysis for Dummies, a Certified Business Analysis Professional (CBAP®) and an IIBA® Board Member. Kupe is a requested speaker in the BA field and has presented at many IIBA chapters and BA conferences. Being a trained improvisational comedian, Kupe is sure to make you laugh while you’re learning. For a feel for Kupe’s view on business analysis topics check out his blog on BA Times. Kupe is a connector and has a goal in life to meet everyone!

Pin It on Pinterest

Share This