Resource Center

Collaboration? Who's collaborating? Author: Chris Vandersluis © 2000 Chris Vandersluis Printed in PM Times

So, you've decided on using collaborative project management software to organize your project team. Congratulations You're on the leading edge of new tools being used in the project managment industry.

That's good, right? Well, it can be but just using the latest pm tools doesn't make you automatically more effective.

For those of you just getting started on distinguishing the many different types of project management software on the market, collaborative pm software differs from, say, scheduling software in that its primary focus is not analysis. A project management scheduling tool such as Microsoft Project, Open Plan, Primavera etc. is primarily a critical path methodology (CPM) scheduling tool. Over the years these products have branched out to include many more areas of functionality but at their heart, the architecture of these tools are still basically scheduling calculators.

Collaborative software uses a premise that communication between project team members should be the driving force behind a project management tool. It includes functionality for issuing instructions, entering status and issues and communicating either in real-time or via email or discussion group electronically.

Is one type better than another? No, of course not. But they are very different. Does one product incorporate both types of functionality? Most do but at their heart, each tool will have a primary focus. We'll be looking at the collaborative tools here so you can decide for yourself the benefits and pitfalls of going one way or the other.

Let's take a look at what implementing collaborative project management software implies.

Who should collaborate?
First of all, who should be doing the collaborating? It's a cheap shot to say "everyone". In fact, informing 100% of the project team members about 100% of the data about the project is counter-productive. Imagine if 100 team members could each comment on the advisability of a requested change by the client every time one came up. The team would spend so much time commenting, they'd find it difficult to find enough time to work on their own responsibilities.

The best way to consider who should be involved in collaborating is to organize a list of team members by the roles that they play. For each set of roles, consider what interaction they should be having.

For example, you might have Quality Assurance personnel who interact frequently with programmers during the QA cycle as they report bugs in a software project. The programmers then must report that the bug has been fixed and is ready for retesting. Tracking this cycle alone requires a high degree of effective communication.

A project sponsor probably doesn't need to talk to each team member but might need to see the status of project milestones on a regular basis each time they're updated. When a problem occurs in the project that might affect one of those high-level milestones, they might want to be able to communicate immediately with the senior project staff to create a contingency plan.

A client doesn't need to be able to chat directly with every engineer on their project but might like to be able to see a range of project reports on demand based on the last update as well as being able to discuss possible project changes or see the impact of late or over-budget areas of the project.

For each role where you can identify that regular communication is required, it is important then to qualify what communication should be made available. Here are some critical questions to ask yourself as you design your collaborative environment:

• Is this communication one-way or two-way?
  This is fundamental. If communication is one-way, then it can often be done in some kind of reporting mechanism. If communication is two-way, then tools for communicating in real time or at least tracing the conversation (as a newsgroup conversation would do) is essential.
• Is communication one-to-one, one-to-many, many-to-one or many-to-many?
  This determines the communications format that's best used and is a question that is not often asked. If communication is from one person to many people, then it's best done through a report. If it's from many people to one person, it's best done through a standard form If it's one-to-one, then it's usually some more intimate communication such as direct dialog, live chat or e-mail. If it's many-to-many, then a discussion group or live chat might work. Not answering this question can result in an ineffective communications format being used for the wrong type of communication.
• How frequently does communication occur?
  Again, this determines the type of communications format that's appropriate. If for example, communication between people in particular roles occurs multiple times in a day, this makes using reporting less effective than direct conversation. If, on the other hand, communication occurs once per month, then making a live-chat scenario work might take more effort to set up than it does to complete the entire communication.
• What is the advantage of automating this type communication?
  Collaborative Project Management software vendors hate that I ask this question. Their answer is that everything should be automated. Why? "Because," they answer. However, as many people have found over the last few years, some types of communication are better done face-to-face or voice-to-voice than over any electronic means available. The ineffectiveness of organizing a meeting between people might be outweighed by the social aspect of the meeting for some situations. When you weigh all the questions we've asked so far, it becomes obvious when this is or isn't appropriate. For example, it might be very worthwhile to organize a meeting between a client and the project leader once per month as the social interaction goes a long way to keeping the client confident and happy with the project's progress. Yet organizing a meeting with all team members every day to discuss progress might be very ineffective compared to gathering the data through an automated statusing form.
  What you're going to find is that for some roles it doesn't make sense to automate that area of communication and for others it does.

If you get the combinations right, the potential benefits of automating your project team in this manner can be significant. Organizing types of communication between different team members makes good sense if you can adjust the communications methods to be more appropriate to the types of communications available.

Do you need collaborative project management software in order to do this? In principle, no. However, many of these products have been created with this type of reorganization in mind and have numerous features that facilitate the types of communications we've been talking about.

If you've already selected the collaborative pm software you'll be using, take pause for a moment to decide what elements should now be implemented or not and who should be getting access to what types of communications. If you're just considering such software, start thinking about who will be given access to it and how you expect each role to become more effective through its use. It will help guide you on what pm tool to choose and what features will be most important to you.

For more information on this article or any aspect of project management software or systems contact the author, Chris Vandersluis or HMS Software at info@hmssoftware.ca or by phone at 514-695-8122.