Wikis, Blogs and Podcasts in Project Management

Posted on
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

Da Vinci once called simplicity the ultimate form of sophistication. If he was right, and I suspect he was, then wikis are wondrous tools for project management — they’re simple to the point of elegance. Ward Cunningham, inventor of the wiki, has even called them “the simplest online database that could possibly work.”

A wiki is merely a Web site that users can edit without special software or even special skills. Just log on, click here and click there, and you can add content, delete content or change what’s already there. Thus, wikis make sharing information a breeze. And projects are all about sharing — sharing work and the documents that organize it.

Work the Wiki
What can you do with a wiki? First, of course, you can share documents, which is no small task for a project team that’s swimming in paper. (Check your desk: If you can’t see the surface because of all the paper that’s on it, then you’re in desperate need of a good document management solution.)

Wikis make sharing faster and simpler than other tools. Sharing by e-mail, for instance, is wasteful in extremis. It leads to sprawling document stores on users’ hard drives or poorly organized Exchange servers — how many users do you know who take the time to sift and sort all their e-mail, placing it carefully in folders by sender, subject or content?

Perhaps even worse, using e-mail to share documents makes storage a rank kind of nightmare: A message sent to 40 users can leave you with 40 new copies of a document on your network. God forbid the message holds PowerPoint slides with heavy graphics, CAD drawings or MP3s, because even the biggest hard drives will buckle under that kind of load.

Intranets are a step up, but they entail special software, long deployment times and more work for administrators already stressed to the limit. Not so with wikis because their software is a quick addition to most Web servers or even a hosted service or appliance. And think of what you can share with them: status reports, updates, action item lists, project charters, change requests, budgets, agendas, minutes, by-laws … in short, anything your team can dream up, even a full-fledged knowledge base or template library.

Most wikis can handle a wide array of formats, including Word and PDF, and some can even handle rich media, too. Other wikis have version control, making them perfect for specs, charters or documents where edits need to be tracked over time.

Using a wiki, workers can do more than share documents, of course — they also can create them. Any user with access to the wiki can simply log on and add new content that appears as HTML. Wikis use simple GUIs (Graphical User Interfaces) that walk users through the process, making it as easy to learn as toasting bread.

Cutting Up the Cadaver
All projects end, and some end badly. But no matter what happens at that final meeting, good project managers know a post-mortem — a session in which you analyze the project in retrospect, looking for strength and flaws — is as vital as oxygen because it shows you mistakes to avoid the next time around.

If you organize your wiki chronologically, it becomes a running record of what happened (or failed to happen) as your project went forward. Then when all is said and done, a review of the wiki can leave you with precious insights into where you stumbled.

And because wikis are built by users and not Web designers or network administrators, their structure often mirrors the way members of a team think and communicate. Users set up their own sections and navigation, choosing an architecture that makes sense to them. This type of organic growth is largely unknown on intranets and other content management systems, but it’s far better than an artificial structure imposed from without.

Sadly, even a tool as useful as a wiki is not without its flaws. Chief among these is the way people use it — because everyone can add or change content, everyone does, and they often write the wrong thing. Silly, offensive useless blather is not unknown on wikis, although in fairness it’s a problem that’s quickly solved. Simply appoint a team member to act as an editor. It’s his job is to review the wiki and prune its content with a red pen, removing the less-than-apt phrase or the outright flame that will spark problems your project should avoid. Some wikis also have built-in access control, letting you stipulate who can and can’t alter content, or what content they can alter, and giving you a hedge against abuse.

Calling All Bloggers
If a wiki is too exotic for your tastes, why not resort to the plain old blog?

True, they were once the Internet’s vanguard, but with millions in existence, blogs have become as commonplace in the business world as Dilbert. Perhaps it’s because a blog can be more than a soapbox or a silly exercise in ego — carefully planned and written, a good blog can help project managers get things done.

How? First, a blog is a way for managers to update team members, and even end users or consumers, of the project’s work. With a blog, you can broadcast announcements, updates, timelines or anything else you’d like to share with your team. And you have the ultimate in easy control over when it gets done. (Blogs from Typepad.com, Blogspot.com and Squarespace.com, to name a few, have a simple and highly refined interface.)

Blogs also can be used to share documents, although unlike wikis, sharing on a blog is more of a one-too-many push and not an all-inclusive call for content. On the other hand, if your project or corporate structure makes a one-way flow of information preferred, then a blog can be more useful than a wiki. And while blogs might lack the version control features of most wikis, they still consume less space on your network than sharing documents by e-mail.

Blogs also have the magic of RSS (Real Simple Syndication) behind them. RSS lets any user with an RSS reader be notified of new content as soon as it’s published. All this involves is posting a simple XML document, known as a feed, on your blog; you can even get software to write the feed for you. Popular options include FeedForAll (www.feedforall.com), Tristana’s RSS Writer (www.tristana.org) and FeedCraft (www.feedcraft.com).

If you’re like most project managers who spend the bulk of their day chasing after team members to give them documents or keep them in the loop, RSS can be a boon, even a blessing — not only will it save you time, but it will keep snarky colleagues from claiming they never received the information you sent them. Now that’s something to blog about.

Pods for Projects
Blogs are great, but not everything should be written. Take meetings, for instance: You can read the minutes — in which case you’ll get a bare echo of the information and even the raw emotions that can erupt in tense project sessions — or you can listen to a recording of the meeting itself, say, in your car on the way home. (Think of it as a book on tape.)

It’s one of the best ways to use a podcast in project management. A podcast — derived from “iPod” and “broadcast: — is simply an MP3 document with news, opinions, or other information that you download from a Web site and listen to in an iPod or other MP3 player. They can be vastly useful for running projects, too. Just tape a meeting of your project team — all you need is a cheap microphone and some recording software — then post the recording on your wiki or blog. If you’ve set up your team members with RSS, they’ll know about the post within minutes, and you won’t have to worry about writing up minutes, correcting them, sending them out and approving them at the next meeting. Users can even burn the podcast to a CD and take it with them for their commute home.

 

Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone
cmadmin

ABOUT THE AUTHOR

Posted in Archive|

Comment:

Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>