This week Jacqueline and I wanted to attack an issue that every business analyst unfortunately faces…failing projects. Specifically, we wanted to discuss what makes them fail or spin out of control and how to overcome these pitfalls.
Episode 5 | February 9, 2016 Business Analysis Podcast Transcript
Jacqueline: Hello, and welcome to another edition of Technology Expresso Radio! This is Jacqueline Sanders-Blackman, your host for today on #AskAnAnalyst. Our featured guest is none other than Kupe Kupersmith. Hello Kupe.
Kupe: Hello. How are you doing?
Jacqueline: I’m doing great. This is a live show, so people are welcome to call in. Our topic today is “Project Hell.” Do you feel like you’re in project hell? Have you been on the project of hell? It seems like we use that quite often in IT. I don’t know what it is about IT, but we defiantly have our share, at least in my experience, where I’ve been on some extremely challenging projects. Another term I’ve heard is the “Death March” project, when people don’t know when to pull the cord. What are your thoughts?
Kupe: To say that there’s project hell means that there’s a heaven somewhere — the opposite. I think there’s this assumption that there are perfect projects out there, and there aren’t. There are so many variables that go along with all the things we deal with on projects, whether it’s people’s attitudes or even the uncertainty of how to implement something. There are so many different variables that you can probably consider every project has a hellish piece to it. It’s about how well you manage that.
Jacqueline: Good point. We’re always on this quest for the perfect project, but like you said, there are so many different variables. That’s why we tweak and hone, and once we’re done with one phase, we’re on to another phase where we find ourselves tweaking again.
Kupe: Yeah, and the “Death March” that you mentioned, too. People don’t know when to stop sometimes, or sometimes they know they should but they think, “Well, we spent a million dollars. Might as well keep going,” instead of making hard decisions and saying, “Let’s stop. Yeah, we threw away a million bucks, but we would be better off going in a different direction.”
Jacqueline: When you say that, too, I have to give a shoutout to one of our other instructors at B2T that I co-taught with last week, which was Greg Busby. He shared with the students that the whole concept, especially in IT, is the art vs. the science of what we’re practicing. There is a lot more art to it than some people want to admit. Every project has all these unique characteristics and variables. We’re more practitioners instead of cookie-cutter. We have to learn, adapt, adjust, and use critical thinking. It’s not black and white in IT.
Kupe: Yeah. It’s the whole concept of practicing medicine. They’re trying things, and they’re constantly learning. It’s the same thing with us. We’re practicing business analysts, PMs, or teams, and we have to have that mindset, you said it before, of being lifelong learners. You have to be ok with that. It’s never going to be perfect, but if you don’t learn from the mistakes that happen, that’s when it gets really bad. If you’re learning from mistakes, not doing it on your next initiative, and trying to avoid it, then that, to me, is always a positive.
Jacqueline: Absolutely. I want to welcome our guests that have joined us. Thank you for joining us today. We welcome you to join in on the conversation. This is Q&A. Our continuing #AskAnAnalyst special guest is Kupe, the president of B2T Training. Kupe is also a keynote speaker, and he does presentations and workshops. If you’re interested in more information, visit their website for more information. You can follow Kupe on Twitter @Kupe. He’s on a mission to meet everybody in the world, so stay tuned.
With that said, I’ve been conducting a very scientific survey. I went out and used the new Twitter feature to post up a survey. It’s informal to find out what people thought about the reasons why projects fail. Twitter has a limited amount of characters, but I picked what is known as the top 4. The ones that came out were miscommunication, project management problems, technical issues, and requirements mistakes. Kupe, I shared the results of our survey, which may not be that far off. There was a tie between miscommunication and requirements mistakes. Can you give us your thoughts and your interpretation on the survey and its responses based on your experience?
Kupe: Requirements mistakes seems to always pop up, and it always seems to be the issue. There have been very scientific studies done that say the same thing as this survey you just did says, that requirements mistakes are the problem. It’s no surprise that that came up. I think it has symptoms of something that’s bigger, and it comes down to communication and collaboration. I’m so glad that miscommunication was tied. It’s all about how teams are communicating and working together. I go back and forth between communication and collaboration: which one is the more important thing to do, but it’s the combination of the two. If people aren’t communicating well or working well as a team, then yes, you are going to mess up.
As an example, one of the things I do in a lot of my talks now is I don’t ask for questions at the end of a session. A lot of speakers will say, “We have about 5 minutes left. Does anyone have any questions?” I don’t do that, because I think people don’t ask questions for one of two reasons: 1. They don’t want to seem silly and 2. They have some interpretation of what was said. Most of the people we talk to, the things we’re talking about are not brand new topics. When they hear something and they have a wealth of experience, they interpret it in one way or another. They don’t have any questions.
That, to me, is a communication issue on our projects. I’ve been in a number of sessions where people are like, “It seems like we’re all clear. Does anybody have any questions before we break up?” Nobody asks the question. That, to me, is not an indication that everybody has the same interpretation. It just means that they have an interpretation of what was discussed, but it doesn’t confirm that we’re all on the same page. That is why requirements get misinterpreted. People think, “We have a requirements problem. We keep missing requirements.” Well, if you work on the communication piece, how you talk to each other, and how you elicit and get those requirements out, then you’re making sure you have a single interpretation of a requirement. That is the communication piece. I think that’s the root cause to a lot of the challenges.
Jacqueline: Excellent point. When people hear ‘communication,’ even how we interpret that word bears clarification. You and I have these experiences. People think, “I want to be a business analyst. I like talking to people. I’m a people-person.”
I hear that sometimes in an interview, but the level of communication, especially when you have to express what the business needs are — there are so many different filters that comes from the person giving the information, then it has to go through your filter, and lastly it has to be passed on to and filtered through either the technical group or the project team. There are so many spots in between, and the whole reality is, it’s not black and white. That’s part of the communication. Going back to the business analyst role, being the communication liaison is a specialty. You could be a people person, and you could be good at talking.
One of the examples I use is how you talk with your friends. You already have a common language, a history, and you can refer to things and shortcut the conversation because these are your friends and family. That’s very different in the business world. You’re talking to people with a vast array of cultures and different understandings of the business space altogether. That in and of itself is complicated. You and I were working on a blog about people understanding that these are specialized skills. I want to give you a chance to talk about that, as far as the business analyst role.
Kupe: Yeah. You brought up a great point about friends and being able to finish other people’s sentences. I think that’s a big push for some groups trying to get dedicated teams. Even though there are other pitfalls related to dedicated teams, one of the things is that you get better and better working together. You start knowing everybody’s skill sets. You start learning how they talk and what they mean by a word they say. If you’re on a dedicated team, things move along a little faster rather than constantly checking “When you said this, what did you mean?”
It’s not just about being a people-person. You have to want to talk to people, but you don’t have to be an extroverted person where you’re the type of person that loves being in a group and having conversations. It’s that analytical/critical thinking mind where you have to recognize not only what filters you have, but what’s going on with everybody on the team and in the room. You have to know when to ask the question: “I feel like there are different interpretations in the room. Let’s get clarification before we move forward.” To me, those are the best analysts. Sometimes, that’s a person that is viewed as annoying, and you have to find the right balance of the art of our role.
It’s finding that balance where you don’t want to be constantly chopping up a conversation and you say “What do you mean by that?” to every word that’s said, because that kills conversation. How do you get that right balance of when to ask the question? You always have to be thinking of those things. I’m going to steal your line, Jacqueline, and the line of another great BA mind, Kate McGoey. As an analyst, when it comes to communication, you have to do two things.
- You talked about this, Jacqueline: You have to be an eavesdropper. You always have to be listening. There are multiple conversations happening everywhere, and you have to be listening to pick up on requirements and interpretations so that you can make sure everybody is on the same page.
- Kate talked about this: requirements in the air, or RITA. People stay stuff in meetings, in the hallway, or in informal conversations, and they’re throwing out requirements in the air. If you don’t capture them, do something with them, and figure out if they’re pertinent or not, then there’s going to be a challenge. A requirement in the air could be a big issue, because the person that put it out there — we do this all the time; we say something, and we assume it got picked up and somebody’s doing stuff with it. That, to me, is one of those analysis capabilities that teams and individuals need.
Jacqueline: Absolutely. That hits upon something else, and I’ll make a comment, have you respond to it, and jump to the phones. Speaking of great BAs, we have a great BA on the phone that’s going to share some of her insight and experiences. Something else related to that is the stakeholder analysis: understanding people and their perspectives. Greg said this in class, that sometimes you have to be part psychoanalyst. What are your comments on that?
Kupe: I went to a conference in September, and this one analyst in two different sessions I saw him at hit on a lot of key things that I think people in our profession need to be aware of. One of the things he said is the knowledge workers of tomorrow, which we are, need to be social anthropologists and really understand it’s not superficial knowledge of our stakeholders. It’s not about where they live, what their timezone is, and when you can schedule meetings. That’s what a lot of people think of when they hear stakeholder analysis. It’s about getting into what you’re talking about and digging deeper into who they are culturally and how they react to certain things. Even when you’re hearing answers from somebody, is that really the right answer?
Years ago I did work in Argentina, and when I was there, I didn’t know it at the time, but I quickly learned that their culture is nice. They don’t want to say something that could potentially challenge you and your words. They just want to go with the flow. When I was there, I luckily picked up that they weren’t being completely truthful. They were erring on the side of being nice rather than giving what was really needed. I was there because we had a bunch of systems in the U.S., and we were trying to figure out what they needed in Argentina.
We would be talking about different features and functions, and they (the Argentinians) would say, “Yep, we need that…that would be great.” They didn’t want to say, “No, that’s not going to be helpful to us because of XYZ.” You have to dig deeper to know what is going on in their minds, in their perception, and how they’re answering things. If I just went back to the U.S. and said, “They want to use our systems as is,” and we implemented them that way, we know there would have been trouble down the road.
Jacqueline: Absolutely. One thing that I learned that was really valuable is learning personality types between the introvert and the extrovert. Sometimes if you lean toward the extroverted side, because I do have some introverted tendencies at times, but if you’re an extrovert, you don’t necessarily recognize and understand the introverted personality. At the same time, you have an extroverted personality that could be dominating the conversation, and you have an opinion on everything. Not that this is bad, but they may not be cognizant of how it’s coming across to the introvert.
Sometimes you have excellent BA’s, but they’re introverted. I’ve talked to some that, like you said, don’t really want to cause controversy. I told them that controversy is where the breakthrough is when you’re trying to come up with an innovative idea. You want to get different points of views in the mix. I’m always about “getting it up front” vs. “bringing it up in user-acceptance testing.” That’s another aspect of understanding personalities.
Kupe: Yeah. I know we have to get to the phones, but what’s happening here is the exact reason why we wanted to do this radio show. Jacqueline and I get into these conversations where she says something that makes me think of something, and it’s back and forth. Before we know it, we’ve been on the phone for 2 hours. This is exactly how this all came about.
What you were saying about personality types, another art skill that people need is recognizing. If you’re an analyst or a leader on your team, if you’re recognizing that “hey, this extroverted person is dominating the conversation,” then you need to do something to make sure everybody is comfortable. They’re not doing it on purpose, but they’re not recognizing that they’re doing it. When I look at the maturity level of people on teams, that’s a maturity sign to me. When somebody can recognize “I’m doing too much. Let me pull back,” or if they’re introverted and they’re like, “This group needs me to interject more. That’s not in my comfort zone, but I need to do it,” that’s a sign of maturity.
Years ago I wrote a blog about how women have a sixth sense around that stuff — I don’t want to be completely stereotypical, but I think women do a much better job of understanding the dynamics in a room. They sense things quicker, or at least quicker than me. That’s a skill that I’ve had to build up over time. It doesn’t happen naturally with me. If I’m in a casual conversation at a party or something, it’s not natural for me to be worrying about everybody at the party unless I’m hosting, but when I’m in a BA situation, I have to make sure to remind myself “look at everybody in this conversation and make sure everybody is feeling good about it.” That’s important.
Jacqueline: Exactly. Excellent point. Like you said, we can keep volleying back and forth, but I’m going to go ahead and open up the mic. Your mic is open, are you there?
Tasha: Yes. Can you hear me?
Jacqueline: Yes, I can. We can hear you loud and clear. I don’t know if you’re going under your pseudonym or your real name.
Tasha: Oh, yes. I’m not going to use my stage name. I’m just going to be Tasha today. Hey Kupe! How are you?
Kupe: Hey Tasha! I heard you were calling in. I was excited.
Tasha: Yeah. I just wanted to say that you made a wonderful comment right in time for valentine’s day about women having that intrinsic characteristic of reading a room. That was very timely. That was perfect. There’s so much to talk about. I want to go back to a conversation and come back up to where we are. You were talking earlier about the collaboration and the communication piece.
For those on the phone, my name is Tasha Hurley, and I’ve worked extensively with Mrs. Sanders-Blackman and with Kupe by default through many conferences and things that we’ve done through work. I’ve been in the industry for over 22-24 years. I have my CBAP, so I take the business analyst role quite seriously.
When it comes down to collaboration and communication, that’s something near and dear to my heart because I’ve worked on small projects, but I’ve also worked on many death marches. It has almost become the reason people call me. It’s kind of like a blessing and a curse at the same time, and I think that comes down to knowing about timing. You mentioned about being a little bit of a psychoanalyst and being able to read people: body language, conversation. It’s somewhat of improv, and Kupe, you gave a workshop on that (improv and timing) at a conference in Vegas a couple of years ago.
That comes with maturity: being able to pick up on certain things, pick up on language, knowing when to interject, when to hold back, when to get a piece of information and know that it’s coming on the agenda, when to schedule workshops, when to feed into that when the right audience is there. One thing that I’ve seen on a lot of projects, including one near to me right now — I’m starting to get on bigger work streams and bigger project initiatives with a bunch of subprojects underneath them, and if those roles are not clear, not just stakeholder roles, but that communication plan between different work streams, you end up with too many chiefs in the kitchen, and you end up with leads that are stumbling on each other and being surprised when another lead comes into a working session when they’ve already initiated work on something else.
We’re going to see more of a problem or more of a challenge in that area with more distributed teams, because we’re taking advantage of our technology to work on projects across the miles. I really think that we have to spend a lot more time up front putting those communication plans in place so that it’s clear who’s owning what all the way throughout any role from strategic to executing test plans. As analysts, we are change agents, and we are communication agents. Sometimes we have to help drive that, making sure who knows what and who’s doing what. I don’t know if that’s something you all are seeing as well or what your opinions are on that. Do you agree with that, or do you see it as being something else?
Kupe: One thing I wrote on my whiteboard as you were talking is distributive teams. It’s becoming more of a challenge, and I completely agree that technology as caught up with us in the sense that we’re able to have quicker conversations with people around the world; we can get people together. Technology is able to help with our wants and needs for distributive teams. You can’t act the same way when everybody’s in the same room. To Jacqueline’s conversation about being an eavesdropper, it’s a lot harder to be an eavesdropper when you’re in your home office and there are people working on projects in Knoxville, Tennessee, in India, and in other places. You can’t be an eavesdropper. You have to work in those communications.
Your point about a communication plan, some people, when they hear the word plan, are like, “That’s not agile…that’s not how we work. We don’t plan,” but you need this plan and you need this way to know how you’re going to work together. Things that happen naturally in a face-to-face environment, you have to plan for it in a distributive environment. It’s good that everybody’s spread out, but there are communication gaps that happen as a result that you have to plan for. To me, that doesn’t mean you can’t be successful with distribute teams, and I think that happens to some people. They’re like, “Distributive teams are not working,” but no. You’re just trying to use face-to-face type things in a distributive world, and it just doesn’t work.
Tasha: I think that’s an excellent point. The more distributed you are, because you don’t have that face-to-face interaction, and because you’re unable to pick up on certain things, there are different techniques for picking up things over the phone, in email communication, Skype for business, IM communications, and things like that. That’s when it’s even more important to have a communication plan in place. Yes, people are like, “If we’re supposed to be agile, why are we writing stuff down?” You have to have room to plan so that you can be successful. That’s key when you don’t have each other in the same place.
Jacqueline: I agree. You said planning up front, and I think that’s somewhat of a lost art. People want to jump in, get moving, and move fast. People scurry, but a lot of things downstream is because of the planning up front. Interesting enough, for years, especially through the IIBA with the BA body of knowledge, putting forth the premise of an enterprise analysis or scoping has been emphasized, but some people still haven’t bought into that. I just want to put that out there, because you were talking about planning up front. I’ll give it to Tasha and then over to Kupe. What are you seeing and finding? Are we getting better at that or are we losing some ground there?
Tasha: Personally, I think that depending upon the maturity of the project team and leadership on certain projects that people are embracing lessons learned from previous projects as they become more distributed. More people are strategically planning ahead based off of more distributed teams like the one I’m on now. If you’re embracing it and you’re actually taking the lessons learned and helping it feed into your next strategy and plan, I see it work. It’s very apparent between those types of situations and those where it’s like, “We just need to jump right into the next one. The customer’s breathing down our neck,“ instead of planning while working on the current load of work to prepare for the next piece of work. I’ve seen both, where it’s like, “Let’s just get across this milestone…we’ll make it work some kind of way.”
Then, the people change, but the roles stay the same. A lot of that planning has to be around roles and not names and faces and around how you’re going to execute. When people take it seriously and incorporate it into their strategic planning and preparation, it really works. You can definitely tell the difference, and it becomes apparent when it’s the opposite. I think we’re going in the right direction with many of the projects I’ve been on lately. A couple of years ago I can definitely say that it was not working as well for other organizations which will rename nameless. It depends on where that organization or where that division within the organization is from a maturity standpoint.
Jacqueline: Absolutely. Kupe, do you have anything you want to say along those lines?
Kupe: Yeah. I’ll take a different angle to add on to what Tasha is talking about. When it comes to scoping and up-front stuff, I’m seeing more and more organizations are realizing that “We have to do a better job.” More and more groups, even though not enough are doing it, more groups are going down that angle.
I still think the piece that gets missed is, going back to communication: 1. making sure that everybody has that shared understanding in the beginning, and 2. keeping that visual and making sure people know the goals, the objectives, and the reasons we’re doing a project in the first place. What happens, and this is why everybody complains about communication plans, is that they’re gone over up front, but then they aren’t used again. People don’t go back to them, and they don’t use them as a tool to be more efficient. It’s the same thing with scoping and having goals out front.
When you get to the nitty-gritty, you start talking about the details, but if you don’t use the stuff up front as a filter to determine “should we do this or not,” then you can run into a lot of problems. Then, you get out of control, and there are all these things that are getting thrown into the mix. People aren’t making touch decisions to say, “No, we’re not going to do that because it doesn’t align with our objectives.” The problem is that there’s this statement up front, but how often are people going back to their objectives? I think that’s a big part of the challenge. Again, it’s communication: making sure everybody is constantly on the same page, know what our goals and objectives are, and has a clear understanding from the beginning and thorough the initiative.
Jacqueline: Great points. In regards to that, you’re right. Tasha knows: we used to wallpaper different conference rooms with the objectives, whether it was the agile manifesto or the ground rules. People are coming and going off the project, and some people just get distracted and get further and further away from those things. Absolutely. That communication is not just a one-time thing. It’s making sure and refreshing people’s memory.
Kupe, and Tasha, I would like your thoughts on this as well: What’s the difference you’ve seen as you’ve gone into some of the different agile projects? Are the problems and symptoms the same? Are they different? Is agile helping some of those historical pain points that we may have seen? What has been your experience with the agile? Some people look at it as this silver bullet, but there are some caveats around it, too, because there are still some basics that people have to keep in mind. How has your experience been around that?
Tasha: Agile, as we all know, isn’t for everything. I think that’s the big problem. At times, people want to recommend agile for things that it just doesn’t fit for. For example, and I’m trying to keep it as generic as possible, but for a more recent situation, agile was trying to be used for software upgrade scheduling. There were so many different elements that were involved based on the type of software that particular business champions were asking this group to install. They may have been dependent on outside vending. They may have been dependent on the server group, which was a total different area than the one we were in. The server group had their own schedule and their own equipment that were on different schedules to be sent out for testing purposes to ensure that the software upgrade was working correctly.
That instance was not beneficial for an agile approach and methodology, and I people just hear, “Agile: it will make us go faster!” Yes, but it can also make you crash and burn faster if you don’t put the plan in place, which takes me back to the whole planning and preparation. Some of that is figuring out if it fits or if you’re actually trying to put a square peg into a round hole. I’ve seen a trend in some environments where they’re trying to do just that; they’re trying to use a flashy word or a keyword to promote speed when there are other elements that should be considered. It works really well for minor change requests to basic software where you’re just adding on or tweaking functionality. I’ve seen that work incredibly well, where a CCB approach is used; you’re on a regular rotation to suggest what should go first, second, and third, and you’re evaluating user stories, velocity, and that kind of stuff. Then, it works very nicely.
I’ve seen it both ways, but I think a lot of it is in that up front preparation. That doesn’t mean an organization or a mission can’t evolve into that, but that will sometimes mean that you have to shave down the square peg for extra fattened edges that shouldn’t even be there anymore. It’s antiquating your approaching, which may be the real reason why you’re slowed down in the first place. It goes back to the whole planning and the whole strategically looking and assessing if you’re ready for what agile really entails.
Jacqueline: Exactly. Kupe, I think we’ve found our fourth co-host, because as we know, David chimes in from time to time as well! Excellent point, and I want to let or audience know: We’re talking about projects from hell; what causes projects to fail. We’re talking about everything from communication, a keyword that Tasha has brought to the conversation, up front planning, being strategic in your planning, and again, looking at, from a business analyst perspective, things that we can do. We have Tasha out of Atlanta with us, and we have Kupe from B2T Training. You’re welcome to call in. Be sure to share the broadcast with others. We’re on the right track and covering topics that are of interest to you. Stay with us.
Kupe, I’ll turn the question that Tasha just answered about agile to you. Are the challenges people experience in waterfall the same challenges in agile? Are they different? Do they just bring their bad habits over, or as Tasha said, do people just use the term in so many different ways that it’s hard to pinpoint?
Kupe: Yeah. I think there are two aspects to touch on. The first one: if an organization decides to go to more of an agile mindset, having dedicated teams, and putting people together, then what often happens is people get put onto a team — his happens pre-agile, too, but the issue is highlighted more in agile — and they still don’t know how to communicate and work together. It was hidden a little more in the waterfall days because people would do more things on their own. They get onto a team where they’re supposed to have open communication, and they don’t necessarily trust each other completely and don’t know how to have conversations. They don’t know how to build a positive, communicative environment. If you can’t communicate with a group, things will fall apart whether you’re agile or not.
Tasha mentioned improv earlier. I push people to get an improv mindset because it’s about building an environment that’s positive, open, and one where people can have good conversations. That doesn’t mean everybody loves each other. It means you can have good conversations and do your best moving forward. If you aren’t a good communicator, if you’re a jerk on a waterfall team, then you’re going to be a jerk on an agile team. That’s going to be highlighted even more. If the leaders don’t recognize it and try to correct it, then it could get out of hand. At that point, people are like, “Agile doesn’t work for us.” When you have communication problems and jerks on the team, you have to work that out.
The other piece is what Tasha was talking about around agile doesn’t work for everything. I think that comes into play if you think agile is a particular methodology like scrum. If you had that attitude in waterfall, it was a problem. Don’t do a process for process’ sake. Where teams, projects, and initiatives fail is when they take that attitude. I was doing a webinar the other day, and someone talked about repeatable processes. You should have them if they add value, but don’t think it’s needed. We’re not building a car. They aren’t as necessary. I believe in process, and you should always be looking at how to improve, but you have to be flexible enough. That, to me, is the agile mindset. It’s looking at how to approach something, knowing what’s going to work best, and knowing how we should go about something depending upon the type of initiative.
One guy came up with an approach to say that agile shouldn’t be an approach, which, to me, was ironic. What he’s saying is that teams have to come together and figure out the best way to move forward. If you’re in a large organization or bigger team, you have to figure out how your team fits into the other teams. Tasha, to your point about the different groups, you can’t say how you’re going to operate and expect everybody else to get on board. You have to be smart and talk about the best way forward. That’s agile. If you think about agile in that way, then we should all be agile.
Tasha: That’s a very good point. I think people take bits and pieces out of the entire agile process. People just like that term because, I don’t know if they see it on resumes or whatever the case may be, but you really have to assess where you are and what communication and collaboration style is going to work for you. That needs to be a requirement session of itself, an up front approach to the project and initiative before you just cherry-pick which pieces you want to do for what parts of a project. Kupe, that sounds like that would be a good topic along with that communications piece.
Jacqueline: Exactly. I wanted to add a couple of points. I love process, and I’ve been in organizations who wanted to implement six sigma or CMMI. Something that you said is while repeatable processes are great, continuous process improvement is not a one-and-done type of thing. You always have to go back and tweak. Like you said, when you’re building a car, the same results are going to come out of that assembly line, but in software development, you have to take the different factors and criteria up front. You have to take the information, crunch that up, discern it, and come out, based on what you know in that moment, making decisions.
I recently saw a Twitter post that we make some of the biggest decisions when we have the least amount of information, and it has always perplexed me as a business analyst. I’m peeling back the onion and getting more information that allows us to revisit our approach or timeline. That has gotten lost, and these things get set in stone about deadlines. New information is not taken into consideration. Process is important, but it’s equally important to use it in the right context.
Continuous process improvement is built into agile as far as your retrospect. When I run into groups that have abandoned the retrospect, I wonder how they were agile if they’ve locked in on an approach? People think that they can cut time by cutting out an extra meeting, but they have to revisit the intent and spirit of it and make sure they’re staying true to that.
Kupe: Jacqueline, I don’t want to be viewed as the anti-process guy. Part of the retrospect should be, “Did that process work?” I’m all for repeatable processes when they make sense, but if you’re just doing it to do it, that makes 0 sense. If you have something like a retrospective/agile approach to analyze what worked, what didn’t, what should we continue doing, and what should be adapted, then I’m totally for it. As the process is working, keep it going. If it’s doing the trick, you should make it repeatable, stick to it, and dedicate your team to sticking to it.
Jacqueline: Absolutely. Tasha, if there are any topics at the forefront of your mind, feel free to steer us into that direction.
Tasha: I wish there was a silver bullet for knowing when to pull the plug on a project. If anybody has that bullet, please let me know. When is the right time to pull that plug? What I’ve seen, once we get in “death march” mode, everybody’s burned out and communication is at a fevered, escalated pitch. We as analysts tend to try to be the level-headed ones, and that’s no disrespect to project managers and other roles. There are different stresses and things that tug at different roles throughout the process. How can we dispel the death march colloquialism or word on projects in IT?
I struggle to be that voice of reason, that calm person, but just from an analyst’s perspective, and I’m switching the question around to you all, are you finding any ways in your leadership opportunities to help avoid and divert that point, that fork in the road, and what are some of those approaches you use to divert and call a truce? Has it been effective, or do you all just crash and burn together? Do you have any war stories where it didn’t work? I’m still in that quest.
Kupe: My first comment is don’t give up the fight. We have to keep fighting the good fight. Whether organizations realize it, they’re saying that they need the critical thinkers on their teams. What you were describing to me is being a critical thinker: keeping a level head, keeping emotion out of it, trying to find the facts of what’s happening, analyzing a situation to recommend ways to move forward. That is the pattern that you have to continue. Even though we don’t always win the battle or influence or persuade people in the right direction, that is the right mode of operation. The other thing that I keep on a sidebar is a decision log. Decision logs are another thing to keep in your toolbox to bring out at the right times and say, “This smells a lot like a situation we had last year, and we made a decision. Was it the right decision?”
You can use that decision log to go back to and say, “The situation we’re in today was just like last year, and here’s the decision we made and why we made it. It didn’t work, so let’s not do the same thing,” the whole definition of insanity being doing the same thing over and over and expecting different results. I’m in so many meetings where I’m like, “Didn’t we talk about this last week? Didn’t we make a decision? Why are we brining it up again?” We actually have a Decision Log Template on the B2T Training website that is available for download. The other piece is courage. Before it even gets to the “death march” point, there are signs that everyone smells and sees, but enough of us don’t have the courage to step up and address the elephant in the room. Some of us, even if we don’t have the answer, we need to have the courage to call a timeout.
Jacqueline: I completely agree with your points. One of the things that you often say is part of the business analyst role is to help the team make decisions. Sometimes the solution is to stop. To help them get to that decision, things, like you said, the decision log helps. Tasha and I have both been into situations where we had to backtrack and create timelines to show what happened in the past to get us to the spot we’re at.
As a business analyst, there are certain things I have to keep records on and keep in my back pocket about decisions and different things that has gone on so that they are available if they need to be presented for us to make the decision in front of us. I look at that as part of my responsibility. Any decision on the project, especially as it relates to solutions and where to go next, is important. The second piece I will add is it’s important to have management that appreciates the business analyst as a consultant and internal advisor. It’s our job to give a way to measure if the team is going in the right direction. I’ve been on plenty of projects where I didn’t agree but we still had to move forward. Doing that has built a reputation, and they start to respect that skill set.
On one project, the end result was to stop the project. Up the chain it probably didn’t get taken very well, but we saved a lot of money. Sometimes you should get credit and recognition for how much money you saved an organization instead of keep pushing forward for the sake of throwing something into production. Some organizations has to appreciate how tricky software development is. Sometimes it’s worth stopping and stepping back. Though you spent money, stopping is better than going forward and continuing to throw money down the drain. I’ve been in all of those positions. Sometimes, management appreciates that insight, or sometimes appreciation builds over time. That’s my experience, so fight the good fight, Tasha!
Tasha: The good thing, especially for the listeners out there who are just getting into the game, at the end of the day, is knowing that by point back to the decision log, you did the right thing. To be able to recreate a timeline is the right thing to do. It’s partial improv, improv psychoanalyst, and partial attorney in law. It’s always sticking to the facts, not going into emotions, and equipping people with the right tools to make sound decisions.
There is an art, there’s a lot of soft skills, and at the end of the day, it’s never personal; it’s always about the business and getting to the right end by equipping people with accurate requirements, accurate points to make decisions to move forward. At the end of the day, you have to have integrity, be accurate, be dependable, and be determined to document information in a very transparent way.
Kupe: Writing requirements and stuff like that is the means to the end. Being a psychologist, sociologist, and facilitating communication and decisions is why we do what we do. Requirements and those things are a means to the end. It helps with communication and analysis, but that’s not what we’re about. I always go back to the Karate Kid move and how his teacher made him paint the fence and do what seemed like trivial things. Those activities are user stories and prototypes.
You have to know how to do all of that stuff, but the reason you’re doing it is to be able to react, to know what’s happening in the room, and to throw those things out at the right time. In karate, when someone throws a cross at you, you have to know, “Oh, I have to use the paint the fence move.” The same thing is in business analysis. As you grow into the role, you have to add more things so that you can see what’s coming at you and react to it.
Jaqueline: Absolutely. Myself, Kupe and Tasha have about 80 years of experience altogether, maybe tipping toward 90. There’s a lot of experience on the phone. We’ve seen the evolution of IT. I’ve seen extreme programming come and then get a makeover and come back in a different variation such as agile. We’ve been around, we’ve seen some things. What comes up a lot when we talk about projects failing is finger-pointing. As an instructor and coach, business analysis and project management should have a good marriage. I had a student ask recently, “Isn’t that the PM’s job?” That scared me. That’s my reaction. What are your thoughts, and am I far off? Tasha, let’s have you give the first words on this.
Tasha: There shouldn’t be finger-pointing at all because, in my opinion, after communications and laying the groundwork, the requirements are a fundamental piece of “the what” that we’re building. The requirements are also what are being collected from our business comrades and champions. It’s never about one individual; it’s a team, that’s why we all have roles. From a human perspective, then yeah, when the ship goes down, everybody is point at the other person like, “Well, you did that…you said this.” That seems to be a reaction. Is it the right reaction? It’s absolutely not. However, there has to be accountability for when things don’t go well and when they go well.
Do I see that a lot? Yes. Is it the project manager’s fault? No. We’re all going down together. That’s why you have to be very deliberate and intentional with capturing and documenting everything; getting the facts documented correctly is near and dear to me. The finger-pointing is never a good way to go out as a team or to accept failure. It’s an opportunity for everyone to take a look at where things may have fallen apart. Pointing to one individual is not the right approach.
Jacqueline: Completely agree. I have to share with our audience: we have Tasha in our archives. Tasha and I have the same dilemma: we have to talk nice about PM’s because we’re married to PM’s. We did a husband and wife series, and she and her husband talked about business analysis and project management. If you want to learn more about that, check out our archives for that great interview. We’ll have to do an update and have both of you back, but thank you so much Tasha for being on today’s show.
Tasha: Thank you.
Jacqueline: Kupe, let me throw that last question to you about how sometimes that finger-pointing gets started.
Kupe: I think people need to first and foremost want to be on the team. This is why I talk about improv so much. The skills make you better at being a team player and supporting each other. There’s an exercise I do when I do my improv workshop called “Group Juggle.” We have a number of balls that the group throws around in a certain order. Balls get dropped, and I highlight that when a ball got dropped, it just sat on the floor. Nobody went to pick it up. Everybody is having that finger-pointing moment like, “It’s not my ball. I threw my ball to my partner.” People will even point their finger at the ball.
You have to have that attitude of being a good team player and picking the balls up. That brings the conversation to responsibility vs. accountability. You have to take responsibility, and the group has to come up with who’s doing what and why certain people are doing certain things. Once you are assigned something, you take responsibility and you follow it through. That doesn’t mean you have to do it alone; you can ask for help, but it’s your responsibility to get something done when you said it was going to get done. You’re also accountable for the success of the team.
We don’t do good business analysis for the sake of good business analysis. We don’t do project management tasks just to do project management tasks. We don’t code just to code. All those things come together for a successful outcome. No matter where you are in the stage of a project, you have to have the attitude of, “What could I have done differently to make the outcome better?” That’s the attitude people have to have, and not, “I did my job. He didn’t do his job.”
I’m trying to teach this lesson to my kids. My daughter forgot her lunch the other day for school. She came home and was like, “Well, mommy didn’t put it in my bag.” I was like, “Whose lunch is it?” I asked her, “What could you do differently instead of blaming mommy?” She was like, “I could of put it in my bag.” That’s the attitude that people have to have. What could you as a member of your team done differently? Thinking of it that way, you’re going to be a better team player and people are going to want to be on your team. That’s a way to get respect.
Jacqueline: Absolutely. I totally agree. Business analysis is a critical part of the project. It’s not just about tooting our own horn. It’s a heavy burden to bear. Those who are passionate about it know it’s about a successful product. When you’re all in, you’re doing those different aspects to hold up and support the team. If you want the glory, you also have to understand what comes along with that. Sometimes the definition on business analysis gets diluted, so it’s an educational process.
You heard it from Tasha, Kupe, and I. It’s a great role, a great responsibility, and if this is your area, you really can sink your teeth into it. It’s very rewarding. The business analyst, sometimes people think you take your natural skill set and jump into it, but there are training opportunities and you want to continuously hone your skills. We talked about certification, which is understanding a body of knowledge written by business analysts with years of experience. Then, there are continued education credits. You need to continuously improve yourself. Can you talk about B2T Training and some of the upcoming events you have for people who want to pursue this and hone their skills?
Kupe: Thank you. Talking about the certification, we’re leading a feedback prep class in March in Atlanta. You can go to our website for more information. The good thing about certification, I’ll be honest that I have this love/hate relationship with it. I don’t think it makes you a better business analyst, but it allows you to prepare for it by having you go through and get re-acquainted with techniques you haven’t done in the past. It highlights and reminds you about techniques. It can amp up how you work day in and day out. It’s going to give you confidence if you know a lot of techniques when you’re going to work sessions at your daily job. I’d love for you to join me for that.
I’m also doing a number of presentations around the U.S. and Toronto. Some are around design thinking and how you use it in the BA space. That’s the next thing for BA’s. The workshop in Toronto will be about understanding personalities and learning how to be a cohesive team player. Those are some of the different things going on, but we’re helping organizations every day. The responses I hear are positive. That tells me that we’re helping people which are going to help projects avoid project failures and death marches.
Jacqueline: Thank you again, Kupe. Great content. Thank you to Jovan Grant, who works the switchboard, Anisah Muhammad, who does our transcripts, and Dawn Major, who does the headlines and hashtag news.
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 6 | February 23, 2016: Good Business Analyst vs. Bad Business Analyst
- Episode 7 | March 8, 2016: Business Analyst FAQs
- Episode 8 | March 29, 2016: More Business Analysis FAQs
- Episode 9 | April 12, 2016: A Business Analyst Attitude for Success
- Episode 10 | April 29, 2016: Consider Your Business Analysis Thinking Approach
- Episode 11 | May 10, 2016: DiSC Assessment and the Project Team
- Episode 12 | May 24, 2016: Negotiation Approaches
- Episode 13 | June 7, 2016: Strategy Analysis and Strategic Thinking
- Episode 14 | July 5, 2016: Business Analysis Insight
- Episode 15 | July 19, 2016: The Remote Business Analyst
- Episode 16 | August 2, 2016: A Modern Agile Conversation
- Episode 17 | September 13, 2016: 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