Jacqueline and I have spent the last 6 episodes of our podcast series discussing the business analyst role, and through those episodes have gotten some awesome questions! We wanted to take a step back this week and answer some of those questions. And also, tackle some of the questions that seem to come up on a regular basis in my daily conversations and in our instructor’s conversations with students. This is just the start of our business analyst FAQs so let us know what questions you have in the comments section below.
Episode 7 | March 8, 2016 Business Analysis Podcast Transcript
Jacqueline: Hello and good evening to everyone. I’m really excited because we have with us Kupe Kupersmith, the president of B2T training and a long-time well-respected analyst in the IT Software Field. Welcome, Kupe!
Kupe: Hello Jacqueline! How are you doing?
Jacqueline: Doing excellent. Really excited about tonight’s topic.
Kupe: Yeah, me too. Usually I’m a morning person, but I’m all fired up and ready to go.
Jacqueline: Excellent. Also on the mic we have Tasha Hurley. Hello Ms. BA extraordinaire.
Tasha: Oh, you’re too kind. Hello everyone. Good evening. Really excited to be here. Thank you Jacqueline for having us.
Jacqueline: Absolutely. And also hanging out with us late night after a hard day of PM’ing, Project Management, is David Blackman.
David: Absolutely. Hello everyone. Thanks for allowing me to sit in with the BA crowd. I do it at work. They have an interesting dynamic on my current assignment where the BAs and PMS all reside in the same groups. It’s one happy family, there.
Jacqueline: That’s right. We welcome that different perspective and point of view. Tonight I’m going to play more of a moderator role. We have a lot of brainpower, so I get to sit back tonight and play the moderator. I’m looking forward to hitting frequently asked questions.
Within the last 2 weeks I’ve been sending out messages, requests, and invites for people to call into our voicemail system and leave messages. I also reached out to our various instructors within the B2T family, including Ali. She was one of the people who sent us back a robust list, but unfortunately she couldn’t make it tonight. We want to thank her for the questions, and look forward to her in future episodes weighing in on some of the answers as well. We’ll do our best to acknowledge and answer those questions.
The reason why I’m going this route with tonight’s episode is that even though the BA role is being defined via organizations like the IIBA, I don’t know about Kupe and Tasha, but I know that when l talk to people, whether they’re in the IT industry or are actually business analysts, I’m still getting some of the same questions because there still seems to be a lot of blurred lines and gray areas for some people, whether they’re just entering the field or exploring it. Hopefully we can clear some things up or at least give some insight based on our experience.
FREQUENTLY ASKED QUESTIONS – #1
With that, let’s get to the questions. Our first question is: What do I do if I get on a project in the middle of it and don’t understand what’s going on? Kupe, I’m going to start with you.
Kupe: Alright. Before I answer the question, let me say that I’m psyched to be on the line with some great BA minds and a PM that I love. It’s not every day that I get to do this.
My answer to the question is fairly simple: get your hands on everything that you can and do it fast. Stick with your PM, your sponsor, or whatever key stakeholders that you know, and determine where things are. BAs sometimes struggle with organizations coming to them with a solution, and BAs have a hard time rolling them back and getting them to understand the needs.
Well, if you get dropped in the middle, that’s actually a great time because you can say, “Hey, I need to get up-to-speed. What are the goals/objectives/outcomes?” All that stuff that you try to do at the beginning of the project, you now have the right, and people aren’t going to complain at that time. They’re not going to tell you to don’t worry about the goals and objectives, because you’re just joining the team while they’re in the middle. If there are documents already out there, do some document analysis and try to get up-to-speed.
Jacqueline: Excellent. Sounds good to me. How about I throw that to you, Tasha?
Tasha: I would agree with exactly what Kupe has already said. I will also say to definitely target documents, any kind of PowerPoint presentations, any kind of roadmaps, and milestone documents that can summarize where the team has been, where they’re are, and where they’re trying to get to. I found, in more recent years, that kind of documentation is a lot more accessible than it used to be in the past, because everyone wasn’t always documenting at that level so that you could get a clear picture of the roadmap. Those are very important. Any type of workflow documentation is important. If it applies, grab hold of user manuals and start training yourself on that so you understand either the package that you’re implementing or the tool set that you’re going to have to use as a BA. Grab those. They are quick and easy ways to familiarize yourself with your tools, the products, and the vendors. Background information about the industry is helpful and key as well. Do your homework so that you come with questions. That dialogue that you spawn off with a senior BA, your lead BA, your PM, or someone in that mentoring capacity, when they understand that you have some skin in the game and you’ve taken time to do some homework, it really helps build relationships. Then, you get to be more resourceful more quickly.
Jacqueline: Excellent. Just to summarize, even though I said I was going to be more of a moderator. You have to do your homework, you’re going to have to get a little bit dirty, roll up your sleeves, and at the same time, start building those relationships early. That’s just a few key points. David, how would you like to comment on that or add to what they’ve said?
David: First of all, I’d like to echo those same sentiments by Kupe and Tasha. I’m an infrastructure project manager, a lot of my projects are hardware infrastructure combined with software related requirements. The way I see it work on my projects is the interactions with my BAs is heavily involved on the front-end and then they are back involved after we build the hardware platform.
We go out and do the build, and once the build is done, I’m turning it back over to the BA and the business line to manage the testing of whatever platforms that we’ve rolled out, whether it be the FQA, UAP, and eventually production. On the back-end, that BA is in the mix managing the requirements, capturing the backlog items, and things like that. So, yes, they should be in there getting spun up with their PM, going through whatever artifacts are available, the existing case that was developed, and anything else that defines the requirements.
Jacqueline: I want to bring it back to you, Kupe, since you gave us the first response. Did anything else come to mind as everyone were talking, or how would you wrap up this question?
Kupe: What I heard from David is that he’s saying PMs do all of the hard work and the BAs come in after the hard work is done.
David: No, I did not say that, I said after the hardware is done…(Laughter)
Kupe: I know. I really don’t think there’s anything much more to add. I like how you summed it up, Jacqueline. You have to get dirty and don’t be afraid to ask the questions. Like I said, if you’re getting dropped in the middle, you have that opportunity to ask those questions because it gives you have to get up-to-speed on what was happening for weeks or months. It’s a fast thing. You have to know who to go to, and does boil down to building relationships, knowing who to talk to, knowing who the best people are, having quick conversations, knowing what questions to ask them, and Tasha talked about doing homework about the industry. Whatever you’re working on, make sure you’re up-to-speed with the domain in the industry so that you can make things relevant.
Jacqueline: Absolutely. One of the things, in my experience when you’re dropped in the middle of a project, is you don’t want to be disruptive or take people backwards, but a little bit of a recap can be for the benefit of the team. Sometimes it has been a while since they looked at those initial conversations and decisions that were made from the objectives and goals, and a little bit of a refresh might be helpful to the team as well as you getting feedback on what you’ve discovered from the homework that you’ve done.
FREQUENTLY ASKED QUESTIONS – #2
That was our warm-up question. So far, so good. Let’s talk about the next question. How do I keep the business from going straight to the solution? Kupe, we’ll let you lead us off.
Kupe: Sure. I think this is a bad question. People in our industry have to start asking and complaining about this, because we’re not in 1980 anymore with Bill Gates and Paul Allen sitting back saying, “One day everybody’s going to have a computer in their home/desk.” That was their vision in starting Microsoft. We’re not at that time where people don’t know what a computer is. Everybody we’re dealing with today is walking around with — especially in the software industry — solutions in their pocket. We have so much technology with these little phones, so everybody can envision solutions.
Even in the 90’s when there were a lot of big ERT Systems being implemented, people were going from manual processes to these new software systems, automated systems; they didn’t even know what was a possibility, so it was easy, then. They didn’t even want to talk about the solution. Then, I think BAs got thrown off when business people who weren’t technologists were coming to the table with solutions. We have to stop asking. They’re going to come with solutions because they see it all the time and they know what it is.
I think the real thing is thinking about how you roll them back, even if they come with a solution. Accept the solution, but roll them back for understanding, like, “You’ve already gone through the thought process, and you have a solution. Help me understand so that me and the team can make sure we’re hitting the mark. What are the overall needs that we have to accomplish?” Get back to that business requirement-type stuff. Let them come with the solution; don’t throw them off, get upset, or get worked up. Find ways to roll them back so you understand the needs. Then, if you see a disconnect between the need and their solution, you can start having conversations about maybe changing that solution.
Jacqueline: Very interesting. Very provocative. Kupe, throwing us some curveballs. Tasha, what do you think?
Tasha: Yeah, I like that. For those who know me and have been on projects with me, I’m all about the BA getting to what your requirement is. To Kupe’s point, we have to be prepared that businesses are going to come with that solution. They’re going to say, “I want a mobile app,” and etcetera. We have to help them step back. Say, “I understand what your vision is.” You have to acknowledge what the customer is saying to you, but make sure you paraphrase: “What I hear you want is the system should be able to…” or, “…the system should have the ability to…” I think we have to be encouraging of that and not be so distraught. We can’t shut down that creative juice that’s coming our way. There are good nuggets we’re going to get for our business, and it’s just a matter of paraphrasing, getting them to step back and understanding what they really want, and acknowledging their vision. Exactly where Kupe was going with that, that’s an excellent way of putting it. I can remember being younger in my journey and being like, “Oh my gosh! They want…” You have to realize that our customers are different now than they were 20, 30 years ago. That’s pretty much my perspective on it. Definitely embrace what your customer’s vision is and their creativity, but part of a BA’s job is also helping them step back and be clear on what business needs they’re attempting to accomplish with what they’ve envisioning.
Jacqueline: Absolutely. I like what I’m hearing. Let’s get our third panelist to land. David, what are your thoughts about what you’ve heard?
David: Well, I agree with everyone else. The business channels and clients are a lot more technically savvy. It’s ok if they’ve gone out and found a solution, but guess what? They’re coming to you as a BA because they need a BA to manage the solution and to manage the want vs. the need as well as manage the delivery of that solution. It’s very necessary to manage the gaps and identify the gaps, especially when you’re dealing with outside vendors.
That solution came from somewhere, so it’s typically an outside vendor. That has been my experience, so you as a BA have to step in the middle between the client and those 3rd party vendors, ask the right questions, and question the answers after that. Very much needed.
Jacqueline: Excellent. I like what you added to that, because you’re right. Instead of BAs fearing that “now we have more sophisticated users that know what they want,” there’s still a viable role for the business analyst. They make an important contribution to help get that solution into place. People shouldn’t fear the fact that you have sophisticated users, but circling back to what Kupe said, respect that fact. That just furthers the partnership between the BA and the Project Manager or the Subject Matter Expert. You guys can leverage that.
Going back to what Kupe and Tasha said, leverage what they bring to the table, then build from there instead of trying to drag them backwards saying, at least acknowledge what they’ve brought to you instead of being dismissive. That’s probably the worst thing that you can do. Bringing it back to Kupe, anything you can add that you’ve picked up from Tasha or David’s answers?
Kupe: There was a phrase that David said that I loved. He said that even though the business stakeholder or user picked the solution, they’re still coming to you because they need you. It’s that confidence that BAs need to have. David, that’s how I interpret what you said. Have confidence that you’re needed and you can do a good job. You can find ways to politely challenge and push back. They’re coming to you for help, so don’t just take it as, “Well, they came with a solution, so I’ll just go implement it.” Most of the time good leaders in organizations are looking for feedback, and the BA has that knowledge and that ability, so be confident.
David: Absolutely. That was exactly my point. I think the BA and the PM have to be well-versed and not just at giving the good news. That’s easy, but they have to frame the bad news, put it into perspective, and make it digestible by the business team and by the client. I think the BA is very good at doing that.
Jacqueline: Excellent. It’s all about keeping them from going to the solution. In our agile world, we are going to the solution a lot faster, and then we are visiting the requirements and documenting what’s necessary. Again, and Kupe, you and I talked about this previously, that business analysts have to be flexible. We have to understand that there is more than one way to get to where we’re trying to go, and I think, Tasha, that you underscored very well that principle.
You can acknowledge what they have, but just make sure, as you’re working through the process, that you get to those other key questions that also need to have value. We’re not throwing them away, but we’re trying to understand why you’re doing it, what value it brings, and that type of thing. We’re not undermining that or throwing that out. They’re still valuable, but we can be flexible in the order in which we get to those points. That’s what I’m hearing. Anything else you want to add to that, Tasha?
Jacqueline: Excellent. So, how about I give you the next question?
Tasha: I knew that was the segue way.
FREQUENTLY ASKED QUESTIONS – #3
Jacqueline: To our audience, these are frequently asked questions. These are real questions that we get in the classroom, from students, and at our various speaking engagements. I can vouch for them. These are real questions. Our next one: How do I get SMEs to get more involved? Ever had that problem, Tasha?
Tasha: Oh, never! I’ve never had that problem. I’m kidding. Yes, I’ve seen the best of SMEs and I’ve seen challenging opportunities to win over SMEs. That’s the way I look at it. I think part of that, as far as helping to get the SMEs more involved, you make sure the expectations are clearly communicated and that we have the SME’s leadership commitment as well. That’s very helpful. Then, it’s important to include that SME throughout the process as much as possible. Each project’s dynamic is different, but keep communication open, keep them involved throughout the analysis process, schedule regular meetings so they know what to look forward to, and have regular checkpoints to recap where you are.
It also helps you as a BA to make sure that you’re building trust, which is a key element with your SME. Make sure that those checkpoints are there throughout the design, development, and training process. I think it’s very key that you involve them at as many points within the life cycle of the project as possible and on a regular basis. The worst thing you want to hear is for someone to say, “I haven’t heard from our project team in days or weeks. I don’t know where the project is.”
I know as a PM, David Blackman is just like, this is completely unacceptable, but I feel like the BA and the PM work very closely together and to help that dynamic. When you build that trust, you get more out of them, you get cooperation, and you get more information and resource availability when you need it. I think a lot of it is communication and that regularity of setting up checkpoints and letting them know where they’re are. They should never have to question that.
Jacqueline: Excellent. Let me throw it over to David. David, what comes to mind, especially in a PM’s perspective, when you’re struggling with the SME to get engaged?
David: Well, in the early stages of the project, I think it’s important to, as Tasha said, create that trust, but there’s something else that’s equally important: value. You have to convey how valuable that SME is to the project and the impact that they have. Our projects are not going to go anywhere unless we can define the requirement and manage the requirement on the front end. There’s going to be a roadblock; you’re going to hit a wall. What’s also important is the information gaps.
There’s always going to be information gaps. I ran into one yesterday, which resulted in me being on a call at 7:00 this morning. The executives in the business line didn’t know what was going on, and they went over to my executives. I was on a call at 7:00 in the morning, and there was a gap. I saw some of the email strains, and my SME was involved. However, they didn’t include myself or they didn’t include my BA, and there were sponsors, so that immediately created a gap.
I think what’s also important is that the information, our meetings, our meet-ups, our meeting minutes, and our status reports are accessible. They have to be accessible immediately by our SMEs as well as both executive channels, the business side as well as the delivery side. Provide a link to where the information is so everyone is aware of where we are on a project. Yes, value, impact, and trust is important.
Jacqueline: As a side note, communication and transparency is important. As Tasha said, keep them in a loop, keep them connected, keep them informed, and at the same time, make sure the project has a good communication infrastructure and outreach. And that everybody knows the rules of engagement on how we can have those conversations. I get a chuckle out of some of my students when I say this: let’s set up the rules of engagement while we still like each other. Don’t wait until the heat of the moment where everyone is like, “I thought we were…,” “You were supposed to…,” and “No one told me…” I don’t want to have those conversations, so while we’re all still doing our kickoff and handing out cake, let’s talk about our rules of engagement, because there are going to be those times when we’re in the heat of the moment and we’ll want to avoid some of those disconnects.
David: I want to speak to that, because sometimes you can have negative stakeholders. They know their impact and they still want to challenge that and be a little divisive or almost derail the project. At that point, you must have a good escalation path so that not only do they know their value to the project, but leadership at the C level knows their value to the progress of the initiative. Then, leadership can ensure that they are either available or replaced.
Jacqueline: Kupe, I know you waited patiently, so now it’s your time.
Kupe: I know. I love it. A lot of the things I was thinking about were hit on. David used the word ‘impact,’ and I was thinking to make sure everyone is aware of the risks of them not being involved; it’s the same kind of thing. When I kicked off the Atlanta IIBA Chapter in 2005, 9 years ago or so, someone came up to me. We were in a meeting, and someone new to the roles came up and asked, “Kupe, I’m on a project but I’m not allowed to talk to the subject matter expert. Their management team won’t let me. What do I do?” My advice was to hand your badge or id to your boss and say, “Thank you. It has been nice working with you. I have to go.” There’s no way you’re going to be successful if you don’t have access to the people who have the knowledge that you need. To David and Tasha’s point, this is a must. You have to make this happen to figure out ways to do it.
There was another story I just heard today as I was teaching a CBAP (Certified Business Analysis Professional) Prep Class. One of the women in there was talking about a project she’s on, and it got to the point where they were getting to requirement sign-off and the development team was getting ready to start to build. All of a sudden, an executive came to this sign-off meeting and saw a number of things. She had to derail the project a little to make sure it got clarified. She was asking me, “What do I do,” and she was thinking, “How could I have done this better? What happened?” We talked through the process, and one of the things was the executive had somebody else as a proxy to be part of the team.
This proxy was ready to sign-off, but then this executive came and things got out of control. There was an information gap, here. I think what you have to do, even if you get subject matters involved, is determine if you have the right subject matters involved? That’s key. It’s not just about getting subject matters, but it’s about having the right ones. In this case, you have to trust and validate. You can trust if someone says, “I’m the ultimate decision maker, but I’m sending Joe to the meetings. He’s going to be the one making decisions for me.” However, you can’t just blindly trust that that person is communicating up and down and getting all the right information. This was the perfect example of that.
As a good team member, you have to ask them, “Do you guys have a good process in place to be sharing and getting information so that we can keep the project moving forward?” If there are delays with approvals or whatever it is, if we’re not getting those, then obviously the project is delayed and other problems come out of that. Validate that those people have a good plan in place and a good way of communicating. If they don’t, then figure out and offer ways to help to get information, which goes to David’s point about making information accessible. I do think we have to get creative.
We get caught into this cycle: going to meetings to get information; if you don’t make the meeting, they’re going to cancel it. Some of the smart people that we need, the ones that know the information, who have the information, and can make decisions, we know are extremely busy. It’s very hard to get them at every meeting and doing stuff. This isn’t something that I came up with, and I wish I could remember the source, but this group was trying to get a business case signed off on and approved. Again, it was high-level. Board members and executives had to approve it.
What they did was they gathered information and started putting it together and putting it along whiteboards. They basically said, “In 2 weeks, we have a meeting to get approval. Whenever you have a minute, you guys go into this conference room where we have all this information on the whiteboard and give us your comments. Let us know what you want changed.” They kept coming in and giving comments, and the team would see the comment, react to it, and do whatever they had to do. People would keep coming in. Then, everybody saw it enough times that you could get sign-offs.
To get people involved, you have to be creative and do different things to give them the opportunity to be involved. Don’t just say, “This is the way it’s going to be. If you don’t come, it’s your fault.” There’s one more piece. Sorry to keep on going, but this is a great topic, a great question, and a struggle that everybody has. Jacqueline, you called it the rules of engagement. It’s about getting the team together early on and talking about how we’re going to collaborate. Again, it’s not just use as a BA or a PM coming up with this, but it’s the team saying, “We’re a team. What is the best way to collaborate and get everyone on the same page?” Have that collaboration agreement up on the wall so that everyone’s aware of it and sees it. Update it as necessary.
Jacqueline: Excellent. I have to throw this over to Tasha. Tasha, when he said ‘sign-offs,’ I had chills. I had flashbacks.
Tasha: Oh, yeah. Serious business.
Jacqueline: Absolutely. I’m glad that you brought up, for all of the tools, techniques, and ideologies, at the end of the day, you have to be creative. That was something that we did when Tasha and I ran into some of our problems, including problems with the sign-off. Talk about some of those creative ways that you’ve had to, I want to say trick SMEs into collaborating whether they knew it or not. What are some of your tricks of the trade?
Tasha: Oh, gosh. If I had tasks going on where I could use an expert to review some things before we go to the team at large, maybe it’s requirements or presentation, I would get their initial feedback on a couple of things. It’s important to find different ways to communicate with your SME. I’m not saying that I’m a stalker, but sometimes the best conversations are in more relaxed, outside, being-around-the-conference-table environment. That, again, is another opportunity to communicate. You keep hearing that underlying tone: communicate; building relationships; building trust; getting their buy-in; including them in some of the touch-point presentations; giving them the sneak preview; making them feel like they’re a part of what’s going on, and you’re not just shoving things down your stakeholder’s throat or your SME’s throat all the time.
They’re called subject matter experts, so utilize them, and then they’ll also see your value. You’ll end up finding that they’ll start asking you questions. “How can you get the conversation going this way because I see it going in a direction that may go down a rabbit hole?” It’s definitely finding those different ways to get them involved in your process. Give them a little bit of that sneak-peak preview so then when you go into your presentation and meeting, you have somebody; you have an ally that can help drive the conversation and get buy-in from the other side of the table, even though we’re all one big table.
At the end of the day, it’s about having that extra support out of your SME, building that trust, building that relationship, showing a sneak-preview, starting to communicate, asking questions, and asking about what they do if your project calls for that. There are all kinds of ways that you can connect with your SME and be creative. I’ve seen it work very, very well.
Kupe: What you were talking about, Tasha, or at least how I envisioned it, it’s formal vs. informal. I think we try to get into this formal-type review, and that’s when things get a little haywire. However, if you’re doing things in a more informal way that suits the people who you’re trying to interact with, they enjoy that. In life, people can’t consume huge amounts of stuff at a time. If you do things in smaller chunks, you can have a quick conversation. Maybe you run into them at the cafeteria line or you do stalk them and wait for them to leave their office so you could have a quick conversation.
Whatever it is, it’s doing things in small chunks. It’s like my daughter, who, if we put a big plate of few, is like, “I can’t eat all this. It’s too much.” However, if you give her a little bit at a time, she eats more than what was on the plate to begin with. It’s that same concept of doing things in smaller chunks. Some SMEs, because their busy and they have a whole slew of things, if you constantly ask them to come to a 2-hour meeting or an hour meeting here and there, it feels like too much because they already have 18 meetings during the day. If you slowly give them things, then they’re going to get excited, and to your point Tasha, then they’re going to want to be a part of it. Then, they’ll be more apt to join in the fun.
Tasha: Yeah. To that point, we used to do cupcake signing parties for sign-offs. We would decorate the room. We didn’t necessarily go out and spend a lot of money. It was regulated. The signature process was a big deal, and it had to be designed exactly right. The dates had to be in a specific format. We had our BA team manning the documents, so it wasn’t just like we were talking mellow yellows, eating up red velvet cupcakes, dancing, and signing away. No.
We had a peer-check process, but we found those kind of ways to do that. We found ways to chunk up our discussions and to make sure we stuck to specific topics within a time slot. We made sure that everyone got everything out of notes, whether it was post-it notes on the walls or lining the walls with paper bags to let people write what they do as far as process-flow. “Mr. SME, write all the steps of your process there, and then we’re going to do that for like 10 minutes. After, everybody can put their sticky notes.”
It’s interactive, instead of just sitting around a table for 2 hours, someone talking, us going back and forth, bantering, writing things for the action item, and planning for the next meeting to do the same thing again. They look forward to the interactive: getting up; doing things; being able to pull out the magic in your toolbox; seeing their work manifest. It’s really finding creative ways of doing it so people are excited. They want an experience. When it’s in bits and they know that you’re clear about your goals, again communication, then they’re looking forward to it.
Jacqueline: Absolutely. Let me try to jump in here between Tasha and Kupe. They’re on a roll. Our question, again, was, “How do you get SMEs involved? Like Kupe and all of us have said, they’re very busy. It’s not just them not wanting to. First of all, they have their day jobs and a lot of circumstances. The other thing is when you get them to a meeting, make sure you use their time wisely. Be respectful of their time. Make sure it’s a well-organized meeting, but that doesn’t mean you can’t have fun.
I know in our world of training, Kupe, we have different types of learners. You have to get some up and moving and involved, others want to read, and some are visual so we have to have something on the wall. I dare say that, Tasha, in our world where we used to plan our workshops, we would do that. We, whether it was consciously or unconsciously, made sure that it was multimedia to change-up the room, the flow, and the energy. We had that little rolling box. It was a crate that had wheels. We had colored this, sticky that, stretch balls and all kinds of stuff. You had to watch the energy of your room, and that was part of that facilitation.
One other thing I wanted to hit upon was what you said: going to lunch and grabbing coffee. I’ve sat in people’s office, and I just came with my agenda of questions. However, if I see that they’re trying to multitask, I help someone staple papers and prepare for their next meeting just to get their time, to talk to them, but also to help them get something off their plate. It’s about being creative. It’s about understanding your SMEs, engaging, emphasizing with them, not making it an us or them, and not being so hardcore about it. That’s how I summarize what was talked about.
Any last words from anyone on how to get your SMEs involved? Going once, going twice? Well, on to our next frequently asked question. These are real-world questions that our students have asked us or our listeners of the show have written in. This is all around the space of analysis and business analysis as we know it in the IT world, but we’re all about expanding that view, too. Tonight we have Kupe Kupersmith of B2T Training, the president of a company that does analysis training, we have Tasha Hurley, who is a longtime, well-respected business analyst, and we have David Blackman, our project manager.
David: I’m trying to get my Honorary BA certificate. I want to be known as a friend of BAs.
Kupe: You’re in. I’ll make you this gift tonight.
Jaqueline: This is your official induction ceremony. Honorary BA.
Kupe: Raise your right hand and repeat after me.
FREQUENTLY ASKED QUESTIONS – #4
Jacqueline: “I will always be nice to BAs.” (Laughter) Let’s get to our next question: What do I need to document on an agile project? Who wants to go there first? Kupe, would you like to start off?
Kupe: Yeah, sure. What can I say about that? My response to that person is, well, what do you document on a waterfall project? The mindset should be the same whether you’re doing “agile” or “waterfall.” By asking that question, it’s kind of taking the wrong angle. It’s coming from people who, not that they wanted to, were instructed to do a lot of heavy documentation. They had templates they had to fill out regardless of what’s going on. On an agile project, on a waterfall project, and on any type of project, you should be critically thinking about what’s necessary.
Our friend, Kent McDonald, always uses the term “document with a purpose.” Agile doesn’t mean don’t document, but it means to document with a purpose. Think about it. What is needed? Is it just for the sake of documenting and no one’s using anything? This goes on all the time. People are documenting stuff, and they get tossed into a repository and never come out. Nobody ever looks at it. Why are you documenting? If it’s meant to be saved for a future project, then great.
Things like business rules are good things to document. If you don’t have a business rule engine or database that’s capturing all of this, then you should be documenting because a business rule is a business rule regardless of what system or solution you’re come up with. You should have those. My thought is work with the team. What does the team need? Where is the team? If you’re on an agile team, maybe it is stories that are up on the wall and there is content behind those stories that the team might need. If your team is not all in the same room, then how are you capturing the information, and who needs that information? It’s thinking about what you need to document.
You should never ask me. People ask me, “What should I document?” I’m like, “I have no idea. What does the people you work with need?” You have to view your job as a facilitator or someone who helps other people do their job more efficiently and better. If your developers and business stakeholders need help to make decisions around what problem we should go after and prioritize requirements, if your developers need stuff to help build the solution, if your QA analysts needs something documented to test, then you should do it. Don’t ask us on the line. Ask the people you’re working with what’s going to make their life better.
At the same time, just because someone says, “I need this documented,” you should ask why, what’s the value of it, when do they need it, how much do they need, and how formal do they need it to be. That’s all I’m going to say for now. I’ll let the other experts chime in.
Jaqueline: I’m going to give Tasha a little bit more time to marinate on that, and I’m going to throw it to David. David, what’s your perspective about documentation on an agile project?
David: Well, it was an interesting question coming from the BA perspective because I actually want to know that myself. In my type of projects, and projects differ, there are some software only projects where you’re doing upgrades and an additional release, so I don’t have any familiarity in that type of environment. I’m trying to define that line as the BAs are engaged with the business lines, business channels, and the third-party vendors, what information are they capturing?
Jacqueline: In our training we break down our agile in line with SAFe: we talk about our portfolio perspective, we talk about the program perspective, and we talk about the team perspective.
When David said “business case,” that made me think more of the portfolio level, the strategic level. There are different projects, team makeups, and stages, but let me hand that back to you, Kupe, to expand upon and make your point.
Kupe: Yeah. That goes along with what I was going to say. I’ve talked on other shows, and Jacqueline, you and I have talked about this at length. I continue to strengthen my belief that it’s all about decision making, and that should drive things that you do. What a BA is documenting, David, I would challenge you to go back to the team and say, “For me to be successful in leading this project, here’s the information I need.” What is the team doing, and how are they documenting that? You need to be a part of that conversation, and a good BA should include you as part of that conversation. I think that’s what it comes down to.
BAs, wherever they are in an initiate, need to figure out what decisions need to be made and who’s making those decisions. At the business case level, obviously there are executives and whoever approves business cases, what do they need to make the approval? What information do they need, and how does it need to be documented? Do they want it documented or do they just want a PowerPoint presentation? Should that PowerPoint be thrown away once the meeting’s over? It’s thinking in those terms and working with all the stakeholders that you deal with to determine how you’re going to do that.
On the flip side, I do believe in consistency. If I’m doing the business case and Jaqueline is doing the business case for the same group, we should have some templates or some consistent approach in how we document it so the people we work with day in and day out don’t see two different formats and have to figure out “where’s the information I need.” However, you shouldn’t just complete something because it’s in a process. If the team doesn’t need it, don’t do it. Does that make sense?
Jacqueline: It definitely does. Tasha, you’ve had time to take this all in. Go ahead and set us straight. What do you think?
Tasha: I think all of the responses were pretty much on point with knowing exactly what’s expected of your audience. I think of it as understanding who’s going to receive the information and the documentation that you’re going to be working on further downstream. From an agile perspective, of course, the first thing I think of are user stories. I’m thinking about this how the question was phrased about: agile documentation. Again, it depends on the type of project you’re on.
For instance, my first tenure of adventure with Jacqueline was an agile environment, but the BAs were documenting user stories in a format that they would use as the test cases as well. It was a very unusual scenario. That was the demand or the request of the BA in that particular situation. As we were going into another adventure later, it was a different type of project altogether where we were actually — Jacqueline, refresh my memory a little bit on the terminology — it was a Win 7 project where we were taking folks on the x key platform.
A lot of my BA documentation for that was quite different, and we ran it agilistically-ish. Instead of doing user stories, we were more involved with lectures and PowerPoints every week. Also, I want to say training guides. There were some data entry that was involved, so we had to keep refining manuals and things like that. You have to be very aware of what the demands of your project are up front with the entire team, so everybody has ground rules, they know the rules of engagement and you know the artifacts you are primarily responsible for.
The reason I say “primarily responsible” is because when you’re on a team, if you can help in the other areas, then you pitch in, as long as you’re not sacrificing your deliverable and your timeline. I think you have to establish what those expected artifacts and deliverables are supposed to be up front. Again, it depends on the context of your project.
Another environment I was in, they were moving too deep. I’m not even going to say it was agile. It was more of a scrum-type process and structure with the stand-up meetings. I was really responsible for taking care of then taking requests and making sure I set up meetings with all the tech folks to make sure that new versions of software were being deployed to specific business units within this big corporation. Again, you have to be really clear.
Like Kupe said, if there are templates, then yes. You want things to look consistent, be branded correctly, be professional, and you have to be really clear with your team, your project manager, your leadership, and what the expectations are of your customers and clients for them to sign off. That needs to be established up front or else you’ll have a lot of spiraling and chiming in. Establishing those rules of engagement and expectations of the artifact for approval is very critical up front.
Jacqueline: You’re absolutely right. Kupe, I can’t help when we talk about agile. I have to chime in a little bit on this. At the end of the day, especially when I read the question, the one thing that I say over and over is agile is not a methodology. I think people have a mindset that they’re used to methodologies and using certain templates and formats. That’s not what agile is. It offers you that flexibility.
Back to what you all have said, you have to use critical thinking and you have to look at the factors surrounding your particular project, not just in the moment or what the team needs. That’s what sometimes people lose. They think about, “Well, my developer just needs…”
Tasha hit a keyword. Let’s say you work in an environment that has audit and traceability is required. I know a project that did that. They went on for 3 years, knowing that they worked in an environment that had audit, but they said, “We’re all agile, so we stopped doing our traceability.” They’re backtracking, now. You do have the team requirements as far as what has to be documented, but agile cannot excuse you from your other responsibilities and liabilities.
Agile wants you to be lean, and they don’t want you to lean on documentation. They want you to communicate, talk among each other, and that type of thing. That’s so important, but they’re not going to give you a “get out of jail free” pass. If you have certain things that are required, whether it’s training or maintenance, if you have documentation requirements, agile does not give you an excuse to not to that. Do the right thing.
Tasha: On that note, I think people hear agile and think, “Wow! It’s minimum documentation! Let’s not document anything!” I hear that quite a bit. I’m like, no, no, no. That’s not the key. Agile is getting the essential documentation that you need. Essential needs to be defined up front with your project team.
Jacqueline: Agreed. Any final words from you, Kupe? I’ll let you close out that topic, and then we’ll move to our fifth question for the night, and it might also be our final question. Any further words about agile and documentation?
Kupe: No. I think you summed it up perfectly. Do what’s necessary. Document with a purpose. There is no set thing. In my opinion, there was no set thing in the waterfall world, either. It’s back to that mindset of critically thinking what is needed and do it. Do it if it’s needed, and if it’s not, then don’t. Keep checking yourself. Don’t do lessons learned when it’s too late, especially when you’re on an agile team; you should be doing it more frequently and constantly learning and deciding, “We have burns because we didn’t have something documented well. Let’s start doing that.” Continue to adapt and evolve.
FREQUENTLY ASKED QUESTIONS – #5
Jacqueline: Absolutely. Let’s squeeze in this last one. It’s kind of a whopper. To our audience: if we don’t get all your questions answered, please send us follow-up questions and comments. Even if it’s the middle of the night and you can’t sleep, call us, leave us a message, and we will pull down your question and make sure it gets in the queue. This last one: How do I know I’m not missing anything? I don’t even know where to begin with that. Kupe, do you want to take a slice at it?
Kupe: Yeah. I’ll give it a go. This is another one of those questions that you have to almost get over. Things are going to be missed. There’s no way that you can capture everything, but you put things in place that allow you to check and make sure that if you do miss something, you have an opportunity to correct and move forward. We just talked about agile. Agile sets you up for that. The way that you don’t miss things is if you work on something, you chunk it up, and you do it in small iterations, for that iteration you’re probably not going to miss anything. There’s something tiny that you focus on, and you have the opportunity to flush that map out and move forward with it.
I’m going to use an example of when my wife and I moved to a new part of Atlanta, to Decatur, and had a house built. We missed a big requirement, and I think it was because of that same concept. We have a two-story house with a basement. The bedrooms are upstairs, and those we nailed. We were really focused and thinking on what size the master bedroom needed to be, each kid’s bedroom, and the closets.
We measured, adjusted, and got things good. The bedrooms there were perfect. The main floor, we caught everything because we thought in detail; we were really focused on it. However, when we came to the basement, we weren’t finishing the basement. We didn’t put much focus on it. We just looked at the garages down in the basement and were like, “Yeah, the garages are big enough. The basement is fine. Let’s focus on this other stuff.” What we missed in the basement area was like an outside storage area, so I don’t have a good place to put my lawn mower and yard tools, partly because we weren’t focused on it. We just moved on.
When I think of the question, I thought of that story and was like, “What was the reason?” It was a lack of focus. The other thing is I don’t think organizations value analysis enough, because analysts should be thinking about the details, but they should also be thinking about the big picture and seeing impact. I think those are the things that go missing more often when you’re just thinking about your initiative and not thinking about the world around you.
People in the analysis space who are really good at this are constantly questioning: “If we do this, what’s the impact on everything else around us?” It avoids missing requirements and making mistakes. Those are two things I wanted to hit on, and I’ll let Tasha and David take it from there and chime back in after.
Tasha: I think Kupe hit it right on the head. You have to get to a place of confidence where you don’t know what you don’t know. There are some meetings and conversations that are going to happen outside of you, and some of that you can’t prevent. It could happen at higher levels or in a staff meeting. You do your due diligence to provide those vehicles for communication, decision areas. What I’m speaking of is some place central where you can share information. The tool is only as good as its processed it gets used. There is a point where you know there could be a bogeyman under the bed that no one knows about except for the one person who has been on sabbatical for 6 weeks.
Sometimes things are going to happen, but thinking through the big picture in advance, you kind of plan in your head for the “what ifs” and the “what whens” when this happens, because 9 times out of 10, it may happen. You want to go in with a positive outlook on it: “If I miss this or that or something comes up, let me make sure of our process as a team.” If you’re seeing gaps, don’t be afraid to raise your hand. You could even pull your project manager aside. Ask questions. If something comes into my mind in the middle of the night, I know this is crazy, but I keep a piece of paper on a nightstand. Sometimes things will come to me that I write down for next week.
Just know that there might be things that get missed, but if you’re doing every effort to make sure that you’re communicating, that you’re transparent, that you’re building relationships, that you’re building trust, that you can put your hands on a documentation and anyone can see where you are in the process, then if something does get missed, you are able to figure out how to recover from it or accommodate for it hopefully in time. At the end of the day, you’re dealing with human beings, and things are going to happen. You just have to be confident and prepared for those things to happen. Build your conference and your experience so you can recover, hopefully gracefully. That recovery and the elegance of it comes with experience. I think on our last program we were on together, we talked about as you get more comfortable with doing things and embracing the unexpected, then you recover and you react differently; your confidence builds with it. Just know that there’s a great possibility that you will miss something, but keep your eyes on not just the details of the BA, because you always hear us talking about being in the details, but you have to keep your eye on the big picture, too. I think that that’s key.
Jacqueline: I’m chomping at the bit on this one, too. I think I’ve been pretty good at playing moderator for most of the night. The one thing I also want to add to both what Tasha and what Kupe were saying is sometimes people underestimate. When I hear that question, sometimes people rely on their SMEness, their knowledge of the subject matter. They’re going by gut instincts and what they know about a particular subject matter. If you do come from that kind of subject matter background, you need to rely on the tools, and that’s the analysis part of it. You need to dissect it, you have to break it apart, you have to do the critical thinking, you have to run scenarios, and you have to do your fact checking. That’s the analysis part, the A in Business Analysis. You do your due diligence.
To Tasha’s point, you do your due diligence as much as possible but you also let yourself off the hook because you just don’t know what you don’t know until it occurs. You want to take the feedback of what you learned. That’s something I tell my students, too, not just after the project goes live, but after the users have had time to use the product. I tell them to do a post-assessment to see what the users liked and didn’t like. I use that as my input to what other questions I could have asked, or what will I ask on my next project? I kept building up my repertoire of different types of questions and different ways of asking the question.
Tasha and Kupe said this: that’s something you build up over time, but my main thing would be to not underestimate the value of analysis. This is why we emphasize continuous education, because there are always new techniques coming out. Kupe just taught a feedback class. 2.0 had a set number of different techniques, and it doubled from 2.0 to 3.0. New techniques are coming out, new ways of dissecting and new thought and concepts around analysis are developing. Stay fresh. Be a lifelong learner, because this is a great space, and we’re all discovering new things. I wanted to add that to your comments. David, we’re going BA deep on you right now.
David: Sure. I’m going to try to tiptoe around that — just tip my toe in that environment. I don’t want to put my foot in there because it’s not my area of expertise, but I’ve been getting some pretty good exposure to the BA environment. It’s hard to capture that, but from a project manager’s perspective, and Kupe and Tasha both hit on some keywords that I jotted down early, but you’re doing the heavy lifting. You’re capturing the major activities, and you have to rely on that.
You also have to identify what the dependencies are, what the predecessors are, and what the successors are. It’s hard to miss anything key because there are dependencies. I can install a server without an IP address. Everything has its own weight. One key phrase that Tasha pulled up that I had written down was how you recover, and Kupe mentioned impact, which I also wrote down. Risk wasn’t mentioned, but risk and impact go hand in hand. Collectively both of them hit on all the key phrases, but with PMs and our schedules and our documentation, it’s hard to miss some little things there.
When you’re building architecture from an infrastructure project manager, it’s hard to miss some key activities because you can’t move forward because there are dependencies. In the BA world, I think it’s easier to miss things. In that respect, you have to rely on your SMEs, your project managers, and your own skill sets. Here’s one that I picked up from you: sometimes as a BA, you just have to listen. When the answer is given, then question the answer. I think that starts to peel the onion back and may uncover some little nuggets that might have fallen through the cracks.
Jacqueline: Absolutely. You have to have fine-tuned ears and listen for those keywords. Kupe, what final words do you have for our audience? We went through our first five. We have our list queued up for next time. We’re going to talk about time management, how much technical skills you need, how to raise issues when you don’t have enough time to do what you need to do, and more. To our audience: keep the questions coming. Kupe, what do you want to say to our audience tonight about our first round of frequently asked questions?
Kupe: I would just say keep ‘em coming. I think the questions themselves are deep, and I think the answers we gave were as deep. It’s no surprise that there are these types of questions. Sometimes I feel like, “Are we still answering these questions,” but I think we’re always going to be answering them. This is what we do. We’re never going to be perfect. Environments constantly change. We’re not constantly changed, but they are evolving and changing. These are common questions to ask, and hopefully we still have this radio show going in 10 years. Hopefully you’re documenting this show, because I would like to bring it back up in 10 years and say, “Hey, these are the same questions we were asked 10 years ago,” because I bet you they’re going to be the same.
Jacqueline: So true. I’ve enjoyed this conversation. Kudos to Ali who gave us some great questions to kick us off. Love the series. We have more coming in. To our audience: don’t be shy. Do you agree or disagree? You can leave us a message. We’ll be back with you in 2 weeks. We’re going to try to alternate some afternoons and some evenings, but I see some new area codes and some new nighttime listeners. Share with your colleagues and coworkers. Again, thank you so much Tasha for sharing this evening with us, thank you Kupe for sharing your evening with us, and thank you to B2T for being our sponsors. Any last words from you, Tasha?
Tasha: No. Just very great conversation. I really enjoyed it, and thanks for the opportunity to share. I’m looking forward to the future questions we get! Keep learning everybody.
David: Next time we’ll have a PM-led session and have the visiting BA.
Kupe: I’d love to be on that panel. Tasha and I would be happy to attend.
Tasha: Oh, yeah!
David: And as Kupe mentioned, these questions will always be relevant because we will always have new BAs and PMs coming into the environment who want to learn. This is going to be cyclical. The next 5 years will bring in a new group and a new crop asking the same questions.
Jacqueline: Absolutely. Well, we aren’t short of advice, answers, or experience. Thank you everyone. You all have a great evening. Thank you to Jovan for managing the phones for us. Thank you to our listeners and guests. Stay tuned: we’re going to have more great programming throughout the week. Thank you again for all of your support of Technology Expresso. That ends another episode of #AskAnAnalyst. Thank you, 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:
- 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 8 | March 29, 2016: More Business Analysis FAQs
- Episode 9 | April 12, 2016: A Business Analyst Attitude for Success
- Episode 10 | April 29, 2016: Consider Your Business Analysis Thinking Approach
- Episode 11 | May 10, 2016: DiSC Assessment and the Project Team
- Episode 12 | May 24, 2016: Negotiation Approaches
- Episode 13 | June 7, 2016: Strategy Analysis and Strategic Thinking
- Episode 14 | July 5, 2016: Business Analysis Insight
- Episode 15 | July 19, 2016: The Remote Business Analyst
- Episode 16 | August 2, 2016: A Modern Agile Conversation
- Episode 17 | September 13, 2016: 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