Wikis and Blogs Transforming Project Management

This link goes to an interesting article about how Wikis and Blogs can change the workflow of a company. I thinks there is application to managing projects.

http://searchcio.techtarget.com/originalContent/0,289142,sid19_gci1184607,00.html

As a project manager, I see real value in using both in project work. I like the idea of using a Blog for communicating the project status to the team and the stakeholders. The monologue with comments becomes a place where stakeholders can pull information about the project when ever they need it. Traditionally the PM pushes out information to the team. I also like the idea of having the whole project history in one place. The helps to centralize the "story" of the project and collect lessons learned for the application in the next project.

Wiki’s are a great collaborative tool. When you have a team that is separated by time and or geography, I can see how working on a project schedule in a wiki would be valuable. Each member can input the expertise into the schedule listing tasks and durations. In the end there is a complete schedule that has the whole team buy-in. Other PM areas can benefit: Risk assessments, Quality feedback, an RFP process, even laying the ground rules for the project could be hammered out in a wiki. Even a project team that is local can benefit by working together… Project the Wiki on a screen in a conference room and take meeting minutes, document assumptions and capture “group think.” Then when the meeting is over, the team can continue making additions as ideas come to mind, everyone can access the information during their project work, and the team collaboration that was started in the meeting can continue.

The interesting thing here is transparency. If used correctly there are no hidden thoughts, no undocumented assumptions and no project surprises. These two tools allow stakeholders to look inside the project as it is happening. The stakeholders can interact with the project by commenting, asking questions, encouraging the team, etc. While the stakeholder is "watching" the inter-working of the project, they are validating the scope... "Is this what I really wanted as my deliverable?" If not, corrections can be made as early as possible in the planning or execution phase. If the deliverable is right, the stakeholder is able to watch its development and have a deeper understanding of how the use and deploy the final deliverable. There is an early "bonding" of the stakeholder to the project deliverable that will reduce the chances of the deliverable being rejected at birth.

Unlike the traditional status report that is e-mailed out every Friday and not read, the Wiki and Blog put the ownership of getting the project information on the stakeholder. Any time an update is needed (even if it is not Friday) a stakeholder can get an update. This is important... these tools may keep the stakeholder from calling or e-mailing the PM, using up both of their valuable time. And in the e-mail scenario, the stakeholder is waiting for a response from the PM, when they could have checked the Wiki or the Blog for an up-to-the-minute project status.

Yes the PM is responsible for keeping the tool(s) update. I would submit, however, that the PM can push some of the administration work of updating to the project team. The team members can input up-to-the-minute information on the status their tasks on the WBS. They can report successes and road blocks. In most cases the PM is calling, meeting with or e-mailing the team members. Then the PM is reforming the information from the team into a status report for the stakeholders. This takes a lot of time on the part of the PM and the team.

The same project status information, kept more current, in a conversational medium, accessible anytime, created with team buy in, that saves time and improves communication efficiency is worth trying.

Good luck with your try and let me know how it work for you.