McDonald on Project Blogs and Wikis - For "Heavy-Duty" and "Innovation Oriented" teams

Dennis McDonald really strikes the "What Project Blogs?" nail on the head when he describes how, for lighter-duty "innovation oriented" teams, blog/wiki systems can be their core platform whereas for "heavy duty" teams, they "take precedence by making the availability of reports and data from the more structured tools more accessible." With blogs for projects, function follows form. More specifically, project teams need to communicate and share content over time - that's the form of a blog and is the principal rationale for why every project team should maintain one, or more, blogs. Additional project management functions required can be layered on top of the blog, or can be provided by other more structured systems when necessary.

McDonald explored the Project Blogs topic via a pair of surveys in which he found that project managers may not yet identify the "blog" as the technology they need - but they certainly identify the features of the blog at the top of their technology requirements. File management and discussion (the basics of information sharing and collaboration) were at the top of the list.

I would argue that the journaling aspect of blog systems, posting content and conducting discussion over time, is the first requirement for project teams. Features facilitating versioning of text and documents, more sophisticated discussion, collaborating on and managing requirements, organizing with tags as well as search and notification via e-mail and RSS all follow suit. This is a case of function follows form.

Communicating and sharing information over time is the required form, where the functions may vary depending on whether the team is focused on brain storming, status reporting, issue resolution, meeting notes, or requirements management.

In my experience, there are two forms of project teams, those that have complex task dependency and resource requirements versus all others. In the former, teams need blogs to support every day communication and in the latter, blogs offer a "whole solution."

McDonald agrees. For the "all others" group, he argues that for teams which are development or innovation oriented:

the collaborative and information sharing features of blogs and wikis might be much more important while the formal chart and task dependency management features of more traditional project management tools might take more of a back seat.

In such processes where innovation, collaboration, learning, and mentoring take precedence over a set timelines and task dependencies, the core features of the blog might provide major benefits, especially if use of the blog can be tied to a reduction in inefficient email attachments and meetings.

For "Heavy-Duty" projects, McDonald says:

There are certain types of projects where the size, complexity, and time dependency call for heavy-duty task- and resource-management tools that are well integrated with corporate management, HR, and time reporting systems. In such cases the communication and publishing functions of the blog would take precedence by making the availability of reports and data from the more structured tools more accessible.

A blog is a simpler and lower cost than most enterprise tools, but the conversation and content in project blogs provides the context to project tracking and resource management tools. The blog content leads the reader to the water - explaining the relevance of a certain report such as describing why a particular resource constraint is a problem and what the team needs to do to fix it.

In light of function follows form, both types of projects benefit from communication over time. The heavy-duty project teams may benefit additionally from the ability to link to records and reports in their resource management systems - or, better, widgets (like our Google Map widget) which can take parameters and display the other application in-line within a blog or wiki page where it can be described and discussed.