"Agile" Change Management: From First Principles to Best Practices

the product manager's role--trying not only to gather requirements, but also to referee between different customer groups. The customer groups always then had someone else to blame-- IT. The Product Manager (who might co-ordinate 10, 15, or more customer groups in a big IT project) has to come from the customer side and has to have some authority delegated from those customers.

Participatory Decision-Making: The Key to Facilitating Agreement

Effective facilitation practices and techniques for obtaining "one voice" from the customer are the "bane" of the product manager's existence. One of the first and most important practices for effectively facilitating customer group decisions is to get the group itself to Decide How to Decide [7]. The values, objectives, and criteria for making a decision must be both shared and explicit! A simple consensus approach is best, when it works. If it doesn't, some successful strategies for driving customers to reach consensus on iteration and release content are as follows:

Normative Voting:   Each customer group gets the same, fixed, number of total "points" (or "votes") to distribute among the set of candidate requests to be prioritized. They can allocate more points to the requests that they deem most important (but no "partial point distributions" are allowed). So I could put all my 100 "votes" on one request if I wished; or I could give 10 points each to my top-ten requests; or I might give 20 points to each of my top three, then 10 points to each of my next three, and split the remaining 10 points across my next 2-3 most desired requests. At the end, the number of points cast by all customer groups is tallied for each request, and then the result is sorted in descending order from highest-to-lowest number of points.

Weighted Normative Voting:   This is very similar to normative voting, but not every customer group gets the same number of "points" for voting. Instead, they are assigned a number of points that is directly proportional to the amount of funding (or business revenue, or investment capital, etc.) they provide to the project. This essentially assigns a "weight factor" to each customer group based on their perceived contribution to the project's livelihood. This is also sometimes likened to "Congressional Voting" where, unlike the U.S. Senate where each Senator gets the same number of votes, instead each "representative" is given a number of votes indicative of the amount of the customer-base (or market share) that they control.

Even Effort Distribution: Rather than assigning votes and tallying totals to see which requests "make the cut" for the next iteration, even effort distribution takes the total number of effort units   (e.g., staff days, or staff hours) that are available to be scheduled for the next iteration, and distributes the resulting total effort units equally between all the customer groups. Each customer group may then select as many requests from the backlog as they wish, provided the total estimated effort for their selected requests does not exceed the number of effort units allocated to them for that iteration. So If I'm allotted 10 staff days of effort, I might select one request estimated at 5 staff days, another estimated at 3 staff days, and one more estimated at 2 staff days.

Weighted Effort Distribution: Instead of evenly distributing effort units among all the customer groups, each customer group is allocated a number of effort units that is directly proportional to the amount of funding (or business revenue, or investment capital, etc.) they provide to the project.  The "weight factor" is determined the same way