This is from Jordan Frank, Vice President Sales & Business Development at Traction Software. I’m in Providence, RI to deliver the closing keynote this afternoon at Traction User Group 2009.

Awhile back, Stewart Mader was involved in a discussion about the role  of professional services in emergent systems like wikis. In the many pilots I’ve seen its become increasingly clear that adoption doesn’t just happen on its own, there are a variety of factors ranging from technology to timing to training and even taxonomy (or folksonomy, if you will) which all play a role.

The role of professional services, in my words, is to bring forward best practices and to accelerate the process of identifying the emergent patterns that may be specific to any one organization.

In Structuring for Emergence, I’ve discussed how those patterns are a part of organizational grain and are best exposed when in context of a facilitating structure. The facilitating structure is defined by the technology deployed, the organization of the content in that technology (including space names, permissions, tags, and the way information is visually displayed) as well as the behavioral, organizational orientation to the technology (including whether there is training, whether contribution is compulsive or voluntary, and how communication in such a system aligns, or doesn’t, with job role and position).

These two cases explain how services facilitate better outcomes, faster:

• Fixture Manufacturing Company: A customer installed TeamPage and started establishing workspaces with no problem. His first few steps were to make a workspace for each competitor. In just a few moments of discussion, we agreed he would be better off with a Market Research workspace containing a tag for each competitor. He engineered his workspaces accordingly and is thriving as he joins the 12-Month club in November 2009.
• Pharmaceutical Marketing Division: Pharmaceutical firms are required to err on the side of caution when sharing information, but have high value for information sharing and relish the opportunity reduce barriers as much as possible. A customer needed two layers of review and started off with a process that involved information content approval by a product specific marketing manager and review of tag usage by a content administrator. I showed them how timing effects could delay the publishing process by days if not a week or more in such a two tier process.

  Instead, we decided on a parallel process where the product marketing manager approved content for publishing while in a separate and independent process, a content administrator was sure to review the use of tags on the content. The latter step is important for wiki gardening, but not a necessary barrier between contribution of draft content and approval for publishing to the enterprise.

Despite anyone’s judgement as to what % of collaboration success is attributed to Technology vs. People, getting the technology right and configuring it in a way that meets rather than defeats a need is a Door 1 pre-requisite.

This is from Ben Naftzger of Atlassian, makers of the Confluence enterprise wiki that’s used by more than 7,000 organizations around the world. His article looks at how an enterprise wiki can help manage the performance review process. – Stewart

Atlassian was recently invited to present to HR professionals at the HRfutures conference in Melbourne, Australia. The key emphasis of the conference was to familiarise the HR audience with emerging Web 2.0 technology and it’s effect on the Human Resources industry.

Two Atlassian colleagues of mine, Joris Luijke and Matt Hodges volunteered to share how Atlassian’s HR Department (the Talent team as they are referred to internally at Atlassian) use Confluence, the enterprise wiki. The HRFutures presentation could not be filmed, so they produced a video post-event to share how Atlassian’s Talent team use a wiki to manage Atlassian’s performance review process:

I hope this video can help drive wiki adoption within your HR team.

Rob Castaneda, Founder of CustomWare Asia Pacific, wrote Working the “Wiki” Way for the March 2008 issue of Octane, quarterly magazine of the Entrepreneurs’ Organization (EO).

In the article, he discusses how CustomWare uses a wiki internally to improve information flow between teams working on client projects:

The Pain Point

The biggest snag we experienced was transferring knowledge and context from the sales team to the delivery team. This muddled flow of information threatened our client projects.

Rob and his company decided they needed to improve communication, and decided to use a wiki as their collaboration platform. [Read more]

Larry Cannell writes about a recent CIO Magazine interview in which Ross Mayfield discussed 4 common wiki uses that can reduce email. Here are Ross’ four examples, and my suggested Wiki patterns that can help you with each:

1. Collaborative intelligence – “for example, in marketing and sales operations, you need to communicate to the field organization about an ever changing product line.” The pattern I’d use here is Magnet to establish a wiki as the “go-to” place for people out in the field.
2. Participatory knowledge base – “99 percent of the pages created [on the wiki] and tagged allow the call center to go from 20 clicks to find information to four, substantially decreasing search costs and decreasing the average call time by 10 to 20 percent.” I’d use the FAQ and Seed it with content patterns here.
3. Flexible client collaboration – “a collaborative workspace between [a firm] and the client.” Agenda is a good pattern for using the wiki to organize meetings with clients, and kickstart client collaboration.
4. Business social networks – “with your business partners or customers, where you’re communicating to them, getting feedback from them, and they’re interacting directly.” I’d use the Corporate Directory and MySpace patterns as the building blocks of a social network.

The WikiSym 2008 Call for Papers is available now. WikiSym will be held 8-10 September in Porto, Portugal!

WikiFest – 6:00 talks

WikiFest is a new addition this year. It’s devoted to helping you start and grow a successful wiki, and I’ve structured it Pecha Kucha style which means max 6 minutes and 20 slides – get to the point, do it fast, and hear from as many people as possible! [Read more]

Fourth in a series by guest author Vincenzo Cammarata.

The true collaboration occurs when people have the possibility to co-work on the same sub-task, activating a mechanism of new knowledge creation. Collaboration is not so obvious if is not clearly supported: the risk is to exchange this “together” learning process with a simple cooperation process, producing not new knowledge but only a simple addition of individual regress knowledge.

In this sense, collaboration has to be helped in order to avoid isolation in job and supported with a compatible scheduling of daily activities. Is also important to create “collaboration bridges” across teams and groups, involving people to participate in each other’s activities or involve experts on other areas to collaborate together.

Related WIOWA Questions:

4.a Support to People (support to effectiveness)

Do you know which people are involved in your same projects?

4.b Teaming (organizational services)

In your team, are individuals plans often compatible with the group activity?

4.c Collaboration (knowledge and collaborative support)

Is it usual to participate to other group projects?

4.d Communication (communication and socialization)

Is it usual to discuss with others about their work, solving problems together?

Michael Idinopolous suggests 3 ways to build a participatory knowledgebase using a wiki:

1. Structure by Topic

The whole point of the wiki is its ability to bring people together and connect dots across organizational silos. That won’t happen if you structure the wiki around those very silos.

Here, he argues the wiki shouldn’t mimic the existing organizational structure because that won’t help break down information silos.

I agree with the principle of using the wiki to encourage new connections across the organization, but it does need to start with some resemblance of the existing organizational structure. That gives people confidence in using it. [Read more]

The new Wikibility Workplaces series being penned by Vincenzo Cammarata was featured in Great Blogs of Fire, the popular serial posting on The Buzz Bin by Larissa Fair and Geoff Livingston, author of the excellent Now is Gone: A primer on New Media for Executives and Entrepreneurs.

Stewart Mader shows us eight key cultural drivers to wiki success. He discusses what attitudes make an innovation oriented organization a “wikible” workplace or – in other words – a workplace where Wiki really works in an effective way?

Thanks Geoff and Larissa!

Mike Kavis writes an excellent blog on his efforts to bring enterprise 2.0 into his organization:

I have been blogging about my Web 2.0 experiments at work and recommended that we should just do Web 2.0 instead of trying to justify it.

With so many open source solutions available for wikis and blogs, the best way to get traction with Web 2.0 technologies is to casually bring it in house, plant the seeds, and let it grow like weeds.

You can have a large amount of people using these tools quicker then you can try to sell the value to an older generation of decision makers who are not familiar enough with the tools to understand the value. [Read more]

Last week I wrote about wiki use at Lee Rosen’s, North Carolina-based law firm. Here’s an article from Fortune Small Business on how he used Incentives & Recognition to spark collaboration on the wiki:

“The biggest reason that we’re switching is that the wiki is easier to use,” says Rosen. “If employees see a better way to organize or present information, they can just go ahead and do it with a wiki.