Why Define Requirements?

If you want to buy a house, you don't go to all the open houses in the area until you find the one you want, do you? And you certainly can't go to all the open houses all over the country. Instead, you sit down and you think about how many bedrooms you need, how much of a commute you can take, and whether special features such as a gated community or a pool would be desirable or something to avoid. You also think about how your needs may change in the future, how much you can afford, and whether you would be willing to buy a fixer -upper.

Although it is said that the top criteria for houses are location, location, and location, you know that in the end the layout of the rooms, the state of the plumbing system, and the size of the closets will have a big impact on how satisfied you will be with the house, and you'd better think about such detailed requirements before you start shopping and while you are shopping. When my family moved to a new area a few years ago, a very wonderful real-estate agent started by taking us on a full-day tour of ten very different kinds of houses, all having the requisite number of rooms and all within our price range, just to see what kinds of houses would be more likely to "work" for us. With her help, we were able to go way beyond the room number and price requirements and create a detailed checklist of must-have , nice-to-have , and " absolutely hate" criteria. (We live in such a house today, which she found for us in less than a month “ thank you, Enis.)

A CRM project is no different. This chapter takes you on that full-day requirements definition tour, all from the comfort of your reading chair . With it, you will be able to create a custom requirements list and to rank the requirements on your list so you can distinguish the must-haves from the nice-to-haves. The requirements list will be your tool during the selection process to screen candidates in or out and to rank the serious contenders. It can even be transformed into an RFP (request for proposal) if you wish to use a formal process. We will discuss both RFPs and a less formal alternative in Chapter 6, "Shopping for a CRM System."

How Detailed Should Requirements Be?

A common question I get from my clients when creating a requirements list is how detailed to get. This is not a trivial question. On the one hand, the requirements list drives the project, so if it's vague or incomplete you will likely make the wrong choice. Because the requirements list will be used during the evaluation phase to score how well each vendor meets each requirement on the list, you want each requirement to be precise enough to allow you to score the candidate tools against it. On the other hand, defining requirements is a time-consuming task that gets ever more time-consuming as requirements get more detailed.

If you were creating a requirements list for a house, you might specify lots of storage space, or lots of light, or a safe yard for kids . That's much better than a standard "3 bedrooms, 2 baths" description, and certainly more useful when trying to decide whether a particular house is suitable. On the other hand, requiring a 5x6 closet off the master bedroom, a living room painted yellow, or a fenced sandbox in the backyard is probably too much detail unless you absolutely needed those specific features. (And at least the yellow paint is easily attainable in just about every house!)

For a CRM requirements list, don't use vague language that you might find on a marketing brochure, such as "the system should scale well." Instead, state how many users the system should support and what kind of response time they should expect. Whether you elect to perform a stress test as part of the evaluation process or to simply rely on references is your choice, but you should have a good idea of what you are testing against.

Don't go for too much detail. A requirements list is not the detailed specifications document that will be created at the start of the implementation phase to direct the customization work. For instance, a requirements list should not include screen specifications. If it did, you would probably not find a tool with those exact screens anyway so the list would be of little value during the evaluation phase.

The level of detail of the requirements list and the amount of effort you choose to put into creating it should match the overall scope of the project. Simpler projects do quite well with straightforward lists, lists that are fairly high-level, pretty short (say, no more than a few pages), and that can be put together within a few meetings of the project team, each lasting a couple of hours. More ambitious projects must have longer, more detailed lists that may require several weeks of work by the project team to gather, evaluate, and rank. This segues nicely to the topic of the process required to build the requirements list.