I have worked in the trenches as a business analyst for almost two decades now, and I have learned to look for one essential element in any potential analyst with whom I work: a willingness to ask what others might classify as “dumb” questions. There are a lot of other traits that I look for, such as great communication skills, humility, attention to detail, and the ability to work with anyone—from executives to the individual worker bees. But the self-confidence it takes to ask dumb questions is the game changer for me. It cannot be taught, and it is a badge of honor.
I am proud to say that I have learned my trade through trial and error. When I started in IT, there was really no such thing as a business analyst as we know them today. There was no IIBA. The internet had just been born and the start-up world was dawning. It was a brand new concept to trace business needs to IT and software. Before we knew it, there were business analysis standards and even certifications. Over time, I often found myself running into business analysts who lived in fear of looking like they did not “know their stuff” in front of their business teams.
Read More: Strategy Execution & Change Management
This often resulted in repeated conversations that never really got to the heart of business problems, an unsatisfied business team, and a very stressed analyst.
A great business analyst is not afraid to drill down to the core of an issue, and that inevitably means being okay with asking fundamental questions. I call them “Captain Obvious” moments. It helps level-set the business team with a common understanding, but it also makes them question why they do things in a certain way. Questions like, “why do you do it that way?” or “what does that mean?” are the ones that everyone is probably quietly asking themselves, but may be afraid to say aloud. You don’t have to be asking “why” at every juncture, but it is important to ask why at the right moments. More often than not, the business team is relieved you asked because they have been asking themselves the same things.
When you ask “dumb” questions, you in fact ground yourself as a credible resource with your business and development teams. If the current state analysis and business requirements are incomplete, it causes mass confusion for a software development team. They start asking about the very things that the business analyst should have asked… and herein lie the teachable moments. When you are brazen enough to ask basic questions, the teams will come to rely on you, rather than potentially dismiss your efforts. People will know that if they assign you to something, you’ll do the due diligence to get to the root of a problem. To be a great business analyst, you need to be willing to leave your comfort zone and take leaps.
We are taught at a young age that there is no such thing as a “dumb” question, and I’ve found this to be wholeheartedly true as I’ve advanced in my career. In examining a process or system, every question is valid. The cost of not asking can be devastating to your project and to your reputation as an analyst.
Looking for Further Reading?
About the Author
Dana McInnis is Principal at Trilix. Dana lives by Emily Dickinson's words, “I dwell in Possibility.” She is energized by the opportunities that exist in eliminating mediocre processes and helping business teams think differently. Dana has more than 20 years of experience as a business and systems analyst, technical writer and trainer, having worked in the application development space within the government, healthcare and financial sectors. She is a Certified Scrum Product Owner (CSPO) and Six Sigma Greenbelt.
Dana is an artist at heart. She received an MFA in Creative Writing and as her final thesis authored a biography of America's most celebrated lighthouse keeper, Ida Lewis, who lived in Newport, Rhode Island.