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. That's not the worst case scenario though. The worst case scenario is that Person B proceeds without the information, and makes a mistake that ultimately costs the project time and money in rework activities (or causes the company to lose an important customer, or to lose public face).

Managers regularly ask for reports and updates on projects. A project worker can document activity very quickly when the activity has just occurred. But sitting down to write a project status report a few weeks later could cause a project worker to lose a day or two running around collecting information they have forgotten in order to write the report (not to mention interrupting other project workers from their project responsibilities). What do you think is more efficient – immediate documentation followed by point-and-click reporting, or assembling reports on demand? Hey – some managers can even be trained to pull their own reports . The additional time people spend communicating in a project management environment is nothing compared to the time they save by NOT having to run around repairing mistakes made due to lack of communication or reconstructing previous work and/or decisions.

Ultimately, there are only three reasons for resisting project management disciplines: 1) Failure to understand the potential benefits, 2) failure to understand that the system is not creating new or additional work, but rather, is placing the work in a specific order and requiring that it get done, or 3) a desire to operate without disciplines, in order to have as much leeway as possible to do things their own way. For those struggling with Reason #1 and Reason #2, I hope these explanations have provided some illumination.

Once implemented (defined – all participants understand the system, use the system as designed, and have optimized the system – half-hearted attempts by uncommitted work teams can't be referred to as implemented), project management results speak for themselves. In most cases project productivity climbs by 15-35%. Which brings us back to the reason for most project efforts in most organizations – to create new value. And what are we supposed to be doing, if not doing a better (faster, less costly, higher quality) job of creating profits for the organization?

(c) 2008. Andrea M. Hill