Beyond requirements: How a BA Mindset Transformed a Healthcare Project

Reflecting on one of the most complex projects of my career, this blog explores how I navigated stakeholder conflicts and overcame uncertainty to deliver a solution that truly made a difference in the healthcare industry. Through real challenges and lessons learned, I share how a business analyst’s mindset can shape project success.

What do you do when you’re the business analyst on an Agile healthcare project and nothing aligns: not the stakeholders, not the integrations, not the expectations? When requirements keep changing and you start questioning whether you’re doing your job well enough?

How it all began

A few years ago, I found myself in exactly this situation. A client hired us to rebuild their digital healthcare application where registered patients could fill out medical information, schedule doctor appointments and hold therapy sessions. On the surface, it sounded like a straightforward rewrite. But from the start, I sensed this project would be anything but simple.

The app had a poor user experience, needed to integrate with multiple systems and suffered from misalignment among stakeholders. Every department had a different vision. Frustrated patients dropped off before completing onboarding, and doctors struggled with incomplete data. All of this led to business losses for the client.

It felt like a lot to untangle — and in many ways, it was. But step by step, I found my way forward. The success didn’t depend only on applying standard BA techniques, but also on embracing the right BA mindset – one that balances structure with adaptability, analysis with intuition, and technical knowledge with problem-solving.

In the next sections, I’ll walk you through how I helped align stakeholders, redesign the patient experience and ensure our solution worked for all users. More importantly, I’ll share the lessons I learned not just as a BA but as someone who had to push through self-doubt to make an impact.

Step 1: Identifying pain points and aligning stakeholders

After defining the high-level project scope, we took a closer look at key issues with the client’s existing application. It quickly became clear that the onboarding questionnaire was the biggest pain point. It was supposed to guide new patients through an initial assessment and help them move forward in getting the right therapy. Instead, most users dropped off before completing it.

Because this had a direct impact on the client’s ROI, stakeholders had conflicting opinions on how it should work. Requirements kept changing. The tension grew with each meeting, and I started questioning whether I was handling the process correctly.

At this point, I knew I had to take a step back and apply a structured approach to bring clarity to discussions. Here’s how I tackled it:

• Document analysis – Reviewed past versions of the questionnaire to familiarise myself with the functionality and define inconsistencies and redundant questions.
• Workshops and interviews – Held frequent discussions with key stakeholders to identify pain points and ensure each perspective was addressed.
• Process modelling – Designed high-level process flows to consolidate different perspectives into a single, streamlined workflow.

The image below illustrates one of these process flows, showing where the questionnaire fits into the user journey. This diagram helped stakeholders see the bigger picture and align on a shared understanding of the process.

This diagram is illustrative and doesn’t contain actual project data to maintain confidentiality.

Step 2: Designing a smoother user experience

Once we got all stakeholders on the same page, the next step was to redesign the questionnaire. Our goal was to make it clear, easy to follow and more efficient by automating the process for determining whether patients could receive therapy. However, there were other users included in the process: doctors needed access to responses in their system, and administrative staff needed data to complete onboarding.

Here, collaboration skills and empathy played a key role. Patients, doctors, administrators and third-party development teams all had different expectations for the experience. With so many user groups involved and multiple systems to integrate, it was easy to get caught up in over-engineering.

I focused on bridging these gaps, making sure the system met everyone’s needs without adding unnecessary complexity. This required actively listening, facilitating discussions and turning insights into a solution that worked for all user roles. I tackled it using the following techniques:

• Decision modelling – Created a questionnaire sheet with a complete list of questions, subquestions, answer logic and business rules for determining therapy eligibility.
• Process modelling – Designed detailed flowcharts and activity diagrams showing how patients progressed through the questionnaire.
• Workshops – Collaborated with technical teams and key stakeholders to define how patient data would flow between systems.

Step 3: Building real user scenarios

Although we managed to define all details regarding the questionnaire, one thing still bugged me: would it work for all types of patients? There’s a Croatian saying “Sto ljudi, sto ćudi” (meaning “A hundred people, a hundred opinions”). And it couldn’t have been more true in this context.

The client’s patients belonged to a sensitive group of users, each one with different needs, and I wanted to make sure that our solution worked for all of them.

I remembered that during the discovery phase of the project, initial patient personas were defined to capture key user characteristics. Taking a business analyst mindset approach, I proactively engaged to work further on these findings and refined the personas by analysing:

• How they would interact with the application – Considered factors like age, gender and medical history.
• Example responses for the questionnaire – Mapped how different medical profiles would influence the flow.
• How their answers would impact therapy recommendations – Ensured the logic accounted for individual patient differences.

To illustrate this, I created a personas workflow that maps how different users would complete the questionnaire and how their answers would shape the system’s logic. This approach helped developers and QA engineers to understand the scope of patient needs and later test the system with real-world scenarios. It wasn’t just about logic and workflows, it was about understanding people.

This is a conceptual representation of the personas workflow and doesn’t include real project data to ensure privacy.

Step 4: Translating requirements into actionable development tasks

With a clear solution in place, it was time to translate requirements into development tasks. If you work as a business analyst or a similar role, then you know that technical teams need clarity. Without it, misunderstandings lead to delays and rework.

To bridge the gap between business and development, I focused on structured thinking, adaptability and attention to detail, delivering the following:

• Epics – Mapped the questionnaire functionality within the larger product scope to align it with other core features and long-term goals.
• User stories – Followed the INVEST criteria to ensure that each user story was well-defined, actionable and delivered clear value. Used the Connextra format to structure user stories while adding business rules, assumptions and preconditions.
• Acceptance criteria – Outlined expected behaviours, edge cases and exceptions to give developers and QA engineers a clear reference for validating the functionality.

The outcome: More than just a better questionnaire

Although the patient questionnaire was a key improvement of the client’s healthcare application, it was just one piece of a much larger puzzle. The development process followed Agile methodology, with continuous iterations, stakeholder feedback and incremental improvements across multiple features.

The entire rewrite lasted over a year. When the application went live, the client took it over and continued the work independently. The positive feedback suggested that we had addressed major pain points and demonstrated how valuable a proper BA mindset can be for project success.

Final thoughts: The power of the BA mindset

After the project was completed, I took some time to reflect on lessons learned. Soon I realised that this wasn’t just about rewriting an application or improving a client’s business . It felt like a turning point in my career. It challenged me in ways I hadn’t expected, pushing me to overcome my self-doubt and truly own my role as a business analyst.

There were moments when I felt stuck, when I questioned if I had the necessary skills or if I was doing enough. At times, every discussion with the client felt like a battle. But by thinking about the needs of end users, focusing on solving the right problems and adapting my approach, I was able to turn obstacles into opportunities.

And that’s the lesson I want to share with other BAs: technical knowledge is important, but your BA mindset is what makes the difference. You won’t always have perfect requirements or ideal collaboration, but if you stay curious, embrace complexity and trust that your work matters, you’ll create real impact.