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.
Burned Before
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?
BO: No.
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].
Requirements Economics
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.
Combining the probability and impact with the frequency nets out something on the order of $500 of cost reduction in net present value.
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.
Conclusion
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.
Wonderful series of posts lately, and something we have all seen way too often and been guilty off ourselves. I will add this though. The really successful are those that find the right balance between passion and objectivity.
Thanks Deepak!
And your insight is great too. I’ve always tried (with varying degrees of success) to use objectivity to guide my passions. Definitely a tough balance to strike.
Your comment makes me think of this too – it is important to not squash someone’s passion when helping them absorb an objective analysis. Redirecting the passion will help them continue to contribute to the project, and to generally enjoy life more.
Indeed. Last thing you want is your brightest minds losing interest and thinking that their talents are not important any more. How those objective ideas are conveyed is important as you suggest
Scott, you present some valid points about expectations and functionality, especially as it pertains to older development environments, where everything had to be built to order and therefore a function did not exist if it was not specified. There are many newer development environments today, however, such as the BPM systems that I commonly work with, where the systems are hugely functional and user-customizable, and could probably do whatever a business owner requires. The problem occurs when the implementation team — whether internal or external — writes a massive amount of customization code that effectively cuts off access to much of the native functionality of the underlying system. I don’t think that allowing direct access to every bit of functionality is a panacea for business expectations, but I do believe that over-customization is definitely a problem in meeting the requirements — both stated and unstated — of the business.
Great points Sandy! Thanks for the comments and continued reading.
This project is, as you suggest, an enterprise software system migration project. The engagement contractually defines a sequence of “deploy new system with minimal process change” followed by “explore process re-engineering that is enabled by new-system functionality.” This decision solves some problems, and introduces others.
Six of one, half dozen of the other.
I believe that the implementation approach is one that will not prevent future access to underlying functionality, although I’m not involved in those implementation decisions. Used to be. Not this time.