ArgonDigital - enterprise automation experts

Share This Post

Business Analyst Tip: In your meetings and projects, don’t miss the gorilla

Business Analyst Tip - Look for GorillasI hate the common phrase “expect the unexpected”. It makes me angry when I hear it, because it defies basic logic. If something is unexpected, there is no way you can expect it, by the very definition of the words being used. However, no matter how much the phrase infuriates me, I think business analysts can learn something by expecting the unexpected when planning meetings and projects.

Maybe a more accurate way to state the phrase would be “create an environment where the unexpected can come to the surface and be noticed,” although that isn’t nearly as catchy. Because our projects are so complex and there are so many unknowns, we will encounter things that we didn’t expect. These are often critical things to notice, especially when they are bad things, because if ignored they could harm the project. However, there are also often unexpected good things that we will come across during the course of any project, and if these are missed, the project will have a much lower chance of success.    

Just because these things are unexpected doesn’t mean that you can’t create an environment where it will be easier to notice them. Quite often, unexpected things are ignored because they don’t fit within the dominant narrative of the project, and most team members have blind spots to things that they don’t expect to see.

There was a research study where a woman in a gorilla costume walks through a game of people playing basketball. (Here is a link to that study, and the video showing the gorilla is here). Because this wasn’t expected, and the study participants were busy doing something else (they were assigned to count the number of passes), half of the people watching the video did not see the gorilla. As unbelievable as it seems, many people missed an event as odd and important as a gorilla walking through the scene. If we miss gorillas, what chance do we have to catch small changes in requirements?

Even small unexpected things have a potentially big impact on our projects. A single usability preference among your users could sink the entire project if missed. Even though you can’t plan for the unexpected, you can design your meetings and project plans in a way that increases the chances that these things will emerge and be noticed.

When going into meetings, design your presentations in a way that exposes you to as much unpredictability and emergence as possible. There are many things you can’t predict about the meetings, for example:

  • All the areas of expertise of your attendees.
  • Attendees’ feelings about the project.
  • Unexpected changes in the project.
  • Unanticipated findings about the project.

Rather than to design your project with tunnel vision, only asking very specific questions and deeming everything else out of scope, it is best to capitalize on any new findings and use them to adjust the flow of the meeting. For example, if your stakeholder has no information on the topic you were asking about, but happened to previously work 10 years in another department, by all means abandon your plans and follow where that unexpected information leads you. To better enable switching gears like this midstream, you must have all project deliverables and background documentation easily available, so that you can instantly pull up something that you originally had no intention of speaking about.

Also, in the questions you ask, mine for this unexpected information. For example, one of my first questions is always, “Who else should I be talking to about this?” Early in the meeting I want to capture the names of anybody I don’t know about, because they may be a crucial piece of the puzzle that nobody knew about before. Even in the latter stages of the project, keep asking for new names, because everyone you talk to has a unique perspective on the project and can see things that others miss.

In order to enable this discovery, I like asking a few broad, open-ended questions before I get into the details. The two questions I generally ask the group are, “What obstacles do you foresee in this project?” and “Is there anybody else I should be talking to?” I usually have a list of all the people I’m planning to talk to on that slide, because the question “is there anybody else” is pretty useless if they don’t know who I’ve already spoken with. The other thing that this list of names gives you is authority: if you’ve already planned on speaking with most of the important stakeholders, the information you present will be understood as being already vetted by some of them, so it makes your models seem much more a collaboration with the business rather than just something that you created on your own.

Another set of unexpected information: thoughts from people on aspects of the project that you didn’t predict they’d have insights on. To help aid this, rather than show small parts of the project to each separate silo of people, show as much of what you have as possible to each group. Look at each group you speak with as a focus group where you have the opportunity to learn what stakeholders think of your plan for the project. The more things you can show them and get a reaction to, the better.

I try to be as open-book and explicit about everything I’ve done and plan to do, because maybe somebody will see something that looks wrong and tell me about it. I’ll put all my plans for the project in front of each group, and basically ask “what do you think?” and “any additional thoughts?” Another benefit of doing this is that if there are no comments from the group, you have gained implicit approval of it. If anyone is ever unhappy with the direction of the project, you can demonstrate that you’ve been showing them the plan consistently throughout the project, and gaining approval throughout. This should convince the stakeholders that you weren’t taken by surprise and had a plan in mind the whole time, and in fact have been showing that plan to everyone you meet.

Adding these approaches into your projects will increase the chances you’ll notice any gorillas running into the room. In the end, it isn’t the number of gorillas that’s important, but simply the fact that you notice them at all…and act on them. Like it or not, some of the most important twists and turns that your project takes will likely come from unexpected things, and only by planning for catching these things can you avoid getting surprised by a gorilla.

 

Business Analyst Tip: In your meetings and projects, don’t miss the gorilla

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage