Author: Larry Blankenship

Best of BATimes: What Problem Are You Trying To Solve?

Written by Larry Blankenship on August 24, 2023. Posted in Articles.

One of the most important lessons I’ve learned to ask during my BA career is “What problem are you trying to solve?” It’s not as straightforward as it might appear.

Often, business partners come with all sorts of preconceptions, which they present as the actual problem. Sometimes they try to be helpful. It’s the BAs job to ask more questions to determine if that’s the real problem.

For example, I had a business partner who told me that the data in an email we were sending to one of our customers was “encrypted”. It would have been easy to waste hours trying to chase that down. I started down that road, until I caught myself and asked “What’s the problem I’m trying to solve?” I asked the business partner to see a copy of the email. It was then that I realized that what she was referring to as being encrypted was actually just raw XML being presented straight to the page. The problem wasn’t that the email was encrypted, it was that it wasn’t easily readable by a human. One parameter change later, and the problem was fixed.

Donald Gause and Gerald Weinberg wrote a seminal work on discovering the real problem called “Are Your Lights On?” I reread it at least once a year, to remind myself how to ask the questions needed to determine the real problem, because sometimes what appears to be the problem at first glance isn’t the real cause.

A recent real-life example was encountered by the Dutch bike manufacturer Van Moof, who found that over 25% of their bicycles were being damaged en route to the customer, especially when being shipped to the US. The company could have invested money in improving their packaging or looking for a new shipping company. Instead, they spent time identifying what the real problem was: the people doing the shipping weren’t being careful with the product, perhaps because they perceived a bicycle as being sturdy enough to withstand rough handling. Or perhaps they didn’t perceive bicycles as being as valuable, so they didn’t feel the need to take extra care when handling them. What was the solution?

In the end, the bicycle company put a picture of a large screen TV behind the picture of the bike. They didn’t indicate that there was a TV in the box. The shippers, who apparently don’t have time to read carefully, treated the updated boxes like there was an actual big screen TV inside them. As a result, damages in transit dropped by 80%.

1. Asking the business or customer what the problem is that they are trying to solve isn’t the end of the process, it’s only the beginning. Here are some ways you can get to the real problem:
Ask what things would look like if the problem was solved. Often, this will let you identify the real problem based on what the business sees as the desirable result. An example given in the book was a building whose tenants complained about the elevator being too slow. The desired solution wasn’t that the elevators be made faster, it was that the tenant’s stopped complaining. In the end, a mirror placed on each side of the elevator offered enough distraction that the perception of the elevator’s speed was no longer an issue.

2. Don’t accept a solution as the problem. Often in my career, the customer brings a solution that they want rather than a problem to be solved. Asking what the problem is that’s trying to be solved often allows for simpler resolutions. For example, one department is complaining that another department’s data entry isn’t accurate. The solution they presented was to add a high number of edits and validity check to the system where the data was entered. This would have required a large quantity of analysis and development time to ensure that the validations were correct and didn’t create additional follow on effects. Instead, time was spent bringing the two departments together to discuss the issues and looking for ways to improve accuracy at the front end. In the end, development wasn’t required, and the problem was solved via process improvement.

3. Spend time on root cause analysis. Sometimes the perceived problem is a symptom, not the actual malady. When I wrote software, a bug would frequently be caused by a change to a variable much removed in the stack from the code I was looking at. Doing root cause analysis will often help you identify what element is actually causing pain. This can also be a matter of overlooking something because “We’ve always done it that way.” The root cause may be the result of some process before or after the pain point that is creating the issue.

In the end, finding the real problem that needs to be solved, can be simple, complicated or somewhere in between. Taking the time to do the right level of investigation is an important part of the BA’s value in the development process.

Published: 2020/06/04

What Problem Are You Trying To Solve

Written by Larry Blankenship on June 4, 2020. Posted in Articles. 1 Comment on What Problem Are You Trying To Solve

One of the most important lessons I’ve learned to ask during my BA career is “What problem are you trying to solve?” It’s not as straightforward as it might appear.

Asking the business or customer what the problem is that they are trying to solve isn’t the end of the process, it’s only the beginning. Here are some ways you can get to the real problem:
Ask what things would look like if the problem was solved. Often, this will let you identify the real problem based on what the business sees as the desirable result. An example given in the book was a building whose tenants complained about the elevator being too slow. The desired solution wasn’t that the elevators be made faster, it was that the tenant’s stopped complaining. In the end, a mirror placed on each side of the elevator offered enough distraction that the perception of the elevator’s speed was no longer an issue.
Don’t accept a solution as the problem. Often in my career, the customer brings a solution that they want rather than a problem to be solved. Asking what the problem is that’s trying to be solved often allows for simpler resolutions. For example, one department is complaining that another department’s data entry isn’t accurate. The solution they presented was to add a high number of edits and validity check to the system where the data was entered. This would have required a large quantity of analysis and development time to ensure that the validations were correct and didn’t create additional follow on effects. Instead, time was spent bringing the two departments together to discuss the issues and looking for ways to improve accuracy at the front end. In the end, development wasn’t required, and the problem was solved via process improvement.
Spend time on root cause analysis. Sometimes the perceived problem is a symptom, not the actual malady. When I wrote software, a bug would frequently be caused by a change to a variable much removed in the stack from the code I was looking at. Doing root cause analysis will often help you identify what element is actually causing pain. This can also be a matter of overlooking something because “We’ve always done it that way.” The root cause may be the result of some process before or after the pain point that is creating the issue.

Match Maker, Match Maker

Written by Larry Blankenship on February 5, 2020. Posted in Articles.

As BAs, we play many roles in the Software Development Life Cycle.

Sometimes we are matchmakers in working to connect the business with the solution that we hope will turn into a long-term relationship. Depending on the project, we may also play officiants (think Justice of the Peace), therapists, obstetricians, pediatricians, geriatricians toward the end of the product’s life, and even funeral directors at the end. We play a role from before a solution is a twinkle in anyone’s eye to the point where we have to lay it to rest. I may have taken a blender to my metaphors from this point forward, so bear with me.

Our first job is to put the business and the solution together. Sometimes we help the business fill out a questionnaire about likes and dislikes, and then try to find a good match. Other times we are writing the equivalent of a Tinder profile, trying to get the user to swipe right. We might even try using agile techniques, which Is the requirements gathering equivalent of speed dating, and we keep sending the business likely candidates for a long term relationship them until they find something they like.

Once we get the two to decide they want to try going steady, we spend most of our time shepherding the relationship along. It’s critical to manage expectations so that the solution never gets the “It’s not you, it’s me.” speech from the business. If it ever gets to this point, they have already cast their eyes elsewhere because the solution isn’t meeting their needs, much like real life.

Once the business makes the commitment is to go a certain direction, we generally work with the Project Manager to finalize the whole relationship:

“I now pronounce you user and solution.”

This is where the trouble can start. As compromises are made, and needs change, it becomes critical to make sure that things don’t change so much that the business or user decides they want to get a divorce. As the saying goes, “Love is grand; divorce can be 10 or 20 grand”

Sometimes in this process, we end up playing therapists. “How did it make you feel when the Project Manager told you the feature you thought was a must have would have to wait until the next release?” Lots of negotiation and discussion, but hopefully no tears.

Other times, we get through all that and we’re ready to start the whole gestation period, preparing the business for the arrival of the solution they’ve been waiting to see for months and sometimes even years. If we’re smart, we’ve done lots of reviews, which are the SDLC equivalent of ultrasounds, so they know what to expect. If we’re not smart, we wait until the very end, only to find out they got a boy when they really, really, really wanted a girl. It’s usually not that drastic, though.

If we’re lucky, and we’ve done our jobs correctly, we deliver the solution to the business and everybody is happy and excited for a while. Then the business starts getting nervous, being new parents.

“No, it’s supposed to do that, remember, that’s what you said you wanted?”

Other times, we just burp the baby and move on, fixing data or making a configuration change to keep things moving. Then when the parents still complain, we have to play Super Nanny, because the parents need to understand that their own behavior is contributing to the problem. When that happens, we may have to explain that there needs to be consistency for things to work right.

As time goes on, the solution matures, and we sometimes have to help fix a broken bone or two or even do a face lift. These are the ongoing bug fixes and cosmetic changes that happen over the life of the system. Usually by the time it gets to this point, there is an emotional attachment, so we have to do everything we can to keep the solution alive.

But eventually things reach the point that we become geriatricians, dealing with gradually slowing performance, and technology that just isn’t able to keep up with the demands the business places on it. We will work with the surgeons (developers) to try to keep things going, but eventually, it’s clear that we’ve reached the point where we need to lay the solution to rest.

In those cases, we spend our time planning the funeral, and sometimes we end up having to play grief counselor, as the business comes to term with the fact that their beloved solution is no more. We have to figure out how to give everyone closure before we sign the death certificate.

Then the whole thing starts all over again. That’s why they call it a cycle.

Writing User Stories When There’s No User

Written by Larry Blankenship on May 23, 2019. Posted in Articles.

One of the first things most of us learn when we make the transition to Agile business analysis is how to write user stories.

If you’ve started your Agile journey, you’re probably familiar with the format: “As a , I want to so that I can ”

However, what happens if you don’t have a user, but instead are dealing with a system? When I started working in Agile, I didn’t have users to write user stories for, I had APIs and file transfers. The users in my case were the systems that would consume the output from other processes and create output used by other processes.

I had to come up with a different way of thinking about user stories. The user isn’t directly involved in the process, or was involved so early in the process, that they don’t have much input or effect on it. I found it was hard to identify roles or user profiles to include in the usual format. This article is about how I learned to work differently to address that question.

When there isn’t a user, the purpose or value of the story has to become the focus. The system should always act the same given the same inputs, so there isn’t the kind of variation you would see with a human user. What becomes more important is the reason the story exists at all: the reason for the system to behave a certain way. Granted, the value of the story is important whether or not a human user is present, but it becomes more important in this case.

In my world, most of the requirements come from changes in state law or legislation, so the reason for a story is quite often to comply with regulations, or to provide required information to the state. In other cases, the department that handles reporting and inquiries from the state needs information to be processed in a certain way, but still doesn’t have direct interaction with the systems that do the processing.

In order to deal with this problem, I use a couple of different formats to write my user stories when a user is not the subject of the story: “In order to/for , the system .” I try to include the business unit or entity that has the objective in the first clause, as it makes the value of the story clearer.

So for example, I might write “In order for the state to process vehicle records properly and to provide efficient transmission, the system sends a valid driver’s license number with each record.” In this instance, the value of the story is that the state is able to process vehicle records properly. If I wanted to, I could go into more detail about that, but since all of the people in my team know why this is valuable, it’s not required.

I can, and often do, provide details about the objective not being achieved as part of the story discussion or as part of the acceptance criteria. This story would probably be part of a larger epic describing what a valid record means for that state, listing all of the fields that need to be validated before a record can be sent. I might include the detail about the consequences of invalid records being sent at that level, since it applies to all of the data in the record. This story is one part of that epic, but keeps the focus on just one data element. I like doing things like this as epics because it’s easier in a case like that to combine stories or separate them to to organize the work.

Another way to write these, if you prefer, is to say “Because , the system . Again, I try to include who made the requirement necessary in the initial clause to make things very clear as to why the story is valuable.

After I discussed this with some of my fellow BA types, one said, why not make the system the user so you can use the usual format? For example “As a , I need to , so I can . This is a perfectly acceptable way of doing things. I do think it takes the emphasis away from the value of the story, which is why I prefer the first two formats, myself.

Once we’ve written the user story, most of us know that the next step is to write acceptance criteria and provide other information that the developers might need to implement the story. In this case, I would need to provide rules for identifying a valid driver’s license number for the state in question. I would also need to provide a set of acceptance criteria to give the developer a way of knowing when the story was complete.

Most of the time this is in the form of use cases or a list of business rules that describe the incoming data, and what gets done about it in terms of error messages, logging, or other responses to the data. This might actually create an ancillary user story involving a human user, for example “As a state reporting specialist, I need to receive an email when a record is rejected by the state.”

Writing user stories is an essential skill for Agile business analysts. Focusing on value is one way to address “userless” user stories. While value is always important, it becomes especially critical when user behavior is predictable and definable.

The Knowledge Awareness Matrix

Written by Larry Blankenship on January 15, 2019. Posted in Articles.

Most everyone has seen the Productivity Matrix with the following rows and columns:

	Urgent	Not Urgent
Important
Not Important

The idea is to focus most of our activity in the Important and Urgent quadrant. It’s critical to pay attention to Important but Not Urgent items so that they don’t suddenly become Urgent And Important. Avoiding putting effort into the other two quadrants is essential to productivity.

There’s a different type of matrix that can be used when gathering requirements. Use it to help identify information that might not otherwise have been discovered until the last minute or even after an application goes to production.

Murphy’s Law of Requirements: Unspoken requirements will always be revealed at the most inopportune time.

Think of it as a Knowledge Awareness Matrix. The intersections of knowledge and awareness show who is most affected, the Subject Matter Expert (SME) or the Business Analyst (BA). In all cases, it’s assumed the knowledge is needed in order to have a full picture of the requirements.

	Aware	Unaware
Know	SME	SME
Don’t Know	BA	BA

I got the idea for this from a Donald Rumsfeld comment while he was Secretary of Defense. “There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don’t know. But there are also unknown unknowns. There are things we don’t know we don’t know.”

PMI discusses this in terms of risk and refers to it with regards to evaluating risk. I use it when planning interviews with SMEs.

The four categories are:

Knowledge the SME is aware of – Things they are conscious of knowing and aware that other people will need to know.
Knowledge the SME is unaware of – Things that are intrinsic to anyone with similar experience or in a similar profession. They may not be aware they need to tell other people about them because the assumption is that everyone knows what they know. Or they know it so well they don’t even think about it. Professional jargon, including acronyms, or a well-established process are places where this often comes up.
Knowledge the BA is aware they don’t have – Questions that need to be asked because it’s readily apparent the information is necessary to acquire. This is most often the first draft of the questions that the BA writes for the initial interview. As elicitation continues, the awareness of other needed information becomes apparent. It’s important to identify items in category 2 as part of this process.
Knowledge the BA isn’t aware they don’t have – Information that they don’t have and aren’t aware they need. This can be edge cases, specific rules, or data combinations that aren’t communicated.

In my experience, Categories 2 and 4 are the most dangerous and can cause the biggest problems in any situation.

They are the biggest source of last-minute changes, and it’s the BAs job to ferret them out.

Category 1 techniques

The question I try to ask at the end of every elicitation interview is “Were there questions you expected me to ask that I haven’t?” Often this helps to drive out information that the Subject Matter Expert (SME) knows and is aware that they know but forgot to mention during the interview.

Using reflective listening on a continual basis not only checks the BA’s understanding but may also help the SME remember other facts that they need to share.

Another technique I like is Example Mapping, which fleshes out a user story with rules and examples and that can drive out further detail. If you want more information check out Matt Wynne’s blog post here: https://cucumber.io/blog/2015/12/08/example-mapping-introduction

Category 2 techniques

Most BAs are familiar with the idea of egoless questions. This is useful when working with a SME that is extremely experienced and knowledgeable. Approaching them as a student, even when knowledgeable about the domain, can often make them more aware of what they know and the need to share it.

Questions that can be used to find edge cases that aren’t immediately obvious:

Has this process failed in the past?
What happened?
Was it fixed, or did you have to come up with a work around?
What did you do?

Another way to help elicit intrinsic knowledge is to interview a more experienced SME with a junior member of the staff in that area. Often the less experienced staff member will have their own questions, which effectively doubles the BAs interviewing power and will further prompt the more experienced person to provide information.

Category 3 techniques:

This is really the bread and butter of any BAs work. Asking questions, and capturing the answers is the most important thing we do. The most important tool in this case is a good set of questions. Taking time to prepare for the interview, reading any documentation, and researching any terminology specific to the area so you can speak the same language are all helpful in this instance.

Keep a record of the questions you’ve used previously in this domain, it can save you time if you need to do an interview with other domain experts.

Always focus on the domain expert’s needs in the interview. The goal is to present yourself as an advocate to get their problem solved. You want to be a trusted advisor, which will help your source be more open and comfortable about asking for your help.

Category 4 techniques:

This is the hardest category to work with, for obvious reasons. If you’re not aware you don’t have information you need, how are you supposed to ask about it? This can often combine with Category 2 in unfortunate ways. In this case the answer is to listen carefully and ask lots of follow up questions.

Things to watch for:

Unfamiliar terms
References to people or processes you weren’t aware of.
Answers that are overly generalized or vague.

Often following up on these questions can uncover additional information, either information that the SME hasn’t provided, or information that they didn’t know they needed to provide.

One technique to deal with this is from sales. There are lots of articles on sales web sites about discovering customer needs. Approaching the business with this approach helps them see you as an ally and trusted advisor in solving their specific problem. That will help things focused on what and why, rather than how, which is a big part of the BAs role, and the focus of the whole process.

What techniques have you used to uncover items in categories 2 and 4?