This chapter is from the book

Prioritizing Requirements

One of the toughest tasks throughout the life of the project will be understanding the ramifications of requirements and making priority calls among them. With a system of any size, some requirements will have to be delayed or may even have to be abandoned as too expensive. Making these decisions can get interesting when interdependencies among the requirements exist, and things get even juicier when political overtones and competition among the requirement sponsors complicate matters.

Although this complexity sounds scary, there’s a counterbalance. The overriding principle of prioritization for any SFA/CRM project is that it doesn’t matter how many requirements you’ve delivered on if the users aren’t adopting the system in droves. This is because the value of an SFA/CRM system—to sales, marketing, support, and executives—grows in proportion to the amount and quality of data the system holds. Make priority calls that cause users to get quality data in the system sooner and that persuade users to get on the system more often... and the rest will follow. Instill this overriding principle in the project sponsors as much as you can so everyone pulls in the right direction.

One way to guide prioritization discussions is to use the short list of the specific business problems that the executives defined earlier in this chapter. These specific improvements should be specific, unambiguous, and quantified—“reduce customer support response times by 20%,” not “improve brand value.” Estimate how the major features will affect these business goals, and from that calculate the return on investment (ROI) for the feature: lowering of costs, increasing revenues, or both. This overview page will help keep things in perspective as you try to make priority calls.

Like all complex decisions, the tough calls will be made in meetings where there is insufficient information. Your requirements summary spreadsheet is the tool the team will use to make those tradeoffs and priority calls. The goal of the project leader is to channel the discussions during these meetings down paths that are rational: all of the choices are achievable, and the final choice optimizes ROI.

Prioritization Tools

Appendix A describes several tools that can be used to prioritize requirements. Give at least one of them a try to find out which tool is most natural for your team and produces the most credible priority rankings.

The two groups that usually get the highest weight in the prioritization are sales representatives and executives. Things that are of direct, immediate benefit to them are assigned a lot of points. The specific points you give to other departments and user types are up to you, but an SFA implementation team forgets “who’s the boss” at their peril.

There isn’t a universal formula for prioritizing requirements: too much depends on the specifics of your company. For example, should the requirements from highly sophisticated users (as identified in Chapter 5’s SFA Maturity Model) be prioritized higher than others (because those users can gain the most) or lower than others (because those users will be better able to cope with an incomplete feature set)? The answer to this question inevitably depends on your company and its management style.

You’ll want to carefully plan out who will start using the system when, as the timing affects priorities. Put simply, the timing and order in which you deliver SFDC functionality and extensions can have a big impact on the total project cost and schedule. Some functional areas go together very easily; others can involve a lot of controversy, meetings, and rework. While the order of functions is fundamentally your choice, a good rule of thumb is to bring users onto SFDC in the order listed in Table 1-1.

Table 1-1. General Sequence of Bringing Users into SFDC

Organization

Activity

Business Priority

Political Priority

Phase

Telesales/inside sales

Orders

High

Medium

I

Order operations

Approvals

High

Medium

I

Sales development

Appointments

High

Low

I

Telemarketing

Cold calls

High

Low

I

Marketing

Lead generation

Medium

Low

II

Sales analyst

Executive support

Medium

Medium

II

Product marketing

Purchase analysis

Medium

Low

II

Sales VP and Marketing VP

Management, forecasting

High

High

II

Executive team

Management

High

High

III

Legal

Contracts

High

Low

III

Sales engineers, consultants

Deal support

High

Low

IV

Shipping/receiving

Distribution

Low

Low

IV

Customer support

Customer care

Medium

Low

IV

Finance

Business analysis

Medium

Low

IV

Field sales managers

Sales management

High

High

V

Partner/channel manager

Channel management

Medium

Medium

V

Individual sales representatives

Selling

High

High

VI

International operations

Selling

High

High

VI

Almost always, the revenue-focused business processes conducted at headquarters are implemented first. Later, other headquarters processes are brought online. Usually, business processes done in the field happen a bit later.

You might wonder why the executive suite and other high-priority roles in the company seem to come so late to the system. Why aren’t their requirements satisfied first? Chapters 3 and 4 answer that question: the quality, completeness, and relevance of the data in the system just aren’t good enough early on. Any reports or dashboards an executive wants won’t be reliable, and they could even provide misleading information that would lower the credibility of the system. It’s a big mistake to bet the farm on SFDC data assets before they are ripe.

Add groups and adjust priorities on the list in Table 1-1 to fit the realities of your business. No matter what the order selected, use the ordering to help prioritize requirements. Requirements coming from teams that will be coming on board early should be treated as having a higher priority (so they get done early).

A key issue in prioritizing requirements is the “squeaky wheel” phenomenon, where a noisy or politically powerful proponent causes great emphasis to be placed on a requirement that isn’t really critical. All too often, a significant proportion of the effort in large projects is devoted to requirements that are “nice to haves” but that ultimately waste time and effort. Consequently the highest leverage thing a project leader or business analyst can do is identify and deprioritize the uncritical. While avoiding confrontation, smoke out dubious requirements using gambits like these:

“How much of your budget would you be willing to dedicate to solving the problem?”

“Can you quantify how much waste this problem has been causing for you on a monthly basis?”

“How much profit increase would the company see if this were done?”

“How much more productive would you be if the problem were solved?”

“Which other department needs this feature?”

“How have you been able to succeed without this so far?”

“What’s the forcing function—the deadline beyond which we can no longer do business the current way?”

“Which of your other requirements would you be willing to put on the back burner to get this one done?”

Avoiding Happy Ears

Whenever a new system is being developed and people are interviewed about what they need, users start to hear hints about how things will work. Nearly everyone will assume that if they’ve heard about an issue, it’s going to be solved by the new system. They’ll even extrapolate, imagining all the wonderful new features that will become available to make their job easier. It’s human nature to be optimistic, and that goes double for sales and marketing folks. But this “happy ears” phenomenon leads to spiraling expectations and scope creep that can kill a project.

Project leaders and especially project sponsors must continuously push to lower these expectations, even if they yet haven’t seen overt signs of happy ears. The project goals must be simple—even minimalist—for the first phases, and “great ideas” must be explicitly pushed off in time. Even when things are going okay, undersell and be tentative about making the schedule. Even if the team has a way of delivering “something great,” consider delaying it (ironically, see “The Art of the Quick Win” later in this chapter). When you do deliver this great thing, do not publicize it until it’s delivered, so that you can provide pleasant surprises to users.

In prioritizing and trading off requirements, the project leader will need a set of executive sponsors who can act as champions for political and resource issues. For SFDC project success, the champions must include the VP of Sales, but usually include the VP of Marketing, the CFO, or perhaps even the CEO. These key supporters cannot afford the time needed to participate in the project, so they’ll need to deputize a senior person on their staff to be a regular participant4 on the SFDC implementation team. The project leader should form a management council of these deputies to make priority calls, policy decisions, and tradeoffs. For simplicity of voting, the team needs to be small and contain an odd number of people (including the product manager). A small management council would include representatives from the Sales and Marketing departments, plus the project leader. A larger council might add representatives from the Finance, Customer Care, International Operations, Professional Services, Channel Operations, and Business Analytics departments. This council will need to have brief meetings on a weekly basis, and it should devote a significant amount of time to analyzing business processes. Because a key factor in ensuring project success will be the availability of the right people for this team, get their (and their bosses’) commitments early.

The challenge for the project leader is to keep one (and only one) priority list that encompasses everyone’s needs, while clearly limiting the number of items that are “must do’s” for each phase. Even so, maintaining a consistent, clear, tightly enforced requirements priority list is an invaluable tool for the project leader, and its existence will help fend off countless arguments during the project.