Email and CAD have revolutionised information exchange, but unless everyone is using the same system, technology can create more problems than it solves
All of us have experienced the frustrations caused by not being able to print attachments to emails or having lots of ZZZs come out when you do. Although I rarely print out drawings, I hear stories about CAD models, drawn to different baselines and origins by different team members, which then have to be redrawn if they are to be used. In litigation, it is always surprising how different members of the team often use different procedures for identifying changes to previous drawings. Email and CAD systems have revolutionised information exchange, but have introduced a mire of new problems.

The government has funded research into this area, and drafts of the fruits of this research are starting to emerge in the form of the Project Information eXchange (PIX) Protocol Tool Kit. This essentially comprises three documents:

  • a team capabilities review questionnaire

  • a project leader checklist

  • a client's guide and checklist.

The main purpose of the client's guide is to explain to the employer what they stand to gain by agreeing a procedure for information exchange at the outset. It talks about "the shared power structure" on projects and the importance of the client initiating the process of information integration. If these matters are left for negotiation by individual team members, "the result can be a political process that depends on the relative power of the parties involved". It notes that negotiation could result in the adoption of the "lowest common denominator", since the IT standards of the weakest member of the team may define what can be adopted on the project.

The guide suggests that the client, along with its project leader, produce a draft template for an information exchange policy. This might be a step too far for many clients, who seem to find it difficult to put together a brief for their projects. So as with the brief, the onus for producing the template could fall to the project manager or design team leader. The draft protocol recognises this by defining specific guidance for the project leader.

The next piece of the jigsaw is the questionnaire, which is to be sent out to the members of the design team for completion. It asks about their project information production and distribution policies, document numbering systems, email distribution policies and the capabilities of their hardware and software systems. Although laborious to complete first time round, this should become a standard document that can be updated routinely and produced quickly when requested. The protocol suggests that if a formal selection procedure is used, the questionnaire be used as part of that process.

Producing a template for information exchange might be a step too far for clients who find it hard to write a brief for their projects

The client or project leader must then appraise the team's responses and produce a draft PIX protocol for the project. This might require individual team members to "upgrade" some of their procedures in order to match those of other members of the team. This has to be a matter for negotiation but often such upgrades are possible at a minimal cost, or for free, and they ensure that a project standard can be established. The final version of the PIX protocol then needs to be agreed: from drawings, sizes and scales, drawing tiling systems, drawing issue processes and conventions, standard revision numbering schemes for documents and so on.

The PIX protocol also enters into more traditional project management agendas by dealing with communication channels and demanding a project directory for all firms involved on the project.

The final goal of the protocol is to provide the client with a coherent set of project documentation relating to the building, in a format that assists the long-term asset management of the facility.