Vendor Selection: Writing a Good Requirements Document

My last two posts (not counting this morning’s detour into Marketo-land) described common errors marketers make when selecting marketing automation systems. How did we come to this?

I see two reasons:

• Marketers are like everybody else. Remember all that yammering about how today’s buyers do their own research, don’t talk to sales until late in the process, and get their information from social media rather than experts? Today’s marketers buy that way too. So the carefully structured, professionally managed selection process is a thing of the past.

• Marketers are marketers.  This means they’re facing more change and a less clear future than other types of buyers, and they’re less experienced with purchasing technology. It’s no wonder they can’t define their requirements as well as someone buying a new accounting system.

But all is not lost. Marketers can do a better job of system selection if they try. Specifically, they can do two things: improve the selection process itself and look beyond features to assess the vendors. This post will focus on the selection process and the next will talk about judging vendors.

As I’ve already written more than once, the key to sound selection process is a good set of requirements. These should be packaged into a formal requirements document so you have them all in one place, easily organized and available to share with vendors. But don’t think you’re writing the document for vendors. Instead, imagine you’ll submit it to the Chief of the Prussian General Staff, who just might slice your ear off if you do a less than thorough job.

Here's what he'll be looking for:

• Background: a general description of your business, including the products, company size, and industry characteristics. This gives a vendor an idea of your key issues and what sort of solution would be appropriate. Remember: a solution that’s too sophisticated for your needs can be as ineffective as one that’s too simple.

• Marketing process: describe your current methods for customer acquisition, relationship development, and retention. Include a channel-by-channel breakdown of your major marketing programs, with the volumes, spending and results for each. Your goals are to define the scope of your required solution and to help prioritize different capabilities. 

• Existing systems: describe the current marketing systems, including the technology, how they’re used, and known problems. This provides additional context for judging the scope of change that’s desired and what’s needed to achieve it.

• Project objectives: only now are you ready to state your goals for this project. You’ve waited this long because the objectives only make sense in light of your current situation. The goals you state here should be as specific as possible, so you can later check that proposed solutions  address them.

• Data sources: describe the internal and external systems that will feed your marketing automation platform. A simple marketing automation deployment might integrate only with CRM. But more complex scenarios could include inputs from Web analytics, order processing, point of sale, accounting, and elsewhere. Present this information in a table with record counts and transaction volumes so it can be used to size and price your solution.

• Required functions: this translates your project objectives into specific system requirements. These include data preparation as well as marketing execution. They wouldn’t generally extend to non-functional requirements like vendor background and pricing, although you could include them here if you’re concerned you’ll forget about them otherwise. Even though these are functional requirements, don’t be too specific in how things should work: you want enough flexibility for each vendor to showcase the best way to use their system. This part of the document is where you're most likely to need outside help: it takes an expert to know what functions are implied by each project objective.

• Use case scenarios: here’s the place to get specific. Pick several key processes, such as specific marketing programs, and describe in full detail how you want them set up. This would include segmentation rules, content creation, processing logic, CRM integration, lead scoring, and any other tasks required to run the program. You’ll later ask the vendors to demonstrate how they would perform those tasks.. The key is to define real projects for your business, not vendor-chosen examples that showcase their strengths and bypass their weaknesses.

These same elements should appear in pretty much any requirements document. What will differ is the degree of detail: I’ve written some requirements documents that are three pages long and some that are thirty. The right scale depends on the complexity of your situation. But even a simple requirements document is well worth the trouble, both to clarify your own thinking and to communicate that thinking to potential vendors.