Use a Wiki

Wiki's are a great mechanism to centralize access to your project information. Hopefully, the wiki will be updated multiple times daily and will always be open in a window on a team members' desktop.

To avoid wasting any precious brain cells that may be needed for the actual project work, here are some suggestions for pages you might include on your wiki. While creating these, you are sure to have ideas about customizing the site for your own software project.

• Stakeholders. Have space for topics such as up-to-the-minute project status, short-term issues, long-term issues, risk, budget tracking, and milestone achievements.
• Developers. Add information such as the connection string to connect to the QA database. Fellow programmers won't wasting time trying to locate the code from other random sources. Team members can share information on topics like coding standards; build and deployment procedures; common pitfalls; and use of advanced coding techniques, such as dependency injection.
• General information. The software project manager should add the help desk phone number, team roles and responsibilities, and individual team member contact information here.
• Team Calendars. Use this site to post team calendars. One great trick is to use an embedded iFrame pointing to a Google calendar.
• Meeting minutes. Archive meeting minutes so the team can easily refresh their memory of the details covered in past meetings. Also, they can quickly reference what they are to research or prepare for future meetings.
• Meeting agenda. Set up a process for stakeholders to suggest future agenda items online. Subject, of course, to the approval of the software project manager, the necessity for the item to be presented to the entire team, and the time limitations of the next meeting.
• Business Analyst. Often this person is not collocated in the developer workspace. This is a perfect space to centralize access to working documents and domain artifacts which can be accessed from multiple locations.
• Testers. The organizational structure may separate testing responsibility from the programmer. This site can provide a clearinghouse between the two teams. Post topics like how to use testing tools, such as, Selenium, QTP, and Quality Center. Bug-tracking procedures can be developed and discussed online, and the final decisions posted here.

Some tips:

• Don't duplicate information. If the information lies elsewhere, link to that information instead of copying it into the wiki.
• Keep an eye on the volume of changes to make sure the information is not getting stale. If it does, people will stop using the wiki.
• Try to make your information real-time data-driven if possible. Look for project management tools that include a wiki interface to enable creation of charts and status that is driven from the actual project data. This gives real-time status for the work in progress.

Any time you send project information via email, particularly with file attachments (documents, project plans, budget information), you should consider whether the team wiki would be more appropriate place to exchange and archive that information.