Wikis and AEC collaboration

Building Information Modeling (BIM) is the starting point of a contributed article to AECbytes.com. In Enterprise Wiki: An Emerging Technology to be Considered by the AEC Industry, Ondrej Kalny likens the information-sharing approach of BIM to the wider need for collaboration within a typical AEC project team, using a ‘hub and spokes’ diagram that will be very familiar to anyone who has considered using a ‘project extranet’ platform over the past few years.

Somewhat optimistically, he then suggests: “Wiki, however, operates on a more general set of data when compared to BIM and can readily address most of the communication problems faced by AEC professionals.”

I have been a long-time Wiki enthusiast, both domestically (as a Wikipedia editor, for example, since 2003) and professionally (my employer, BIW, uses Wikis on its intranet and is looking to extend their use), but I do not yet see Wiki becoming a mainstream technology within construction teams – particularly when the AEC industry has only, perhaps grudgingly, begun to adopt construction collaboration (aka ‘extranet’) technologies – a type of system he seemingly almost completely overlooks in his article.

‘The Basics of Enterprise Wiki’

Reading Kalny’s Wiki definition, he describes functionality that is already available within most industry-strength AEC collaboration systems: secure access, links to documents and images, email functionality, categorisation of information, audit trails, etc.

Look at his claim: “Compared to other content management systems, wiki lets users easily gather all the up-to-date information and correspondence pertinent to a project within one central location“. Substitute ‘wiki’ with ‘extranet‘ and you have a succinct definition of a technology already tried, tested and trusted on thousands of projects in the US, Europe, Australasia and other markets.

He lists some different approaches to deploying Wikis, but none sound as though they could be implemented quickly, particularly where you need to bring together several separate companies, each with their own IT systems, firewalls, etc. However, there are several widely used systems (both locally hosted and delivered as Software-as-a-Service (SaaS) or on-demand applications) – all of which can be quickly configured and rolled-out into a multi-company, multi-disciplinary AEC team in a matter of days. Moreover, they use familiar website principles, have been developed specifically for the AEC industry, with AEC-specific structures, forms, workflows, naming conventions, etc, and are usually supported by professional staff with detailed knowledge of AEC projects.

‘How Wikis Can Help in the AEC Industry’

Kalny then looks at several areas where wikis “are more efficient than the traditional and even some modern (non wiki) communication media” (note use of the word ‘some’). However, while there are undoubtedly some internal efficiency gains to be had, few are relevant to the multi-company project team:

• Wikis can be used to replace email for communication of in house non confidential information with long term information value. – Fine for internal email, but of limited value for a typical project team comprising several different companies. What is needed is a way of communicating that allows all exchanges to be captured within a single repository for future reference – and email is not the answer (see my previous views on email here and here, for instance)!
• Use wiki to track, resolve and archive design issues. (When an employee leaves or retires from the company, the information is still available in the wiki, not lost in a private mailbox.) Currently, once most design information is shared within a project team, it tends to be contained in drawings and specifications which are then shared for comment and subsequent revision, usually with AEC professionals in other companies. Modern collaboration platforms provide sophisticated mark-up and commenting tools, with full audit trails and complete version control, that allow authorised team members to develop designs using familiar computer applications and conventions – not email. And all this information, including all inter-company interaction, can be archived at the end of the project for future reference purposes.
• Use wiki to organize, index and archive completed projects for future reference. As just mentioned, ‘extranet’ systems allow information about completed projects to be organised, indexed and archived. Clients may require a full project archive; supply chain members may just need an archive containing all the data to which they had access during the project.
• Use wiki to develop an in house knowledgebase about standardized design techniques and software. I can think of instances where major clients, contractors and consultants may want to capture internal knowledge for future possible re-use – indeed, I have spoken to the IT team at UK-based architect Feilden Clegg Bradley, which has used wiki to share information within its practice (see the 2005 Sharing Knowledge case study, pp. 32-35). However, particularly for use in construction projects, an ‘in-house knowledgebase’ may become another “island of information” unless the enterprise enables easy sharing of data with its external partners. For example, I have worked with a major UK retailer who uses the web-based BIW standards functionality to share all its corporate standards with its key contractors, subcontractors and suppliers.
• Project owners (such as Departments of Transportation, Departments of Design and Construction, etc.) could use public wiki with restricted editing permissions for outside users to better address questions from designers and community. … Already extensively enabled through ‘project extranets’.
• Wikis are known to significantly reduce meeting times or even eliminate meetings, because most of the issues are resolved directly in the wiki. Same applies to construction collaboration platforms/’extranets’.

Kalny lists several organisations which have used wikis successfully, but admits “their deployment in the AEC industry is still rare,” before urging the AEC community to “put some effort into exploring and realizing the full potential of this emerging technology” – which I support.

As mentioned, BIW has been looking at Wiki functionality for some time and I can think of a few ways in which it could be utilised to support web-based collaboration/’extranet’ technologies (for example, I think some operation and maintenance manuals could easily be reconstituted as wikis). But if teams are struggling with ad hoc email, face-to-face encounters and “little bits of paper and notebook knowledge that ‘someone’ has”, I think wikis may help internally. They should not be seen (yet) as a replacement for properly implemented ‘extranet’ type technologies when it comes to sharing information among multiple companies involved in the delivery of construction projects.