Most folks have a credit or debit card. And, while most (including myself) use their card to make purchases, sometimes I’ll use mine to scrape ice off my windshield. It’s one of those metal ones, so it comes in handy for odd tasks. If the credit card company replaces it with a plastic card that can’t be used to scrape ice off my windshield, have I lost functionality? Did the credit card company miss a key requirement?
Oftentimes a Business Analyst (such as myself) is needed when upgrading, enhancing, or replacing an existing application. Other times we’re engaged on projects where two companies or parts of the same organization consolidate around a common software system. While there are countless variations on this theme, we need to keep an eye out for “under the radar” usage scenarios. This is where users of a system adopt creative solutions when the tool itself does not have built-in features to support the need. Identifying these innovative use cases, often referred to as “edge cases”, is crucial.
I’ve seen this many times myself. On one engagement, my client merged with a regional competitor. Both firms used the same line of business software for managing support agreements and tracking service requests. The hope was that we could just import their data into our systems and move on. But it wasn’t going to be that easy. The acquired company used different forms of lease agreements and had complex service agreements that didn’t fit neatly into the software, so they developed workarounds. It worked well for them. However, when it came time to determine how to merge the two systems, we had to understand these use cases. The data will fit, but data represents business activity. If we don’t understand those business activities, we have data that’s been separated from the underlying activities it supports. We spent some extra time with the teams to understand how they accommodated these scenarios. Once we were able to identify the gaps we could determine how to mitigate them.
So, how do we go about uncovering these scenarios?
To be successful, we need to learn as much as we can about how our stakeholder groups use the system, and look for clues to uncover additional usage scenarios. Oftentimes they come up through workshops, interviews, job shadowing, and everyday conversations. Remember, people who use these tools day in and day out don’t always understand the details — they just know how they use it. Since time is always in short supply, we should use a methodical approach. Start with a high-level map. In this case, it’s the groups that use the system, the inputs they receive, the work they perform, and the outputs. This could be a simple flowchart, a story map, a value chain — whatever visual aid works best to keep the elicitation process moving forward. Then, work with each group to gather more details. You’re distilling high-level processes into more detailed ones. Workshops are helpful here. Use an iterative process to break down the activities further, until you have individual scenarios. Then, review the results with the stakeholder group to make sure all the scenarios have been uncovered. Throughout this process you may need to work with smaller teams or individuals to gather needed details. Don’t worry too much about whether you’re using the “best” approach. You can always adapt. What’s important is that you’re kicking off the elicitation process and getting people thinking about their work. You may want to consider the following:
- Learn about your stakeholders and the work they do; not just how they use the system or the desired functionality. It’s helpful to understand the business domain in order to ask more meaningful questions
- Listen for uncertainty and knowledge gaps. They tend to lead to new usage scenarios and workarounds
- Reach out to those teams that use the system on a regular basis. Understand their usage scenarios. Often there will be many teams that use a given system. I always start with a larger stakeholder group and pare down as needed
- Always ask targeted, open-ended questions. The goal is to gather information, and the best way to accomplish it is to engage your stakeholders
- Isolate each scenario. Sometimes there are many usage scenarios and a lot of overlap. Distill them down to make them distinct
- Work with your Project Manager or Sponsor to determine how much time should be spent on this work. It’s likely not anticipated and therefore there’s no time in the schedule for it. It’s arguably important work. Help folks understand why it’s important
- Make use of the vast pool of BA resources available to you. Consider using the Business Analyst Body of Knowledge (BABOK 3.0) as a reference for best practices and tools and techniques. The BABOK, your peers, the community at large — they’re all important resources
This is an example of the challenges we face as Business Analysts. We need to elicit these use cases and understand how they impact requirements or risk missing key usage scenarios. Once you understand them, you can distill out the required functionality. But, what about deprecated scenarios? Yep, we need to consider these as well. Workarounds are often temporary or change when enterprise factors change. Remember too, that you may encounter “unofficial workarounds” that people use instead of the intended tools. Just because someone uses something outside its intended purpose does not make it a required functionality. While identifying these scenarios is important, verifying their importance and validating the new solution are just as important.
So, did I lose functionality when the credit card company gave me a plastic card? Since it’s unlikely they would have considered it to be a primary use case, the answer is probably no. However, I’m sure they’d give me a metal card again if I upgraded to the platinum account (the one that also comes with the ‘platinum service fees’). Uncovering creative usage scenarios is a challenge but using an iterative approach to breaking down work processes is a sound way of uncovering them.
David Duvlea: Essentialist – Sr. Business Analyst, CBAP, PMP
