Project Information - Where to put it and how to use it?

I've had cause to think about the issues of managing projects without a LAN. Indeed managing any kind of business activity without a LAN requires a particular mindset.

If you think about project information it falls into a number of clear categories:

• Control material - things like status reports, actions, issues etc. This stuff is both structured and requires formal control. In a LAN-free environment it lives in some kind of web-based project control tool. This kind of information is generally well understood and well catered for by projects and project managers;
• Formal documentation - material such as requirements documents, reports, project plans. This material belongs in a document management tools - web-based. The tool should allow check-in, check-out with version management and fine grained access control. Again, this material is well catered for and well understood by project managers;
• Semi-structured project information. This is the perhaps the most troublesome type of information. How often have you had a client or someone else saying "where do I find last week's status report?". You don't want them wandering around in the document management system and you don't want to have to continually email documents around. Similarly the endless questions about "what's happened about x this week?" can be more effectively answered by having that information in a central spot. It's this last set of information that is both the most troublesome for projects whilst being the least thought of in terms of management.

Clients, project owners, management and client team members are often very interested in progress, often in a qualitative fashion. It takes a lot of time to keep all the stakeholders up to date, particularly those with a voracious appetite for information.

Enter the wiki and blog. This is the right place to manage this sort of information. A really simple initial structure gets you off the ground. The master pager of the wiki has links to these pages:

• Who's who? Many projects have a large pool of people that they deal with. Induction for new project members can be incredibly slow and time consuming because of the large number of people that they need to be aware of. Creating a Who's Who page and then encouraging all team members to keep it up to date can be a big help here. This is particularly important with the layer of people who are outside the team but very important to the project;
• Status. This is the place for final copies of the weekly or monthly status reports. Once they are finalised a copy can be placed on this page to give interested parties access without needing to provide access to the DMS;
• Documents. Every project creates "landmark" documents, whether it's a stage report, a Func Spec or a set of FAQs. These could be placed in a "public" section of the DMS. The reality is it's probably easier to put them on the wiki page. This forestalls the endless questions from project members like "can you send me a copy of...?".
• Blog. Perhaps the least thought of capability is a blog. This is where project members can be encouraged to publish short snippets about small project achievements, activities for the day and planned future activities. It's a way of letting other project members and stakeholders know what you are up to.

Sitting alongside those pages you need some way of letting others know what has changed on the wiki or blog: either email or RSS feeds work well. Expecting interested parties to visit and check for updates is not very useful, you need to tell them what's happening.

Similarly the capacity to email items of interest into the wiki and to have attachments appear is also important. It creates an additional means of interacting with the system.

So here's what I'd like to know: Do you use wikis and blogs in projects? Do you find them useful? What specific tools do you use?

I've been using the Snow Leopard Server Wiki Server 2, I like it, it works well and it's very simple to use.