What does it mean to say “this is a solution masquerading as a requirement“?
Years ago, as a junior analyst, I worked on a project for a holiday company. The specific functional area I was involved in had to do with making the bookings themselves. A thorny topic within that was the notion of “bouncing” bookings. The business was having great difficulty in explaining how they currently “bounced” bookings, and we had great difficulty understanding.
The statement of scope said something along the lines of “the System will enable the bouncing of bookings” and a brief definition of bouncing was provided.
To explain, some bookings were “Named”, in that the customer (i.e., the holiday maker) had chosen a particular hotel and expected to be staying at that named hotel. Other bookings were “Generic”, in that the cu
stomer expected to stay at a particular resort and at a particular class of hotel, but not any specific hotel. Unbeknownst to the customer, generic bookings were assigned to specific hotels, but could be re-assigned around hotels prior to the customer’s arrival, in order to maximise the efficient allocation of rooms. The specific mechanism for doing this was known as “bouncing”.
We struggled with this notion for weeks. The Subject Matter Experts from the business knew how to do it on paper, but found it difficult to explain it to us. This was natural enough, as they were relying on years of experience, which we lacked.
Fortunately, a member of the team eventually spotted that the ability to bounce bookings in the way the business was trying to describe was not actually the requirement. The real requirement was to be able to re-allocate generic bookings in order to maximise room use. The notion of “bouncing” turned out to be just one way of doing that. In other words, it was one possible solution to the problem and not necessarily the best way forward, just the way the business was used to doing it. However, figuring out the best solution was the job of the designers, not the analysts.
The business fell into the trap of describing what they currently did as their requirement and we fell into the trap of taking what they wanted as the requirement, instead of seeking to understand what they needed.
Takeaways:
- Analysts, always be on the lookout out for the underlying problem because the SMEs might be describing a solution rather than a problem.
- Customers, don’t just transfer your current behaviour to your new system. Think about the four monkeys. What is the real problem?
Kind regards,
Declan Chellar
Related posts:
Leave a Reply