Built on Collaboration

Hi there, I'm an Implementation Consultant at Aconex and previously worked for another collaboration provider, CTSpace (formerly BuildOnline). My role involves working with the lead organizations on a project to determine how the web collaboration tool is set up and configured to best match their project requirements. Project communication and determining which mail types to use is something that comes up on every project (and nearly always causes conflict) so I thought this would be a good topic to cover - I welcome your views!

A core aspect of any web collaboration system is how the project team uses it to communicate. Most web collaboration tools allow the configuration of various project mail types to suit the requirements of the team and the project - most importantly this may involve certain contractual obligations when it comes to how these communications are named and distributed.

Typically, the correspondence the team uses will include things like: Architect's Advice, Site Instruction, RFI (Request for Information), Client Advice etc. Part of the challenge when implementing a new project is getting the team to agree on the various types they really need. Discussions can often become confused as various team members explain how they think the team should communicate. This can easily result in a very long list of mail types, therefore making it difficult for a user to decide which mail type to use and also difficult to locate the various pieces of correspondence after they have been sent.

One approach that works well, and enables a more productive discussion resulting in a more appropriate list of mail types, is getting the team to think about the basics of communication. Sound simple? Well it is. No matter how we communicate (talking, phone, email, SMS etc.) we really only use three methods:

1. Question or Request - Asking for or requesting information from someone
2. Information or Advice - Providing information or advice to someone
3. Instruction or Direction - Telling someone to do something

You can probably see where this is going. So for example, an RFI is obviously a question. A Payment Claim would be a request. A Bulletin would be information. Thinking in this way can help reduce duplication, confusion and it also helps document the processes that are invariably involved.

A typical process often begins with a question (e.g. an RFI). Obviously, a question requires a response and so this may come in the form of advice (e.g. PM Advice, Contractor Advice) or a more formal instruction (e.g. Contract Instruction, Principal's Direction). Getting back to the basics also forces us to think about 'closing the communication loop'. So for every request or question, there should be a corresponding response to answer (close) the question.

Terminology is also important where certain words like approval or notice may have contractual implications. But, whatever words are used the team should always understand what mail types should be used and when. Closing the loop must be inherent in this understanding otherwise communication routes will fall apart, leading to mistakes, delays and cost overruns. All this must be documented clearly and concisely and this is where agreeing on processes at the start of the project becomes crucial.

We are all exposed to communications from a multitude of sources and it's all too easy to become bogged down and to suffer from the proverbial 'information overload'. Looking at the basics of communication focuses the team on what's really important and it may even help us communicate more effectively in the world outside our projects.

Labels: Good practice