Successful Requirements Gathering for Healthcare Digital Strategy

There’s a common refrain that gets uttered at the end of any unsuccessful project: “The requirements weren’t clear.”

Fingers start pointing, blame gets thrown around, and no one ends up happy. Thankfully, there’s a simple way to alleviate that problem, and it’s as obvious as it is challenging: requirements gathering.  

Here are some common pitfalls to avoid in requirements gathering, and 10 steps you can take successfully kick off your 2018 digital healthcare projects.

What Is Requirements Gathering?

Typically, requirements gathering (or “requirements elicitation”) refers specifically to the practice of defining software requirements, but really every project has requirements, from a new patient experience platform to a remodeled kitchen. At its core, this is the process of understanding what you’re supposed to be building, and why you’re building it.

This process often involves a set of activities including:

• Requirements elicitation: getting business requirements  from all relevant internal stakeholders (not just Marketing and/or IT) and patients that will interact with the new platform
• Requirements documentation: codifying that information in the form of personas, user stories, user journeys, KPIs, and feature specifications so they are accessible to the digital team
• Requirements understanding: making sure everyone’s on the same page about what the heck you’re all trying to build

What Happens If You Skip Gathering Requirements For Your Digital Patient Experience Redesign?

Depending on your project methodology, you may gather requirements at the beginning during a discovery phase, you may do it during the project within each sprint or build cycle, or you may skip it altogether and hope for the best. That last option is a simple way to sabotage your project and guarantee a lot of late nights and awkward status meetings.

10 Tips For Successful Requirements Gathering

Successful requirements gathering is both an art and a science, but there are some general steps you can take to keep this all-important aspect of your digital experience platform project on the right path. Here are some guidelines that we try to follow at Phase2.

1. ESTABLISH PROJECT GOALS AND OBJECTIVES EARLY

This step can feel redundant: of course we know why we’re doing this project…don’t we? Even if you think you know, write it down, and get your stakeholders  to sign off on it. Without clearly stated goals and objectives, you are lacking a framework to guide future decision-making. How do you know if a newly introduced requirement actually fits in your project? Simple: does it help accomplish a goal, or does it satisfy an objective? If so, it’s probably a good fit. If not, it’s a good candidate for a future release.

2. DOCUMENT EVERY REQUIREMENTS ELICITATION ACTIVITY

When you’re in the midst of stakeholder interviews and documentation review, you can often feel like you have a great grasp on things. But then a week goes by, and some details start to get a little fuzzy, and you realize you don’t quite have a full grasp of your business requirements. It sounds obvious, but making sure that you are taking detailed notes during your stakeholder interviews is a powerful step in successful requirements gathering. And it’s not enough to just write everything down, as you’ll see in #3…

3. BE TRANSPARENT WITH REQUIREMENTS DOCUMENTATION

Sure, you understand the requirements. And your stakeholders  understand the requirements. But do your stakeholders understand your understanding of the requirements?

After every meeting, go through your notes and clean them up – then share them with the project team, including the stakeholders. This transparency not only helps make sure everyone’s on the same page, it fosters a sense of project buy-in all the way through your project, beginning with the business requirements. And it circumvents the issue of someone saying “hey, you agreed to X but it’s not here!” 6 weeks into the project. If it’s not in the notes, it didn’t happen.

4. TALK TO THE RIGHT STAKEHOLDERS AND USERS

A project can often have “hidden” stakeholders. Ask probing questions in your kickoff and initial meetings to try and get to who the real users are (your patients, doctors, and internal teams). Often those people are not going to be the main decision-makers, but their buy-in is essential to a successful project. Disgruntled users who are forced to use a system every day that was designed without their input are a key ingredient for a failed project.

5. DON’T MAKE ASSUMPTIONS ABOUT REQUIREMENTS

Don’t assume that you understand everything, even if it seems obvious. A seemingly simple requirement such as “we want a blog” can mask all sorts of underlying assumptions, requirements, etc. What are the fields for a blog post? How are authors managed? What about tagging? Categories? How are the posts displayed? Are they aggregated into an archive? Is there an RSS feed? Who are the authors and what is their level of technical proficiency? Etc. etc. etc. The devil truly is in the details, but you can catch him by the tail if you ask a lot of questions and don’t rely on assumptions.

6. CONFIRM, CONFIRM, CONFIRM

This ties into “be transparent” but is not entirely the same thing. Just sharing your notes with a stakeholder is great, but far more valuable is actually having a quick review with them and getting their official sign-off. This is true for meeting notes, user stories, diagrams, wireframes, really any kind of requirements artifact that you are creating. Radio silence is not an indicator of success – get actual confirmation from your stakeholders that you are representing the requirements correctly in whatever format you’re using, then move on.

7. PRACTICE ACTIVE LISTENING

Making someone feel heard is one of the greatest things you can do for them. But it goes beyond just listening to what they say – you also need to listen to what they don’t say, and how they say things, and read their body language, etc. This is called active listening and it’s a key component of successful requirements gathering. Don’t assume that you’re always getting the whole story – listen for little cues that reveal pain points, desires, unstated goals, and assumptions.

8. FOCUS ON BUSINESS REQUIREMENTS, NOT TOOLS

Be careful when you are gathering requirements that you are really focusing on and listening to what your stakeholder needs. For instance,  if we’re looking at improving the patient experience,  follow the patient journey , not what your tool-of-choice happens to do best. Even if you know you are going to be using a certain product, you need to adapt the product to accommodate the patient journey goals. Listen and gather first, then determine where the gaps are between the patient journey and any existing product you may have in mind. Remember: requirements are about the WHAT, not the HOW.

9. PRIORITIZE YOUR PRODUCT FEATURES

In an agile methodology, we work towards a Minimum Valuable Product (MVP), which encapsulates the least amount of functionality that would count as a successful product at launch. Even when following a non-agile methodology, prioritizing is your friend when you are gathering requirements.

It’s easy for requirements gathering sessions to turn into wishlist gathering sessions, where stakeholders tell Santa (i.e. you) everything they want. The point isn’t to ignore that information (in fact it often reveals goals and assumptions if you’re using Active Listening) but rather to clearly and transparently prioritize what you’re hearing and delineating what is in scope for your initial launch and what is not. You definitely want to track wish-list items, “nice-to-haves,” etc. but prioritizing helps you focus your efforts and helps you make decisions if time gets short and something has to go.

10. REMEMBER THAT YOU DIDN’T GET EVERYTHING

Even the best requirements gatherer is going to miss things. Why? Because you and your stakeholders are human beings, and human beings make mistakes. You will think of things later that you forgot to ask. Your stakeholder will think of things that they forgot to mention. Things will change. Priorities will shift.  

The good news is that if you plan ahead for this, you can build in time during your project lifecycle for ongoing requirements management. This time is essential because requirements (being human-driven and human-created) are simply not static. Giving yourself time to actively manage requirements throughout the entire project can help you stop scope creep before it starts, and make sure that your team is always focusing on the right set of priorities that match actual requirements.

There’s obviously a lot more that can be said about the art and science of requirements gathering, but hopefully this list has given you some helpful tools to manage your 2018 digital healthcare initiatives successfully. Now that you know how to define what you’re building, learn how to align your stakeholders around a common vision for your project.