Both the effort distribution and normative voting approaches provide an incentive for cooperation between the participating customer groups. Disparate customers may pool their votes or effort allocations for mutually desirable requests, especially those that require significant effort. More cooperation and commonality among the selected requests results in a greater volume of requests being implemented that align with each customer group's wants and needs.
The voting approaches tend to take less time to reach consensus; they also run the risk of requests that are important to a minority not being implemented in a timely fashion. The effort distribution approaches tend to involve more wheeling and dealing between customers to forge alliances for their most desired requests. This can be time consuming, but can also ensure that each group has at least some of its top picks implemented in the near future.
As previously mentioned, the customer base itself should be responsible for deciding which of the above approaches (or other approaches, including simple consensus) should be used. Decision making criteria should include the types and amounts of the impacts and risks, as well as the associated business urgency and value. Don't forget that the longer it takes to convene a customer meeting to communicate, prioritize, and select the requests to implement, the less responsive your change management process will be (and the less agile the project and team can be).
There must be a balance between the extent to which the product manager must seek and facilitate agreement from customers, and the extent to which the product manager is entrusted and empowered to make on the spot decisions in the interests of the customer base. A good rule of thumb is to gather the customer representatives together for the request prioritization and planning meetings at the beginning of each iteration, and let the product manager make the decisions for any issues that arise in the during an iteration. When working with the development team to elaborate the details of a request, the product manager is the preferred person to work with for the sake of consistency and conceptual integrity. However, it can also work well to have 1 to 3 customer representatives do this on a request by request basis.
A Word About Fixed Scope/Price Contracts
Conducting agile change control for fixed scope/price contracts can be particularly tricky. One approach that has worked well for ObjectMentor is to use the time normally spent conducting thorough analysis and estimation to instead conduct a few trial iterations that implement some of the higher-priority features. Then use the resulting data from those iterations to estimate (and, hence, bid) on the overall contract.
It is also vitally important that the contract specifically outline the process and mechanism for proposing and accepting changes to the scope of the contract (and to the process and mechanism itself, not to mention the rest of the contract).
What About Change Tracking?
So far we've mentioned very little about change tracking and traceability. Tracking and reporting the status and content of requests and changes across many artifacts and activities can be extremely unwieldy. We often require sophisticated tools to assist us in this complex and tedious endeavor. Agile approaches strive to minimize the number and size of non-code artifacts that are created. Fewer artifacts and documents mean fewer items to tracked and less effort and complexity to track them.
In the case of XP, its proponents say index cards are preferred in favor of tools. Their physical limitations force developers and customers to keep things short and simple, and physically associate a request, its corresponding requirements, and its tests with the same physical artifact (in XP, the customer acceptance tests are the detailed requirements). Scrum and other agile methods appear to be less insistent upon the use of index cards, and less resistant to the use of tools (such as spreadsheets or change/request tracking systems).