Managing Project Communication

I've written before on the topic of how to prevent project failures, but very little about what happens as projects are failing. I was recently chatting with some colleagues about what does happen when a project begins to head south.

First of all, there always seems to be a tendency to blame the outsider. Basically this argument looks something like: "You never got the requirements right (from the customer) / you never delivered correct requirements (from the consultant)"

What does this boils down to is a failure in communication. Now the question from a risk management approach is how one keeps this communication in sync. Based on our discussion we came up with the following:

• Regular status meetings. If your executive sponsor is not at these meetings, schedule regular steering committee updates which should be just the project manager(s), architect(s) and the executive sponsor. They might not need to be weekly, but they must not be optional any of these people. Do not rely on only one side to make these reports.  Everyone must be on the same page. Make sure the sponsor is aware of the key challenges so that there are no surprises.
  
• Obtain consensus and settle the issues quickly and decisively. If there are dissenting opinions about major decisions, get the issue settled once. Don't keep circling on the issue. If there's an issue that just won't go away, get the parties in front of the executive sponsor as I've noted above. Get a final ruling and move on.
  
• Establish change controls. For some reason, no one likes to use these. There's a feeling that these are things to hide behind, rationalize additional cost or bog down the project in extra paperwork. None of these are true. All that's being done here is making sure that all project principals are aware of the change. This establishes responsibility and sets up controls for making sure that things don't get out of control. And I'd imagine that the amount of paperwork involved in a change control is minor compared to having to write the report of why the project failed. Trust me, this is not fun.
  
• Use and establish some sort of project strategy/methodology. I don't care what it is, but make sure a project plan exists and that there is structure in place. There should be a project manager who will make sure that there is a plan to complete the project, but the architect and senior engineers should make sure that there are development standards which must also include documentation!
  

These points are intended to increase communication and decrease mistrust and politics. If the project team meets regularly, tracks what they are doing and how the project changes and has a structure for managing progress and change there is less of a chance of having a post-mortem and more of a chance of documenting the best practices that were done right!