After my previous posts on this topic (see 1, 2 and 3), Duncan Mactear of 4Projects and I formed a two-man NCCTP fact-finding delegation to the latest meeting of the CICA Major Architects IT Group, held at Foster’s head office in Battersea, London. Around the table we faced representatives from Foster’s, RHWL, Sheppard Robson, Broadway Malyan and BDP, plus the CICA’s own Erik Winterkorn. What did we learn?
- Problems arise when extranets are implemented too late – after project data standards have already been set, or when a substantial amount of design work has already been undertaken. Standards can help, but too often they take up time, and they aren’t a work-winning issue.
- “Extranets benefit the client and the project, but not the architect“
- Larger architects’ practices often have established, sophisticated internal drawing management and/or quality assurance systems; adding an extranet to the mix can mean duplication of many routine processes. One architect said he regarded the extranet as a system to be used for managing published data, while his internal system was used for ‘work in progress’. For smaller practices, however, it was recognised that an extranet could form the basis of a reliable file management system – so long as they fully understood what happens at the end of a project (ie: the need to obtain a full project archive detailing all their inputs to the project).
- “It’s not just about managing the 20% of drawings we produce, it’s about reproducing the 80% that we need to look at for co-ordination purposes. We have to print them out and then absorb the costs.” Which brought us neatly to red-lining….
- “Red-lining is a pain.” … “We don’t just make a few comments, we bleed over drawings!” … “It’s almost impossible with a mouse, and digital pen devices and tablets are an expensive extra.” … “We would need larger screens but they are so expensive … and the screen resolution isn’t good enough …” “We’ve tried whiteboarding but you need back projection to make it work because of the shadows”. … One firm described how teams print out their drawings, mark them up by hand and then “get a monkey to enter them onto the extranet system“. Often an architect’s feedback would take the form of a detailed sketch, not just a minor amendment, which would need to be scanned back into the system.
- “It’s easier if you are engaged on a programme of work, a framework for a single client – more difficult if you are working for a single client procuring a one-off project.”
What did I learn from all this? Well, it was clear that some comments were influenced by experience with collaboration systems of low levels of sophistication, or by experience on projects started when extranet functionality was less advanced than it is today. Also, some of the vendors and their project team partners have become more adept at implementing the systems in their projects at the right time and in the right way – several of the apparent failings were not due to the technology per se, but to inappropriate processes or to people issues (training, etc).
I think the meeting was very worthwhile. We gathered the opinions of an influential group of project team members, but they offered just one perspective. It might also be useful if we could repeat the exercise with some of the other CICA groups (eg: consulting engineers, contractors, clients).