Nice To Have

Gathering requirements isn’t like asking kids what they want for their birthday. We aren’t giving our customers carte blanche, we are trying to identify the valuable requirements – things that solve problems and achieve value in a significant way.

Needs and Wants

Our customers usually know what they want. There’s a debate about if customers know what they need. Kids want cell phones. But how many kids need a cell phone? Assuming they aren’t working Canal Street in New York City to warn counterfeiters about police raids, they probably don’t need them.

We presented a hierarchy of customer needs, stealing from Maslow for inspiration.

1. Meets the needs of our business
2. Fulfills the wants of our business
3. Enables us to improve the way we do business

The first level in the hierarchy is definitely a “must have” requirement. The second level might be a “must have” or might be a “nice to have”. The third level is most likely a “nice to have”, but could be a “must have” requirement. To tell them apart, we need to understand, scale, ROI, and context.

Scale

The scale of a requirement is measured in terms of benefit to the business of implementing the requirement, or impact to the business of not implementing it. We talk about positive benefits, but sometimes it is easier to start by measuring the impact of not having a requirement implemented.

For example, it is easy to imagine the impact of an exterminator running out of pesticides while he is on a route – perhaps the lost time to replenish his supplies. From an impact standpoint, this might be 2 hours lost (and therefore two treatments rescheduled). To determine the benefit of sending out the exterminator with sufficient chemicals, we can multiply the impact (say $150 in lost revenue, assuming an otherwise full treatment schedule) by its frequency – once every 5 weeks per exterminator, to get a $1500 potential for annual savings. Multiply this by ten exterminators, and we are talking about a $15,000 per year scale.

This might be large enough to be high-priority, or it might not. We don’t know.

ROI

To measure the ROI of a requirement, we have to understand cost as well as benefit. To assess cost, we have to move out of the requirements realm and into design. From that design we can estimate the cost of the solution.
We could solve the exterminator problem with some fancy data models that predict usage based upon historical data and an analysis of the scheduled treatments of the day. This would involve the costs of collecting, analyzing, and maintaining the data, as well as the cost of calculating the quantities every day.

We could also attempt to solve the problem by having all exterminators carry an extra 10% more pesticides. If the pesticides for a given treatment cost $10, and a typical schedule includes ten treatments per day, we would increase the amount of work in progress (WIP) inventory by 10% or $10. An old manufacturing rule of thumb says that the cost of maintaining inventory is on the order of one third of the value of the inventory on an annual basis. Using that estimate, the cost of increasing inventory levels is about $3 per exterminator.

Potentially, we are saving $15,000 for an investment of $30. That is an ROI of 5000%!

This certainly would exceed the hurdle rate for our expected value calculations – but we still don’t know if this requirement has a high priority.

Context

We could be in the middle of a project that saves our customer a million dollars. A potential savings of $15,000 is not going to be worth considering in that context. However, if we are in the middle of a project that asks us to save as much as we can with a $500 maximum investment, the requirement seems very likely to be high in the priority list.

Conclusion

We have to understand how much a solution to a problem might save our customer. We have to know how much that solution will cost – to determine ROI. We also need to understand if this problem is the elephant in the room, or a fly on the elephant. If the relative financial impact of a requirement is low, it should not be prioritized above a requirement with more “bang for the buck.”