As Jacqueline and I continue down our path of frequently asked questions, we’ve found that a lot of the answers are it depends. However, a lot of the “it depends” can really depend on your attitudce. This week, I hope that we can convince you that having the right outlook and attitude can contribute to your success as a business analyst, even when you are stuck on an impossible project!
Episode 9 | April 12, 2016 Business Analysis Podcast Transcript
Jacqueline: Hello. Good afternoon, good evening, and maybe even good morning somewhere. This is Jacqueline Sanders with Technology Expresso Cafe Radio. Welcome to another edition of #AskAnAnalyst with none other than Kupe from B2T Training. Hello Kupe.
Kupe: What’s up? Good afternoon! Ready to go!
Jacqueline: I know! 2 weeks flew by…t677676he whole time I was thinking about where our conversation ended and where we are going next, because it’s really starting to heat up. We’re really getting our momentum. We’re peeling back the years. We’re being analysts, and we’re analyzing this whole space. This is our 9th episode. We have our archives, 1-8, that you can go back and visit (see the end of this post for links). We’re dealing with the questions that come to us from students and from people that we’ve talked to about how to crack some of the things we see over and over in projects. That’s one of the things that we ended in the last episode.
Some of the frequently asked questions have included: “How do I know when I’m done?” “How much documentation do I need to do?” At the very end, we even asked, “Are we even asking the right questions?” That’s common to analysts. Do you remember that comment at the end? That really was a start of a whole other vein of questions. We can talk about what the business analyst should be doing and how they should be approaching it, but a lot of it, we respond with “it depends.” Let me throw it to you, Kupe. Where was your mind when we ended on that note of saying: “Are we even asking the right questions?”
Kupe: Yeah. I’ve been in this space over 18 years, and Jacqueline, I know you’ve been in it as long. The similar things pop up all the time, so what is it that we’re trying to get after? You and I had the conversation a few days later around “is it even just about what the analyst have to do or is it the makeup of the whole team?” What works for Team A might not be what works for Team B. In the end, it comes down to the culture and the organization. It’s not just about following processes or thinking about what documentation needs to be done. We want successful projects, so how do we go about doing that?
Jacqueline: Absolutely right. That is so important, and that’s why these conversations aren’t just directed at business analysts. We have to broaden who is having this conversation, because everybody, at the end of the project, seem to know that requirements is why the project wasn’t successful, wasn’t as successful, why something was missed, or why the client wasn’t happy. They know that at the end of the project, but join us in having the conversation at the beginning so we as a team are thinking about what we need to do so we’re not having that conversation on the backend about what is missed. That’s the foundation for some of our conversations, and I really feel like we’re now peeling back the onion. There’s definitely a lot of advice we can give people, and we still welcome any question.
We’re always open to your questions (leave a message for us 855-484-6837) that are on your mind that you’re dealing with at the moment. It might be about the documentation or how much or how little, but today, you’re going to find that this level of questions is about looking beyond just the business analyst. Let me go to our first question, and as we respond to this, we’ll hit those different areas. We’re hitting all cylinders, today.
BUSINESS ANALYSIS FAQ – #1
Kupe, what advice do you have for people on “impossible projects” and where the business analyst feels like they’re the one that’s always being blamed? Sometimes we say if you’re in a bad situation, just leave; just go find another opportunity. However, not everyone is situated in the middle of Atlanta where there are opportunities at your fingertips. Sometimes you’re in an organization and the BA feels backed against the wall. What can we say to them?
Kupe: Impossible projects…that’s a pretty broad thing. There are a lot of things that could seem real difficult. First off, everything is possible, but there are factors that cause projects to feel impossible, burdensome, or tiring. You’re right, do you have an opportunity to move, leave the project, and leave the company? You don’t want to be miserable doing this stuff. You work everyday, so you have to find ways to make sure that you’re feeling fulfilled and happy. When it comes to “impossible projects,” challenging groups of stakeholders, or challenging processes that you have to deal with based on what’s happening in the organization.
I think it goes back to the old saying: “How do you eat an elephant?” It’s one bite at a time. Don’t try to say “The next project, we’re going to completely flip everything around and it’s going to be so much better” or “I’m going to push hard to change our project process and do it differently so that we could improve.” It’s finding little things one at a time and knocking them off the list. If it’s stakeholder engagement, then try to find one stakeholder on the next project that you were struggling with on the last project. Now, how do you get them on board? How do you work better with them? How do you collaborate with them? If it’s within the process, maybe a lot of organizations have PMO’s or an organization is responsible for the processes and the tools that you use. Maybe go to them and say, “Can I not do this piece for this project, and here’s why.”
Just pick one thing and slowly work out all the challenges and the inefficiencies that are going on. It’s hard for me to pick out one thing, because there are so many different challenges that there can be. You need to go after that one thing, and maybe every project, it might take a year or two, but every project try to chip away at those things. You’ll start to feel some pride or enjoyment out of making the changes that you feel need to happen and hopefully everybody else will be excited about it, too.
Jacqueline: That comes with some of the territory of being in environments that are ever-changing and being a change agent. It’s interesting that as business analysts, we’re always walking into the business, whether it’s something they requested or a need in the business, we’re changing their world, and at the same time, within IT, there is always a backlog of things that can be done differently or better. Sometimes they’re still doing things they’ve always done it and you have to break the cycle and get people on board.
Everything you just said, Kupe. We’re doing both outward and inward within IT. You have to bear in mind that people change, and sometimes it’s uncomfortable. It’s the people aspect of just bringing about change, and like you said, you just have to be patient both with your internal team and with your customer base when you’re trying to do new things or you see better ways of doing things. A lot like the business, IT is trying to get whatever is on their plate today done, and they don’t have a lot of time to think about “We could be doing it this way.”
Kupe: The other thing to remember, too, is that, especially in large organizations, reorgs happen and people leave and new people come in. You could be headed down a path where you have a director, a manager, or whoever some of the key decision makers are to make change happen, you have them on board, and then all of a sudden there’s a reorg and that director moves to a different department and a new director with different thoughts and ideas comes in. You might have to start over. That’s just a part of the change, and by hopefully sticking to smaller items, you can get things underway quicker.
The smaller something is, the easier it is for somebody to say, “Yeah, we can do that.” If you go to your director and say, “We need to change our entire project process, and here’s what I have laid out,” they’re going to be like, “Woah! I can’t consume that. There’s no way we’re doing that. There are too many parts and pieces.” However, if you say, “For this project, I want to tweak this and do it this way,” they’ll probably be like, “Go for it.” Then you can show, “That tweak really helped. On the last project, we were able to do this a lot better.” Then they might be more open and be like, “Let’s talk to other teams and see if they want to do it.” Eventually things start to steamroll.
Doing things in smaller chunks — that’s not a new concept, so I’m not claiming this as “Kupe’s new idea” or “Jacqueline’s new idea.” Do things in smaller chunks, try to bring people along, and be patient.
Jacqueline: Exactly. The other piece is that some people feel that only your company is dysfunctional. I dare say that some people, even when you live somewhere like Atlanta and you have a lot of opportunities, you may find yourself jumping from job to job because you’re trying to find this utopia. That’s a complete misunderstanding. I’ll let you speak to that and see what your thoughts are.
Kupe: Yeah. I compare that to everybody thinking that there’s a perfect family out there. “My family’s dysfunctional. Why are we dysfunctional? When you look at their family, they look like they’re so put together.” That’s crap. It’s not like, “Here’s a functional family, and everybody else is dysfunctional.” Everybody operates the way they operate. I’m not talking about real, unhealthy habits going on in families or in companies. I’m talking that there’s just not a utopia, as you say. There is not this perfect organization where everyone’s happy. There are companies that lean towards that and others that don’t, but there is no one right company you have to find. This goes back to the question that they couldn’t leave. You have to find organizations that believe in your culture.
You need to be a leader, and you can change that culture. You have the ability. It doesn’t matter where you are within the organization. You can begin to change that culture by acting the way you want to act and by bringing people along with you. Then, people are going to want to be on your team, and the people that want to be on your team are the ones like you. So, you can start to build this culture from the bottom up. You also don’t have to change the culture of an organization, but you can change the culture of your team. At least you’ll be happier and you’ll enjoy coming to work and being around the people you’re with. Back to the point: there is no functional company that is the best. Everybody has their glitches, differences, and changes. There is no utopia out there.
Jacqueline: Exactly. I have to use a phrase of Tasha Hurley, who often joins us on our noon day show. She’s on her Spring Break, so I hope she’s enjoying it and will join us back when she comes back this way. One of the things she always says is at the moment something might feel like a frustration, but keep asking, “What can I learn/get from this?” That’s an attitude and mindset toward that particular environment. I often used to say of the things I would experience, “These are going to be great war stories when I get in training class because I can share them with the students.” Sometimes you’re in a position where you’re learning what not to do so you can apply it later. Some people think that their company is the only thing going through something.
I as a consultant, I walk in organizations and really had no leverage to tell them what and what not to do and how to do it. I was brought in on some of those assignments just to work a piece of a project. At the same time, I had certain tools and techniques that I used. I didn’t necessarily ask for permission, but I did them in the background. Sometimes people miss that opportunity. I hear them say, “They won’t let me,” and I’m thinking, “Do you have to have permission and/or can you actually, through using it and having success, be able to introduce it?” I literally had people approach and say, “How did you know that so fast?” or “You seemed to have the answer when we were talking,” and I could refer back to a tool or a technique that I was using. I don’t know if you had anything you wanted to add to that.
Kupe: I was just talking to one of our other instructors yesterday about that exact topic. We have people in class that say, “We don’t do that at company X,” or “That’s not part of our deliverable package and it’s not going to change. Why bother learning that technique?” The reason for learning that technique is not for deliverable or that it has to be approved as a step that you do. They’re used to analyze the situation, so if it can help you analyze a situation, do it. Do it on your whiteboard, your notebook, or your PC. You don’t have to show anybody.
I talk about the context diagram. You’re using the context diagram, and your company doesn’t use that as a communication mechanism or a deliverable. That’s fine, but you can throw it up on the whiteboard based on the information you have and start to see, “Am I missing anything?” You never need permission to use any of the tools and techniques, because there’s analysis time that you have to do with just you or your team that doesn’t include everybody.
I read an article yesterday about the choices millionaires make. This article was about the choices that people rich in money make and the things that they do. One of the things they talked about was rich people choose to focus on opportunities. They see potential for growth. Poor people see potential loss. Rich people focus on the rewards, while poor people focus on the risks. Poor people focus on the obstacles, while rich people focus on the opportunity. I think when it comes to impossible projects, don’t focus on the obstacles that are in front of you.
Look at in from a different lens and look at it in a different way to see the opportunities. Say “What do I have the opportunity to do to make this better?” rather than saying, “There’s this obstacle around our project process,” or whatever that obstacle is. Rather than thinking about the obstacle, think about opportunities. To your point, Jacqueline, “What are the opportunities for me to do this stuff,” and then do it. Focus that way rather than looking at everything like, “Another wall…another wall…another obstacle.” That gets tiring. I’ve been there.
For the most part, I’m an optimist and I try to live my life that way, thinking about, “Yes, it was a failure, but what does it mean? How can I learn?” We’re human, too. For anybody to think I’m always like that, I’d be kidding myself. There are times when I get down. When you think about it, it just sucks the life out of you. I just choose to try to flip it around. It’s good to know that I make a choice like millionaires. I’m not a millionaire, but I’m making choices.
Jacqueline: Yes, you’re just like all the other millionaires.
Kupe: I act just like ‘em. I just don’t have the bank account.
Jacqueline: That’s also good for people on impossible projects on how not to get stressed out. If you focus on the impossible part, then it gets built up inside of you and you start dreading every aspect of your work because you’ve labeled it this “impossible project.” There are some projects that on the front end, I’m thinking to myself, “I don’t see it, but maybe someone else knows something I don’t know.”
I remember one project where I had the attitude that, “If this is what I’ve been assigned, then I’m going to try everything in my power to make it a successful implementation.” We tried every different angle that we possibly could, and we happened to be working with a third-party vendor. Some of my students have even spoke to this, where they’ve been in situations where there wasn’t a formal evaluation or gap analysis like there should have been. It was more saying, “I went golfing with a buddy and his nephew built this system, so we’re going to use it.” My mindset going into it was, “This is the hand I’ve been dealt.” We went full steam ahead and did everything on our side to make it successful, and it really was the vendor that finally said, “We can’t make this work.”
My point of view was, “We did our side, and I always give 100% as if this was the one that was the solution that was in fact the best choice.” They finally admitted that they couldn’t provide us with what we needed. It was a success, so why continue to waste our money and invest small-term in this? We hadn’t gotten to go live or any type of big conversion. Sometimes you go to that conversion, and now you’re going to live with whatever they have to offer. I felt like we stopped it before it became a financial nightmare. There was some success out of it, but that was how I decided to look at it. It’s all about you mindset; sometimes you just have to do that for your mental sanity, because otherwise you’ll get stressed out if you just focus, as you said, on the obstacles, on the risks, and that type of thing.
Kupe: You made me think of that you have to remember those times. A year down the road it may happen again. There’s some other cool tool that someone feels is going to be a great opportunity to implement, and they want you to go ahead and implement it. It’s easy for them to forget that there was a similar situation. You could say, “Before purchasing it, why don’t we do XYZ first. It may save us more time and money.” Helping people remember that when you’re in a situation that smells a lot like the other one did, then “Hey, let’s take a quick timeout and try to stop,” or decide, “Yes, you are right. It is the right decision, so let’s move forward and implement it.
Jacqueline: Absolutely. Kupe’s available on Twitter: @Kupe. I’m @RequirementsPro, and also, there’s @TechExpresso247. Jovan is on Twitter right now and sending the questions out so that you can see the questions and answers that we’re going through today. It’s all about project success. It’s more than pointing fingers at one person on the team or pointing fingers at just the business analysis. It’s about broadening this, because everybody on the team has a stake in the project’s success, so what can we do as a team?
BUSINESS ANALYSIS FAQ – #2
Let me go to the next question: What do you do if management doesn’t support time-tested practices such as prioritization? Some people say “best practices,” and they’re using the phrase “time-tested practices,” but there are definitely ways that management can support those things that has already been proven. However, just because it has been proven, it doesn’t necessarily work. I’ll let you take that.
Kupe: Just to clarify, my view on best practices is that as a whole, when people say “best practices,” don’t just accept it as it is. A practice was best in a particular situation, and your situation might not be exactly that. You have to figure out how to implement this practice so that it fits in your organization. Don’t just say, “Oh, this is the best practice. Let’s do it.” Things like prioritization, there are different ways to do prioritization that are better than the others, but the fact is, you need to prioritize in some form or fashion. I like using the phrase “putting things in order,” because with prioritization, people typically think that there’s high, medium, or low. If you order things, something has to be first, second, and third.
What do you do? It goes back to your answer, Jacqueline, that you don’t go ask your manager for approval to prioritize. This is a hard one, because there’s no way for a team to operate if they don’t have a priority. This might dip into another question we have, Jacqueline, and I apologize for going off script a little. I feel like teams that don’t prioritize are set up for failure. The team is held to a budget and a timeline, one scope is finalized, and they have to do everything in that budget and timeline.
Well, what we’re doing is not manufacturing where there are years and years of experience and we’re building the same exact car or creating the same widget over and over and over and there’s a multitude of data to support how long it takes to do these things. It’s just not that way. It’s more closely related to building a house. We talked about this before. I would ask my manager, “Would you be ok with saying we’re going to a builder of a house and saying that we’re not going to talk about the size of the house and all the things in it, but I need a house built in a month and I want to pay $100,000.” Then, you sit down and start coming up with “It needs to be a 5-bedroom, 2-car attached garage with a room up top. I need 2 floors, and I also need a basement. I need the highest end appliances; I don’t want any cheap appliances.” You wouldn’t do that.
People understand that, but for some reason when it comes to software, it’s like we should just be able to create this stuff. When management says, “We can’t prioritize; we don’t want to do that,” it’s going to happen at some point. A team can’t do everything all at the same time. The team is going to make a decision. I think a counter to is going back to saying, “As a team, this is how we’re going to approach it.” You don’t have to say “priority,” but just be like, “We are going to take this approach. We’re going to do these things first, then those things, and then that.” Try to get their reaction, and at least that will open up a conversation to discuss why you’re doing it that way rather than another way. Get their buy-in and tradeoff. It’s about tradeoff and risks. I think that, in essence, is the answer.
Jacqueline: Exactly. I want to tie in to some of the things that you said, and maybe it’s not said enough that people want IT, building software, problem solving, and using technology to be so predictable. They want it to be a science. It’s not a science. Every problem has its unique aspect, every team, every stakeholder, every group of stakeholders. You’re really treading on new territory. We always talk about, that’s one of the things I love about it, but at the same time, if people think that you could look at a problem and say, “Because it’s a contract management system, it’s going to take 3 months. We’re going to install it and use it out of the box.”
It just doesn’t always work, and most of the time, it doesn’t work out that perfectly because there are interfaces to different systems, we capture our data a certain way, our process is this, we do this, that, and the third, and on and on. Before you know it, in order to make this work, for me, even off-the-shelf products have to have those different things taken into consideration. One time I had to tell a stakeholder that buying software is not buying a pair of shoes, especially without even trying them on. Imagine buying a pair of shoes, and you’re like, “They’re shoes, aren’t they? I buy from off the shelf.” We know that 99% of the time, you have to try on your shoes because each one of them is different. I don’t think people think about software like that.
Kupe: You’re right. They think it’s a predictable, easy thing. Part of the challenge is, today, that we have so much technology at our fingertips that people think this stuff just happens. “Why can’t you build me an app just like this one?” It’s just not reality. I don’t know completely how we got where we are today, but I think you’re right. People think it’s, “I just need a system that does XYZ. Just do it.” They’re not thinking about all the impacts. This is where good analysis comes in. It’s to help people understand the impacts of the things that they’re asking for. All you can do is be real and show the facts. This is being a critical thinker. Show the facts.
Say, “This is reality.” Well, by saying “this is reality,” you’re probably saying they’re not living in reality so you don’t want to use those words, but say, “What the situation is, here are the impacts of us trying to do this.” The other factors of the quadrant (budget, scope and time), is quality and usability. We can get something up. Is it going to be bug free? Probably not. Is it going to be the easiest thing to use? Probably not, because we’re crunched for time and we’re going to do the best we can do within that timeframe, within that budget, and within scope. It’s about highlighting the impact. If someone says they don’t want to do prioritization, then, “Ok. Here is the challenge.” Point out what can happen.
Do it in terms of risks. “Here’s the risk if we don’t prioritize these things. It’s requested that we launch by a certain time. If we don’t prioritize, and we know this from years and years and years of building software that it’s not a science, at this point in the game it’s hard to tell 6-months down the road that we’re going to be able to get all these things in within the time. If we don’t prioritize, there’s a chance, 6-months come, that we’re not going to get everything in, everything’s not going to be to the quality you want, or nothing gets done because we’re trying to do all these little pieces that nothing is done within 6 months, and it’s not a launchable product.” It’s highlighting the impact of not doing something.
This goes back to a presentation I do and a class I do on business analysis planning. We never have enough time to do all of the stuff we want or we think it’s going to take to do a successful project. There’s just not enough time, but if you’re planning for your business analysis effort and saying, “This is what I think needs to take. I need 6 weeks to get all this stuff done,” and the team is like, “We don’t have that much time. We can’t take 6 weeks,” then what can we pull out that is less risky to the project? Maybe there’s a stakeholder group that we don’t engage with because it’s less risky, or maybe we don’t do a certain level of analysis on something because it’s less risk, but we definitely need to do these 5 things. Maybe we can add more people to the project. It’s all about having an intelligent conversation and showing the impact and the risks of not doing one thing over the other.
Jacqueline: Exactly. I think the more we talk about it, that analogy to the building and remodeling a house resonates. I sometimes bring it up in class when I ask the students, “Does anybody watch HGTV?” Everybody kind of brightens up. I love using it after lunch because it gets everybody’s attention. One of the things you said, you might have this big list of things that you want your perfect home to have, but you may have a day that you need to move in, and so you might move in even though there are still some additional projects you’re going to continue to do. We all know, when you live in a house, there’s always your to-do list, and you’re continuously tweaking and adding. Once you’ve lived in it a while, sometimes you discover things that you didn’t know by just looking at a blueprint and trying to visualize how you might live in that house.
One of the things, again, is when you move in, you need to have your priorities in order, or like you said, the order in which things need to be done. There are some things that have to be done before we move in, but once you move in, there are some things that have to be ordered as well. That’s so much like software. You’re going to have that go-live, or that move-in day, and you’re making that decision up front: what needs to be done before move-in or go-live, what things do we have to do, and what order do we want to do them in before we move in? I wish and hope that some of the project managers and product managers are listening, and maybe this is resonating with them as well.
You also said that sometimes you take incremental steps and find allies that see things the way you do outside of just the BA group. We can’t just have this conversation among the BAs, but find an ally here and there. Then, a light bulb starts going off. Collectively, the state and the mindset starts to change, and it’s from the grassroots up. That’s another way to impact management as well: if more and more people are saying it, seeing it, and supporting it, it can trickle up sometimes.
Kupe: Yeah. You made me think of something: why is it requirements? Because when things don’t get done, it becomes about a requirement, and not usually a big requirement but a smaller requirement. Going back to the house, maybe you missed a drawer. “I expected to see a drawer here. What happened?” The builders are like, “It’s not in my spec, so…” The BA misses a requirement, and to me, it’s not just the BA’s job. It’s everybody’s job to be looking at stuff and to be questioning. “Did we look at this?” Everybody on the team has to be empowered to raise their hand and say, “Have we thought about this?” “Why not this?”
Asking those questions as we go gives us time and the ability to make the changes necessary instead of waiting until the hand and being like, “Oh, we missed a drawer. It was bad requirements again, so BA, you’re terrible.” You run into the same exact problems. It’s imperative to everyone to hear this message that we say so often, that requirements is a team sport that everybody is involved in. It’s not just the BAs. They might be overall accountable or responsible to make sure things are done, but everybody has a role to play.
BUSINESS ANALYSIS FAQ – #3
Jacqueline: Absolutely. The questions are getting less black and white, because we’re getting into that big area of frustration for a lot of business analyst, what if a BA feels like they’re backed in a corner, not getting management support, things are being pushed down on them and they’re expected to perform their duties? Something you said was key: the planning process of what the analyst does and it being a conversation. I often talk about there needs to be a conversation between the BA and the PM.
I’ve seen it for myself where on the project plan, what the BA does is a one-liner: requirements, and people are like, “That should take about a week or two, whereas to really do justice at the very minimum, what also needs to be identified is the licitation process and all those dependencies. It shouldn’t be an environment where the analyst is doing it on their own. We talk a lot about the analyst also being the subject mater expert, and talking about best practices, that would probably be on my list . . .
Kupe: Of not best practices . . .
Jacqueline: That’s a no no. They’re doing their elicitation, and then there’s the analysis, which often is that follow up, the dissecting, the peeling back, looking at the different levels, cross-examination, and fact-checking; that’s the analysis piece, and that can be a back and forth depending on what you discover. Again, you’re discovering it sooner vs. later. The third step which is it needs to be documented and presented to the various different stakeholders. All of those need to be part of the planning process, conversation, negotiation, and as a team, agree to what risks you’re willing to take on.
If we say we’re going to try some things as we go along and then revise and revisit like that agile back and forth, then we’re agreeing that we’re not going to have it set in stone and we’re going to have flexibility. With that flexibility, there are certain risks. There might be some things that we discover. We’re saying that as a group, we agree to take on certain risks. One of the things I said that I don’t think is said enough is that when you’re building software, it’s not always predictable and it’s not a science. Even on the BA side, we have to accept that there are some risks you have to take. You can’t do every step.
We’re moving out of that world of waterfall where we thought we could have perfect requirements and we do the build and deliver it with no questions asked. Again, we have now discovered, from 30-40 years of doing this, that there are going to be some things that you discover along the way, and to build software and to go into areas that you’ve never been in before, there are some risks. Allow the team to take some risks, and allow there to be some discovery that might come on later in the project. Don’t let it be a negative thing.
I think BAs are sometimes rigid in that when we talk about our question with management support, we know they can’t give us unlimited time, so we have to realize that there are going to be some issues. As a team we have to agree on what we can’t do and how far we’re going to go down one road. There has been times when I heard my PMs say, “Ok, that’s enough,” and I had to accept it. After we decided as a team, then I also had their support. I don’t know if you had any comments on that.
Kupe: Yeah. In the end, that’s what it takes to get away from the blaming of the BA. It’s the team’s decisions: “Are we going to do this or not do this?” or “How are we going to ensure that everybody has that shared understanding of what we’re trying to attack and has the opportunity to ask questions?” It is a team thing. We have to move forward to the next phase being all on the same page. If things don’t go perfect, which they don’t all the time, at least the team is like, “Ok, then what can we do differently?” That’s the attitude that you have to have.
Years ago I saw a presentation. They were ex-airforce pilots, and they talked about what they would do after a mission. A lot of teams do this, but I don’t think they take it to heart. They would come in after a mission, leave their badges at the door, and they would just talk about the process: what went well, what didn’t go so well, and how can we improve. It didn’t matter who it was, but if something went wrong, they would talk about it: “Next time, if you do this and this, we would do better,” and just move forward.
When a team has a trusting relationship, and everybody probably knows when there’s trusting relationships on the team and things go wrong, it doesn’t matter. The finger-pointing doesn’t happen. Everybody bands together like, “How can we improve?” rather than finger-pointing like, “I had it in the requirements, but you just coded it wrong.” That just doesn’t help anything. If something didn’t get found in QA Testing, why? What happened? Did we keep pushing testing back to where they didn’t have enough time and we didn’t give the testing team the information they needed to determine what was important to test first, second, and third? Whatever that reason is, talk about it and then improve. That’s all we can do as professionals.
Jacqueline: Exactly. Awesome. Thank you, and thank our listeners for joining #AskAnAnalyst with Kupe, the president of B2T Training, and myself, Jacqueline, also known as @RequirementsPro on Twitter. Kupe is @Kupe. We’re going through some of the questions, and some we get in class. You’re welcome to email us questions or call-in questions. You can email us at firstname.lastname@example.org. Again, thank you for joining us. We have a whole archive. This is Episode 9 of our #AskAnAnalyst podcast.
BUSINESS ANALYSIS FAQ – #4
Let’s move on to Question 4. We might’ve touched upon this one, but I know it’s near and dear to many people’s heart: Many projects, the schedule, the budget, is determined up front even long before the BA identifies the requirements. Then the BA is brought in, and those things are already locked down. I know this because I heard this from my students. They want to give you the scope and the requirements, and they keep going back to “we want it all,” but they’re not playing fair because they’re not revisiting the budget or the schedule. What is a BA to do? Do they just do what their told or do they just wait until the end of the project and see where the chips fall? What do you suggest?
Kupe: I think part of it is you want to try to raise the issue in a way to try to get people on board, but at the same time you don’t want to do an “I told you so” kind of thing, like, “I told you it was going to fail.” In this situation I want to focus on the last part that you said, about do they just do what their told. The way to have the conversation, and this is with a lot of things, is to put things back on you as the person that you just don’t understand yet.
If someone says you need to do XYZ, you need to say, “I don’t understand, yet, how that’s going to help us get to the end game and help us get to success. Help me understand how that’s going to get us there,” or, “Help me understand why we shouldn’t do XYZ, because I feel that is going to help give me and the team clarity, and then we’ll be able to point in the right direction.” Don’t challenge someone around, “Why should I do that?” and asking, “Why did you do this?” That automatically puts people on the defense and gets them in a mode of “Just do it.”
It goes back to thinking about that 4-year old who asks, “Why? Why? Why?” and the answer is, “Because I said so.” That’s what the parents end up saying. You don’t want to challenge that way, but it’s flipping it around to help you get on the same page. I use this language often. People are like, “We have to do this and that,” and I’m like, “It sounds really cool, but I’m just not there yet. I just don’t understand how that’s going to help us,” or, “I don’t understand why that’s good for our business.” Always roll it back to that.
The other half of this goes back to what I was talking about earlier: giving impacts. I really do think, unless it’s completely, completely unreasonable, that a team can get a lot of things done in a short order, but what suffers is going to be around quality. How pristine is it going to look? How bug free is it going to be? How user-friendly is it? All of those things are going to be factors.
That’s the other piece that you as a BA have to highlight as the leader on the team. You’re accountable for making this happen, and if you don’t bring that up — maybe it’s a team thing. The develops have to stand up, too; they can’t just cower back. Then, what’s going to happen with them is they’re going to be working all night long until they pass out to try to make it happen, and that’s not what anybody wants. I’ll let you chime in, Jacqueline, to add, agree, or disagree.
Jacqueline: I’m right there with you. I’ve worked in some environments where I’m told, “We push you on purpose.” They want to get the maximum out of the team, so they kind of put there constraints on you to see what you’re going to give. There is a little bit of pressure on, and some people abuse padding schedules. You have the opposite end where they do see, “What can you do within these constraints?” The most important thing in my mind is we’re going to run out of time before we run out of requirements. If you were building a house, you can always say, “What about this?” You can always come up with more, and that’s the same with software.
However, I am, as a business analyst, still trying to steer. It’s all about steering the team, and that’s what makes us different from just being documentation and technical writers. We have to coach the team as well as facilitate the team and somewhat be the adviser. Some of it, and you touched upon this, too, is you have to learn that style and that finesse working with the team because you’re steering from the back. You’re not at the front with everybody just following behind you. It’s vice versa. You’re part of the team, and you have to keep bringing up, “Have we considered this?” and “Let’s make sure we do this first because we’ll get the biggest bang for our buck.”
Two phrases are getting the “biggest bang for your buck” and doing “low-hanging fruit.” I have to say, I’ve worked for organizations who were always about the low-hanging fruit, but the low-hanging fruit didn’t always give us the biggest bang. Sometimes you have to help the team, like, “Remember that other project we did when we did all that low-hanging fruit, and when it was all said and done, all we had was these scattered, random enhancements and we never really got to the gut of what was the paying point.”
Kupe: It’s constantly reminding people about that. It’s reality. It’s being persistent of first remembering and second being able to remind people that we’re getting into the same patterns: “We know what happened, so let’s change how we’re doing it.” I used this analogy on the last episode for a different reason, but I think it applies to this. It’s about an ER doctor and a primary care physician.
If you’re in a situation where you’re having a heart attack or you had one and you get brought into the ER, the ER doctor is ripping you open, getting your heart pumping again, getting the blockage out, and doing whatever they can to get that done. It might be ugly. You might survive this big heart attack, but you might have a big scar, you’re going to be in the hospital, and so many other things. You might be in a lot of pain for awhile because that ER doc had to move quick. The scope is the same but the time is very limited. You go in, do what you got to do, and get the person back up.
ER Doctor versus a Primary Care Physician – What Type of BA are you?
A primary care physician takes a much longer approach. They might prescribe some medicine, they’re going to be checking your blood pressure, and you’re returning to them every six months. It’s a much longer process, but it’s a cleaner and healthier process. That’s the attitude and a message that has to be delivered to the people that are saying, “We gotta do it quick, we gotta do it now, and it has got to be perfect.” Well, it’s not going to be perfect. It’s not possible. If they have a way, an example of a team that did it, then let’s bring that team in. They must be the miracle workers, and maybe that team should be responsible for this. There is no team like that. In the end, it goes back to being persistent, having intelligent conversations, and hightailing the impact of doing what people are asking you or your team to do.
If it doesn’t feel right, you know, you’ve been there, and you’ve done it. Some of the questions include the phrase ‘keep being…’ as if this is always the case. Well, if it’s always the case, then you have history and you know what went wrong. Your goal is to try and make it better. It goes back to thinking about what the opportunity is. Maybe you talked to the people that are pushing you in this manner to say, “Let me try this. I know on the last project we fell into the same bucket, so we need to change something. Let’s try this and see if that gets us closer.”
Jacqueline: After I make this next comment, I want to go to the phones to say hi to an old friend that has been an avid listener and supporter of Technology Expresso. I wanted to add that as I’m sitting here with my laptop, I had it propped up with my “Essential Skills” book for our Essential Skills class, and I flipped it open real quick. The part we do the Shark Tank and the different challenges, we also have something called “Intelligent Disobedience.” I wanted to drop that in, because we have an exercise and discussion around that.
Kupe: Yeah, exactly.
Jacqueline: That just ties into the saying stand true to your convictions. If something doesn’t feel right, it’s ok for you to stay on that point of view, but there’s a way to make sure that you have the support, evidence, facts, and even a good alternative. Just talk the team through and steer them in a different direction. Something I always say, and the question here was, “Does the BA just do whatever they’re told to do?” The fact of the matter is, you have to pick your battles.
You have to stand firm. You pick your battles, then talk with the rest of the team. Build alliances and see if other feel the same way, that we’re repeating the same mistake over and over and we need to do something about it. Build the right case and come up with solutions and alternatives of why different things need to happen in order to have different outcomes. Then, take it to management respectfully, and make sure that you’re well-prepared to make your case. You have to look at those opportunities, but caveat: pick your battles. I want everybody to stay happily employed.
Kupe: Right, the goal.
Jacqueline: Hello! Where are you calling from, Sharon?
Sharon: I’m calling from Houston, Texas.
Jacqueline: Thank you for listening to today’s show.
Sharon: Absolutely. I’ve been in the states for about 2 days now, so I’m just trying to get back acclimated to this side of the country.
Jacqueline: I gotcha. I know you have heard some of our tips and challenges for mostly those who are working in the industry and developing software, but you yourself are more of an entrepreneur that found yourself in this arena of software development and design, so maybe some of the pain points that we’re talking about, maybe you’ve experienced some of those things. I’m sure it has definitely been a learning experience for you.
Sharon: It definitely has been a learning experience. I’m listening to the show and listening to you guys talk about business analysts, and I wear so many hats that sometimes I may find myself as a business analyst. Not only am I working with the team that I’m on now, but I’m also creating other apps. I’m working with students and startup companies in St. Kitts. Having think tanks and listening to your show today, I could see myself in those places where I’m talking to other entrepreneurs and we’re brainstorming about different types of solutions. Having that communication — communication is the biggest thing.
We are all different type of thinkers, and I’m very creative. I remember on your show maybe about 4-5 months ago, you mentioned about being an introvert thinker or being a creative person but more introverted than extroverted; I’m one of those kinds of thinkers. When I’m in a group and we’re designing, having a think tank, or hacking out something, communication is the biggest link between all of us because we all think differently. Being persistent and listening to some of the tips that you guys are mentioning — I’m making notes, and I’m absorbing these tips because I find myself in those areas.
Jacqueline: Absolutely. I’m so excited. It’s so good to hear your voice, and thank you, as always, for listening to the show. We definitely have to catch up, and you’re always welcome. A lot of you may remember Sharon Simmons. She did a series for us, and it’s in our archives. She wasn’t a technical person, but she created an app. She has even documented how she went about creating the app as a non-techie and wrote a book about it. If you’re interested, definitely check out our archives.
The other thing, Kupe, that I think is interesting, and I’ve had more than one person say this, is that things that we’re talking about, other people can relate to them because it comes down to problem-solving, whether the solution is technology or you’re solutioning in general. As a business analyst, some of the communications, restraints, prioritization: this resonates with people, and so someone like Sharon who has created a couple apps, now, working with the students, it still applies to their efforts as well. It’s really cool that it’s not just people that are doing IT professionally or doing business analysis professionally. As we said in the beginning, this is about having project success.
Kupe: I’m glad, Sharon, that you basically said, “I’m a business analyst, too.” I think that supports my belief that keeps popping up: everybody needs this business analysis mindset, regardless. It’s not, to your point, Jacqueline, “You do business analysis if you have the title BA and you work on IT projects.” No. That’s not what this is about. I met someone for coffee this morning that does business analysis all the time, and they’re a program director at a large university. They could easily have the title business analysis, because the stuff she does is all business analysis type tasks, though not IT. Some of the things she has to do relates to IT, but not all and not a majority.
Jacqueline: Absolutely. Again, thank you Sharon for joining us today, and I’ll definitely be circling back with you. To Sharon and to others like Sharon, visit b2ttraining.com. I do some blogs, and Kupe does some blogs as well. There are different templates. Again, you don’t have to have the title. This is about problem-solving, coming up with solutions, and I think that it will really surprise people that this conversation and this arena isn’t just a job title. You mentioned it, Sharon: we talk a lot about different types of thinking, thinking tools, and communication. Kupe and I did, at the IIBA, about 6 different types of thinking. All of this is in that same space of problem-solving and whatever it takes for successful projects.
Sharon: Yes. Thank you so much for letting me hop on and hop off. Kupe, it was good hearing your voice, and Jacqueline, I would like to catch up with you soon.
Jacqueline: Absolutely. Thank you again. That was Sharon Simmons out of Houston.
BUSINESS ANALYSIS FAQ – #5
Kupe, I don’t know if you want to wrap up or if you want to look at one of the final questions: What if the only thing your team agress on is that everything wrong with the project is the BA’s fault?
Kupe: Looking at the positive, at least you got them to agree on something. That’s the first step. It comes down to, we talked about this at length before, that requirements are a team sport. The first thing is “feedback I give on accepting feedback.” So, I think you have to take it in. Don’t take it personal. I don’t want to tell you what to do, but try not to take it personally. Flip this around and try to get advice and understanding of how what you could’ve done differently. If the spotlight is on you as the BA, then take one for the team and admit, “I can improve. How can I get better?”
Open the conversation. Don’t push back and be defensive. When I give my talks around accepting feedback and improvement, the first thing is you have to ask for feedback. People don’t necessarily give you the critical feedback you need. In this case, people are giving the feedback; they’re pointing the finger at you saying you’re the problem. Now, you have the conversation. After getting the feedback and getting an understanding of what they feel could’ve went better and what you, personally, as the BA could’ve done better, you just say thank you and accept that.
Don’t get defensive, because if you get defensive, then it becomes a battle. If you’re like, “Well, I did that because you did this,” and then they’re like, “If you didn’t do that, I wouldn’t have done this.” It becomes a back and forth, and nothing gets accomplished. You can’t do that. You have to rise above it and say, “Ok, thank you for your feedback.” Go back and think about what you can do differently and what is possible for you to do differently. Next, go back to the team and say, “I heard you. Here’s what I can do in the constraints of the team. Here’s what I can improve on. What I need help on is XYZ. Is anybody willing to step in and help me with that?” At least you’ll then have the conversation.
By getting defensive, it’s just going to cause problems. By going to your manager and saying, “I’m doing a good job. It’s them. Can you help step in?” you’re then bringing the managers, directors, and people above the team into the conversation, which is just going to make it worse. People are going to start to take sides, and those managers, directors, and people that you escalate to really don’t have a lot of information about what’s going on day-to-day. In reality, unless they’re a part of the team, they don’t the day-to-day stuff, so what they’re making decisions on is all what they’re hearing from different people. It’s really hard for them to make good decisions.
If this is the behavior you have when everyone agrees it’s the BA — you should take the highroad and say, “It is all me. What should I do? Give me ideas and advice so that I can improve.” Then, hopefully that attitude goes to the next person. When it’s something they can improve on, they’ll have the same attitude. Then, as a team, you’ll start having these conversations where it’s not adversarial, but it’s for the improvement of the individuals and the team as a whole.
Jacqueline: I like that a lot. You’re absolutely right. Ask the team for feedback, be open for that feedback, and look at how you can continuously process improve. The other piece that I tell groups is one thing I love to take from agile. Whatever your iteration is, they have that 2-4 week checkpoint where you’re doing your retrospect. Even if you’re not on an agile team, just do, for your own professional development, retrospect with your team.
What I don’t like about this question is don’t wait until the end and then you feel like everybody is pointing at you. Find out when this tide came about along the way. Ask, “Are we not on the same page,” and “Are we not in agreement?” Not in that way, but, “What do you like about how it’s working? What can we change? What can we improve?” You’re having this conversation along the way so that you don’t get blindsided. You shouldn’t be blindsided that people are starting to think “we’re not getting enough information” or “we didn’t go deep enough.” Course-correct early and often. As agile says, fail fast. Start eliciting feedback early and often.
Kupe: Absolutely. That’s the key. Everybody has that sense, at least I think so, though some people catch on quicker than others. Sometimes I don’t catch on as quick as other people, but you have that sense like, “Something’s probably not right. People are not happy about something.” Ask the question, and be proactive about it. “Is everything OK? What’s going on? What can we do to improve?”
Jacqueline, I don’t know if you do this in class, but some of our instructors kick off everyday of the class like, “What went well, what didn’t go so well, and what can we improve on?” You can do that, too. You don’t have to do it everyday, but every week or every 2 weeks. Just get it to be a pattern. You can start it with, “How can I improve?” but hopefully it’ll improve to “Let’s not just talk about you. Let’s talk about all of us,” and then it becomes less about finger-pointing and more about how to consistently get better.
Jacqueline: I will try that for sure.
To our audience: Are there some questions you have? Maybe the questions today inspired you and now you want to jump in and be a part of the conversation. We absolutely would welcome your input. What’s your frustration? What are you experiencing on your project? Maybe it’s something totally different.
I want to take the time to thank you, Kupe, for being with us today. Thank you to all of our listeners. Thank you Jovan. I had a great time seeing those tweets come out, and I saw quotes of some of our soundbites. Just want to invite everyone to visit our archives and listen to the previous 8 episodes, if you haven’t, to catch up. Visit B2T Training’s website, the sponsor of today’s show. Thank you, Kupe!
Kupe: Thank you! It has been great, as always.
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 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: Business Analysis Basics
- Episode 18 | October 4, 2016: More 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
- #AskAnAnalyst Podcast Episode 27: Remote Agile Team Success - March 23, 2017
- #AskAnAnalyst Podcast Episode 26: Are BAs Becoming Obsolete? - February 28, 2017
- #AskAnAnalyst Podcast Episode 25: State of Agile - February 7, 2017
- #AskAnAnalyst Podcast Episode 24: An Agile Mindset - January 27, 2017
- A Monthly Guide to Becoming a Better Business Analysis Professional - January 11, 2017
- #AskAnAnalyst Podcast Episode 22: Business Analysis in 2017 - January 10, 2017
- #AskAnAnalyst Podcast Episode 21: Business Analysis in 2016 - December 8, 2016
- #AskAnAnalyst Podcast Episode 20: Effectively Give and Receive Feedback - November 15, 2016
- #AskAnAnalyst Podcast Episode 19: Live from #BBCCon - November 3, 2016
- #AskAnAnalyst Podcast Episode 18: More Business Analysis Basics - October 4, 2016