During many of my consulting projects I’m called upon to recommend new or improved software systems for loyalty or related functions such as customer relationship or experience management. If my client has already spent time thinking about the problem, and many have, I am eventually presented, typically in a reverent manner, with “The List.”

You all have one, or maybe more than one – a spreadsheet or document containing page after page of “the system must do this,” “the system must do that,” and the so very useful “we think we want the system to do something like ....” Sometimes The List is very, very detailed. Sometimes The List is very, very short. Sometimes my client’s are convinced that The List is ready to use and sometimes they’re pretty certain a lot of work needs to be done on The List. I saw a situation a bit ago where a group had started to work on The List and clearly had spent thousands of hours on it, but then threw up their hands and surrendered. I wasn’t certain if this showed bravery or despair, but based on what I saw on The List, my recommendation would have been to bury it in somebody’s back yard and forget about it.

My client’s hope is of course that I can quickly review The List, agree that it is necessary and sufficient, then organize it into a coherent RFP (or RFI), one that vendors can readily respond to, and around which subsequent procurement decisions can be made. The client’s fundamental expectation is that The List will get them a much more flexible system than the current system – one that allows their loyalty program to “move at the speed of marketing.” Sadly, The List has failed in just about every instance, and more sadly, The Lists being created today aren’t that much better than The Lists that were created a few years ago.

It would seem that I am disparaging the concept of The List, but this is not the case. The List is critical to the procurement process. If you don’t have The List, you’re certainly succumbing to the “if you don’t know where you’re going, any road will get you there” philosophy (and only after a great amount of time and a great amount of expense). I am also not belittling the effort needed to create The List. I’ve created a few from scratch and it’s not for the faint of heart.

I do however believe that the content of The Lists are flawed. They are flawed in one easily identifiable way and one way that I believe is somewhat unique to the demands of marketing and particularly to loyalty systems. Each of these flaws separately will diminish the value of your procured (or built) system, but together, they will often have you wondering why you bothered.

The easily identifiable flaw is by-and-large intrinsic to the process of translating strategic needs and plans into tactical requirements. This can be thought of as a Men are from Mars, Woman are from Venus kind of problem, but instead of having men and women, we have marketers and information technology (IT) folks. The challenge is that marketers and IT folks not only speak different “languages,” but they think differently and they need to do this in order to do their jobs. The difference, the gap, makes it difficult to create good requirements. This can be illustrated by a simple example.

The Marketer wants to be able to send e-mails, so the initial requirement is penned as something on the order of “We need to be able to send out e-mails.” The IT person, looking at that statement has many, many questions, some of which will likely sound inane (if not insulting) when asked of the Marketer, but nonetheless they must be asked so the right system is put in place. Some of these questions would include “What kind of e-mails?,” “To whom are we sending the e-mails?,” “What volume of e-mails?,” and on and on. Straight away there is confusion. The Marketer sees the first question and thinks about sending e-mails upon registration and when awards are ordered, while the IT person is thinking about HTML vs. text. The Marketer thinks the second question is odd because of course he wants to send e-mails to the members while the IT person knows that other people may be tracked in the database and is wondering whether there should be a capability to send those people e-mails as well.

And so it goes. The IT person needs exacting detail to make sure the solution handles the requirements while the Marketer doesn’t understand the need for the minutia much less what some of the minutia really means. Further, what is not said and discussed can have a huge impact on the solution. For example, the Marketer could assume that parameter substitution is a standard capability of new e-mail systems so does not mention it while the IT person knows that the current system doesn’t do any parameter substitution and so assumes that since the Marketer hasn’t mentioned it, that we don’t need to do it. Oops.

If you’ve been through this process, you’ll agree that deriving the requirements for The List is a pretty agonizing activity. I’ve seen situations where the Marketer is unable to decide what they need, much less what they want. I’ve seen situations where Marketers essentially give up as the process seems, and in some cases surely has, gone into an infinite regress with the IT people trying to design the system rather than specify what it must do. I’ve seen many cases where the Marketers and the IT people are working very hard to “do the right thing,” but the knowledge gap between the two groups is too large and requirements are missed.

The good news about requirements definition is that there are seminars, books, and other ways to learn how to identify and write good requirements. Getting some education (or contracting somebody with the skill) will go a long way to improving the content of The List. While requirements creation is often the domain of IT (or perhaps the business analyst, which is often an IT function), I suggest it wouldn’t hurt to have somebody from Marketing capable with the skill as well – your process will go so much smoother as a result. There are good ways to limit the number of “oops” in terms of requirements, even without education. For example, I often ask my clients what their “nirvana state” is in a particular area. That is, if money and time were no object, what would they ask for? This typically results in a lively discussion identifying all manner of functionality. Of course, we don’t have unlimited time or money, so some functions will need to be passed over, but ideally all the options have at least been put on the table.

Let’s do a little thought experiment to better understand the other major flaw in The List.

You’ve just been told to replace your existing loyalty system with new technology. Your boss says that unlike the old system, the new system must be “flexible,” which is followed by the unspoken “or else.” To assist you in your activity, you’re given the Requirements Materializer Mark II (the Mark I not being entirely successful). The RMMII, affectionately known as “Remi,” can instantly “reverse engineer” any information source into requirements.

It just so happens that the first functional area you’ll be looking at is e-mail. So, you hook Remi up to the head Marketer and out comes a list. You drop the 3-year marketing plan into Remi and ta-da, another list. You locate all the IT folks that know anything about e-mail and you hook them up as well. You even take an “E-mail 101” course and then hook yourself up. Of course, what you’ve really created is a “wish list” rather than The List, but you then sit down with the Marketer and patiently walk through and explain and discuss everything, and together you get down to the minimum set of requirements and these then go onto The List.

In all likelihood you’ve just failed at your task. You’ve identified everything that is known and expected to be required. In fact, you’ve defined the most complete system that could be defined from all the sources you used. Yet, you haven’t created a flexible system, it can’t move at the speed of marketing. You’ve failed at your task. Why?

Because it’s likely that none of those data sources resulted in requirements to accommodate the marketing constant – change.

Whoa. At this point, the Marketer is thinking that if they knew what new requirements would be needed they would have asked for them. Which is absolutely correct. The IT person is thinking that there’s no way they can stipulate a change that the Marketer can’t even describe. Which in the grand scheme of things is correct, but in many identifiable situations is incorrect. In fact, the Marketer has likely and unknowingly given IT what they need in order to, if not predict, then to at least anticipate, portions of the future.

One technique for discovering this hidden information is sometimes referred to as the 1, 2, many rule. In software engineering, if you have 1 or 2 of something, you tend to code a simple and direct solution. On the other hand, if you have 3 of something, you should consider whether you can have more of them. If you can, you should code a more general (and extendible) solution. The change to a general solution necessitates a fundamentally different architecture. The need for the change may not occur when going from 2 to 3, 3 to 4, or 4 to 5, but when it does occur, the expense in time and money to retrofit the existing solution will be substantially higher and more time-consuming than if it had been implemented that way at the outset.

In our e-mail requirements we likely have something on the order of “The ability to send an e-mail to the member upon their enrolling into the program.” We might also have something on the order of “The ability to send an e-mail to the member upon successfully placing an order for an award.” We’re already up to 2 cases. If we see another case (e.g. upon account closure) we should seriously consider some requirements that help us understand the viability of handling an arbitrary number of different cases.

There are other ways of identifying areas of the application that may be subject to changes in the future. For example, if you have been operating your program for some time, you likely have a history of where changes have been made. This can also be used as the cue to add these kinds of requirements.

The common pattern for handling this situation is to first include requirements for the specific cases you need for proper operation of your program. If you have more than a couple of cases, you should then include an inquiry about what other cases are currently handled by the application. You should then also ask what cost and time would be required to implement an arbitrary new case.

If you go to RFP with these sort of questions in The List, the vendors will squirm and writhe and not want to answer. They’ll claim they don’t understand the question or that the amounts vary so much that they can’t say. But, the answers to these kinds of questions is key to understanding their offering’s flexibility. The same can be said about an application that is being developed internally. If each one of these kinds of changes is going to take a couple of weeks, or a month, or a couple of months to put into production, how can the application allow you to move at the speed of marketing?

Sadly, most commercially available applications, even those touted as being built on a “rules engine” will inhibit your creativity. But, if you include the right requirements on The List, when you make your selection or have the application built, you’ll at least know what’s going to be quick and what’s going to be slow and costly, and you should be able to plan and budget accordingly.

Hopefully I’ve provided you with enough insight that you can go back to The List and consider whether you’ve specified a set of requirements that will really move the needle in terms of responsiveness. Are you requesting a system that’s better but fundamentally just as limiting or are you requesting a system that’s flexible and can “move at the speed of marketing?”