July 26, 2010, 5:04 PM — Priorities are so clearly part of rational project management. But they also fall victim to emotional and political pressures, so priorities jump around all too often. This is particularly true with CRM projects, thanks to the right-brained types in sales and marketing, and the frequent reorgs and marketplace shifts that really do change what's important. While the rapid, incremental deliveries from Agile's scrum teams certainly help accommodate rapid change, it's a good idea to have some tools to make the priority list more stable in the first place. Given that the No. 1 cause of scope creep is a weak or erratic prioritization mechanism, getting this process right will pay dividends throughout all phases of your CRM implementation.
While no single prioritization tool or method will be appropriate for all companies and situations, here are questions that help evaluate the efficacy of a prioritization method:
• Is it easy to understand and use?
• Does it elicit the right kind of input from users?
• Does it produce predictable, credible, defendable rankings of features?
• Does it realistically balance costs versus benefits, or does it lead to over-optimism that blindly leads toward high expectations?
• Do people--particularly management--follow the rankings, or do they overrule them within a few weeks?
Here are two methods we use to capture the preferences, characterize the politics, and weigh the priorities on CRM projects. The basic tools you need are nothing more than a laptop, a projector, and a spreadsheet. The magic comes from how the "priority votes" are collected and processed.
The Delphi Method
With traditional prioritization techniques, the larger the group, the more they are influenced by group-think and political sway. In extreme cases, the collective IQ of a group sinks to the lowest common denominator of its members. To counter this tendency, the RAND Corporation developed the Delphi Method, the original "wisdom of crowds" decision-making system.
One of the innovations of the Delphi Method is to ask for each of the participant's "votes" in private, and to ask participants what level of confidence they have in their own vote. We've take it further, asking participants several "damping factors" about the priority they're giving to a requirement:
• What's their level in the organization (e.g., director) -- in most requirements, higher in the organization means more weight, but in some it means a lower one.
• What's their department.
• What's their level of confidence in their vote.
• What's their level of confidence in the business payoff (cost-benefit ratio) predicted for the requirement.
• To what degree will they personally use or benefit from the requirement.