Finding the right balance when defining requirements can be hard. On one side, we want to avoid an inadequate system – “Don’t prevent my success by excluding features I might need”. On the other side, we want to avoid cost-overruns, delayed schedules, and negative-ROI features. This can be a hard line to walk.
Business Analysis Balancing Act
My brain is in business analyst mode while writing this. While the ideas can be extended to product management too, for this post, we’re only looking at the problem from a single-customer, enterprise software project perspective.
During a meeting with our business owner (BO) today, I had the following exchange:
BO: I assume that the [new] system will let me […]
BA: Never assume that the system will do something you need it to do (while we’re gathering requirements). Since we’re customizing existing software, it may do what you want, but you shouldn’t assume it. Do you need to do [X] with the system?
BA: OK, so you will never have [situation Y] which would require [X]?
BO: You said never, and I can’t say never. We jump through a lot of hoops to keep our business running on [the legacy system] because people said “we’ll never need to do that!” So I can’t say never. I expect that the system will let me do everything I might need to do.
We can learn a lot from this exchange. First, we know that our business owner (stakeholder) appreciates the importance of the requirements gathering process to actually getting the deployment (customized enterprise software) that she needs. Second, we realize that she isn’t focused on the practical elements of deployment – she is focused on not getting a lemon. This is good – her job isn’t to balance wants and needs with feasibility and value – that’s our job.
Our business owner comes right out and identifies that not requiring something has caused pain for 16 years (the life of the legacy system) for her and her department. She’s been burned before, and will do everything she can to avoid being burned in the future. We learn from our mistakes, and now she is applying her learning to discussion of capability [X].
We can apply the concept of expected value to determine how to prioritize requirements to support capability [X]. Assuming that [situation Y] is the only one that would require [X], we first identify the likelihood of [Y] happening. In this case, [Y] would require a change in existing business policy, as well as the occurance of something that “isn’t likely” and “hasn’t happened in the 16 years” that our business owner has been at the company. We’ll conservatively assume there is a 5% chance that [Y] will happen over the next few years. If the changes that make [Y] possible were to happen, then it would happen as often as ten times per year.
The value of [X] can either be expressed in terms of the cost of not supporting [Y], or the cost of making [Y] happen without the needed capability of [X]. In the context of other, already identified, requirements, we believe that there is a workaround solution that is already included in the plan for the deployment – leveraging other already defined requirements / capabilities. This workaround, while undesirable (from a usability perspective), would have a relative cost per incidence of a couple hundred dollars (in the context of a multi-million dollar project) in extra labor costs.
Easy Choices, Hard Messages
Unfortunately, this means that we’ve already spent more on our analysis of [X & Y] than we would ever hope to save. Our economic analysis tells us that we shouldn’t hesitate to exclude this feature.
We have to circle back with our business owner, and help her appreciate why [X] will have an incredibly low priority, and almost definitely won’t (and shouldn’t) happen. And we have to do it in a way that she feels like she isn’t getting burned again.
This is a real-world anecdote. We can learn from it that people often feel passionately about things that really don’t matter when you analyze their value in the grand scheme of things. What is important is to make our decisions based on facts (and their resulting forecasts), not emotions. And then we have to communicate effectively, both to create understanding, and to use this opportunity to strengthen rather than weaken the relationship.