Author: Ryan McPherson

Smart Business Analysts Ask the Obvious Questions

Written by Ryan McPherson on October 10, 2018. Posted in Articles.

“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.

Why Bother With Current State?

Written by Ryan McPherson on September 4, 2018. Posted in Articles.

Recently I found myself walking some senior managers through a requirements document I had prepared when one surprised me with a question I did not expect.

They wanted to know why there was so much of the document devoted to describing the current state and the various challenges and deficiencies the organization faces in the relevant process. It’s a fair question, but after a decade of business analyst work, I had started to take the importance of detailed current state documentation for granted.

So why bother with current state?

For one, current state documentation is how we demonstrate to our stakeholders that we’ve been paying attention and that we understand what they’ve been telling us. This helps to build relationships with stakeholders, but more importantly, it keeps us honest. It’s an opportunity for our stakeholders to audit our knowledge of their challenges. If we aren’t working from an accurate understanding of what the problems actually are, what are the odds that our requirements will drive us towards a solution that addresses the underlying issues rather than a symptom? I always challenge the business analysts that report to me to explain the problem before they start talking to me about their requirements for precisely this reason.

It’s also necessary background for our solution providers. Let’s envision two distinct scenarios.

If we’re working with software developers to implement a change request or enhancement to an enterprise system and we give them a laundry list of “the solution must” statements, the few that can stay awake all the way through a requirements review are not going to be able to provide any special insight.

They may still develop a fully compliant solution, and if your requirements are darn near perfect, you might even deliver a solution that passes user acceptance testing on the first try. But I wouldn’t be optimistic.

Imagine instead a requirements review meeting that begins with a detailed explanation of what a day in the life looks like for the person we’re developing this solution for, where we focus on the challenges this enhancement or change is meant to address. Then we start talking about the functional requirements, and our developers are engaged and using their own reasoning and logic to see how these requirements relate back to the problem.

It’s been my consistent experience that the vast majority of software developers find this to be far more exciting, and that only makes life easier for everyone. This is especially valuable if you’re working with folks on an internal team that you’re going to continue to work with again and again on future projects. I think you’ll find this often leads to some great suggestions that you wouldn’t otherwise benefit from, too.

Alternatively, if we’re going to be bringing in consultants to assist in selection or implementation, whether hardware or software, the need for current state documentation is even greater.

Without detailed current state documentation, how are we going to bring the outsiders up to speed? It’s faster and more accurate to work from a well written, edited piece of documentation that already contains all of the relevant and applicable flow charts rather than trying to explain the background as you walk through the requirements. It’s especially nice if you can provide the documentation in advance and they can come in with the gears turning and their questions ready on Monday morning.

When we’re working with external solutions providers, we also may not have the opportunity to “fix it in testing” (not that should we be relying on that). This is especially true if we’re selecting or implementing hardware solutions.

For example, you might provide a great set of requirements that allows the vendor to suggest a wonderful touchscreen computer… that you then go to implement in a manufacturing environment where the employees must wear protective gloves that render the touchscreens inoperable. If only you had explained who was going to be using the computers and what for, the vendor might have known from experience to ask the right questions and may have suggested alternatives or at least provided you with the foreknowledge to order compatible gloves.

It also always takes longer to re-explain misinterpreted requirements than it does to start off by explaining what’s happening in the first place. No matter how great your requirements are, they’re always going to be subject to interpretation, and nothing helps to ensure the intended reading better than a shared understanding going in. This is true regardless of who you’re working with to arrive at a solution, but if you’re working with external consultants or developers, it becomes that much more expensive to spend time going back-and-forth. Later on when it’s time to explain why the project ran over budget, it’s going to be bewildering to a stakeholder who is familiar with the current state as to what was so confusing about the requirements. This reflects poorly on all involved, and unnecessarily so.

So, why bother with current state? Because it will help you get to a better solution, with less effort, less re-work, less expense, and provide an all-around better experience for everyone from the stakeholders to the solution providers.