Maybe you’re thinking of making the transition to Business Analysis.
Perhaps you are a long time developer who wants to make a career change. Or you have an idea for a project, and you find yourself being its champion. Maybe someone has decided that your company needs to move to some other SDLC methodology and you have been chosen to explore what that means.
Or maybe you are like I was a few years ago. Having worked for one company for over 20 years I was faced with an unexpected transition. After my first extensive job search, I landed a new job with a new title I’d never heard of before – Business Analyst. Because of my experience, they put the Sr. moniker on it – Sr. Business Analyst. I didn’t know what the title meant.
I’ve told versions of that story in a couple of interviews to explain how I landed in the Business Analysis arena. Evidently folks are impressed when you can do something well – even though you don’t what you’re doing!
When I started in the new position, it took me a while to discover that I had been acting as a BA for quite some time. But it was hard for me to accept the new title. Why? My title had been Sr. Systems Engineer. At least I kept the Sr. part. But I wanted a title that sounded more like a technical genius, lead developer, project manager or at least project leader. I’d often filled those roles, along with systems designer/architect, security officer, client liaison, tester, process engineer and a host of other roles. I had switched between them over and over again.
Then a friend asked me, “What did you do at that other job?” When I told her, she said, “That’s a BA.”
“That’s not a technical thing,” I protested. “That’s a business thing.”
Acceptance was hard, but eventually I started figuring it out.
Until relatively recently, it seems that most Business Analysts, like me, just found the role without knowing it. Thankfully that is changing.
Say that again?
That’s right, there was another identity crisis in the Business Analysis profession which was working itself out while I was going through my personal and professional search. The industry seemed to be asking, “What is a BA, again?” I thought it was some combination of technical genius, lead developer, project lead, project manager, systems designer, systems architect, security officer, client liaison, tester and process engineer. My friend said that’s a Business Analyst. A little focus would be nice, both for me and for Business Analysis as a whole.
I find that the Business Analyst role has long suffered from that identity crisis. So let’s help give some definition to the role. And to assist with that, I’ll refer to A Guide to the Business Analysis Body of Knowledge (BABOK Guide, v3) by IIBA. Right off the bat, it gives a lot of focus that was missing from my friend’s definition.
“Business analysts are responsible for discovering, synthesizing, and analyzing information from a variety of sources within an enterprise, including tools, processes, documentation, and stakeholders. The business analyst is responsible for eliciting the actual needs of stakeholders—which frequently involves investigating and clarifying their expressed desires—in order to determine underlying issues and causes.” (BABOK Guide, v3, pg 2-3)
Let’s shorten that a bit. Business Analyst bring clarity to business needs by investigating the issues and their context. Then they use the knowledge gained to define solutions to fill the business needs.
When I learned that, I thought, “What? Where’s the tech genius? Where’s the systems architect?” It seems there’s no super-do-it-all role for a Business Analyst.
Or is there?
Let’s look at this role another way.
When I was young, I remember hearing about some of the great Renaissance thinkers. People like Milton, daVinci and others who still have impact on so many elements of our society today. One of the things I remember about those people is how they knew a lot about everything. Art, literature, architecture, theology, politics, economics, medicine and science were all subjects which they were not only aware of, but fluent or expert in. I remember thinking that I’ll never be as smart as those people, but I can set a goal to always be expanding my knowledge in many different directions.
Likewise, the Business Analyst role requires a hunger for multifaceted learning. The role is designed to be independent of any specific functional area, industry, sector, methodology or technology. Saying that another way, Business Analysts are exposed to just about everything. And successful BAs demonstrate the ability to apply the trade across multiple technologies, methodologies and functional areas. Business Analysis requires a great amount of adaptability and develops a great amount of exposure.
I know many BAs who have:
And a few I know have exposure to almost everything I’ve just listed. So even though we’re not experts on everything and can’t aspire to the levels of the Renaissance thinkers, we do know who to ask that is. And we learn from them.
Breadth of Experience Matters
More than that, everything you learn on one project from all of those different methodologies, sectors, technologies and focus areas will be useful on future projects. This is one of the most exciting elements of Business Analysis.
Since learning that I really was a Business Analyst, it is amazing how each job transition was facilitated by the position I had immediately prior. It doesn’t always happen that way, but there’s been so many instances that I cannot deny it. One job for a manufacturer led to a college requiring the manufacturer’s product and services when hosting the US Vice Presidential debate. A position with a health insurer leading to a public sector position in the same industry. During each transition, though there was a tie to the old, the experiences differ so much that there’s always a lot to learn.
Traits of a Business Analyst
Earlier I said that to be a Business Analyst requires a lot of adaptability. That is because the right solution is always flavored by the broader context of whatever endeavor the organization has in mind. The right solution for the same problem can be very different in a different context.
To understand that context requires an additional trait – curiosity. There are hundreds of questions to be asked and answered. Each answer reveals a little more, but raises new questions. When you’re just about to the end, it’s inevitable that you’ll think “I’ll never get to the bottom of it.” Then, just as inevitably, a few items are revealed and everything falls into place.
This brings me to the next trait – persistence. Just like you can never grow tired of questions and of learning, you must also keep pursuing the answers.
Currently I’m working on a reverse engineering project. Many of the customer’s Subject Matter Experts were let go a few months back, so getting answers is taking much longer than usual for this kind of a project. My work partner and I had been going in circles for about three weeks asking the same question – “What’s next?” It seemed like the information would be left hanging with no where to go. We knew what must happen. We couldn’t get the answers to how it should happen. We had asked “What’s next” numerous times, but got answers to every other question – not the one we were asking. Normally I would be OK with that, because the information usually does add clarity to something, just not the something I’m looking for at that moment. This time, it was just going in circles. Three weeks of going in circles. It left us feeling dizzy and we start thinking we’ve lost. Finally, we gave a presentation of what we’d learned so far, and we asked the question one last time.
This time the answer came. It was so simple that we were able to fill in 80% of our remaining work that afternoon. Three weeks work was resolved in 4 hours. And that illustrates another trait – Patience.
Patience can take a couple of different forms. Being able to wait without getting frustrated is one kind of patience. One way to channel that kind of frustration is to keep busy in another aspect of the project. A former boss of mine used to say, “If we can’t have progress, let’s at least have movement.”
Another kind of patience is the ability to handle difficulties, whether it’s people or challenges, without getting rattled. Perhaps that’s better called level-headedness. Things do get heated. People may get irritated. And if the challenge was easy, they wouldn’t need a Business Analyst to assist in the work. There are times that the relational aspects of the work can be as challenging as the work itself. Handling those frictions, knowing that there’s a good level of friction and a “crossed-the-line” level, and knowing how to keep that balance are all key skills.
What it takes
At the beginning of this article, I discussed my journey to becoming a Business Analyst. Luckily, falling into the role isn’t the primary path anymore. Really, that’s the hard way to go about it. Having the role better defined and growing clarity on what it means is good for the Business Analyst role, those who aspire to become Business Analysts and for the organizations that hire BAs. The International Institute for Business Analysis (IIBA) has gained a lot of visibility and has published several books on the subject. Notably is the A Guide to the Business Analysis Body of Knowledge. IIBA has also created certification tracts which, for those trying to break into the field, will give a level of assurance to a potential employer. If you have what it takes to become a Business Analyst, please check out their web page at www.iiba.org.
In the coming weeks, I will be sharing more on my journey into Agile Business Analysis. So please stay tuned.
First published on LinkedIn, December 19, 2015