New Tools, Same Problems on IT Projects

Collaborative tools such as Microsoft’s SharePoint hold enormous promise on all sorts of IT projects. “Wikis” and their ilk contain amazing features. Going back a few years to the pre-SharePoint era, I can remember using different intranet sites to do the following:

facilitate document sharing and updating
improve intra-team communication
rid the organization of its dependency on email

Collectively, these collaborative tools can improve project management. Through their successful and consistent usage, the organization can improve its chances of achieving its goal: a smoothly run project.

Sounds good in theory, right? Unfortunately, many times the promise of these tools is far greater than their actual benefits. (This is also true of Enterprise 2.0 in general.)

But why is this the case? I’d offer two simple and related reasons:

Collaborative tools are only as good as the people who use them
Old habits (read: email) die hard

Email may be the Internet’s first killer app, as project-related messages convey important information about tasks, dates, and news. From a collaborative standpoint, there are a few major problems with email:

Emails can easily make the …

facilitate document sharing and updating
improve intra-team communication
rid the organization of its dependency on email

Sounds good in theory, right? Unfortunately, many times the promise of these tools is far greater than their actual benefits. (This is also true of Enterprise 2.0 in general.)

But why is this the case? I’d offer two simple and related reasons:

Collaborative tools are only as good as the people who use them
Old habits (read: email) die hard

Emails can easily make the content on a wiki dated or even irrelevant
Emails tend to be much less easier to find and search than content posted on wikis
People constantly forget to copy others on email
Most emails are downloaded to individual PCs, making them suboptimal for future reference

To be certain, wikis will never obviate the need for emails. What’s more, not every piece of information on a project should be posted on a wiki.“Hey Vince, didn’t you think that Nikki sounded like an idiot during the meeting today?” However, emails should constantly reference collaborative sites to reinforce the notion that the wiki governs the project, not 100 disparate emails.

Solutions

Organizations should take the following steps to ensure the optimal use of collaborative tools:

Start at the top

The PM or project leader sets the tone for the entire group. It’s hard to expect individual end-users to move from emails to wikis when the PM doesn’t lead by example. This type of leadership also includes making gentle suggestions to those who rely on email or—perish the thought—don’t update their documents anywhere.

Hold team members accountable for updates on wikis

Individual end-users must use collaborative tools consistently throughout the project. This goes beyond updating their own availability or progress. If the organization uses SharePoint, for example, then it needs to be the epicenter of the project. Unless the material is confidential or politically sensitive, all project plans, test scripts, requirements, and training materials need to go on the wiki. Period.

Cross-reference wikis in emails

Today, many people now routinely read email via BlackBerrys, iPhones, and other mobile devices. This isn’t changing anytime soon. To that extent, expecting everyone to abandon email simply is folly. However, emails should contain URLs to the same content on wikis. Doing so will help minimize conflicting or missing information.