One of the core skills of a Program Manager is to build consensus. Microsoft (like many knowledge-worker driven IT companies) is not a top-down organization. For the most part, projects, ideas, directions are taken on through a consensus building exercise at one level or another. While this can be frustrating and slow at times, it does a very effective job at weeding out bad ideas and honing good ones.

So how do you go about getting an idea to stick? Because Microsoft is an organization of people, it is more than push-a-button-get-an-answer. You have to work with and through people with all their wonderful idiosyncrasies, creativity, passions, hopes and fears. As a PM, you are often asked to build consensus with folks that are much more senior, more technically deep, and even more bull-headed that you. What should you do in those cases? Recently I got a few folks on my team together to trade stories on how to build consensus.. here are just a few of the ideas we came up with. Notice not all of them work in every case, pick the ones that feel best for you and for the situation.

1. Ask for help. Rather than come in with a ready-made solution you just want them to buy-into, come in with a well thought out problem statement and get them to brainstorm with you on possible solutions. Hopefully the one you had in mind will come out or better yet, maybe you will get a better one.
2. Write it down. One of my favorite VPs is fond of saying "Writing is thinking". Write down your idea in a complete, well thought out way. This gives something concrete for folks to comment on and buy into.
3. Get the data. In many cases there is hard data that can substantively inform a decision. Using 3^rd party data in this way enables the discussion to be less about opinion than interpretation of data. For example if you are trying to diced if you are going to target an OS platform like Win9x, get data like the number of Win9x users hitting microsoft.com or projection data from marketing.
4. Customer anecdotes. Even in cases where hard data is difficult to come by, a quote from a customer or story about a customer deployment can be very valuable. For example, it is way more powerful to say: "Yesterday I was talking to the folks from ESPN, and they thought feature blahh was a must have" rather than "I think feature blahh is a must have".
5. Build a prototype or demo. If a picture says 1,000 words, a demo says 100,000! There is nothing like seeing an idea to life, even in a limited way.
6. Define the middle ground. Outline the extremes of the possible solutions, painting your proposal in the center. This encourages the other person to agree with you or be closer to one of the extremes. For example, "We can completely break compatibility or freeze-dry the product and not evolve… OR we selectively take changes we need to"
7. Actively take feedback. People love to make their mark, give them plenty of room to do that. As long as it doesn't substantively change the plan, be very open to change. For example, when I am doing a dry run for an exec review, I make a point of taking appropriate changes from every stake-holder, especially those that are not 100% in agreement with the plan. The extreme of this the admiral's pipe.
8. Change your mind. Never forget that you may be wrong. The goal here is not for your idea to win and everyone else to lose, it is for the best ideas to come to the top. If someone else has a better idea, drop yours and take it and start building consensus around it!
9. Appeal to respected other. Let's face it, the person you are trying to convince may not respect you and therefore will never buy into your idea. If so, find out who they do respect and talk to them.
10. Identify the blocker. Often times there are is just one thing about the plan that is a blocker but lots of other issues come up. Try to weed through the issues until you find the one that is truly a blocker and deal with it. You are just wasting time dealing with the easier issues that are not blockers.
11. Let history be your guide. The IT world is a great big cycle, anyone that has been watching the industry for more than 2 years knows that the same ideas come back around with the same set of issues. Appeal to historical examples, how is your solution going to be better or different? For example: "Unlike clippy, we are going to provide help in the context of where it is needed"
12. Find the agreements. In most cases you agree on way more than you disagree on. Defining the agreement makes it clear how close you are to consensus and you may find that you have enough consensus to move on.. that what is left as disagreements don't substantively mater in the short-medium run.
13. Define the disagreements. Spell out clearly what the blocking issues are. Be sure you deeply understand the other persons' position. Getting the disagreement written down clear can help you both see what additional data would help resolve the issue and will help others to chime in.
14. Find out who matters. It is impossible to have 100% agreement with absolutely everyone involved. Very rarely are IT organizations a democracy with everyone getting an equal vote. Let's face it, some people mater more than others. Find out who the key players are. Who needs to take action on the plan, who controls the resources, who can veto? If this person doesn't matter, maybe you don't have to get them to buy-in.
15. Deal with the fear. Sometimes there is an underlying issue that has nothing to do with the matter at hand. Does this person feel you did them wrong last time? Is there a territorial issue at play, is there some other reason for a lack of trust? You have to deal with this first.
16. Why more than what. Deeply understand why the person is taking the position they are. Directly ask why, make suppositions and test them. But focus on the why way more the what of the disagreement. The why might have to do with history, politics, personalities, etc. Address the why directly.
17. Be differentiated. Not everyone is equally invested in every issue. Find out who the key stake holders are that are deeply invested in the issue and give them higher touch, earlier feedback opportunities. For example, sending a spec out to a wide alias might seem like a way to build broad based consensus but it could backfire if those directly involved feel short-circuited.
18. Be broad. Especially later in the lifecycle of an idea, the more people you get to buy in the better. There is a wisdom of the masses element that can help a lot. For example reviewing possible product names with key marketing and sales people are key, but it can be helpful to get broad range of opinions as segments of the population may have an adverse reaction to the name. In this phase, 1 or 2 negative reactions is to be expected, what you are looking out for is trends and repeated reactions.
19. Simple wins. Spend some time thinking about how to simplify your idea.. what is the essence of it? How can you represent it in a simple-yet-meaningful way? Ideas that are more simple are easier to understand, easier to implement and harder to find nits to disagree with.
20. Check your emotions. Is your anger, passion, or frustration getting in the way of your consensus building? It is amazingly hard to deal with one person that is reacting poorly to a new idea, it is completely impossible if both you are reacting poorly. Building consensus is NOT about proving you are right, smarter, better than the other person. Relinquish all desires along these lines and focus on the objective. Go home and play your Xbox to prove your worth ;-)
21. Avoid getting entrenched. Once people take firm sides on an issue you have already lost in many ways. The best consensus building is done as ideas are being formed (yours and others). After someone has already taken a side they are more apt to defend that side out of pride. Presenting ideas as a black and white choose fuels the "taking sides" fire. Don't force an answer until you'll get the right answer.
22. Let time pass. New ideas may take a while to sink in. Many folks are uncomfortable making snap decisions, give them time to think through all the implications. Check-in regularly to show you care and to keep on track but don't force a decision unless you really, really have to (that is quite rare).
23. Let them save face. If someone has been entrenched in a position for a while, their lack of love for the new idea might have more to do with making them look like a "loser" than the merit of the idea. Are their concessions you can make? Are some timeframes better than others? Are there other areas you can offer your support in?
24. Create a path. If you can't get consensus on an issue, try getting consensus on the path or steps toward an agreement. What data do you need? What 3^rd party could you appeal to? What prototypes must be done? Stepping back from the issue in this way allows room for agreement and trust to form before confronting the issue again.
25. Have Principled Flexibility. By definition, there must be a single, coherent idea around which consensus is built. If you change the idea substantively every day you will never build consensus. Figure out what the core idea is and stick to it, but be open to changing the non-core elements as much as is needed.

In the process of creating this list, a few anit-patterns emerged. Certainly you can NOT any one of the above to find out how to botch a consensus building activity. In addition, here are a few common ways I see people screw up in consensus building.

1. Blessed Ignorance. Many failures can be attributes to folks not realizing they are in a consensus building activity. They miss-judge it as a competition or information dissemination and thereby forgetting to listen and take feedback. It is very helpful to identify the situation clearly, calling it by name, and maybe references in this post ;-).
2. Escalate. When faced with a difficult consensus building activity, the knee jerk reaction in the corporate world to talk to the "stubborn" co-workers boss. Presumably the goal is to get the manager to get the problem-child in line. A few questions to ask before you escalate. Will the damage to your long term relationship with the stubborn coworker be worth even the best outcome from escalating? Will your coworkers boss buy the idea themselves? Will you come across as incompetent at a core PM skill (building consensus)?
3. A mission from God. Occasionally a PM is asked by a senior exec to drive some initiative. A common mistake in this case is to assume that this makes you infallible and obligates everyone to buy-in immediately. The truth is that even in this case you need to build consensus. At best the exec air-coverage gives you the foot-in-the-door and hopefully defines the core principles.

So, what do you think? Other patterns or anit-patterns for consensus building you have used? I'd particularly love to hear stories about using any of these.