- Getting to Business Value
- Developing a Model of Your Customer Relationship
- Setting Business Goals
- Setting Requirements: Who, Where, What, and Why
- Organizing and Publishing Project Documents
- Prioritizing Requirements
- When Requirements Should Bend
- Knowing Your Boundaries
- Making the Business Case
- Quantifying the Return
- Developing a Straw-Man Schedule
- Avoiding the Big Bang Project
- Outsourcing
- Setting Executive Expectations
- Getting the Right Resources Committed
This chapter is from the book
This chapter is from the book
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.
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?”
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.