Recently my team at work embarked on a big project, one that involved a lot of meetings, expansive ideas, and the creation of large strategic documents. In a previous column, I described my experience trying to capture some of the intelligence that emerged in the meetings we held. But we also tried to use technology (collaboration software) to get people to contribute to this project outside of the meetings.

Frankly, it was a disaster. Our collaboration system became a wasteland, a great technological framework with no humanity in it. I lay only part of the blame on the service we were using, Intuit's QuickBase. I've seen similar initiatives based on other technologies fail in almost exactly the same way ours did, so I'm letting Intuit off the hook in this case.

I have seen a small number of collaboration systems succeed, too. But sadly, because I've witnessed more disappointment than satisfaction with these products, I have a better handle on the common failure points.

Unclear personal benefit. In our case, we were asking people in the company to read a draft document, then comment on it in discussion boards. Almost everyone claimed to be too busy.

Any good manager will tell you that's just code for "What's in it for me?" Our people simply didn't see why they should bother posting their comments in a public forum, using an unfamiliar tool. And we, as managers, didn't communicate to them the clear benefit of doing so.

Too easy to ignore. Done wrong, a message board is like an optional offsite meeting: You're going to have to drag people to the site to get any sort of participation.

But drop into their office or the electronic version of their office (their e-mail or instant-messenger system), and the chances for good input go up dramatically, especially if you use IM and just sit there tapping your fingers until they respond.

That's a problem that portal-based services, such as QuickBase, can't solve directly. They are offsite destinations, and while they can send alerts to users via e-mail, they aren't integrated into users' lives. All other things being equal, systems closely linked to e-mail get to users where they live and work and, thus, are more likely to elicit the response and feedback that management wants.

Roadblocks to signup. Presumably, your collaboration system is closed to all but the members of your team. That's appropriate since you don't want the entire world reading and commenting on confidential plans. Each user, therefore, will need some sort of login ID and password. But if the system slows down users by asking them to set up new accounts, you're just giving them an excuse not to bother. Some systems even send signup requests back to an administrator, which really kills the impulse to participate in a collaboration system.

So make it easy. Either go with their previously approved network ID (possible only if your system can integrate with your network login system) or preassign the user IDs and passwords.

The old way is not the best way. When we started our project here, I thought that message boards were the way to go, simply because I've participated in a lot of them over the years and I understand the format. But there are newer methods of group communication that are more appropriate for today's workforce. In particular, I'm thinking of blogs and wikis.

Blogs, as you probably already know, are (usually) chronologically based discussions run by one person or a small group of people that readers can reply to online. The blog format--short and to the point--is a better match for today's time-strapped worker than the more convoluted threaded message-board format.

Wikis are different altogether: free-for-all collaborative Web sites where any registered user can modify anything on the site. I've seen wiki-based collaborative systems (using Socialtext's software) get lots of use and provide much value. And this is despite the inherent danger in a wiki that, at any time, any user could completely ruin the system by throwing up a bunch of off-point content or even erasing what's online already.

And that is why they work. A wiki often will teeter close to anarchy, but it's a common ground, not a corporate room owned or controlled by the bosses. Wikis tend to get disorganized and wild, but that reflects the nature of real human interaction and idea sharing.

There is and always will be a place for structured communication. But when it comes to getting people to brainstorm and participate in a technological medium, a lack of preexisting structure can be an advantage. You never know what a team of smart people will come up with, so boxing them in is rarely a good idea. Let them build their own boxes instead.