Trick or Treat! It’s Halloween here in the United States and so I decided to have a little fun with this week’s video. We’re looking at 3 “tricks” or issues that can trip us up as business analysts, and how we can reframe them as “treats.”
A lot of issues are really blessings in disguise. Better to clear them out early than let them fester and cause even bigger project problems later.
So, without further ado – Trick or Treat!
For those who like to read instead of watch, here’s the full text of the video:
Happy Halloween, if you are in the U. S. and watching this video. Soon after it’s published, it’s on or near Halloween, and this is a special edition of our videos series because we’re doing a trick or treat video today.
I’ve got my orange and black on (those are Halloween colors here). And I want to take it a step further. This is crazy – first time ever in a Bridging the Gap video – I’m going to do this with a tiara. This is from my 3-year-old’s Halloween costume. She’s going to be Tinkerbell. Okay, does this look ridiculous? Probably a little.
We are business analysts. We still get to have fun. First time ever video with a Tinkerbell tiara on.
We’re talking about tricks or treats as a business analyst. What I mean by that is things that feel like they are issues in the moment, but are actually treats in disguise. How can we reframe the things that happen, the issues that pop up in our work as BAs, so that we feel like they are a positive thing that we can move forward from?
Trick #1 – You Didn’t Get This Right
The first one is, when we get feedback on a model or requirement, it’s like, hey, you didn’t get this right. It’s totally wrong. At first, we can feel like we did something wrong. Aren’t we supposed to know the requirements? We’re the BAs after all. Didn’t I get this right? Should I have worked harder? Should I have analyzed it more? Should I have kind of figured this out somehow?
Most often, if you’re asking questions, and doing analysis, and doing your best to prepare for your meetings, and prepare for your models, and doing the research that a normal business analyst would do, most often, you didn’t actually do anything wrong. Most often, that feedback of “you didn’t get this right” or “you made a mistake” is really the feedback that we needed. It’s why we create these models in the first place.
And, so, I want you to not feel like you somehow messed up when that happens and, instead, just reframe that. “Hey, great, I want to hear about my mistake. How would you correct this requirement? What would you add to this model? Let’s have a discussion about it.” Totally move on. It’s not a mistake.
Trick #2 – Hearing Crickets
The second thing that can seem icky at first, and we’re going to reframe it, is what happens if you just hear crickets? You ask a question and then nothing. Silence. Silence is uncomfortable, isn’t it? Kind of like wearing a tiara in a video for a business analyst. It’s uncomfortable. It’s uncomfortable for you. It’s uncomfortable for your stakeholders.
Sometimes, people need time to think. If you are more introverted, we just had a video about being a more introverted business analyst. Some of our stakeholders are more introverted. We need time to think.
Maybe, I don’t know quite the answer. Maybe I’m nervous, or maybe I’m expecting somebody else to pipe up with the answer. Give that a little bit of space. It’s okay to have some silence in our meetings. It doesn’t have to be boom, boom, boom, boom, boom, like that. You can have silence. Allow that silence to work its magic and for people to come up with their answers.
You don’t want to go on forever, though. You wouldn’t want to have like five minutes of silence in a meeting unless you’re all doing independent brainstorming, which is a great technique to break the silence. Like having everybody just independently write their own ideas and then get together and share those. Great way to engage introverted stakeholders as well and give them some space to have those thoughts. Use a technique like that to break the silence.
Again, go back to modeling. Draw something up on the whiteboard and let them point out your mistakes instead of trying to feel like they should come up with the answer for you. At first, you lead them through it and help them get that “Yes, but” response.
Or, as a last resort, do you not have the right stakeholders in the room? Again, these are positive things. You’re learning. If they’re having difficulty answering the question, maybe there’s a better technique I need to use as a business analyst to engage them. If they don’t know the answer to the question, maybe there’s somebody else I should be asking. There’s always a way to take that a step forward and to use that as information that moves your project forward.
Trick #3 – That’s Impossible
The third one that I’m going to talk about, which is common, is when an attack person says, “Hey, great requirements idea. Totally impossible. Can’t do it.” Particularly frustrating when it comes up after your stakeholders, like after you’ve involved them in some sort of review. They’ve been involved, maybe, in a bit of the requirements process, and nodded their head and said, “Yeah, that makes sense.” And now, somewhere along the way, they say, “Sorry, we can’t do it.”
It’s frustrating and hard, usually, to go back to the business stakeholders, but think of the alternative. Would it have been better for them to continue with implementing those requirements and maybe the plug would have been pulled out on the project before they could implement anything of value? Whereas, if they’re coming back to you early and saying, “Hey, we can’t do it like the design or the requirements say. We need to make some adjustments.” Often, that’s the time where you can still negotiate and figure out alternate solutions and get together and create a better outcome before months have gone by and now it’s too late and nothing of value is delivered.
Would it have been better if they just did whatever they wanted? Coming back to you and saying, “Hey, this isn’t going to work,” is better than them just coming up with an alternative solution and implementing that instead, which happens. That’s a bigger problem because that’s the silence problem. That’s the not hearing back about your requirements problem.
Again, that feedback is always a blessing in disguise. Instead of thinking about it as a trick, it’s so hard. It is hard. But it is an opportunity to revise the requirements and come up with a new solution.
Again, it’s Halloween in the U.S. My Tinkerbell. I wish I had the wand with her costume so we could just go, “Trick” and turn that into a treat. “Trick,” turn that into a treat. But the theme here is more information is better information. The more that your business analysis process is moving forward and you’re learning your stakeholder engagement, getting feedback, even if it’s not the feedback you really wanted or thought of, or expected, if it’s moving the process forward, you’re heading in the right direction.
Always be thinking about how can I turn this trick into a treat, and you’ll be on the path to doing better business analysis.
Have a happy Halloween! Talk to you soon.
