In this episode, Matt Adams helps us understand what to do when we’re given a solution to implement. His approach leads us to become trusted advisors instead of note takers.
After listening to this episode, you'll understand:
- The problem with implementing a solution that you’re given
- How to identify the underlying need and value to the customer
- What to do about specific requests from a single customer
What do you do when customers ask you to write the requirements for a solution you’re given? If you simply write the requirements as requested without considering whether or not that solution is the right solution, you’re not providing much value.
The tendency for customers to provide a solution and ask you to write the requirements is a common problem. The requested solution may only solve symptoms of the real problem or might not solve any problem at all.
Finding the Real Problem to Solve
When presented a solution, one of the first things you can do is work to discover the problem your customer is trying to solve through that solution. Using a root cause technique such as 5 Whys allows you to dig down deep to discover the intended value of the solution.
Asking ‘why’ at five levels helps you to understand the root problem. For example, asking “Why do you want to send a message to the inventory system?” may help you discover an underlying problem that the proposed solution won’t actually solve.
Understanding workarounds that the customer currently uses to address the problem may also give you clues as to the underlying problem and solutions to address that problem.
Observe to Discover
Observation is another technique you can use to discover the real underlying problem. Identifying workarounds and observing the way customers use their current system help you gain a better understanding of the challenges and opportunities faced by your customer.
Observation may also help you to find a faster, simpler solution that will meet your customer’s needs.
Process maps and data about the problem also lead you to better solutions.
With User Stories, we often include a ‘so that’ clause. The ‘so that’ portion answers the ‘why’ question.
While some people skip the value portion of the User Story, it’s critically to understand the value. You should also dig deeper into the ‘so that’ clause and ask ‘why’ to make sure the User Story is solving the right problem.
A ‘so that’ clause isn’t just for User Stories. Adding a value clause (so that) to traditional requirements helps you to better understand the driver behind the requirement. You can also use it to make sure you’re digging deeper to understand the ‘why’ behind each requirement.
Listen to the full episode for all of Matt’s advice on what to do when you’re given a solution to implement.
Add a ‘so that’ clause to all of your requirements and make sure you dig deeper by asking ‘why’ about the ‘so that’ clause to make sure you’re solving the right problem.
Also, ask about current workarounds your customer uses to solve the problem. This helps you to better understand the curent process and discover the real problem.
Links mentioned in this episode:
- Matt’s website BA-Guru
Founder, BA Guru
Matthew Adams is the founder of BA Guru, a website devoted to helping you develop your business analysis skills. Matt specializes in delivering tangible system and process improvements, while sharing his best BA techniques, tips, and experiences through BA Guru.
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.