I was talking with a customer the other day about change. He's trying to get his team on board with a wiki to cut down on the flood of email chains and bring some order to his small firm's file server. "How do I push through the organizational changes needed to make this work?" was his question. The need for change and how to affect it is a fairly common line of thinking for somebody trying to implement an internal wiki.

The key is to not lead with change. As soon as you start talking about change, the ears of all the naysayers and stuck-in-the-muds perk up. Humans are, by nature, resistant to change. You need to find another way in.

Consider a well known marketing aphorism: sell the benefits, not the features. Nobody cares if a widget has seventeen feature packed interchangeable modules. They only care if it solves their problem. The great Billy Mays (may he rest in peace) didn't bore you with details about OxyClean's powerful combination of sodium carbonate and sodium percarbonate. He showed it working on five or ten specific types of stains that people usually consider hopeless. Problem solved; product sold.

When introducing a wiki to your team, don't call a meeting about implementing a wiki. Call a meeting about the problem your company is suffering from. Ask people to come with data describing the problem. If email glut is your poison, ask people to come to the meeting with some stats: the number of emails they receive per day, the number of those emails with attached files and how many of those emails have been CC'd or forwarded beyond the original recipients.

Go through everyone's notes and define the problem collaboratively. In the case of email overload, talk about the valuable information going down the drain, the inefficient communication, the duplicate and inconsistent copies. If you're dealing with management, look at the problem in terms of cost. Get everyone thinking to themselves, "man, this email thing is a problem."

Then start talking about solutions. Go through a "perfect world" solution exercise. Well, in a perfect world, people would collaborate on a central body of knowledge rather than forwarding, copying and inline-commenting on email threads. Content created during collaborative communication would be available on the web to anyone who might need it. You get the idea.

The point here isn't how to successfully launch a wiki within your organization - that's a bigger topic than this post can muster. The point is, don't talk about change. Talk about problems and solutions. Like Billy Mays, focus on how a wiki will address specific attributes of the problem. Then focus on what tasks and roles will be involved in making a wiki work - that's the change in disguise. If presented properly, you'll have people volunteering for these tasks and roles rather than groaning about a new way of doing things.

The wiki isn't going to change anything on its own. You will need to affect change to make it work, it's just best not to make that the point.