Smart Business Analysts Ask the Obvious Questions
“Never make assumptions” is some of the most popular advice given to business analysts. How not to is the obvious question that so rarely seems to have an answer included.
But let’s rewind and approach this from an entirely different angle. Let’s talk about asking obvious questions like that instead. Now I know we’re all fond of the saying “there are no stupid questions,” but we all know that twinge when we worry for just moment that a question might be too obvious. There are a bunch of reasons to ask these questions, though.
The first is to remove the stigma of expertise. Once people assume you’re an expert, they stop telling you things that they think you already know. This is maybe the most dangerous type of assumption: the kind others make on your behalf. You don’t know these assumptions are being made, and you have no way to discover them as they’re occurring. You might catch them in a requirements review session, or you might catch them in user acceptance testing, or you might catch them after you go-live. If you’re asking me though, I’d rather catch them much earlier than any of those touchpoints. If we make a point of verbalizing our thoughts when we catch ourselves thinking something like “this probably means”, we are actively encouraging people to talk to us like they’re training us, rather than as a peer.
Dispelling the illusion of expertise can also be vital in relaxing the room. When people are dealing with someone they perceive to be an expert, some folks will feel pressure to keep up with the expert, or to demonstrate their own expertise. This can often be exacerbated when their manager is in the room. Lots of people are understandably uncomfortable with having their experience and expertise being outshone in front of their boss. This can manifest in all kinds of counterproductive behaviours, but even if it doesn’t, why would we ever want a stakeholder, subject matter expert, or user to feel intimidated? This completely undermines any sense of engagement, and it’s how we can do all the right steps in building consensus and yet still end up with users that are adamantly opposed to change. Reducing resistance to change is one of the outcomes organizations typically expect when they make the investment to involve business analysts, so it’s important that we do everything in our power to ensure that we’re delivering in that area.
Another way that becoming less of an expert in the eyes of your stakeholders can be of benefit to you is that it tends to lead to more realistic expectations. I’m not suggesting that we should pursue lowered expectations as a means of achieving success more consistently, but it is important that the users we represent have a realistic impression of what we actually know. We often reveal to people aspects of the bigger picture that exist outside of their bubble, and this leads to an impression of being all-knowing. That sometimes translates into an assumption that we must know their piece of the process just as well, and we need to actively work against that. If user level stakeholders think you must know everything, they’ll be sorely disappointed when the solution you deliver doesn’t address their concerns. Even if those specific concerns never came up.
But in addition to improving the quality of our work, asking these types of questions can reduce the risk of project delays.
We can apply this general technique to business processes. Everything happens for reason, whether it’s a good one. Understanding why each stakeholder thinks each step is necessary, or what it accomplishes in the big picture prevents assumptions. Once you’ve got your swim lane diagram finished, it should be easy for you to point to any step and explain what its purpose is, or what business value we think we’re getting from it. If not, then you’ll risk finding yourself frequently having to decide whether we can make an assumption or if we need to do additional follow-up investigation. It usually doesn’t add much time to ask what the benefit or necessity of a given activity is, but it can add substantial delay to a project to have to schedule repeated follow-up meetings.
Asking the obvious question can also be an effective means of bridging resistance to change. If we think it’s possible that a process can be substantially improved by a change that the users or process owners may find radical, we may need to challenge some deeply held assumptions.
We can do that by trying to sell the change on its pros and cons, but this doesn’t instill a sense of ownership in the people affected by the change. Sometimes that’s acceptable. But where we encounter resistance, we might be wise to consider asking instead of telling.
We can dig into greater detail on the steps where we think there might be opportunity for change, which can naturally allow us to begin asking for more information on the purpose of those steps. By asking the obvious questions, we challenge our users and stakeholders to explain the reason behind a process, which brings them on board in thinking about it from a requirements perspective rather than a solution perspective. When they get to participate in discussing whether a change is viable from the perspective of trying to meet the underlying requirements, we get buy-in built into the solution.
Is this the answer to how not to make assumptions? It’s one way that might help. Where it doesn’t, I think you’ll still find ample value in asking anyways.