Creating a Requirements List

Gathering Requirements

The requirements definition process depends on both the scope of the project and the knowledge of the project team about CRM tools. For a small project with a well-informed team, a relatively informal meeting of the project team may suffice to transform the template checklist at the end of this chapter into a custom checklist suitable for proceeding to the tool evaluation phase. As projects become more elaborate, requirements definitions also get more complicated. The most efficient way to proceed is to alternate between working with the whole project team and letting individuals and subteams work on specific portions of the checklist. The overall process flows as follows:

  • Start with a kickoff meeting for the entire team to go over the process of defining the requirements and to organize the work. At this point, the project team may be a skeleton team consisting of only the business and IT owners (and the project manager and the executive sponsor, of course!) and without the super-users or technical staffers.

    The requirements definition process is a great opportunity to identify who should be on the team. If you can't complete a significant piece of the requirements, then you know you'll have to engage a specific resource to do it (smaller pieces can be farmed out as needed without requiring the specialist's presence on the team for the duration of the project). The requirements definition process is also a great opportunity to observe the individuals on the team and to make appropriate substitutions either immediately or for the implementation phase if expertise or enthusiasm is lacking.

  • Parcel out the various sections of the requirements list to the appropriate groups or individuals and let them research them independently. The project manager must keep a tight rein on the schedule so you don't spend inordinate amounts of time on the selection phase. Going back to the schedules discussed in , "Overview of CRM Selection and Implementation," you should be targeting anywhere from one to six months total for selecting the tool, depending on the complexity of the project, so don't let the requirements definition take up more than a week to a month depending on the complexity of the project.
  • Once each subgroup has completed the work on individual sections, bring the whole team together again to validate and approve the entire set of documents. It may seem strange to ask individuals who know little about a particular topic to validate the choice of the specialists, but it's a powerful technique for both team building and quality assurance. On the team-building side, cross-reviews allow all the members of the team to understand, at least at some basic level, all the aspects of the tool project. Cross-reviews also make for better quality, as individuals who are not directly involved with a particular area often raise relevant questions and suggestions during the review, deepening the specialists' thinking about their findings, catching incompatibility issues between sections, and sometimes steering the research in a new and improved direction.

    The validation meeting is a good time to handle the ranking of the items on the team. We'll discuss this activity next.

Ranking the Requirements

Most requirements-gathering efforts result in an overabundance of requirements, as the team gets hooked by the intriguing bells and whistles offered by vendors. The team that started out wanting a simple sales-tracking tool may wind up "needing" a full quoting and proposal-generating system with wireless integration after getting some inspiration from the creative CRM marketplace. Is there any harm in trading up? Sounds like a potential disaster to me, not to mention an expensive disaster. The sad reality is that a team that was perfectly sized and equipped for a straightforward project can rarely be scaled up, either in quantity or in sophistication, to deliver a significantly more complex project. And even if it were possible to bring the more ambitious project to fruition, it's not clear that the functionality that was added in the frenzy of requirements gathering would actually be used or useful. Fortunately, gross inflation in the scope of a project during the requirements definition phase is usually cured quickly when the team finds out that the larger project cannot be achieved with the budget at hand. Hence the importance of including a budget in the requirements definition. How can you avoid creating a requirements monster in the first place? By asking the team to prioritize the requirements. The prioritization exercise should be conducted in a group meeting of the entire team, both to get buy-in from everyone and to get good cross-pollination as described above. For larger projects ask the subteams to prioritize their areas before the group meeting to make it more efficient. The main problem during the prioritization exercise is to keep the team members from deciding that everything is top-priority. This is true whether you have a few priority levels or many, so I recommend using just three levels.

  • Top priority: must-have, can't live without it. These are the features that really make the system. Usually they can be directly related to the initial impetus for the project, to the vision. They should all have a direct link to the tangible goals for the project. For instance, if your goal is to have all customer information in one place, a top-priority item would be that the tool include a customer database suitable for the kind of customer (such as consumer versus corporate). Anything that is labeled as top-priority but that cannot be related to the original concept for the project should be questioned, taking into account that the level of details of the requirements list is much greater than the vision. For instance, if your goal is to ensure that all sales reps have instantaneous access to their customers' data at any time, from anywhere, and your reps tend to be on the road most of the time, one of the functionality requirements may be that you need the system to support wireless data synchronization. The business goal said nothing about wireless synchronization, but it's the way (one of the ways, we'll come back to this point) to accomplish the goal.

    If the project is replacing an existing system, it's likely that the functionality of the existing system will show up in the must-haves, and that's usually a good thing since you don't want to deliver less than what the users already enjoy today. However, don't be afraid to discard existing functionality as appropriate. For instance, the current tool may boast a heavy-duty customization tool, but you may not need one if you can find a tool that supports most of the required functionality out-of-the-box.

  • Medium priority: should-have, would have a tangible business benefit, but could do without. This can be a difficult category to populate, as articulate team members can make a good case that requirements that have business benefits are really essential to the accomplishment of the vision. The should-have requirements are often the foundation of future implementations. Let's revisit the wireless data synchronization example above. Perhaps your sales force is somewhat less mobile, and perhaps a once-daily data synchronization—that can be performed from a fixed location—is sufficient to bring them fresh information and to allow them to send updated information to the central system. In that case, good old non-wireless data synchronization would suffice and would be the top-priority requirement, while wireless data synchronization would be downgraded to a medium-priority requirement that may be implemented in a second phase of the project if needed.
  • Low priority: nice-to-have, can definitively do without it. Low-priority items are those items that are useful, sometimes really attractive to the members of the team, but cannot be linked to tangible business benefits. The link between low-priority requirements and the vision is tenuous. They are often generated by cool vendor demos and datasheets rather than by the team members. Their absence should never be used to reject candidate tools, although they can be icing on the cake for the winning tool. Going back to the example of wireless data synchronization, if sales reps start their day in the office and therefore can sync up their data with the central system from the office, wireless data synchronization may be only a low-priority requirement. Certainly it's nice to have for those occasions when a sales rep skips the office start, but it would not impact the goals of the project if it were omitted.

    Some project managers like to trim down the requirements list by completely dropping the low-priority items from the list. My heart is with them, but I've found it doesn't work well with project teams who usually have a strong emotional attachment to all the requirements on the list. I usually keep all the requirements even those tagged low-priority. You can always sort them out of view in the spreadsheet when required and you will have them handy for future use.

The requirements prioritization exercise can be painful, so it's a good test of the project manager's ability to work with the team. Useful techniques include reviewing the overall vision for the project, encouraging dialog between the technical and business users, and gently questioning the top-level requirements that are particularly difficult to meet. It's fine to keep tough requirements in the top-priority category if they are indeed essential, but only if everyone agrees that they are. The outcome of the requirements prioritization is a "final" list of requirements, one that should be shorter than the initial draft and that clearly identifies the top priority items.

When Do I Start Shopping?

Although it's realistic for the requirements list to undergo some changes and refinements during the early stages of the tool selection process, don't initiate serious talks with vendors until you have at least a draft of the requirements list. As long as you don't know what you want you may waste time with unsuitable candidates (visit houses you would never buy) and you may ignore potential candidates (that townhouse would put you so close to the office). You could also fall for the first tool you see without fully thinking through what you really need (buy the big house in the new development when that little bungalow close to town would be a better fit for your lifestyle). That being said, if the project team is very new to the CRM world, it may be very difficult to create the requirements list without doing any shopping at all, since no one has a good feel for what's out there. If you are in that situation, try some light browsing of existing systems without spending much time on the browsing and without making an emotional commitment to any one vendor. If the timing works out, a great way to browse is to attend a suitable conference that features an exhibit hall, for two reasons:

  • You can see all the tools, or at least a nice variety, in one go;
  • In a public setting the tools you will see won't be customized to your exact needs, so it's easier to avoid falling in love with a particularly well-tailored demo only to realize later that most of it was handcrafted specially for you.

Barring a conveniently scheduled conference, a good alternative is to sign up for web-based seminars with a handful of tool vendors. So-called webinars often contain lots of PowerPoint slides and only a short demo, so you may have to suffer through some low-yield moments, but at an hour a pop they are still pretty painless. They will give you an exposure to a variety of approaches to handling customer-related functions as well as a feel for how slick tool demos can be. Such browsing is not truly shopping and can safely be done before the requirements checklist is created.



   
Comments