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.

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.

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.

Using the Wiki to Manage Client Projects

Rob describes how CustomWare keeps materials and information for each project in a distinct space that staff and clients can access. Using separate spaces is good for keeping information organized, and setting permissions so that each client sees only the information relevant to their project:

With our wiki in place, we decided to partition the system into the relevant “spaces,” each designed for a separate project where staff members and clients could readily contribute information. Whenever new documents or information needed to be distributed, we placed them in the secure wiki website. Instead of emailing large attachments – which could be annoying to deliver – we simply emailed clients links to the documents online.

Reducing email is another excellent change in practice that frees peoples’ time so they can better focus on projects, and better captures information in a central place where all involved can see and use it.

How has it helped?

Thanks to our wiki system, our knowledge transfer between client engagements is pretty tight and in shape. And most of the information is captured and communicated efficiently. The wiki has been a great tool for operational, day-to-day use, and it’s become far better than servers or e-mail when it comes to storing important information and documents.

The full article is an excellent read, and Rob also discusses several other ways the company is using its wiki. He ends with an important piece of advice:

Using a wiki helps, because it is a great way to provide a blank canvas with which the team can work. However, like any technology, it is a tool, not a complete solution.

He’s right – a successful wiki depends on the active participation of as many people as possible. That’s a matter of changing existing practices and habits by showing people how the wiki improves the way they work, and giving them reasons to use it.

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.

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!

Important Dates

May 3rd: submissions deadline for research papers, practitioner reports, workshops, panels, and tutorials

May 17th: notifications for workshop submissions

June 11th: submissions deadline for posters, demos, and DoctoralSpace proposals

June 25th: notifications for research papers, practitioner reports, panels, tutorials, posters, demos, and DoctoralSpace proposals

July 19th: final revised PDFs due

Sept 8th-10th: WikiSym 2008

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?

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.

Here’s what I advise organizations:

1. Create spaces that reflect existing groups, teams, and departments (Sales, Marketing, Research, Product #1, Product #2, etc.) but keep all those spaces open to everyone in the organization.
2. When you add new content to a space, ask yourself: can this information be accessible to everyone or does it need to be restricted to specific people?
3. This way, you build a wiki that’s mostly open and encourages self-sufficient access to knowledge & cross-collaboration, but also preserves the security and privacy of sensitive information (and makes it easy to ease that privacy when you’re ready to make certain information more public).

2. Lead with what you want

…a page called “Trends in Retail Channel Marketing” is a better wiki page than “2006 Analysis of our Company’s Channel Marketing Spend”. (Of course, the report might be useful as backup–so include it as a link from the main page on trends).

Here, he’s suggesting that it’s not very useful to just use the wiki as a dumping ground for content that’s idle. It’s better to actively develop the information – say, for a research report – right on the wiki, then attached the final report to the wiki page. That way, people get both the content in a reusable form, and the report in an archival form, and both are in context by being presented together.

Also, when people actively create information on the wiki, they’re more likely to reuse that information where appropriate since they

• a) wrote it, so they know what it contains
• b) will likely write future information on the wiki, and will be in the mindset to recognize that they already have relevant content elsewhere on the wiki.

3. Link, Link, Link

Encourage them to “linkify” any term (yes, I mean any term) in their entries that is either proprietary vocabulary, potentially unclear to some readers, or describes a strategic concept where the company might have proprietary insights.

I generally agree with this one, although I think it’s good to exercise judgment about how many terms to link. It’s good to link to definitions of ambiguous terms, but it’s better to replace those terms with clearer ones that require less definition. That way, you can focus on making your core text as readable as possible, and focus your linking on terms you want your readers to focus on.

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!

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.

On building interdisciplinary connections between people who wouldn’t ordinarily interact:

The architect team has found that blogging has created several quality discussions with people who they don’t get a chance to interact with that often.

I have received requests from marketing, sales, and public relations to meet about possibly extending blogs to their departments. In an IT strategy session today, one of the teams working on our “people strategy” recommended more blogs to improve communications.

On reducing email:

We are trying to develop these processes without using any emails. We are only allowed to use face to face discussions and the wiki to come to consensus.

On the impact after just six weeks:

There are still some people who laugh at the notion of blogs and wikis, but in time this will become as normal as email and the telephone. And the beauty of it is that we didn’t pay a penny for any of it and we didn’t have to sell it to anybody. We simply built it and they are coming.

“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.