Problem Statement - The Elicitation Technique for Internal Business Requirements

The Problem

Unlike Product Requirements that are very straightforward (like a new User Story or an enhancement to an existing one), from time to time we get ambiguous and partial business requirements internally (i.e. not customer or partners) that are typically buried in solutions -

1. “We need to be compliant with GDPR regulation”,
2. “There is a vendor who is willing to offer services at a lower price point”,
3. “We need to start this internal team blog and being transparent about what we do”

Which on analysis boils down to:

1. “We need to focus on Compliance as we are majorly exposed to the risk of a Regulatory Audit”,
2. “We should focus on cost savings as we are running low on funding”,
3. “We need to reduce tension and conflict with other teams”.

Source

These sort of one liners will often come from a senior role like a Director, VP or SVP, and as the Product Manager deciding or recommending items for Roadmap there is a slight apprehension coz it’s….well a senior role and they’ve probably thought it all through with a wealth of experience. This unknown pressure or confidence may result in reduced due diligence with proper requirements elicitation (which is typically not done at less senior levels or if it’s coming from the customer). Also, there is other challenge of finding enough time on a senior exec’s calendar to do all the elicitation [1] and understanding the needs and stakeholders thoroughly.

Similarly, there are other requirements which every group/BU in an org. needs to adhere to like regulatory or compliance or security. In these situations there is a feeling that requirements are all evident and straightforward, perhaps enough due diligence would have been done prior in understanding why we are doing this in the first place. The challenge here is that since everyone knows it all there is a hesitation or shyness in asking the same questions which people must have asked a 100 times before - Asking the same may make us look dumb!

Impact

Obviously, these situations are ripe for incomplete elicitation resulting in either incorrectly ascertaining the value of a requirement, or missing needs of key stakeholders, or missing a key stakeholder group that is impacted, or incorrectly framing the problem/opportunity.

The Solution

For the situations I often find that a Problem Statement is one of the better elicitation techniques. I first came across this in an Insurance company for a million dollar project. Although very evident in the benefit this technique is effective in highlighting all the stakeholders that are impacted by this problem so that no group is overlooked.

The Problem of being on outdated version of Identity and Access Management software
Results in Bugs and incompatibility with newer functionality
Due to which

• End Customers will have poor user experience signing to their accounts
• Customer Support team has to spend additional time handling support requests
• Application Support team has to spend additional time troubleshooting Bugs and Support Requests
• Architecture team has to spend additional time accounting for technical risks and additional time with analysis
• Product team is restricted in their ability to release new functionality
• Security team may raise audit findings for vulnerabilities

A Successful Solution would ensure that we upgrade to the latest version of software or at least include the patches with the most features within the next 6 months


The Problem of not being transparent about our team’s processes and priorities
Results in tension and conflict with other Product Groups that depend on us
Due to which

• Product Groups are hesitant to fully engage with us, often complain about the lack of clarity about their tickets that are handled by our team

A Successful Solution would ensure that every team that is dependent on us is aware of our processes, prioritisation, priorities and roadmap

The Problem of high unit cost per sms from the external vendor
Results in high yearly cost for sms service
Due to which

• Customers are paying a high cost for using our services as costs are in turn passed down to them

A Successful Solution would ensure that we reduce the high unit cost per sms so that we are saving at least X amount per year which can in turn be passed down to our customers

The Benefits

In addition to identifying all stakeholders and the impact to them, this also helps lay the setting to add data and build the case for this change as below:

W.r.t. Access Management

1. On an average how many issues are getting raised by customers presently?
2. On an average how many issues are being tackled by App Support Team? What’s the level of severity for these issues?
3. What new functionality is the Product Team planning on releasing in the next two quarters?
4. Is Access Management a high impact area for Security Team?
5. Does Architecture Team consider this a high priority in the next two quarters??

Another very important and key benefit is that it helps separate the solution from the problem opening up the possibility to explore multiple solutions

To utilise this effectively

A Problem Statement is better suited for elicitation when requirements are suggested by internal such as Executive, Security, Business Continuity, Architecture e.t.c. since they often affect multiple internal groups. It may not be very effective as suggested earlier for customer request for new features.

To begin the PO or the PM should work on this independently and ensure that the impact for each affected stakeholder is correctly captured and verified. If possible add metrics to quantify the impact for each group. Once this is done then align with the requestor. This will ensure that the problem is clearly separated from the solution, which the requestor would typically suggest, so that a range of solutions can be explored to effectively solve the problem.

Another effective technique I’ve experienced when it’s too awkward to ask a lot of initial questions and gain a good deep understanding about the background of a project is to have the back of another Product Manager or Product Owner who is comfortable (or rather vocal) about answering a lot of these simple but profound questions. I once had such as Lead PO who would himself organise a daily 30 minute questionnaire event for all POs named “Dumb questions”. Any sort of simple silly question was encouraged so that there was zero misunderstanding or rather complete understanding about the change.

Why are we doing this? Well..to save money
Why focus on cost savings now? Well…. since the industry is going through a recession
How long is the forecast for recession? What happens when things start turning around in 6 months? If implementation for savings takes 6 months is there any value in doing this?


Notes:

1. “Some refer to it as “Requirements Gathering” which I personally find blatantly hideous as if we are “gathering some Apples”. The proper term is 'Elicitation'
2. Image Credits: https://www.teamly.com/blog/wp-content/uploads/2021/12/Be-Part-of-the-Solution-Not-the-Problem.png