Collaboration. I hate this word, it’s overused, especially in the PR industry. I should know, I work for a PR agency and my job – technically speaking — is to “collaborate” every day on all sorts of things with all sorts of people.
In fact, chances are good that if you’re reading this, that’s part of your job too – so let’s cut to the chase.
You don’t really have a “collaboration” problem. You already know what you need to get done and who you need to work. You also know how you’re going to do it, but what you need help with is how to do it more *efficiently*.
You’ve heard a wiki might be the ticket, you’re just not certain how best to use it, where to start and of course, why it has that funky name.
My advice: understand your needs first. Worry about the funky name later.
I find that the pain points in a typical PR team’s workflow are never big ones. Instead, it’s usually a multitude of smaller, ankle-bitter-like inefficiencies that in sum slow the team down and impact productivity. Here are just a few examples:
- Versionitis – When too many people make too many changes to one email attachment and you’re left wondering “which one is the latest?”
- Email Exhaustion – When the sheer volume of email in your inbox exhausts your capacity as a mortal to effectively read and/or reply to important messages in a timely manner.
- Consistent Inconsistency – When the members of your team are dependent on consistent access to info via inconsistent methods (e.g., email, IM, file servers, etc.). Also see versionitis.
Again, you need to really understand what the pain points are in your existing work process before you can throw technology at the problem. And even then, it should be in small doses.
Also, while wiki adoption is typically pain-driven (i.e., solving *your* pains), there are plenty of additional reasons to consider using this tool. It’s low cost and ease-of-use are good reasons. Knowledge collection fits in here too, in fact it addresses a rather unique pain to the PR industry – turnover.
How many times have you been burned by a former colleague or a client or an agency that moves on with important info siloed in their heads or on their computers and you’re left having to piece together the program history? When turnover occurs, you not only lose valuable intellectual capital (translation: good ideas you never did anything with), you lose time too. A wiki becomes an invaluable way to capture and protect the integrity of your program irrespective of employee turnover or agency transitions.
You’ve Got Problems, Congratulations.
Now that you’re thinking about some of the pains in your program and where a wiki might help, you’re inevitably thinking “now what?”
My advice: take the plunge, but remember: baby steps.
There are a ton of wiki products in the market ranging from hosted services to back-end appliances to do-it-yourself open source implementations – each ranging in cost and complexity too. I leave it to you to determine which service meets your unique needs, but I will say this: It’s my observation that most companies prefer the hosted services offered by commercial providers like JotSpot and Socialtext. With the hosted services there’s no installation and no set-up, you just need thirty seconds and a credit card and your wiki is born.
Finding a wiki is actually the easy part. What comes next is much harder.
Have Wiki, Now What?
Once you have a wiki, how do you introduce it to your team and get cracking on the pains that motivated you to set it up in the first place? This is tough because for the uninitiated on your team, you’re asking them to not only learn how to use a new tool but also change their daily work patterns – that’s not an easy sell.
Anticipate questions. Expect resistance.
The worst thing you can do at this stage is ironically the most tempting – that’s migrating all of your pain points all at once to the wiki. You’ve lived with your pains for this long, a little longer won’t kill you. Will it?
Give your team time to acclimate to the tool and set them up for the best possible experience with it by starting off with the migration of smaller and more manageable projects. Remember: baby steps.
For example, a classic victim of versionitis is the weekly status report – arguably the most mundane task in the known PR universe. I twitch just thinking about the mess of emails and attachments that go back and forth within a group as each person adds their updates and a final document slowly emerges for client delivery. It’s a waste time and money. And I won’t even go into the headaches that come when these reports somehow “fail” to make their way out of email inboxes to their intended final destination on a central server or intranet for future reference.
A weekly status report is a great example of a small pain point that a wiki can remedy almost immediately. The wiki centralizes all the edits and ensures the most current version is always showing, plus that week’s report is automatically archived for future reference. There are additional benefits too, like the ability to capture notes from the meeting, hyperlink to outside sources and append related attachments. Most important, you’re only asking your team to change their working pattern for one activity.
Start small and the wiki will sell itself.
Putting Your Wiki to Work
Over time, look for ways to gradually migrate more of your pain points to the wiki. The speed of migration should be dictated by your team’s adoption and comfort with the wiki. I find that ongoing activities and/or any projects that are tracked via separate Word documents or Excel spreadsheets are the best candidates for wikification. Media lists, speaking calendars, edcals, and regular program reports all come to mind as practical examples.
The good news is that as your team acclimates to the wiki, there’s inevitably less resistance to using it and consequently your team can really broaden the scope of how it’s put to work.
For example, at this stage think about how you can move past static updates to more real-time work like managing edits on a press release, coordinating customer case studies and partner activities, as well as press tour schedules and yes, even their corresponding briefing materials.
Finally, as you become the jedi master of your wiki domain, really look for ways to exploit the technology to your advantage.
For example, most wiki providers offer integrated blog applications. The advantage? Blogs are a natural fit for news tracking and reporting, so put it to work for your team. Additionally, most wiki pages are syndicated via RSS. The advantage? Receive updates automatically when updates to certain sections of the wiki are made and alleviate the burden on your email inbox. Similarly, most wiki pages have a unique email address. The advantage? Copy the wiki on important emails and keep a shared archive of your correspondence automatically.
There are countless other ways to put a wiki to work for your PR program – both internally and externally – I think the most important thing to remember is that the most effective wikis *augment* existing communications and workflow patterns, they don’t replace them. There will always be a need for spreadsheets and word documents and presentations. And yes, unfortunately, email too. Your challenge is figuring what combination of these elements, plus a wiki, will help your team work smarter and faster in the long run.
This time last week I contributed a post to GPRBW 2.0 on the practical applications of wikis in a PR program. I’m republishing that post here in its entirety for posterity…and for my other two readers who didn’t catch it the first time round.
Mike Manuel is the founder of the award winning Media Guerrilla blog. Media Guerrilla is an insiders take on the practice of technology public relations with a focus on the issues, tactics and trends that are specific to the tech industry.
Visit Media Guerrilla …
