One topic that seems to create a lot of concern – with both customers requiring consulting and blog readers – is the topic of using systems to facilitate communication. There are three camps. Camp 1 is the group who is convinced that systems create bureaucracy, slow down the process, and undermine creativity. Camp 2 is the group who has no systems in place, is not innovating, and isn't finding their process moving along quickly at all – and therefore is willing to consider something better. Camp 3 is the group that has implemented effective systems and seen the benefit. Oh – in all fairness, there is also a Camp 4 – the folks who have implemented a system and turned it into a bureaucracy, at which point they turn back into Camp 1. Which is a shame.

The most commonly sought type of communication system is a project planning or project management system. Every company is engaged in some sort of project management and/or product development, and those projects are usually the basis of the primary value-added activities of the company. Value-add activities are the foundation of profitability, so it is no wonder that companies who do not do a good job of managing projects also do not do a good job of turning profits. The observations I will make in this column can be applied to other types of communication systems, such as knowledge-management applications and CRM, but for the sake of broadest reader application, we'll talk about project management.

In every company I have ever gone into and set up a project planning system, there has been significant initial resistance. The objection is always the same: "We have enough to do without an extra layer of reporting." So my first step is to help them analyze what has worked and not worked about previous project management efforts. Nine times out of 10 the failures are related to project communication, and when they can see that in graphic form, diagrammed on a white board, they give the system a chance.

It is probably no surprise to you that many project management efforts are doomed from the beginning. Why? Because project sponsors frequently do not agree with one another about project scope, desired outcome, or budget requirements. Sometimes this disagreement is opaque even to those in disagreement. This happens because people use the same words but mean different things by them, or because people assume knowledge or agreement on the part of others and do not explore their assumptions. Sometimes the disagreement is clear to the top managers, but they proceed anyway. The two primary reasons for this are: 1) They do not wish to engage in conflict and think that by avoiding it, the conflict will go away (sound crazy to you? Start observing and see how often intelligent people engage in patently crazy behavior), or 2) the participants are aware they disagree, but they figure they will fight it out on the details instead of at the beginning. Yes, these illustrations are examples of management dysfunction and failure, but they are also examples of the types of communication failure that prevent an otherwise worthy project from ever getting a chance.

Even if a project is launched with full agreement and clear communication, it can fail due to communication glitches throughout the life of the project. Creating open, accessible information systems is the goal of every project management effort. The most common complaint I hear about project management systems goes something like this: "Project management systems make all the employees do the work twice, once when they perform the action and once again when they fill in group members through software programs or required reporting."

In a well-constructed project plan there is as much reporting as is necessary for the team to function well together, no more and no less. If a group is engaged in product development of a complex nature, with lots of participants from engineering through marketing, there is much information to be shared. If a group is engaged in simple project planning, then less information sharing may be necessary. If you consider that failure to provide enough information (or the right information) keeps other team members from doing their jobs effectively, then fears regarding recording and reporting requirements can be looked at in a different way.

Ideally the construction of the project plan is such that the communication step only takes a moment or two to complete. But there are times when doing the work means providing complete documentation of a step just taken. If it is important for other team members to be able to access the information, it is not double work. It is a necessity. Even in projects that only include one or two people working in the same room, assuming that the participants hear one another's conversations or paid attention every time the others spoke is dangerous. That old saw about the meaning of the word assume is still correct. Furthermore, many times decisions have to be made by some team members when other team members are unavailable. The presence of effective documentation and status reporting can make the difference between a great decision and a disastrous one.

Finally, do you think that reporting of projects doesn't occur in environments without project management systems? Of course it does. But it is highly inefficient. Person X is waiting for technical information regarding a step taken by Person B, but Person B is unavailable. So Person X wastes three days on the project, because they can't proceed without the information.