When I think about my transition into business analysis, the first thought that comes to mind is a hallway conversation. A senior BA on the business analyst team approached me on my way back to my desk and mentioned a new position was opening in the department. She recommended I apply.
My first response was “well, there are a lot of projects in QA right now; it might not be a good time.” And her much wiser response to me was “Well, then when will be a good time? This is a good opportunity and probably more money too.” It was good advice. After a lot of soul searching about whether or not moving into business analysis was really a good career move for me, I acted on her advice and applied to the internal position. About a month later, after just a year and a half on the QA team, I found myself moving from the second floor to the third to sit at my new desk with the BA team.
But in all reality, my career transition into business analysis did not start with that conversation. And while at the time I saw this conversation as a lucky one, I had been unknowingly approaching my QA role as an aspiring business analyst.
In what follows I’ll share what I now understand to be the key activities that helped me demonstrate I was ready to be a business analyst.
#1: PARTICIPATING IN REQUIREMENTS REVIEW MEETINGS
I wasn’t immediately invited to attend requirements review meetings. But I was interested in learning more so I asked to be invited. Again. And Again. And Again. Finally I got myself on the invite list. I listened and learned and eventually started to speak up.
I found errors. I questioned details. I helped make the requirements better by being a critical consumer. From the perspective of the business analysts leading these meetings, I was probably erring on the side of being annoying. I have no doubt that this factored at least some degree into that hallway conversation.
I can just hear them scheming: Maybe if we get her on our side, she’ll stop pestering us in our meetings!
My advice to you: Get yourself invited to meetings, especially those related to requirements. Listen first, learn everything you can, and then make yourself as much of a pest as you dare!
#2: CREATING A NEW PROCESS
The particular role I was assigned to was one of those business activities that everyone realized was necessary but no one wanted to own. The type of testing I did had been bunted around from department to department for the last few years. The last person in my role had left after 6 months.
After being hired, I took ownership of the work and created a process. Over time I took things further by organizing related work done by other departments and automating part of the process. By the time I left things were running smoothly and my work could be transitioned to someone else in the department.
My advice to you: Take ownership of work that’s laden with solvable problems and that no one wants. You’ll face very little resistance and get noticed when things get better quickly.
#3: JUMPING INTO THE LIAISON ROLE
Testers tend to be liaisons. When a business stakeholder finds an error, it’s logical for someone from the test team to validate it, write it up, and submit it to the software team for fixing. There was another gap here in my organization and I jumped in to fill it. Before long I was talking to developers from different offices to explain the problems we were seeing and validating issues submitted from our user acceptance test process.
My immature communication skills were put to the test and over time I learned how to communicate with developers as well as how to communicate technical information back to business stakeholders.
My advice to you: Jump into the fray and communicate. It doesn’t matter where the communication break-down is, if you can help fix it, you’ll demonstrate many BA competencies.
#4: DEVELOPING PRODUCT KNOWLEDGE
And while doing all of the above, I learned our products inside and out. I understood how the software was put together and what the key features of most of our products were. I also got to know all of the key business stakeholders. This knowledge proved immensely valuable for my first business analyst role, although it was eventually career limiting and I think I was wise to leave it behind when I moved into a BA role in another organization.
My advice to you: If you know the business, learn the technology. If you know the technology, learn the business. Then leverage the business, industry, or software domain experience you already have for your first business analyst role.
HINDSIGHT IS 20/20 BUT
Of course, at the time, I couldn’t have explained any of this. It’s taken a lot of self- analysis for the patterns to emerge. But that doesn’t mean the pattern wasn’t there. I just didn’t see it at the time.
Today, in my role as a coach and mentor for aspiring business analysts, I find that most of the mid-career professionals I talk to have similar patterns. They’ve been jumping in and demonstrating they have the mindset of a business analyst for a long, long time. And now they are waiting for their chance meeting in the hallway – for someone to give them their first shot. The thing is, once you see your own pattern, you are empowered to change the conversation and seek out the opportunities where you have the most chance of success.
I hope that by sharing my pattern, I help you see parts of your own.
What elements of my pattern resonate with you? In what other ways are you already demonstrating your capabilities as a business analyst?
Комментариев нет:
Отправить комментарий