Beyond Requirements: How a Business Analysis Mindset Transformed a Healthcare Project

Disclaimer: The views and opinions expressed in this article are those of the author and may not reflect the perspectives of IIBA.

This is the fifth and final entry in our “Ideas in Action” writing contest. Like what you’re reading? Vote for it in our LinkedIn poll at the end of the contest!

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

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 business analysis techniques but also on embracing the right business analysis mindset¹—one that balances structure with adaptability, analysis with intuition, and technical knowledge with problem-solving.

In this article, 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 business analysis professional 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 directly impacted 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 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 familiarize 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, other users were 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, sub-questions, 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 the details regarding the questionnaire, one thing still bugged me: would it work for all types of patients? As the Croatian saying goes, “Sto ljudi, sto ćudi” (A hundred people, a hundred opinions)—and it couldn’t have been more fitting in this context. The client's patients belonged to a sensitive group of users, each 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. I proactively engaged to work further on these findings and refined the personas by analyzing:

• 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 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.

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 in a similar role, 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 business analysis mindset can be for project success.

Final Thoughts: The Power of Mindset

After the project was completed, I took some time to reflect on the lessons learned. Soon I realized 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 business analysis professionals: technical knowledge is important, but your 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 a real impact.

Your next breakthrough in business analysis begins here. Download The Standard today to cultivate a mindset for success—one that’s flexible, adaptable, and equipped to uncover value in any situation.

---

Notes

1. The business analysis mindset emphasizes qualities such as adaptability, problem-solving, collaboration, and continuous learning. For an in-depth exploration, see Yulia Kosarenko's Business Analyst: A Profession and a Mindset (2019).
2. INVEST criteria is a framework for writing effective user stories, introduced by Bill Wake in INVEST in Good Stories, and SMART Tasks (2003). It emphasizes that user stories should be Independent, Negotiable, Valuable, Estimable, Small, and Testable, ensuring that they are clear, actionable, and aligned with business needs.
3. The Connextra format for user stories ("As a [user role], I want [goal] so that [reason/benefit]") is widely used in Agile development to ensure clarity and user focus. For more details, see Mike Cohn’s User Stories Applied: For Agile Software Development (2004).

---

About the Author