When I work on requirements gathering with customers, I warn them that they shouldn’t rate the bulk of or all their items as “must have.” The issue being that you won’t get everything you ask for and that, if you don’t prioritize your absolute top needs as the “must have” category, when someone else picks for you (which too frequently happens), you end up not getting things you really need. In fact, you sometimes end up getting things you don’t need as critically as those you do.
On a somewhat unrelated note, I happened to finally be reading the book “Crossing the Chasm” by Geoffrey A. Moore. This book is a classic book about “marketing and selling high-tech products to mainstream customers. It was written in 1991 and is not only still relevant, but still highly thought-of and suggested.
I happened to be reading a section about tablet computing*, how some companies have gone to these devices and made good use of them, but the section I’m currently reading is describing how to describe that need. This is kind of funny that this book is from 1991 and the topics are pretty much the same as today’s topics but, regardless what topic we discuss, much of it has different names but is essentially the same discussions we’ve been having for years-and-years.
In any case, the book happens to mention that, in their example, there are no “must have” items and that there truly are very few “must have” items in real life. It dawned on me that this relates to our problem with requirement gathering.
First of all, when everything on a list is marked as a “must have,” the people with the money are immediately skeptical that the task has been properly done. Additionally, some of them have read books like this one and know that there are few things in life that truly are a “must have.” But if we change our ratings from “must have” to “extremely practical to have” it loses the sense of urgency. Would you get the money you need to implement a system full of “extremely practical to have” items? Would your management be impressed by your practicality? Does every list of requirements need a certain sense of hysteria behind its need to actually get any of it?
Requirements gathering remains difficult to do because, not only is it difficult to get the list pretty good (it’s never perfect – just remember that), but the ratings really aren’t any good, at all. They’re totally misleading. But then, without knowing who will see them and how they’ll react to them, could we be totally practical about this and get any new system? Maybe that’s where the cost-benefit analysis comes in. But that’s not easy to put together, either, and management is usually skeptical of that, too, knowing there’s a tendency to put too much optimism in the numbers.
One more thought: we seldom denote the difference in those items that are truly necessarily in a new laboratory informatics software implementation and those that are going to improve the workflow or in those that provide a cost benefit. They’re not the same things but we seldom allocate the extra time to make these distinctions. If we did, would our outcome be better? Without good data to support this, I will not try to make this claim. Even this effort would have to be prioritized so that it wouldn’t go into so much detail that the team couldn’t finish the task.
* So far, the main difference between the 1991 and the 2012 discussion on tablet computing seems to be that, in 1991, you would download all the data and in 2012, we now can use wireless networks to go get information, as well.