You may remember Emily Kong. She recently shared her story of turning from IT Analyst to Business Analyst. She was kind enough to check in with us again and let us know about her first two months in her new business analyst job. Read Emily’s story to learn what it’s like to work in a new domain, how to succeed at your first project, and the kind of flexibility business analysts need when it comes to documentation. You can also find out more about Emily by connecting with her on LinkedIn.
I recently started a new role as a Business Analyst at a financial institution. The first thirty days was full of questions and uncertainties. I was briefed with an introduction to the overall company organization, functions and projects. My manager gave me a handful of printouts and intranet sites to work on. They were really insightful as a sneak peak to how projects were managed, as well as what incidents and requests were normally handled.
One of my biggest challenges was learning the business domain. Like every other company, every stakeholder I spoke to used specific industry jargon and abbreviations. For example, we call the consultants who have deep industry knowledge “SME” (Subject Matter experts). In my previous company, they were “vendor”, “consultants”, “engineers”, or simply “IT”.
A note that I learned from my management courses was to adapt to your audience to get your message across. With this in mind, I basically spent most of my first week learning all internal processes, finding out best practice, and knowing who the key players are. I tried to memorize as many standard processes as possible.
My first project was one of many complex system integration projects running in the company. It was to establish standards and draw a line between IT operational and business applications tasks.  Business users would typically contact any IT personnel directly. In order to segregate duties, I created new work flows on how an issue is classified, raised and resolved.
One of my challenges was to use a new analysis tool for data extraction and analysis of issues.  I had never used the third party tool before so I decided to research it online. After studying several tutorials, I created a few reports based on the system data and modeled the reports to my managers. I was able to leverage the large quantities of data as raw material to make better decisions.
Thirty days into the role, I got used to the processes, businesses, and culture. I realized that I was constantly asked to articulate, present or compile the same report in different flavors. This is because some stakeholders needed more visibility of raw data while others just needed a plain summary.  Some of the reports were direct but others required a complete breakdown of each data. However, they shared a common goal – to understand the situation.
In order to be prepared for more questions, I invested more time in digging deeper into the processes. IT and business now understand the segregation of tasks. Issues follow the correct channel to be classified, filtered and escalated. This deliverable is a stepping stone to my consequent projects. My final deliverable is that all services/processes will follow the company standards.
Before I knew it, 60 days passed and my assignment was completed successfully. Although I spent a lot of time and energy on other aspects of work such as communication and report generation, mental preparation is the most important of all when you start a new job. Don’t give into periods of self-doubt. Remember all the hard work you have put in. It will keep you going.
Thanks Emily for sharing your story. We wish you all the best continued success in your new role!
>>Read More Career Transition Stories
Want even more inspiration? We’ve documented dozens of business analysis career transition stories here on Brigding the Gap.