How I Found My Way into Business Analysis

Summary

Almost 10 years ago, I stepped out of my comfort zone as a Developer and moved into a Business Analyst role.

That one decision changed my career. It had opened doors to projects I never thought I'd lead. It expanded my network and gave me opportunities that eventually allowed me to help more than 100 professionals make similar career transitions through Business analysis coaching.

Looking back, it wasn't just a job change. It was a mindset change. I am grateful I took the leap.

How it started

In 2018, I joined the Department of Education in Western Australia as a web administrator and subject matter expert for Liferay, an enterprise content management platform. I believed I had been hired because I knew the system. That was true, but it was only the beginning.

My main responsibility was supporting enhancements and new features for the Department's intranet, used by more than 55,000 students, staff and parents across Western Australia. A change that looked small on a screen could involve huge impact for the users. Technical knowledge alone was not enough. 

Business stakeholders would describe the outcome they wanted, while technology teams needed enough detail to deliver it. I found myself asking questions, clarifying assumptions and checking that both groups had the same understanding. I was no longer simply explaining how the platform worked. I was becoming the liaison between business and technology while closely working with content owners, business teams, developers, architects, testers and operational stakeholders.

Stepping into business analysis

As I became more involved in delivery, I was offered the opportunity to move into a Business Analyst role. I was unsure whether changing direction was the right long-term decision. In hindsight, it was one of the best decisions I have made in my career. I accepted the role and stepped into a traditional business analyst role and this where it all started. 

I worked with stakeholders across multiple teams to clarify and validate requirements. I wrote user stories and acceptance criteria for Agile sprints and helped the delivery team understand both what needed to be built and why it mattered.

Testing was also part of my work. Using Zephyr for Jira, I checked the functionality against the agreed acceptance criteria. I was not simply recording whether a test passed or failed; I was tracing the solution back to the original business need.

On another stream of work, as a business analyst, I supported the migration of Department’s newsletter from a legacy system into the enterprise CMS. The change involved metadata, vocabularies, integrations and input from SMEs, developers, architects, testers and business users. Requirements had to survive many handovers without losing their meaning. 

That experience showed me the reality of business analysis and the realization that requirements do not always arrive neatly packaged. Stakeholders may know what is frustrating them without knowing what the solution should be. Technical teams may build exactly what was written, only for testing to expose an assumption nobody had discussed. Through this experience I learnt that the BA has to keep the thread intact from the first conversation to the final outcome.

Confidence followed evidence

For a while, I hesitated to call myself a Business Analyst because I had not entered the profession through a formal BA pathway. I assumed the title should come first and confidence would follow.

The opposite happened. Confidence came from evidence: a stakeholder confirming that I had understood the real need; a developer being able to act on a clear user story; a missed scenario being found during testing rather than after release; and teams with different priorities reaching agreement because I had helped make the issue visible.

I also stopped viewing my software and IT experience as separate from business analysis. It became my quiet advantage. I could understand technical constraints without allowing the conversation to begin and end with technology. I learned to start with people, process and purpose, then work towards the solution.

Transition into business Analysis coaching

As I continued the BA path, I became curious about how other analysts handled difficult stakeholders, changing requirements and defects reaching production. I began attending BA networking events and asking practitioners which techniques had helped them in similar situations.

That curiosity led me towards professional development and BA certifications. While studying, I helped form a study group and later became an IIBA study group facilitator. Teaching and discussing techniques with other analysts strengthened my own practice and developed my confidence as a coach. I went on to achieve the PMI-PBA, Agile BA and Scrum certifications.

Over time, I have used those lessons to support more than 100 professionals navigating their own career development and transitions. Coaching others was not part of my original career plan, but it grew naturally from the same instinct that drew me to business analysis: helping people make sense of complexity and move forward with clarity.

The career shift I am grateful I made

Today, I am continuing the path I started 10 years ago with the same passion. My BA career began with my knowledge of Liferay, but it took shape when I learned to connect business needs with technology delivery. The role brought together the parts of work I value most: curiosity, problem-solving, continuous learning and working with people.

I did not leave my technical background behind to become a Business Analyst. I just learned to use it differently.