Bip 2207-2010

Building Information Management
A Standard Framework and Guide to BS 1 1 92
Mervyn Richards
Building Informa ? on
Management
A Standard Framework and
Guide to BS 1192
Mervyn Richards
First published in the UK in 2010
By
BSI
389 Chiswick H igh Road
London W4 4AL
© Bri ? sh Standards Ins ? tu ? on 2010
All rights reserved. Except as permi ?ed under the Copyright, Designs and Patents Act 1988, no part of this
publica ? on may be reproduced, stored in a retrieval system or transmi ?ed in any form or by any means,
electronic, photocopying, recording or otherwise, without prior permission in wri ? ng from the publisher.
Whilst every care has been taken in developing and compiling this publica ? on, BSI accepts no liability
for any loss or damage caused, arising directly or indirectly in connec ? on with reliance on its contents
except to the extent that such liability may not be excluded in law.
Whilst every e ffort has been made to trace all copyright holders, anyone claiming copyright should get
in touch with the BSI at the above address.
BSI has no responsibility for the persistence or accuracy of URLs for external or third- party websites
referred to in this book, and does not guarantee that any content on such websites is, or will remain,
accurate or appropriate.
The right of M ervyn Richards to be iden ? fi ed as the author of this Work has been asserted by him in
accordance with sec ? ons 77 and 78 of the Copyright, Designs and Patents Act 1988.
Typeset in Calibri by H elius, www.helius.biz

Printed in Great Britain by Berforts Group, www.berforts.co.uk
Bri?sh Library Cataloguing in Publica ?on Data

A catalogue record for this book is available from the Bri ? sh Library
ISBN 978 0 580 70870 1
Publishing and liability
Th i s gu i d e i n cl u d e s re l e va n t sec ? on s fro m th e a c kn o wl e d ge d gro u p s , bu t a l so i n cl u d e s
n e w i n fo rm a ? o n fro m c u rre n t l e a rn i n g b y th e Co n stru c ? o n P ro j e c t I n fo rm a ? o n Co m m i ? ee
( CP I C) a n d th e B ri ? s h S ta n d a rd s I n s ? t u te ( B S I ) o n a n u m b e r o f re c e n t p ro j e c ts .
Th i s i n fo rm a ? on i s pu bl i sh ed as gu i d a n c e of a ge n e ra l n a tu re , and th e a u t h o r a cc e p t s no
l i a b i l i t y fo r a n y u s e to wh i c h i t m a y b e p u t.
iii
Ackn owl e d ge m e n ts
Produc?on Informa ?on: A code of procedure for the construc?on industry, pu bl i sh ed by
CP I C ( www. CP I C. o rg . u k) .
PIX Protocol Guide and Toolkit, p u b l i s h e d b y t h e B u i l d i n g Ce n tre Tru st. N o w a va i l a b l e fro m
t h e CP I C we b s i te ( s e e a b o ve ) .
Ava n ? , I CT Co l l a b o ra ? ve Wo rki n g: To o l ki t d o c u m e n t s . Co n stru c ? n g E xce l l e n c e 2 0 04. N ow
a va i l a b l e fro m t h e CP I C we b s i te ( s e e a b o ve ) .
M a n y o f th e i m a ge s in th i s gu i d e a re ba sed on th ose fi rst pu bl i sh e d in CP I C ’s Produc?on

Informa ?on: A code of procedure for the construc?on industry ( 2 00 3 ) and BS 1 1 9 2 : 2 007
d o c u m e n ta ? o n o r b y M R 1 Co n s u l ? n g Ltd .
Contents
Preface xv
1 Introduc? on 1
2 Produc ? on informa ? on for the construc? on industry 3

2.1 Roles and responsibili ? es 4
2.2 Common Data Environment (CDE) 4
2.3 Standard Method and Procedure (SMP) 5
3 De fi ni ? ons 7
4 Roles and responsibili ? es 13

4.1 Design Coordina ? on M anager (also known as the
Design M anager on some contracts) 13
4.2 Lead Designer 13
4.3 Task Team Manager 14
4.4 I nterface Manager 14
4.5 Project Informa ? on Manager 14
4.6 CAD Coordinator 14
4.7 CAD Manager 15
4.8 So ? ware versions 16
4.9 CAD checking tools 16
5 The Common Data Environment (CDE) 17

5.1 Func ? onal sec ? ons of the CDE 20
5.1.1 Work- in- progress 20
5.1.2 Shared 24
5.1.3 Published documenta ? on 28
5.1.4 The purpose of the ‘D’ code 29
v
Contents
5.1.5 Archive 36
5.1.6 The distributed CDE for project and
programme 40
5.2 BI M and the Common Data Environment 40
6 Standard Method and Procedure

47
6.1 File naming 47
6.1.1 File iden ? fi ers 47
6.1.1.1 Document/drawing descriptor 48
6.1.1.2 Graphic/model fi le descriptor 48
6.1.1.3 All other documents 49
6.1.2 Field name de fi ni ? ons 50
6.1.2.1 Project 50
6.1.2.2 Originator 51
6.1.2.3 Zone 52
6.1.2.4 Level/loca ? on 59
6.1.2.5 File type 60
6.1.2.6 Role codes 60
6.1.2.7 N umber 63
6.1.2.8 File-iden ? fi er examples 64
6.1.3 File- iden ? fi er metadata 65
6.1.3.1 Status 67
6.1.3.2 Revision 67
6.1.3.3 Version 68
6.2 Origin and orienta ? on 68
6.2.1 Coordinates 68
6.2.2 Spa ? al coordina ? on 69
6.2.3 Building grids 69
6.2.4 Site surveys 70
6.2.5 Alignment of the building to real- world
coordinates 70
6.2.6 Example of building alignment 72
6.2.7 Dimensional consistency 72
6.3 Drawing sheet templates 73
vi
Co n te n ts
6. 3 . 1 D ra wi n g ? tl e b l o ck a ? ri b u te s /ta gs 73
6. 3 . 2 M od el ? tl e b l o ck 74
6. 3 . 3 D ra wi n g s h e e t s i ze s 77
6. 3 . 4 D ra wi n g s h e e t s ca l e s 77
6. 4 La ye r sta n d a rd s 78
6 . 4. 1 Ro l e 78
6 . 4. 2 E l e m e n t/cl a s s i fi ca ? on 79
6 . 4. 3 P re s e n ta ? on 79
6 . 4. 4 D e s cri p ? o n /a l i a s 80
6 . 4. 5 E xtra ct fro m B S 1 1 9 2 80
6. 5 An n o ta ? on 81
6. 5 . 1 Di m en si on s 82
6. 5 . 2 Ab b re vi a ? on s 82
6. 5 . 3 Sym b o l s 82
7 Speci fi ca ? on 85
7. 1 M a ste r s p e ci fi ca ? o n syste m s 86
7. 2 Syste m s o ? wa re 87
8 Implica ? ons of design management 89

8. 1 Ti m e a n d re s o u rce p ro gra m m i n g 90
8. 2 Ap p ro va l o f i n fo rm a ? on 92
Appendix A Master document index template 95
Appendix B Process maps 97

B. 1 Cre a ? n g a m od el fi le 98
B. 2 S h a ri n g a m o d e l fi le 99
B. 3 Co o rd i n a ? n g m od el fi l es 1 00
B. 4 Tra n sfe r o f o wn e rs h i p 1 01
B. 5 Cre a ? n g a d ra wi n g re n d i ? on 1 02
B. 6 D e s i gn te a m s i gn - o ff p ro ce s s 1 03
B. 7 Ap p ro va l ro u te – sta ge 2 1 04
B. 8 Ap p ro va l ro u te – sta ge 3 1 05
vi i
Contents
Appendix C Consultant’s technical systems

ques? onnaire 107
Appendix D Project team member ques? onnaire 109
Appendix E Drawing sheet template 111
Appendix F Measurements and bene fi ts 115

F.1 Project results – overview report 115
F.1.1 Introduc ? on 115
F.2 Key measured impacts 116
F.2.1 I nvestment required 116
F.2.2 Return on investment 116
F.3 Commentary 117
F.3.1 I nvestment required 117
F.3.2 Return on investment 118
F.3.3 Request for informa ? on (RFI ) analysis on
a single core project 119
F.4 Emerging themes 120
F.4.1 Belief 120
F.4.2 Achieving payback on a single project 120
F.4.3 Fixed, single industry- wide Avan ? CDE/SMP
or a fl exible approach? 121
F.4.4 Model fi les and their impacts 121
F.4.5 Level of challenge 122
F.4.6 Increase in quality of informa ? on 123
F.4.7 Consequen ? al bene fi ts 123
F.4.8 Which projects are most likely to bene fi t
from Avan ? ? 124
F.4.9 Bene fi ts and risks of a <100 per cent
Avan ? implementa ? on 124
F.4.10 N eed for ac ? ve, independent support
and coaching 125
viii
Co n te n ts
Appendix G Abbrevia ? ons 127
Appendix H References and further reading 133

?
S ta n d a rd s p u b l i ca on s 133
?
O th e r p u b l i ca on s 134
Appendix I Contact details 135
ix
Co n te n t s
Figures
1: H i gh -l e ve l Co m m o n D a ta E n vi ro n m e n t 18
2 : CD E exp a n d e d d e s cri p ? on 22
3 : E xa m p l e wo rk-i n - p ro gre s s a rch i te cts ’ m o d e l s 24
4: Arch i te cts ’ m o d e l s u p l o a d e d fo r s h a ri n g 26
5 : S h a ri n g m o d e l fi l es 27
6 : Co o rd i n a ? n g m od el fi l es 27
7 : U p l o a d i n g stru ctu ra l m o d e l s 30
8 : Arch i te ct ’s re m o va l o f d u p l i ca te l a ye rs 31
9 : Co n cu rre n t a n d i te ra ? ve u p l o a d s a n d d o wn l o a d s 32
1 0: Cre a ? n g d ra wi n gs fro m s h a re d m o d e l s 34
1 1 : S ta tu s D 37
1 2 : Arch i ve s e c ? o n o f th e CD E 38
1 3 : CD E i n te a m e n vi ro n m e n t 41
1 4: CD E i n p ro gra m m e e n vi ro n m e n t 42
1 5 : Th e B I M d e ve l o p m e n t p ro ce s s 45
1 6 : D e ve l o p m e n t o f i B I M co n te n t 46
x
Co n te n ts
1 7 : E xa m p l e s o f zo n e s 52
1 8 : 3 D m o d e l s th a t re l a te to a zo n e re l a ? n g to a co re 54
1 9 : G ro u n d fl o o r s l a b s , co l u m n s , sta i rs – wa l l s 55
2 0 : S e co n d fl oor a s fi rst – a n d th i rd fl o o r – a s s e p a ra te
re fe re n ce fi l es 55
2 1 : Co m p l e te d a rch i te ctu ra l sta i rca s e co re 56
2 2 : S t ru ctu ra l – fo u n d a ? on s a n d fl oor l i ? as de fi n ed by
stru ctu ra l fra m e a s s e m b l y 56
2 3 : Co m p l e te d st ru ctu ra l sta i rca s e co re 56
2 4: G ro u n d fl o o r d u ctwo rk a n d gro u n d fl o o r ri s e rs +
a rch i te ctu ra l fa b ri c 57
2 5 : D u ctwo rk + a rch i te ctu ra l + stru ctu ra l fo r two
fl oor l i ? s 57
2 6 : Co m p l e te co re a l l d i s ci p l i n e s 58
2 7 : E xa m p l e s o f zo n e s i n a b u i l d i n g 58
2 8 : Ca rte s i a n co o rd i n a te syste m 69
2 9 : B u i l d i n g gri d d e fi ?
ni on 71
3 0 : S i te gri d d e fi ?
ni on 71
3 1 : Al i gn m e n t o f th e b u i l d i n g to th e re a l -wo rl d
co o rd i n a te s 71
xi
Co n te n t s
3 2 : B u i l d i n g gri d a n d s e ? n g o u t p o i n ts 72
3 3 : D ra wi n g s h e e t ? tl e b l o ck 75
3 4: M o d e l fi le 76
3 5 : M od el fi le ? t l e b l o ck 76
3 6 : S o m e sta n d a rd sym b o l s 83
3 7 : Si m p l i fi ed ? m e a n d re s o u rce p ro gra m m e 91
3 8 : Cre a ? n g a m od el fi le 98
3 9 : S h a ri n g a m o d e l fi le 99
40 : Co o rd i n a ? n g m od el fi l es 1 00
41 : Tra n sfe r o f l a ye r o wn e rs h i p 1 01
42 : Cre a ? n g a d ra wi n g re n d i ? on 1 02
43 : D e s i gn te a m a p p ro va l sta ge 1 1 03
44: Ap p ro va l ro u te : sta ge 2 1 04
45 : Ap p ro va l ro u te : sta ge 3 1 05
xi i
Contents
Ta b l e s
1: De fi ni ? on of terms 7
2: Assigned roles 15
3: Project codes 51
4: Example of originator codes 51
5: Level codes 60
6: File types – for drawings and models 61
7: File types – for documents 61
8: Role codes (from BS 1192) 62
9: Status codes 66
10: Examples for purpose of issue 67
11: Se ? ng out a building grid 72
12: Drawing sheet sizes 77
13: Drawing sheet scales 77
14: Example of layer name codes 78
15: Presenta ? on codes from BS 1192 79
16: Approvals stages for a model fi le 92
xiii
Co n te n t s
1 7 : M D I te m p l a te 96
1 8 : E xa m p l e l i st o f a b b re vi a ? on s 127
xi v
P re fa c e
B ri ? sh S ta n d a rd B S 1 1 9 2 : 2 00 7 , Collabora ?ve produc?on of architectural, engineering and

construc?on informa ?on — Code of Prac?ce wa s pu bl i sh e d to p ro vi d e a sta n d a rd and
‘b e st- p ra c ? ce ’ m eth o d fo r th e d e ve l o p m e n t, o rga n i za ? on a n d m a n a ge m e n t o f p ro d u c ? on
i n fo rm a ? o n fo r t h e co n stru c ? o n i n d u st ry.
A ‘sta n d a rd ’ i s re q u i re d , s o th a t a l l o ffi ce s , te a m s o r te a m m e m b e rs ca n p ro d u c e i n fo rm a ? on
to th e sa m e fo rm and q u a l i ty – en a bl i n g it to be u sed and re u s e d wi th o u t c h a n ge or
i n te rp re ta ? on . I f a n i n d i vi d u a l , o ffi c e o r te a m c h a n ge s th e sta n d a rd wi th o u t a gre e m e n t , i t
wi l l h i n d e r co l l a b o ra ? o n a n d d o c u m e n t s h a ri n g. ‘M y sta n d a rd ’ i s n o t a cc e p ta b l e i n a te a m
wo rki n g e n vi ro n m e n t.
Co n stru c ? o n P ro j e ct I n fo rm a ? o n Co m m i ? e e ( CP I C) d e fi n e s p ro d u c ? o n i n fo rm a ? o n a s ‘th e
i n fo rm a ? o n p re p a re d b y d e s i gn e rs th a t i s p a s s e d to a co n st ru c ? o n te a m to e n a b l e a p ro j e ct
to b e co n stru c te d ’. I t i s i n d e p e n d e n t o f wh o e m p l o ys th e d e s i gn e rs a n d wh i c h p ro cu re m e n t
ro u te o r fo rm o f co n tra c t i s u s e d . P ro d u c ? o n i n fo rm a ? o n i s th e o u t p u t o f t h e d e s i gn te a m
a n d s p e c i a l i st co n tra cto rs , a n d i s co n ve ye d b y d ra wi n gs , s p e ci fi ca ? on s a n d bi l l s of q u a n ? ty
or sch e d u l e s of wo rk. In a Bu i l d i n g I n fo rm a ? on M od el l i n g ( BI M ) wo rki n g e n vi ro n m e n t
th e d e l i ve ry m a y ta ke th e fo rm o f t h re e - d i m e n s i o n a l m od el s wi th a s s o c i a te d i n fo rm a ? on
a ? a ch e d b y d i re c t a ? ri b u ? on or popu l a ? o n fro m a d a ta b a s e .
U n l e s s th i s i n fo rm a ? o n i s co m p l e te , a c cu ra te , we l l stru ct u re d a n d co o rd i n a te d , i t wi l l n o t b e
e ff ?ec ve a n d – n o m a ? e r h o w go o d t h e d e s i gn – i t wi l l n o t b e s a ? sfa c to ri l y re a l i ze d o n s i te .
Po o r p ro d u c ? o n i n fo rm a ? o n ca u s e s d e l a ys , e xtra co st s a n d p o o r q u a l i t y, wh i c h i n tu rn gi ve
ri s e to d i s p u te s o ve r wh o i s re s p o n s i b l e fo r t h e p ro b l e m s .
G ood p ro d u c ? on i n fo rm a ? on i s th e re fo re vi ta l l y i m p o rta n t to th e s u c ce s s o f th e p ra c ? ce ,
p ro j e c t a n d d e l i ve ry o f th e m a j o r co n t ra c ts h a n d o ve r d o cu m e n t re q u i re d fo r t h e s u cc e s sfu l
m a n a ge m e n t a n d m a i n te n a n ce o f t h e a s s e t th ro u gh o u t i ts l i fe .
BS 1192 is n ot on l y a m ea n s o f d e l i ve ri n g th e two - d i m e n s i o n a l d ra wi n g i n fo rm a ? on th a t
is re q u i re d fo r a p ro j e c t, bu t it is a l so th e ba si s on wh i ch i n fo rm a ? on m a n a ge m e n t and
xv
P re fa ce
t h e d e l i ve ry o f th e th re e - d i m e n s i o n a l I n te gra te d B u i l d i n g I n fo rm a ? o n M o d e l ( i B I M ) a n d i ts
a s s o c i a te d d a ta s h o u l d b e d e l i ve re d .
We h a ve co m p i l e d t h i s gu i d e to gi ve m o re d e ta i l e d i n fo rm a ? o n on th e sp e ci fi c e l e m e n ts o f
th e p ro ce s s s u p p o rte d b y th e sta n d a rd .
xvi
1 I ntroduc ? on
This guidance document has been produced using background informa ? on on procedures
that have been taken from successful applica ? on in the construc ? on industry, and has been
developed in conjunc ? on with the management processes required to manage informa ? on
through the project lifecycle. The adop ? on of such procedures will allow the move from
a document- centric environment to an informa ? on- centric environment – unlocking the
power of informa ? on technology.
The toolkit has been developed from the computer- aided design (CAD) standards, methods
and procedures of over 70 di fferent companies in the construc ? on industry who work
in collabora ? ve framework environments, Construc ? on Project Informa ? on Commi ?ee
(CPI C), its consultants and steering groups, Construc ? on Industry Research and Informa ? on
Associa ? on (CI RIA) research documents (funded by the DTI), and many other individual
prac ? ? oners.
It also takes account of BS 1192, ISO 13567, CPI C’s Produc?on Informa ?on: A code of
procedure for the construc?on industry, Uniclass classi fi ca ? ons and the PIX Protocol Toolkit,
developed by the Building Centre Trust. All of these documents are now available on the
CPIC website.
This procedure relies heavily on industry documenta ? on, research and prac ? cal applica ? on
within live projects. The projects range from simple housing developments to the value of a
few hundred thousand pounds to the most pres ? gious mul ? - billion- pound projects.
The knowledge and experiences of those prac ? ces have been measured and published over
the past 15 years, showing both bene fi ts and blockers to the applica ? on of collabora ? ve
working. For the most part, such innova ? ve applica ? ons have been successful, with the
bene fi ts far outweighing the e ffort employed.
Recommenda ? on: these procedures apply to all organiza ? ons, from small
consultancies and small projects to major contractors and large-scale projects.
1
2 Produc ? on informa ? on
for the construc ? on
industry
Research has shown that inaccurate, incomplete and ambiguous produc ? on informa ? on
causes many problems on site. The impacts on the project are late delivery and increased
cost – es ? mated to amount to approximately 25–30 per cent of the construc ? on cost,
and a ffec ? ng each member of the supply chain. E ffec ? ve communica ? on of high- quality
produc ? on informa ? on between designers, manufacturers/fabricators and constructors is
therefore essen ? al for the sa ? sfactory realiza ? on of construc ? on projects.
The evidence shows that improving the quality of produc ? on informa ? on reduces the
cost of developing that informa ? on, as well as the incidence of site- quality problems,
leading to signi fi cant savings in the cost of construc ? on work. The 2003 CPIC publica ? on
Produc?on Informa ?on: a code of procedure for the construc?on industry quotes an 18 per
cent reduc ? on in drawing costs and an overall cost–bene fi t of at least 10 per cent of the
contract   sum.
Further tes ? ng on live projects has demonstrated that, when applied properly,
standard methods and procedures provide savings and improved pro fi t for each
o ffi ce and all members of the supply chain. To change or ‘simplify’ any element of
the procedure – without an understanding of the impact of that change – puts the
improvements at risk, and at best will only maintain the ‘status quo’.
In addi ? on, the processes and procedures o ffer the poten ? al for greater saving in the
delivery of the lifecycle informa ? on and the asset management data to be used and upd ated
throughout the life of the facility or u ? lity.
There are three speci fi c areas that must be addressed to enhance the produ c ? on informa ? on
process. These are:
• roles and responsibili ? es;

• Common Data Environment (CDE); and
• Standard M ethod and Procedure (SM P).
3
Produc ? on informa ? on for the construc ? on industry
2. 1 Rol e s a n d re spon si bi l i ? es
Ownership of data along with the clear de fi ni ? on of responsibility is a crucial part of any
design delivery. This document de fi nes speci fi c roles together with associated responsibili ? es
to aid the process.
2. 2 Com m on Da ta E n vi ron m e n t ( CDE )
The CDE is a procedure for managing the itera ? ve development of the design documenta ? on
to achieve full integra ? on and spa ? al coordina ? on of the data/informa ? on from all
par? cipants and o ffi ces, and from all originators within project supply chains.
These procedures are not restricted to the development of the design team informa ? on.
The procedure must be used throughout the process of delivery and into the management
of the asset itself. The subcontractor and fabrica ? on design teams must deliver the fi nal
‘virtual construc ? on’ model represen ? ng the actual construc ? on elements. In turn the
contractor, commissioning agents and suppliers must also use the CDE to complete the
database of informa ? on required for asset management.
The procedure also ensures that data/informa ? on is checked and issued fi t for a speci fi c
purpose at a number of de fi ned ‘gates’ such that it may be used for the stated purpose.
Finally, the procedure allows for the dissemina ? on of the signed- o ff informa ? on ‘fi t for
detail design development’ or ‘fi t for construc ? on’, and the collec ? on of all relevant data/
informa ? on needed to deliver the project handover document for the administra ? on,
maintenance and deconstruc ? on of the fi nal product.
These processes were well de fi ned and managed in a paper- based fi ling system, but with
the adop ? on of new electronic technologies, the need for good management has been
overlooked and the systems have not been replaced.
The procedures outlined in this document apply to all approaches to project modelling,
including:
• coordina ? on of the project model fi les in 2D as they develop;

• coordina ? on of the project model fi les in 3D as they develop;
• produc ? on of 2D drawings from 3D models;
4
Produc ? on informa ? on for the construc ? on industry
• produc ? on of 2D drawings using 2D CAD dra ? ing so ? ware;

• the collec ? on, management and dissemina ? on of all relevant construc ? on documenta ? on;
• the management of all spreadsheets, text fi les, etc. as extracts from the model;
• applica ? on of the process and procedures for the delivery of the ‘integrated Building
Informa ? on M odel’ (iBI M ) and all relevant handover documenta ? on; and
• applica ? on and coordina ? on of the speci fi ca ? ons and cos ? ng requirements.
2.3 Standard Method and Procedure (SMP)

This document also de fi nes a Standard M ethod and Procedure (SM P) that should be used
for developing and presen ? ng the design informa ? on and documenta ? on for construc ? on
projects. Organiza ? ons should de fi ne standards consistent with BS 1192.
When commencing a project that will involve the produc ? on of CAD/BIM informa ? on, it is
cri ? cal for each o ffi ce to adopt the approaches outlined in this document, when using any
so ? ware solu ? on for producing 3D or 2D models and 2D drawings.
To implement this SM P, the following eight principles should be followed:
• Roles, responsibili ? es and authori ? es: agree roles, responsibili ? es and authori ? es – in
par? cular, the responsibility for design coordina ? on of the various design disciplines.
• Common Data Environment (CDE): adopt a CDE approach and allow informa ? on to be
shared between all members of the o ffi ce team. Some form of document repository –
for example, a project extranet or electronic document management system – will need
to be used when collabora ? ng on a project.
• Document management/electronic data management (DM /EDM ): agree a suitable
informa ? on hierarchy that will support the concepts of the CDE and the document
repository.
• File- naming conven ? on: adopt fi le- /document- naming conven ? ons, so that relevant
informa ? on can be iden ? fi ed using fi le names. Agree the reference codes for ‘status’
and ‘revision’ of fi les and documents, but these are not part of the fi le name.
• Origin and se ? ng out: agree the origin of the coordinate system and method for spa ? al
coordina ? on.
• Drawing sheet templates: agree the ? tle block, a ? ributes, paper sizes and produc ? on
scales. M ake model fi le and drawing templates available including: ? tle blocks, layer
names, text styles, line types, etc. for consistent delivery of the fi nal construc ? on
informa ? on.
5
P ro d u c ? o n i n fo rm a ? o n fo r th e co n stru c ? o n i n d u st ry
• La ye r sta n d a rd : a gre e a ‘l a ye r- n a m i n g sta n d a rd ’ ba sed on BS 1192 th a t i n cl u d e s a
cl a s s i fi ca ? o n syste m . B S 1 1 9 2 re co m m e n d s th e u s e o f t h e U n i c l a s s cl a s s i fi ca ? o n syste m .
• An n o ta ? o n : a gre e a sta n d a rd fo r a b b re vi a ? o n s , te xt d i m e n s i o n s a n d sym b o l s a n d e n s u re
a l l m o d e l s a re d ra wn to s ca l e a n d d i m e n s i o n e d a s s u ch .
E a ch o rga n i za ? o n i n vo l ve d m u st a d o p t t h e p ro j e ct S M P, a n d a l l re l e va n t p a r ? e s ( cl i e n t , d e s i gn
co n s u l ta n ts , su ppl y ch a i n p a rtn e rs , e tc. ) m u st a gre e and co m m i t to i t. E a ch o rga n i za ? on
s h o u l d p ro d u c e th e p ro j e c t S M P a t th e p re - co n tra ct sta ge a n d i n cl u d e i t i n th e p ro cu re m e n t
d o c u m e n ts a n d co n t ra cts .
6
3 De fi ? ni on s
Ta b l e 1 is a s h o rt ve rs i o n of th e de fi ?
ni on s to be u sed wh e n re a d i n g and a p p l yi n g th i s
d o cu m e n t .
Ta bl e 1 : D e fi ? ni on of term s
Te rm De fi ?
ni on
2D Two d i m e n s i o n a l .
2 D d ra wi n g A 2 D d ra wi n g co n ta i n s a vi e w o f a m o d e l th a t i s
re fe re n c e d i n to a ‘d ra wi n g s h e e t te m p l a te ’ ( b l a n k
d ra wi n g a n d ? tl e b l o ck) . S u c h d ra wi n gs m u st
a l wa ys b e co n s i d e re d to b e sta ? c d o cu m e n ts , a s
th e y a re d ra wi n g re n d i ? o n s o r s n a p s h o ts o f th e
d e s i gn ’s m o d e l fi l es.
2D m od el M o d e l wi th e n ?? e s h a vi n g 2 D p ro p e r ? es.
S u c h m o d e l s m u st a l wa ys b e co n s i d e re d to b e
d yn a m i c , a s th e y wi l l b e m a d e u p o f ‘m o d e l fi l es’
th a t a re ‘xre f ’ o r ‘re fe re n ce ’ fi l es.
3D Th re e d i m e n s i o n a l .
3 D m od el M o d e l wi th o b j e c ts h a vi n g 3 D p ro p e r ? es.
S u ch m o d e l s m u st a l wa ys b e co n s i d e re d to b e
d yn a m i c, a s th e y wi l l b e m a d e u p o f ‘m o d e l fi l es’
th a t a re ‘xre f ’ o r ‘re fe re n c e ’ fi l es.
3 D vi s u a l i za ? on 3 D i m a ge s fro m th e 3 D CAD m o d e l o r a vi rtu a l
re p re s e n ta ? o n o f th e b u i l d i n g o r fa c i l i ty to b e
co n stru cte d ; u s e d fo r vi s u a l i z i n g th e p ro j e ct.
a ? ri b u te M o d e l l i n g co n c e p t u s e d to re p re s e n t p ro p e r ? es
o f, a n d re l a ? o n s h i p s b e twe e n , e n ?? es.
a u th o r O ri gi n a to r o f m o d e l fi l e s , d ra wi n gs o r d o c u m e n ts .
BI M B u i l d i n g i n fo rm a ? o n m o d e l l i n g.
CAD Co m p u te r-a i d e d d e s i gn .
7
De fi ?
ni on s
Ta bl e 1 : De fi ?
ni on of term s ( con td )
Term De fi ? ni on
CAD sta n d a rd S ta n d a rd u s e d to p ro d u c e CAD m o d e l s th a t wi l l
i n c l u d e o ri g i n s , u n i ts , l a ye ri n g co n ve n ? on s, l i n e
sp e ci fi ca ? on s, fi l e - n a m i n g co n ve n ? o n s , d ra wi n g
n u m b e ri n g , e tc.
CAD vi e we r So ? wa re u s e d to vi e w CAD m o d e l s o r re n d i ? on
p ri n t fi l e s wi th o u t re q u i ri n g th e u s e r to h a ve th e
so ? wa re th a t p ro d u ce d th e m o d e l .
CAD D Co m p u te r-a i d e d d e s i g n a n d d ra ? i n g. A co m p u te r-
a i d e d d e s i gn s o ? wa re a p p l i ca ? o n wi th a d d i ? on a l
fe a tu re s s u c h a s th e a b i l i ty to o u tp u t d ra wi n gs
fro m th e s o ? wa re .
CAWS Co m m o n Arra n ge m e n t o f Wo rk S e c ? on s
p u b l i s h e d b y CP I C fo r u s e i n s p e ci fi ca ? on s a n d
bi l l s of q u a n ?? es.
CC Co n stru c ? o n Co n fe d e ra ? on .
CD E Co m m o n D a ta E n vi ro n m e n t. A s i n gl e s o u rc e o f
i n fo rm a ? o n fo r a n y g i ve n p ro j e c t, u s e d to co l l e c t,
m a n a ge a n d d i s s e m i n a te a l l re l e va n t a p p ro ve d
p ro j e c t d o cu m e n ts . A CD E ca n b e sto re d o n a
p ro j e c t s e rve r o r e xtra n e t.
CD M Co n stru c ? o n ( D e s i gn a n d M a n a ge m e n t)
[ Re gu l a ? on s] .
CI AT Ch a rte re d I n s ? tu te o f Arc h i te c tu ra l Te c h n o l o gi sts .
CI B SE Ch a rte re d I n s ? ? tu o n o f B u i l d i n g S e rvi c e s
E n gi n e e rs .
CI /S fB Th e U K ve rs i o n o f th e Co n stru c ? o n I n d e xi n g
Cl a s s i fi ca ? o n Syste m fo r Co n stru c ? o n p ro d u c ts
a n d e l e m e n ts – a ve rs i o n o f th e SfB c l a s s i fi ca ? on
syste m o ri g i n a ? n g fro m Swe d e n .
CP I Co n stru c ? o n P ro j e ct I n fo rm a ? on .
CP I C Co n stru c ? o n P ro j e ct I n fo rm a ? o n Co m m i ? ee.
CS G Co n stru c ? ve S o l i d G e o m e try re p re s e n ta ? on . A
CS G o b j e c t i s co m p o s e d fro m sta n d a rd p ri m i ? ve s
u s i n g re gu l a ri ze d B o o l e a n o p e ra ? o n s a n d ri gi d
mo ? on s.
8
De fi ni ? ons
ni on of te rm s ( con td )
Te rm De fi ?
ni on
data Informa ? on not yet interpreted or analysed.
DGN File extension for Bentley Systems’ M icroSta ? on

and I ntergraph’s I nterac ? ve Graphics Design
System CAD programs.
document management Technology that provides more control and be ?er

management of computer-generated fi les. It
adds enhanced fi le security, revision control, fi le
descrip ? ons, extended fi le names and user access
privileges to the basic fi le directory management
features of the computer opera ? ng system.
DM S Document management system.
document repository En ? ty including an electronic data management

(EDM ) system, project extranet or folder
hierarchy on a Windows fi le server.
documenta ? on Sec ? on of the CDE for drawing rendi ? ons that

have been approved as fi t for a speci fi c purpose –
for example, fi t for construc ? on.
drawing ? tle block Framework – o ?en containing the project team’s

logos – to show the drawing ? tle, number,
purpose of issue, status and revision informa ? on.
DWF Proprietary AutoCAD web format.
DWG Proprietary AutoCAD fi le format.
DXF File format used mainly for impor? ng and

expor? ng CAD data between AutoCAD and other
CAD-related programs.
EDM S Electronic document management system.
en ? ty Synonym for object.
FM Facili ? es management.
graphic fi le File format designed speci fi cally for represen ? ng

graphical images.
IAI I nterna ? onal Alliance for Interoperability. N ow

known as Building Smart.
iBI M Integrated Building I nforma ? on M odel
9
De fi ni ? ons
ni on of term s ( con td )
Term De fi ?
ni on
ICE I ns ? tu ? on of Civil Engineers.
ICT Informa ? on and communica ? ons technology.
IFC2x I ndustry Founda ? on Class version 2x.
informa ? on Representa ? on of data in a formal manner

suitable for communica ? on, interpreta ? on
or processing by human beings or computer
applica ? ons.
layer A? ribute given to en ? ? es within CAD fi les

enabling their visibility to be controlled. Further
values may be assigned to the a ? ribute to enable
control of whether it can be edited or deleted.
marked-up drawing Paper or electronic drawing that has been marked

up with comments from other disciplines or the
client.
model fi le N a ? ve CAD fi le that can be a 2D or 3D model.
object Item having state, behaviour and unique iden ? ty –

for example, a wall object.
originator Author of models, drawings and documents.
OS Ordnance Survey.
PDF Portable Document Format. A standard document

format from Adobe Systems for transfer between
di fferent computer systems.
purpose of issue States the purpose for issuing the document.
reference fi le CAD model fi le associated or linked with another

CAD model fi le. Also referred to as an xref.
rendi ? on Documenta ? on in a form enabling the

informa ? on to be viewed, printed and marked
up. For example, PDF and DWF fi les are
documenta ? on consis ? ng of snapshots of 2D
drawings. Such rendi ? ons are generated each
? me the drawing is prepared for ‘sharing’ at
regular milestones.
revision Used to iden ? fy revisions of documents, drawing

and model fi les.
10
De fi ?
ni on s
Ta bl e 1 : De fi ? ni on of te rm s ( con td )
Te rm De fi ? ni on
RI BA Ro ya l I n s ? tu te o f B ri ? s h Arc h i te cts .
R I CS Ro ya l I n s ? ? tu o n o f Ch a rte re d S u rve yo rs .
S I Syste m Le Systè m e I n te rn a ? o n a l d ’ U n i té s . [ I n te rn a ? on a l
syste m o f u n i ts ]
SM P S ta n d a rd M e th o d a n d P ro ce d u re .
sta n d a rd fo n t Agre e d s e t o f fo n t typ e s a n d s i ze s to b e u s e d fo r
th e p ro j e c t.
sta n d a rd l a ye ri n g co n ve n ? on Si n gl e l a ye ri n g co n ve n ? o n u s e d b y th e p ro j e ct
te a m .
sta tu s De fi n e s th e ‘ fi tn e s s ’ o f i n fo rm a ? on i n a m od el ,
d ra wi n g o r d o c u m e n t.
TB M Te m p o ra ry b e n ch m a rk.
U n i cl a s s Uni fi e d cl a ssi fi ca ? o n s fo r th e co n stru c ? on
i n d u stry s p o n s o re d b y CC, R I CS, R I B A a n d CI B S E .
Th e c l a s s i fi ca ? o n syste m i s b a s e d o n CI /S fB, CAWS
a n d o th e r re l e va n t d o cu m e n ts .
VP N Vi rtu a l p ri va te n e two rk
xre f/re fe re n c e fi le CAD m o d e l fi l e a s s o ci a te d o r l i n ke d wi th a n o th e r
CAD m o d e l fi l e.
zo n e M a n a ge a b l e s p a ? a l s u b d i vi s i o n o f a p ro j e c t,
de fi n e d b y th e ‘p ro j e c t te a m ’ a s a s u b d i vi s i o n
o f th e o ve ra l l p ro j e ct th a t a l l o ws m o re th a n
o n e p e rs o n to wo rk o n th e p ro j e c t, fl oor pl a n
o r sta i rca s e , e tc . E a ch zo n e o r s u b d i vi s i o n i s a
re fe re n c e fi l e . Wh e n o n e o r m o re re fe re n c e d
fi l e s i s vi e we d , th e fu l l fl o o r p l a n o r s i te p l a n m a y
b e re p re s e n te d . Th i s s u b d i vi s i o n a l s o b e co m e s
i m p o rta n t wh e n u s i n g extra n e ts , a s i t a l l o ws th e
fi l e s to b e ke p t to a m a n a ge a b l e fi l e s i ze .
11
4 Ro l e s a n d re s p o n s i b i l i ? es
At t h e sta rt o f a p ro j e ct , i t i s i m p o rta n t to i d e n ? fy th e ro l e s a n d re s p o n s i b i l i ? e s o f t h e d e s i gn
te a m , a n d o f s p e ci a l i st s u b co n tra cto rs wh o h a ve d e s i gn co n te n t i n th e i r wo rk p a cka ge s .
I t i s a l s o n e ce s s a ry to d e fi n e t h e ro l e s a n d re s p o n s i b i l i ? e s o f i n d i vi d u a l te a m m e m b e rs a s
we l l as th e s ch e d u l e o f re s p o n s i b i l i ? es fo r d e l i ve ra b l e s o f th e o ve ra l l te a m . Th e ? tl e s of
th e m a n a ge rs may d i ff e r, b u t th e i m p o rta n t fa cto rs a re th e o wn e rs h i p , re s p o n s i b i l i ty a n d
a u t h o ri ty.
E xa m p l e s o f t h e te a m m e m b e r ro l e s re q u i re d wi t h i n a l a rge p ro j e c t a re s e t o u t b e l o w.
4. 1 De si gn Coord i n a ? on M a n a ge r ( a l so kn own a s th e De si gn
M a n a ge r on som e con tra cts)
Th e D e s i gn Co o rd i n a ? on M a n a ge r p ro vi d e s a co m m u n i ca ? on s link b e twe e n th e va ri o u s
d e s i gn te a m s and th e co n stru c ? on te a m s . Th e D e s i gn Co o rd i n a ? on M a n a ge r is u su a l l y
p ro vi d e d by th e co n tra c to r, and i n te gra te s th e d e s i gn d e l i ve ra b l e s of th e p ro fe s s i o n a l
d e s i gn e rs , s p e c i a l i st d e s i gn e rs a n d s u b co n tra c to rs a ga i n st t h e co n stru c ? on p ro gra m m e to
e n s u re ? m e l y d e l i ve ry.
4. 2 Le a d De si gn e r
Th e Le a d D e s i gn e r m a n a ge s t h e d e s i gn , i n cl u d i n g i n fo rm a ? o n d e ve l o p m e n t a n d a p p ro va l s .
Th e Le a d D e s i gn e r co n fi rm s th e d e s i gn d e l i ve ra b l e s of th e d e s i gn te a m , e sta b l i s h e s th e
zo n e stra te gy a n d o wn e rs h i p , a n d e sta b l i s h e s th e st ru c tu ra l gri d a n d fl o o r l e ve l s . Th e Le a d
D e s i gn e r s i gn s a n d a p p ro ve s th e d o c u m e n ta ? o n fo r d e ta i l d e s i gn co o rd i n a ? o n a n d p ri o r to
p a s s i n g to ‘s h a re d ’. I n s m a l l a n d m e d i u m - s i ze p ro j e ct s , a Le a d D e s i gn e r co u l d b e t h e s a m e
p e rs o n a s th e D e s i gn Co o rd i n a ? o n M a n a ge r.
13
Ro l e s a n d re s p o n s i b i l i ? es
4. 3 Ta sk Te a m M a n a ge r
Th e Ta s k Te a m M a n a ge r i s re s p o n s i b l e fo r th e p ro d u c ? on o f d e s i gn o u tp u t th a t fa ci l i ta te s
th e p ro d u c ? on of su ch e l e m e n ts of th e d e s i gn th a t re l a te to th a t ta s k. Ta s ks a re o ? en
d i s c i p l i n e - b a s e d , s o th e Ta s k Te a m M a n a ge r i s u s u a l l y a d i s ci p l i n e h e a d , re s p o n s i b l e to th e
Le a d D e s i gn e r.
4. 4 I n te rfa ce M a n a ge r
An I n te rfa ce M a n a ge r s h o u l d b e a p p o i n te d fo r e a ch ta s k. I n a s p a ? a l s e n s e , i f m o re s p a ce i s
re q u i re d – fo r e xa m p l e , t h e sta i rca s e – th e S ta i rca s e I n te rfa c e M a n a ge r wi l l h a ve to d i s cu s s
t h e n e e d fo r i n cre a s i n g th e sta i rca s e a re a , a n d n e go ? a te wi th th e I n te rfa ce M a n a ge r( s ) fo r
e a ch of th e fl o o rs s e rve d by th e sta i rca s e to d i s cu s s th e i m p a ct o f m a ki n g fu rth e r s p a ce
a va i l a b l e . Th e I n te rfa ce M a n a ge r wi l l be re s p o n s i b l e to b o th th e Ta s k Te a m M a n a ge r a n d
th e Le a d D e s i gn e r.
4. 5 Proj e ct I n form a ? on M a n a ge r
Th e P ro j e ct I n fo rm a ? on M a n a ge r p ro vi d e s th e fo ca l poi n t fo r all fi le and d ocu m e n t
m a n a ge m e n t i ssu es in th e p ro j e ct . H e /s h e a l so e n s u re s th a t all i n fo rm a ? on is co m p l i a n t
wi th sta n d a rd s and th a t e a ch m od el or fi le h a s been s i gn e d o ff fi ‘ t fo r p u rp o s e ’. Th i s ro l e
s h o u l d b e re s p o n s i b l e to th e D e s i gn Co o rd i n a ? o n M a n a ge r.
4. 6 CAD Coord i n a tor
A CAD Co o rd i n a to r e n s u re s th a t th e re i s a co n s i ste n t a p p ro a c h to p ro j e c t m o d e l l i n g ( 2 D o r
3 D) and CAD i ssu es and p ra c ? ce s a c ro s s th e p ro j e ct . H e /s h e a l so co o rd i n a te s th e p ro j e c t
n eed s fo r IT sol u ? on s, co o rd i n a te s th e a gre e d p ro j e c t CAD ‘sta n d a rd and m eth od ’ and
u p d a te s to th e p ro ce d u re s , a n d a l s o e n s u re s co m p l i a n ce wi th th o s e sta n d a rd s a n d m e th o d s .
Th i s ro l e sh ou l d be re s p o n s i b l e to th e Ta s k Te a m M a n a ge r and th e P ro j e c t I n fo rm a ? on
M a n a ge r.
14
4. 7 CAD M a n a ge r
A CAD M a n a ge r e n s u re s th a t all CAD m od el s and d ra wi n gs a re d e l i ve re d to th e p ro j e ct
u s i n g a gre e d I T s o l u ? o n s , a n d a c co rd i n g to t h e a gre e d p ro j e c t CAD ‘sta n d a rd a n d m e th o d ’
a n d p ro ce d u re s . Th i s ro l e s h o u l d b e re s p o n s i b l e to t h e CAD Co o rd i n a to r.
Re com m en d a ? on : t h e ro l e s , re s p o n s i b i l i ? e s a n d a u t h o ri ? e s o f th e te a m s h o u l d b e
e sta b l i s h e d o n a p ro j e c t- b y- p ro j e ct b a s i s a n d wri ? e n i n to t h e p ro j e ct p ro c e d u re s . S e e
b e l o w fo r d e ta i l s . O n s m a l l e r p ro j e ct s o n e te a m m e m b e r m a y ca rry o u t a n u m b e r o f
ro l e s .
At th e sta rt o f a p ro j e ct , ro l e s s h o u l d b e a s s i gn e d a n d re co rd e d – fo r e xa m p l e , a s s h o wn i n
Ta b l e 2 . Li st a l l co n ta c t i n fo rm a ? o n a ga i n st e a ch ro l e .
Ta bl e 2: Assi gn ed rol e s
Rol e Name
Com p a n y
D e s i gn Co o rd i n a ? o n M a n a ge r
Co m p a n y X Name
Ad d re s s
Em a i l
Te l . /m o b i l e
Le a d D e s i g n e r
Co m p a n y X Name
CAD Co o rd i n a to r
Co m p a n y X Name
Co m p a n y Y Name
CAD M a n a ge r
Co m p a n y X Name
Co m p a n y Y Name
Ta s k Te a m M a n a ge rs
Co m p a n y X Name
Co m p a n y Y Name
P ro j e c t I n fo rm a ? o n M a n a ge r
Co m p a n y X Name
Co m p a n y Y Name
15
E xa m p l e s o f th e re s p o n s i b i l i ? e s re q u i re d wi th i n a l a rge p ro j e ct a re s e t o u t b e l o w.
4. 8 So ? wa re ve rsi on s
Re com m e n d a ? on : b e fo re sta r ? n g th e p ro j e c t, t h e d e s i gn te a m m u st a gre e th e CAD
so ? wa re a n d ve rs i o n s to b e u s e d .
Th e CAD Co o rd i n a to r s h o u l d u s e t h e re s u l ts fro m t h e q u e s ? o n n a i re s i n Ap p e n d i c e s C a n d D
e sta b l i s h wh i ch s o ? wa re i s u s e d b y th e va ri o u s d e s i gn e rs a n d s u p p l y ch a i n te a m s .
As an alterna ?ve, the PIX Protocol Guide and Toolkit should be used to capture the
informa ?on requirements of the client and the CAD and IT capabili?es of the design team
members. For more informa ?on, see th e new CPIC website. An online version of the PIX
Protocol is available from th e new CPIC website ( www. CP I C. o rg. u k) .
4. 9 CAD ch e cki n g tool s
As p a rt of th e c h e c ki n g p ro c e s s fo r CAD /B I M m od el fi l es, u se ch e cki n g so ? wa re fo r
co m p l i a n c e wi t h th e a gre e d sta n d a rd s :
• La ye r n a m e s co m p l y wi t h p ro j e c t sta n d a rd s .
• D i m e n s i o n te xt h a s n o t b e e n ch a n ge d ‘m a n u a l l y ’.
• Ti tl e sh eet a ? ri b u te m e ta d a ta i n fo rm a ? on h a s been co m p l e te d and co m p l i e s wi t h th e
p ro j e ct CD E /S M P o r CAD /B I M sta n d a rd .
Re com m en d a ? on : ca rry o u t re gu l a r a u d i ts , a n d re t u rn to th e i r o ri gi n a to r a n y fi l es
t h a t fa i l wi t h a re p o rt o n n o n - co m p l i a n c e .
16
5 The Common Data
Environment (CDE)
The fundamental requirement for producing informa ? on through a collabora ? ve ac ? vity

is to share informa ? on early, and to trust the informa ? on that is being shared as well as
the originator of that informa ? on. What is needed is a disciplined auditable process that is
transparent and controllable.
The method for managing a project through a Common Data Environment (CDE) is
applicable to all sizes of prac ? ce, and in par? cular it prepares that o ffi ce to be able to work
collabora ? vely. As a standard that is adopted by all, it will help to remove the problem
of having to constantly retrain on each and every project when client standards are to
be applied. If the clients accept the procedures and make them contractual, then these
problems disappear.
The CDE is a means of allowing informa ? on to be shared e ffi ciently and accurately between
all members of the project team – whether that informa ? on is in 2D or 3D, or indeed textual
or numeric. The CDE enables mul ? disciplinary design teams to collaborate in a managed
environment, where the build- up and development of informa ? on follows the design,
manufacturing and construc ? on sequence. A high- level func ? onal view of the CDE is shown
in Figure 1 on page 18 and a detailed descrip ? on is shown in Figure 2 on page 22.
The CDE process also ensures that informa ? on is only generated once and is then reused
as necessary by all members of the supply chain. It also ensures that the informa ? on is
constantly updated and enriched for fi nal delivery as part of the Facili ? es M anagement
(FM ) document.
There are a number of ways and di fferent environments in which the CDE can be used.
Si n gl e d e si gn d i sci pl i n e e n vi ro n m en t, i n The CDE is implemented within the design

th e ori gi n a to r ’s o ffi ce . o ffi ce to manage the team members
producing design informa ? on on a
number of projects.
17
Th e Co m m o n D a ta E n vi ro n m e n t ( CD E )
Figure 1: High-level Common Data Environment

18
The Common Data Environment (CDE)
Ta sk Te a m e n vi ron m en t, co-l oca ted . To manage the mul ? -discipline teams on

single projects.
Proj ect or progra m m e en vi ron m e n t, To manage the Task teams in a mul ? -

co-l oca te d . disciplined and mul ? -project programme
when the teams can be co-located.
Proj e ct or progra m m e n o n co-l o ca te d . To manage the workfl ow and sharing of

informa ? on across a mul ? -disciplined,
mul ? -project programme over the web or
VPN . A virtual team environment.
Figure 1 shows the high- level func ? onal view of the CDE. This would be used in the discipline
or mul ? - discipline team environments that are co- located.
Advantages of adop ? ng such a CDE include:
• ownership of informa ? on remains with the originator, although it is shared and reused;
• shared informa ? on reduces the ? me and cost in producing coordinated informa ? on; and
• any number of documents can be generated from di fferent combina ? ons of model fi les.
If the procedures for sharing informa ? on are consistently used by the design teams,
spa ? al coordina ? on is a by- product of using the CDE processes, and will deliver produc ? on
informa ? on that is right fi rst ? me.
I nforma ? on can subsequently be used for construc ? on planning, es ? ma ? ng, cost planning,
facili ? es management and other downstream ac ? vi ? es.
Coordina ? on should be achieved as a consequence of the detailed design produc ? on

process.
• Some examples of the di fferent kinds of informa ? on that should be available in the CDE
through a project’s lifecycle are shown in sec ? on 5.1.5 of this guide.
• Data within a CDE are fi nely granulated and structured to ease their reuse. It provides
the ability to produce tradi ? onal drawings or documents as views of mul ? - authored data
within the CDE. It also gives greater control over the revisions and versions of that data.
19
• The structured use of a CDE requires strict discipline by all members of a design team
in terms of adherence to agreed approaches and procedures, compared with a more
tradi ? onal approach. The bene fi ts listed above can only be realized with a commitment
to operate in a disciplined and consistent manner throughout a project.
One element not de fi ned in BS 1192 or in this guide is a solu ? on to the problem of
interoperability between the di fferent CAD and Building I nforma ? on M odelling (BI M )
solu ? ons used within a project. Generally the guidance would state that whenever possible
data/informa ? on should be made in the na ? ve format of the solu ? ons being used. In
addi ? on, the project teams should agree on the number of data rendi ? ons required, and
check these rendi ? ons to ensure their interoperability or to understand the limita ? ons of
the solu ? ons they relate to. Example formats are .dwg, .dgn, .nwd, .nwf, .rvt, IFC, aecXM L,
gbXM L, CIS2 and SDN F.
The use of the PIX Protocol templates and ques ? onnaires may help to establish the level of
maturity and the level of interoperability achievable between the partners on any given project.
5.1 Func ? onal sec? ons of the CDE
Although the CDE can be used to hold any type of informa ? on – for example, CAD/BIM
models, drawings and any other associated documents or data – the following sec ? ons
describe the use of the CDE from a CAD/BI M point of view.
There are four sec ? ons of the CDE and ‘gates’, or sign- o ff procedures, that allow data/
informa ? on to pass between the sec ? ons. See Figure 2 on page 22. The naming of the
gates is signi fi cant:
Work in progress to shared – check, reviewed and approved

Shared to published – authorized
Published to archive – remeasured (checked) and verified
5. 1 . 1 Work- in- progress

The work-in-progress (WIP) sec? on of the CDE is where members of the project team carry out
their own work using their company’s so ? ware systems. Such work- in- progress informa ? on
is likely to be stored on their in- house servers, with access to view or change informa ? on
20
limited to the owner and other project team members of that company (see Figure 3 on
page 24).
It is important to understand that within the o ffi ces of individual disciplines it is essen ? al

to maintain the same processes to manage the internal team as those used in the project
environment. This is the WIP process.
The design teams are responsible for the quality of the WI P informa ? on, and should ensure
that appropriate checking and review processes are in place. Therefore each model fi le
will only contain the informa ? on for which each design team is responsible. N ote that the
design teams also include Work Package subcontractors who develop designs based on
consultants’ designs.
CAD informa ? on can be structured into a number of models. A 2D model fi le comprises a

series of layers that represent, for example, a grid, columns or walls, as shown in Figure 27
on page 58.
I n the case of 3D models, the informa ? on is described at the level of objects or elements
that represent, for example, a column, wall, door or window.
Within the WIP, management systems must allow for version control of each update of
the data fi le, and these must be fi led using a ‘M inor Version’ index, e. g. 1.1, 1.2, 1.3, etc.
This is usually indicated as a version number. For data that is s ? ll in its preliminary design
itera ? ons, this is usually indicated as P1.1, P1.2, P1.3, etc.
When the data are shared with the remainder of the external project team, they are transferred
to the shared area, and the revision is updated to a ‘major revision’, e. g. P2 and P3, etc.
When this occurs, the data con ? nue to be updated in the WIP (in the internal system) area,
but the minor versions will be indexed to P2.1, P2.2 and P2.3, etc. un ? l the next shared
milestone.
The version numbering of the fi les is important, as extracts will be taken from the models
during their development to verify material schedules and checks against the cost plan.
This may pass through a number of itera ? ons un ? l the data and informa ? on can be shared
with the other members of the team. The data fi les or extracted fi les (perhaps text fi les or
spreadsheets) will use the naming conven ? ons, and the revision/versioning procedure is
applicable to all.
21
1 3
Figure 2: CDE expanded descrip ? on
22
1 SH ARED 4 PU BLI SH ED DOCU M EN TATI ON
Minor full revisions Major revisions

Th i s system starting at P01 is th e interg er of th e WI P Th e approved revi sioni ng system wil l be al ph abetic, A,
revisi on. B, C etc. Th e u se of the fu l l maj or revi sion indi cates th at
Th erefore P01 . 1 becomes P01 . th e m odel is now a leg al docu ment and wi ll form part of
U prevvi ng i n th e sh ared area wil l be for desi g n th e cl ient’s au dit trail . Th is does not mean th at th e
prog ression, be th at th rou g h coordi nation wi th oth er docu m ents are ready for construction u nless th e statu s
disci pli ne model s or a natural evolu tion of th e desi g n. code is set to A. See below.
Th e owner of th e model is th e only discipl ine th at may
u prev, u pdate or rem ove a model. On each su ccessive su bm issi on to th e cli ent th e alph a
revisi on wil l increase increm entall y.
Status N o al ph a revisi ons sh all be skipped i n th e cl ient’s au di t
Th e statu s i n the SH ARED area may be one of th e trai l. (Th i s excl u des I , O & P, whi ch Tech ni cal Consu l t-
fol lowi ng : ants h ave been i nstru cted to omi t. )
S1 – Fi t for Coordi nati on (with oth er di scipl ine models)
model fi les only – non l itig i ou s Status
S2 – Fi t for I nformati on – Th is statu s is non-l iti g iou s and Data issu ed to th e cli ent as a temporary requ est wi ll be
th erefore i ndicates sh ari ng with tech ni cal consu ltants to issu ed with a D statu s. Th i s i ndicates that al th ou g h
exch ang e information. publ ish ed data, i t m ay not be u sed for constru ction
N ot to be i ssu ed to th e cli ent for i nformation. (See D approval or constru cti on. Th is data wil l not h ave h ad
statu s. ) cli ent si g n off.
D1 – Fit for Costi ng – leg al doc.
S3 – Fi t for I nternal Revi ew and Com ment – mu st be D2 – Fit for Tendor – l eg al doc.
u ndertaken before i ssu e to th e cl ient – non-li ti gi ou s. D3 – Fit for Contract Desig n – l eg al doc.
S4 – Fi t for Constru cti on Approval (RI BA D) D4 – Fit for M anufactu re/Procu rement – leg al doc
Fi t for Constru ction (RI BA E, F & G ) D statu s wi ll u su al ly be a requ est from the cli ent to th e
N on-l itig i ou s i nformation, to be issu ed to th e cl ient for Lead Desi g ner. Th i s data wi ll not be issu ed to th e
fi nal sig n-off statu s. sh ared area, bu t direct to th e cl ient. Th is data wil l not be
u sed for constru cti on approval or constru ction unl ess
issu ed th rou g h th e sh ared area, coordinated and issu ed
in th e correct manner for cli ent sig n off.
2 SH ARED SI G N -OFF AREA
Pu bl ish ed data with fu ll cl ient si gn off wi ll be issu ed:
Area where data is issu ed to th e cli ent. A – N o Com ment – fit for constru cti on.
A cl ient sig n-off area for ch ecking , veri fyi ng and
approving data. Pu bl ish ed data with partial si g n off:
Data wil l normall y be issu ed to th is area in ag reed B – Comment/Parti al sig n off – fi t for constru ction wi th
packag es in li ne with th e desig n prog ramm e as di ctated minor comments from th e cli ent. All m inor comments
by the cli ent. need to be i ndicated wi th a cl ou d and a statement of ‘i n
abeyance’.
AB – As Bu il t.
3 WORK I N PROG RESS
Th e WI P wi ll contai n:
M inor versi ons. Th i s i s th e m inor revisi oning system
starting at P01 . 1 and i ncreasi ng in increments, P01 . 2,
P01 . 3 etc.
Th e statu s of th e model in th e WI P area wil l be set at

S0 (i niti al statu s) .
23
Figure 3: Example work-in- progress architects’ models
5. 1 . 2 Shared

When the models rela ? ng to, for example, the architectural design have reached a status
that is ‘fi t for coordina ? on’, the model informa ? on should be uploaded into the ‘shared’
sec ? on of the CDE, as shown in Figure 4 on page 26.
To be able to move informa ? on to this area, all model fi les will have to have been thoroughly
peer- reviewed, checked and approved, and fi t for a speci fi c purpose. It is also important for
the model fi les to be checked to ensure they conform to the project CAD standard.
The model fi les can now be shared by the whole design team and trade contractor’s disciplines.
The shared sec ? on of the CDE is where informa ? on can be made available to others in a
‘safe’ environment. The early release of informa ? on assists in the rapid development of the
design solu ? on. To allow this to be achieved, the concept of informa ? on ‘status’ has been
adopted.
24
The informa ? on status gives ownership of the data to the design teams, and restricts access
by the construc ? on teams un ? l informa ? on is su ffi ciently coordinated and authorized.
The de fi ni ? on of each status required to assist in the design development process is given
in Table 9 in sec ? on 6.1.3 of this guide. These ‘informa ? on statuses’ should not be confused
with the client/construc ? on authoriza ? on (sign- o ff) status of ‘A’, ‘B’ or ‘C’.
The data shared with status ‘S1 = Fit for Coordina ? on’ should be in the na ? ve CAD format,
DWG or DGN , as model fi les in either 2D or 3D.
All data/informa ? on with status ‘S2 to Sn’ should be produced as documents (electronic
drawings) in DWF, PLT or PDF non- changeable formats. Although speci fi c reference is made
here to CAD formats, the same process can be used for all other types of documents, such
as text reports and spreadsheets.
For a more detailed example of crea?ng model files, see Appendix B.1.
Any member of the project team can use the shared m odel fi les for reference or coordina ? on.
Other design team members can reference the latest versions of models from the shared
sec ? on of the CDE into their WIP areas, as shown in Figure 5 overleaf.
These referenced models can be used as background informa ? on onto which the recipient
can overlay their design informa ? on. See Figure 6 overleaf.
For a more detailed example of sharing model files, see Appendix B.2.
25
The model status is moved to a ‘Fit for Purpose’ status. In this example that is SI ‘Fit for
Coordination’.
Figure 4: Architects’ models uploaded for sharing
26
DOWN LOAD
REFEREN CE
Figure 5: Sharing model fi les
Figure 6: Coordina ? ng model fi les
27
Where the suppor? ng systems allow this to be achieved, model fi les should be referenced.
However, where these systems do not exist, the fi les are downloaded from the shared area
by other design teams. These fi les must never be re- uploaded or changed and uploaded.
When a model fi le is used as background informa ? on by another design team member
(see Figure 7 on page 30), it is important to ensure that this does not result in informa ? on
being duplicated in model fi les – for example, layers in 2D models or objects in 3D models.
Therefore, the team must agree a procedure that ensures informa ? on occurs only once in
the shared area.
For a more detailed example of model file coordina?on, see Appendix B.3.
I n the example shown in Figure 7, the structural engineer has designed the structural
member sizes and takes ownership of the structural column layer. When the structural
engineer uploads this informa ? on into the shared area, the architect’s fi le must be revised
and re-shared to remove the architectural ownership of the columns (see Figure 8 on page 31).
For a detailed example of the transfer of ownership, see Appendix B.4.
I n Figure 9 on page 32, the process of con ? nual uploads and referencing is set, and the
project con ? nues sharing, de fi ning and re fi ning the itera ? ve process to comple ? on. The
task or discipline design managers should control the rate of sharing, specifying through
the review, check and approve stages when data has reached a point where it should be
shared. The managers should set the whole process against an agreed and integrated plan
of delivery or through a ‘master document index’ (see Appendix A).
5. 1 . 3 Publish ed docum enta ?on

The published documenta ? on sec ? on of the CDE contains drawings – and, if agreed by the
project teams, the model fi les – which are snapshots of the shared informa ? on taken at a
speci fi c ? me. They are compiled by referencing the relevant approved model fi les into a
coordinated model fi le and cu ? ng the views and sec? ons from the models. These in turn
are referenced into a drawing sheet template that contains a ? tle box and associated text
a ? ributes. A drawing rendi ? on is then created in a non- changeable format – for example,
28
a PDF or DWF fi le. This drawing rendi ? on will contain a snapshot of the coordinated mul ? -
authored model fi les in the ‘shared’ sec ? on of the CDE, as shown in Figure 10 on page 34.
For a detailed example of crea?ng drawings from models, see Appendix B.5.
Before informa ? on is released into the documenta ? on sec ? on of the CDE and made available
to the wider project team – for example, for procurement or construc ? on – informa ? on
must be checked and approved.
Suitable review and authoriza ? on processes must be de fi ned and rigorously adhered to,
and these should apply equally to Work Package subcontractors’ drawings as well as to
design consultants’ documents.
Approved documents will be given a status of ‘A’ or ‘B’ (or ‘C’ if rejected), as shown in
sec ? on 6.1.3 of this guide.
Where the construc ? on team requires documents for purposes other than construc ? on
(e. g. tendering or procurement) at a ? me prior to their approval for construc ? on, the status
‘D’ is used (also as shown in sec ? on 5.1.4 of this guide). These ‘D’ status documents retain
a preliminary revision reference ‘P1–P n ’.
Once the documents have received sign- o ff status ‘A’ ( fi t for construc ? on), the document
moves to the contractor’s ownership and the revision nota ? on changes to ‘C1–C n ’, to show
that this is a construc ? on document and no longer preliminary informa ? on.
For a more detailed example of approval routes, see Appendices B.7 and B.8.
5. 1 . 4 The purpose of the ‘D’ code

The S0–Sn status codes are used when the informa ? on is being developed and ‘shared’
by the design teams and the specialist subcontractors. The informa ? on is approved for a
speci fi ed use, but is not ‘authorized’ by the client.
29
Figure 7: Uploading structural models
30
Figure 8: Architect’s removal of duplicate layers
31
Figure 9: Concurrent and itera ? ve uploads and downloads
32
33
Figure 10: Crea ? ng drawings from shared models
34
35
The D1–Dn status codes are used when informa ? on is needed by the contractor or client
for a speci fi ed purpose, but is not ‘authorized’ by the client as fi t for construc ? on. These
data and documents must never be used for construc ? on purposes, or to give others an
instruc ? on to construct. Figure 11 shows the use of D status coding.
As shown in Figure 11, the informa ? on is transmi ?ed from the WI P area directly to the
Published Documenta ? on area; it does not pass through the client authoriza ? on process
but goes through the review, check and approve stages.
5. 1 . 5 Archive

The archive sec ? on of the CDE is for inac ? ve or superseded material. Such informa ? on
will provide a history of the project informa ? on transfers, change orders and knowledge
reten ? on, and can be used for other contractual purposes or ‘discovery’ (see Figure 12).
Such an archive may be a physical loca ? on in a fi le system, but in many document repositories
the system automa ? cally manages the archiving process. However, it is important to keep
the history of superseded informa ? on so that a ?er comple ? on of the project, teams can
analyse the project’s development for ‘lessons learned’.
Although the task of managing ‘archive’ informa ? on can be within a document repository,
the team should also consider scheduling data backup at agreed intervals.
I n addi ? on to the auditable tracking of the project history, the archive should also contain
all relevant informa ? on as a handover document for the project lifecycle, including:
• remeasured as built/as constructed and veri fi ed informa ? on;

• as drawings and model fi les;
• change audits;
• asset data;
• health and safety fi le, including Construc ? on (Design and M anagement) regula ? ons
(CDM );
• all relevant opera ? ons and maintenance informa ? on; and
• documenta ? on as speci fi ed in the client’s brief as deliverable. See the PIX Protocol for
collec ? ng the client brief for deliverables.
36
Figure 11: Status D
37
Figure 12: Archive sec ? on of the CDE
38
Download or
reference files
39
5. 1 . 6 The distributed CDE for project and programme

• The diagrams and explana ? ons above show the processes and systems in an ideal world,
but the design team may need to modify them for individual projects.
• For the project management and the design management requirements beyond the
plan of work, for example RI BA Plan of Work Stage D, the processes s ? ll hold.
• I n the distributed ‘Task Team’ environment, as shown in Figure 13, each team operates
to some extent as an independent team, but all teams s ? ll need access to the shared
informa ? on.
Figure 14 shows the desired situa ? on, with extra- team sharing, that should be used and
managed with the right so ? ware, I T solu ? ons and a revised management process.
5.2 BIM and the Common Data Environment

This document is intended to give guidance on a collabora ? ve process for the delivery of
consistent high- quality informa ? on and data, from which a project may be constructed and
delivered with the minimum amount of e ffort in terms of cost and resource.
It also provides the founda ? on for the greater aspira ? on of Building I nforma ? on M odelling
(BI M ) and a fully integrated Building I nforma ? on M odel (iBIM ) and the delivery of the M ajor
Projects Handover document. BS 1192 is fully scalable, and has been used successfully on
small projects with a value from as li ? le as a few hundred thousand pounds as well as mul ? -
billion- pound contracts.
The basis of the guide is to provide an upgrade path from basic 2D CAD drawing produc ? on,
3D models and drawing produc ? on to the aspira ? on of the fully integrated BI M model.
Figure 15 shows the possible stages/phases of implementa ? on and the bene fi ts that can be
achieved during the process. It also helps any organiza ? on or project team to assess their
progress in their development and implementa ? on of BIM .
Figure 15 also forms the basis of future development work that will enable the authors to
add detail to each stage of development. Figure 15 is copyrighted and should not be used
in any other way, copied, changed, altered or published in any other form, than that shown
in the original.
40
Figure 13: CDE in team environment
41
42
Figure 14: CDE in programme environment
43
Level Descri p ? on
0 U nmanaged CAD, probably 2D, with paper as the most likely data exchange mechanism.
1 M anaged CAD in 2 or 3D format using BS 1192 with a collabora ? on tool providing a

CDE, possibly some standard data structures and formats. Commercial data managed by
standalone fi nance and cost management packages with no integra ? on
2 M anaged 3D environment held in separate discipline ‘BIM ’ tools with a ?ached data.
Commercial data managed by an Enterprise Resource Planner. I ntegra ? on on the basis of
proprietary interfaces or bespoke middleware could be regarded as ‘pBIM’. The approach
may u ? lize 4D Programme data and 5D cost elements.
3 Fully open process and data integra ? on managed by a collabora ? ve model server and
could be regarded as iBIM or integrated BIM , poten ? ally employing concurrent engineering
processes.
In a fully integrated iBIM world the roles and responsibili ? es of the total supply chain will
be known and their responsibili ? es for data delivery will be contractual. The clients need to
establish what is required at the handover stage and appoint the appropriate members of
the supply chain to deliver those requirements.
To ensure delivery, workfl ows and processes need to be established; BIM is a process not
a product. It is about the collec ? on, management, sharing and distribu ? on of informa ? on
at each and every stage of the concept/feasibility/design/construct and manage lifecycle.
I t uses many di fferent products used by di fferent members of the supply chain to carry out
the par? cular and separate (but not unrelated) ac ? vi ? es that make up the total informa ? on
genera ? on process.
For the major part, current CAD vendor BI M solu ? ons only generate graphical informa ? on
with some a ? ributed data. The major informa ? on or metadata content – perhaps greater
than 90 per cent – is of a textual or alphanumeric nature; in addi ? on to the informa ? on
produced during the professional design ac ? vi ? es and specialist design and manufacturing
44
Level 0 Level 1 Level 2 Level 3
Building Lifecycle Management

iBIM
BIMs
BRI M
BSI M
AI M
SI M
3D
FI M
2D IDM
IFC IFD
CPIC
AVANTI ISO BIM
BS 1 1 92: 2007
User Guides CPIC , Avanti , BSI
© 2008 Bew - Ri ch ards
Drawings, lines arcs text etc. Models, objects, collaboration Integrated, Interoperable Data
95% of u sers 2D an d 3D spati al coordin ati on based on A fu ll y i n tegrated an d in teroperable i BI M

2D drawi ng s l ack of coordin ati on i n creases CPI C, Avan ti and BS 1 1 92:2007 has the h as th e poten ti al to m i ti gate risk th rou g hou t
cost at 25% waste throu g h rework poten ti al to rem ove error and redu ce th e process an d to i n crease profi t by +2%
waste by 50% th roug h a col laborati ve process
Figure 15: The BIM development process
ac ? vi ? es, the client needs to de fi ne addi ? onal requirements for this data and metadata for
par? cular projects and for facili ? es management. See the PIX Protocol on the CPI C website
(www.cpic.org.uk).
Some informa ? on is common across construc ? on projects, but the majority is speci fi c to
the type of facility (hospital, school, airport, etc.).
The roles and responsibili ? es of those who have to provide that informa ? on, and the type
of informa ? on itself, are yet to be developed. In Figure 16 (overleaf), some forms of content
are shown below the process line.
BS 1192 is the only published procedure that manages the design development, procurement
and construc ? on phases of a BI M delivery, and as such it should be implemented in the
o ffi ce and on projects.
45
46
Key to Colour Coding

Core BIM Process
Guidance & support ref asset coding methods & tools Common Compliance CAD/BIM
CAD Standards Standards and
Model file sharing Model files contain
File Naming Spatial Handover
enrichment
Layer Naming coordination Virtual construction Documentation/Models
process
Key Procedures
Blocks & Objects Clash Checking objects fully populated checked Roles and
Level of Detail Common Object Create & Align Asset and approved Responsibilities for
Library Data delivery
Other References
Common Standard
for Asset Coding &
Design & Model Naming.
Geographic Data Maintenance Maintenance Documents and data
Management Define Units for a Integration Integration
Object Libraries delivery
Location Data Delivery Format Check Data Content specification
Define Content
Maintenance, HS
Risk register etc.
Specify roles and
responsibilities for
delivery
Figure 16: Development of iBIM content

6 S ta n d a rd M e th o d a n d
P ro ce d u re
6. 1 Fi l e n a m i n g
6. 1 . 1 File iden ?fiers
Re s e a rch h a s s h o wn th a t m a n y p ro b l e m s o cc u r b e ca u s e d e s i gn te a m m e m b e rs ca n n o t fi nd
th e re l e va n t i n fo rm a ? on o r th e m o st u p - to - d a te i n fo rm a ? on . Th e fi l e - n a m i n g co n ve n ? on
h a s b e e n d e ve l o p e d to s u p p o rt th e CD E p ro c e s s , a n d to a l l o w fa st s e a rch e s fo r i n fo rm a ? on
th ro u g h d a ta b a s e m a n a ge m e n t syste m s or fo l d e r- b a s e d sto ra ge syste m s . Th e n u m ber of
fi e l d s h a s b e e n ke p t to a m i n i m u m co n s i ste n t wi th p ro j e ct re q u i re m e n ts . Th e co n ve n ? on i s
n o t i n te n d e d a s a B ri ? s h S ta n d a rd fo r d o c u m e n t m a n a ge m e n t.
A n a m i n g co n ve n ? o n i s re q u i re d to d e l i ve r a ra p i d s e a rch ca p a b i l i ty fo r a l l re l e va n t ‘p ro j e ct ’
d o cu m e n t s and d a ta , i n cl u d i n g d a ta fi l es and B I M /CAD fi l es, bei n g m a n a ge d t h ro u gh a
re p o s i to ry su ch as an e xt ra n e t, e l e ct ro n i c d ocu m e n t m a n a ge m e n t syste m ( E DM S) and
d o cu m e n t m a n a ge m e n t syste m ( D M S ) s o l u ?o n . S i n c e t h e s e a rch fa ci l i t y i s i n p l a c e to h e l p
all p ro j e ct pa r ? ci p a n t s , th e naming co n ve n ? on sh ou l d su i t th e n eed s o f th e p ro j e c t as a
wh o l e – n o t a n i n d i vi d u a l , a d e s i gn e r, s p e c i a l i st o r co n t ra c to r. H o we ve r, i t d o e s n e e d to ta ke
i n to a cco u n t th e n e e d s o f th e i n d i vi d u a l o rga n i za ? o n s i n th e wi d e r te a m . I t a l s o ta ke s i n to
a cco u n t th e n e e d to co l l e c t, m a n a ge a n d d i s s e m i n a te d a ta /d o cu m e n ts wi th i n a CD E .
If a d o cu m e n t m a n a ge m e n t syste m re q u i re s a m o re co m p l e x o r a l l - e m b ra c i n g d o cu m e n t-
naming co n ve n ? on , th i s ca n be a d d ed as an addi ? on a l d ocu m e n t name on th e d i gi ta l ,
pl o ? e d o r p ri n te d d o c u m e n t – o r e ve n i n t h e ? tl e b l o c k. I f th e d a ta /d o c u m e n t m a n a ge m e n t
syste m h a s t h e a b i l i ty, t h e n a d d i ? on a l m e ta d a ta ca n b e a s s o c i a te d wi th e a ch fi l e fo r m o re
co m p l e x re tri e va l p ro c e s s e s .
As th e i d e n ?fi e r fo rm s p a rt o f th e CD E m a n a ge m e n t p ro c e s s , th e sta n d a rd s h o u l d b e a p p l i e d
a s te ste d and pu bl i sh ed : it is all to o e a sy to fe e l th a t yo u r co m p a n y o r o ffi ce has a be ? er
o n e . E xp e ri e n ce h a s s h o wn th a t t h e re i s n o t a b e ? e r sta n d a rd fo r th e p ro c e s s b e i n g u s e d –
on l y a d i ff e re n t o n e th a t u s u a l l y e n d s u p b e i n g u n a b l e to s u p p o rt th e re q u i re m e n ts .
47
Standard Method and Procedure
Recommenda ? on : adopt the following conven ? on when de fi ning a fi le iden ? fi er

(container) – for example a model, drawing or any other related documents.
[Project]-[Originator]-[Zone]-[Level]-[File Type]-[Role]-[Number]
The ‘Project’, ‘Sub project’ (if speci fi ed) and ‘Originator’ fi elds de fi ne the project or building
in a project and the responsible agent – not the owner – for the delivery of the informa ? on.
The ‘Zone’ and ‘Level’ fi elds in a fi le iden ? fi er locate informa ? on within the building or
by linear loca ? on on civil projects. The remaining fi elds are used to uniquely iden ? fy the fi le.
Recommenda ? on : in general, keep each fi eld to the smallest number of digits; using
hyphens enables you to use variable fi eld lengths if required.
The use of hyphen (-) delimiters between the fi elds in a fi le iden ? fi er enable the use of
varying- length codes. For example, a two- or three- character code could be used for the
originator.
6.1.1.1 Document/drawing descriptor
Project Originator Zone Level File type Role Number

SM - BS - 00 - GF - DR - S - 00001
The drawing descriptor and its rendi ? on (DWF, PDF) are de fi ned by the nota ? on ‘DR’ in the
fi le type fi eld. The fi le extension (such as .PDF or .DWF) is not part of the descriptor.
6.1.1.2 Graphic/model fi le descriptor

SM - BS - 02 - GF - M2 - S - 00001
M3
48
Standard M ethod and Procedure
When the descriptor is used to name a model fi le, the nota ? on M 2 (2D model fi le) or M 3
(3D model fi le) is used in the fi le type fi eld.

SM - CO - 02 - GF - M2 - M - 00001
M3
SM - CO - 02 - GF - M2 - E - 00001
M3
SM - CO - 02 - GF - M2 - E - 00002
M3
SM - CO - 02 - GF - M2 - E - 00003
M3
When model fi les are required by the same originator, but are from di fferent disciplines (as
is normal for the M EP (M echanical, Electrical, Plumbing) consultant, and they exist in the
same ‘Zone’ and ‘Level’ (loca ? on), you can use the ‘N umber’ to create a unique fi le name
when concatenated.
I n the second and third examples above, there are three model fi les in the same Zone.
One may be low voltage and another high voltage, or it could be that there are two low-
voltage circuits at di fferent levels within the same Zone, with a high voltage circuit. In these
examples, the di fferent requirement may be stated within the model fi le ? tle as metadata
to give a more detailed understanding.
6.1.1.3 All other documents


SM - BS - 02 - GF - RF(I) - S - 00001
SM - BS - 02 - GF - TQ - S - 00001
SM - BS - 02 - GF - SP - S - 00001
SM - BS - 02 - GF - SC - S - 00001
The descriptor can also be used as a fi le name for any other type of document. The fi rst three
examples are for RFI (request for informa ? on), TQ (technical query) and SP (speci fi ca ? on).
The fi nal example is for numbering structural calcula ? ons (SC).
49
For RFI , TQ and SP, the numbers can all start at 00001 for each type of document for each
originator, role or contractor, as those fi elds themselves ensure that the fi le will be uniquely
iden ? fi ed. Uniqueness is achieved by concatena ? ng the whole fi le container name, not by
dependence on the numeric number at the end of the conven ? on. The number is to allow
further subdivision for easy iden ? fi ca ? on, as explained in the text. I t also allows for the
team or task team to control their own needs rather than having to worry about the usually
complex problem of alloca ? ng a drawing or document number.
For numbering SC, the calcula ? on may be a fi le containing a number of sheets of calcula ? on,
and can be numbered as one fi le. I f the project requires individually numbered sheets, this
should be done on each individual sheet within the fi le, and not by fi ling each sheet as a
separate fi le. Table 7 gives a list of suggested document fi le type abbrevia ? ons.
The following sec ? ons describe in more detail the various codes that make up a fi le iden ? fi er.
6. 1 . 2 Field n am e de fin i?on s
6.1.2.1 Project
The ‘project’ designa ? on is an alphanumeric code that the project team uses to iden ? fy the
project. The client may actually de fi ne a project code for all members of the project team to
use. H owever, if each team member needs to have their own project code rela ? ng to that
company, this can be added as a ? ribute data in a separate box on the drawing ? tle sheet.
See the Drawing Template example Figure 33 on page 75.
For example, Table 3 de fi nes some project codes where there are mul ? ple sites within a
project. Alterna ? vely, the project code could also represent the actual project and sub-
project.
Alterna ? ve methods would be the project abbrevia ? on ‘Palace Exchange’ as PX and the
sub- project ‘South M all’ SM as PXSM .
Where an organiza ? on needs to use its own internal project numbers, these can be indicated
in the drawing ? tle block using a separate ‘project number’ box. This can be as a ? ributed
data or as metadata.
50
Ta bl e 3 : Proj e ct cod es
Cod e Proj e ct
SM South M all
NM N orth M all
AW Advance Works project
6. 1 . 2 . 2 Ori gi n a tor
It is important to understand the responsible agent for each piece of informa ? on being
shared among the teams. The responsible agent is the company contractually bound to be
responsible – not necessarily the originator of the informa ? on. This may be produced by a
subcontractor to the responsible agent.
The ‘originator’ is an alphabe ? c code that represents the company responsible for that
aspect of the work. The codes must represent the company name, and not the discipline.
Re com m en d a ? on : use a two-character originator code in a project. H owever, the

use of three-character codes for the subcontractors in the fi rst and second ? er supply
chain allows meaningful codes to be chosen.
For example, Table 4 de fi nes some ‘originator’ codes that relate to the companies working
on a project.
Ta bl e 4: E xa m pl e of o ri gi n a tor cod e s
Cod e Ori gi n a tor
UA Unique Architects
GP Good Prac ? ce (Engineers)
BS Burnished Steel (Fabricators)
SG Solar Glass (Suppliers)
CO (Company N ame)
51
S ta n d a rd M e th o d a n d P ro ce d u re
Fi re com partm ent zones
En erg y
Wards
sou rce
Operati n g
th eatres
X-ray
Ai r con diti on in g 1
M atern ity
Air con dition in g 2
Adm i n
Ph arm acy
Acci den t &

em erg ency
Out-patien ts
Ai r condi ti oni ng zones
Figure 17: Examples of zones
6.1.2.3 Zone

The ‘zone’ iden ?fier is u s e d to s p l i t th e p ro j e c t i n to m a n a ge a b l e s u b d i vi s i o n s ; a l l m e m b e rs
o f t h e d e s i gn te a m m u st a gre e zo n e s a t th e sta rt o f a p ro j e ct a n d p u b l i s h th e m a s a s h a re d
d o cu m e n t . I n d i vi d u a l d e s i gn te a m m e m b e rs m a y re q u i re a l te rn a ? ve zo n e s fo r t h e i r i n d i vi d u a l
n e e d s . Zo n e s a re n o t d ra wi n g a re a s , a n d d o n o t re l a te to th e a m o u n t o f th e p ro j e ct s h o wn
o n a n y gi ve n d ra wi n g. Th e y a re th e re s p o n s i b i l i ty o f t h e d e s i gn te a m m a n a ge rs , n o t th e CAD
o p e ra to rs .
52
Movement–expansion joints generate

zones that are structurally isolated
Energy
Wards source
Operating
theatres X-ray
Maternity
Admin
Pharmacy
Accident &
emergency
Out-patients
Cladding zones
The reason for spli ? ng the project into zones is to enable mul ? ple users to work on the
project, as well as limi ? ng the size of model fi les to prevent reduced performance of
so ? ware or communica ? on.
A zone may be based on an important aspect of design, such as structure, cores, specialized
func ? ons, H VAC (H ea ? ng, Ven ? ng, Air Condi ? oning) systems or strategic elements such as
cladding. These are indicated in Figure 17.
53
Sta n d a rd M eth od a n d Proced u re
Ductwork and Ductwork, foundation

foundation and structural frame
Architectural model
Ductwork, foundation,
structural frame and
plant room walls
Figure 18: 3D models that relate to a zone rela ? ng to a core
54
Zones are rather like two- or three- dimensional jigsaw pieces. They are not a pastry- cut
through the model so that every discipline’s zones cover the same area. Di fferent disciplines’
zones can interface in di fferent ways, as shown in Figure 18. They do not have to be square;
they simply have to fi t exactly with all the adjacent pieces of the same discipline, without
overlapping or leaving any gaps. If other disciplines’ zones are then overlaid, a composite of
mul ? - authored informa ? on will produce the complete project model.
In other words, a zone de fi nes the extent of model fi les, and one or more model fi les (xref
or referenced fi les) can relate to a zone. M ore normally, a zone is restricted to a level or
loca ? on, in a two- dimensional sense that does not combine mul ? ple levels or loca ? ons.
The example given below shows the breakdown of a staircase core that would be drawn as
a single element if de fi ned on a drawing or a 2D extrac ? on. I n this example, each model fi le
for all of the building elements is restricted to fi t between each level – even for the staircase
and columns.
(a) (b)
Figure 19: (a) Ground fl oor slabs, columns, stairs – (b) walls
(c) (d)
Figure 20: (c) Second fl oor as fi rst – (d) and third fl oor – as separate reference fi les
55
Figure 21: Completed architectural staircase core
(e) (f)
Figure 22: Structural – (e) founda ? ons and (f) fl oor li ? as de fi ned by structural frame
assembly
Figure 23: Completed structural staircase core
56
(g) (h)
Figure 24: (g) Ground fl oor duct-work and (h) ground fl oor risers + architectural fabric
Figure 25: Ductwork + architectural + structural for two fl oor li ? s
57
Figure 26: Complete core all disciplines
Figure 27: Examples of zones in a building
58
A simpli fi ed view of zones using 2D reference fi les is shown in Figure 27.
A model fi le represents a zone de fi ned by each discipline.
Re com m e n d a ? on : a zone is named by a numeric code. Use either two- or three-

character zone codes consistently in a project.
As indicated in the fi le- naming conven ? on, the codes for each zone are simple: 01–99 for
small, simple projects; or 001–999 for larger, more complex projects.
6. 1 . 2 . 4 Le vel /l oca ? on
The ‘Level’ code is a two- or three- character alphanumeric code that represents the level or
storey of a building. Within civil engineering contracts the ‘level’ code may indicate di fferent
construc ? on levels. It will also be applied to grade separated structures where the level on
an interchange may be above or below the ‘highway level’. In sha ? s, sewers and galleries
we invariably encounter levels and so the nota ? on will hold. On specialized infrastructure
projects other nota ? ons may be necessary and these should be dealt with on a project-by-
project basis.
Table 5 indicates examples of level codes.
BS EN ISO 4157-1 de fi nes the naming conven ? on for fl oor levels, and BS EN ISO 4157-2
de fi nes the room naming for each fl oor.
I n a civil engineering contract, the ‘Loca ? on’ may be indicated as a ‘chainage’ for roads and
railways; on large ground- covering sites, such as oil re fi neries, a postcode or grid- loca ? on
system should be adopted.
De fi ne this on a project- by- project basis.
59
Ta bl e 5 : Level cod e s
Cod e Le ve l
ZZ M ul ? ple levels
02 Second fl oor
01 First fl oor
MX M ezzanine fl oor X
M2 M ezzanine fl oor 2
M1 M ezzanine fl oor 1
GF Ground fl oor
LG1 Lower-ground level 1
LG2 Lower-ground level 2
F1 Founda ? on level 1
6. 1 . 2 . 5 F i l e type
The ‘File type’ is a two- character alphanumeric code that indicates the type of fi le. File
types are used to iden ? fy the type of informa ? on in the fi le, for example, a CAD model fi le –
not the format of the fi le content, e. g. .DWG, .DGN or .PDF.
Tables 6 and 7 list examples of typical fi le types. Agree addi ? onal fi le types with the
document controller to ensure consistency within the project team and in any document
repository that manages the project informa ? on.
The list of fi le types is likely to need extending to suit the exact requirements of the project
team, and these should be de fi ned and agreed at the start of the project.
6. 1 . 2 . 6 Rol e cod e s
Table 8 shows a list of standard codes for roles as recommended in BS 1192.
60
Table 6: File types – for drawings and models
Code File type

DR 2D drawing
M2 2D model fi le
M3 3D model fi le
MR M odel rendi ? on fi le (Coordina ? on model, e.g. N avisWorks)
AF Anima ? on fi le (of a model)
VF Visualiza ? on fi le (of a model)
Table 7: File types – for documents
Code File type

BQ Bill of quan ? ? es
CM Comments
CO Correspondence
CP Cost plan
DB Database
FN File note
HS H ealth and safety
MI M inutes/ac ? on notes
MS M ethod statement
PP Presenta ? on
PR Programme
RD Room data sheet
RI Request for informa ? on
RP Report
SA Schedule of accommoda ? on
SC Structural calcula ? ons
SH Schedule
61
Table 7: File types – for documents (contd)
Code File type

SN Snagging list
SP Speci fi ca ? on
SU Survey
TQ Technical query
Table 8: Role codes (from BS 1192)
Code Role
A Architect
B Building Surveyor
C Civil Engineer
D Drainage, H ighways Engineer
E Electrical Engineer
F Facili ? es M anager
G Geographical and Land Surveyor
H H ea ? ng and Ven ? la ? on Designer
I Interior Designer
K Client
L Landscape Architect
M M echanical Engineer
P Public H ealth Engineer
Q Quan ? ty Surveyor
S Structural Engineer
T Town and Country Planner
W Contractor
X Subcontractor
Y Specialist Designer
Z General (non-disciplinary)
62
The ‘role’ code is a single character indica ? ng the discipline or ? er contractor responsible
for content, not the individual or sub- subcontractor. On larger projects, it may be useful
to extend the role code to two or three characters as dictated by the ‘project’ need. Titles
such as ‘structural steelwork detailer’ or ‘reinforced concrete detailer’ are not acceptable,
because the purpose is to iden ? fy the responsible agent contractually, not the individual –
in these examples, this is usually the chartered or quali fi ed designer.
Selec ? on of roles or ? tles should, however, be controlled, otherwise meaningless codes for
sub- or sub- subcontractors may proliferate.
6.1.2.7 Number

The ‘N umber’ may be a four-, fi ve- or six- character code to suit project requirements. The
number is viewed in a number of ways:
• Each design discipline starts at 00001, and then allocates addi ? onal numbers to suit
its own needs. This overcomes the problem of alloca ? ng numbers across the project
team in an a ?empt to have con ? guous numbering. In this process, it is the concatenated
naming conven ? on that creates uniqueness, not the number.
• The fi rst two or three characters of the number could signify an ‘element code’ that further
classi fi es the fi le. One classi fi ca ? on code system should be chosen and consistently used
by all project teams. BS 1192 and CPI C recommend the use of Uniclass. I f Uniclass codes
or another classi fi ca ? on system are used in this way, it usually creates prolifera ? on of
duplicate drawings where only the classi fi ca ? on di fferen ? ates it. I n modern document
management systems, the ability to distribute one drawing for many purposes is possible
and desirable.
However, as explained at the start of sec ? on 6 of this guide, all fi le iden ? fi ers must be
unique when the ‘role’, ‘originator’, ‘fi le type’ and ‘number’ codes are considered. The
following examples indicate how this is achieved:
The ‘number’ is unique when joined For example, this also enables one ‘originator’
with the ‘fi le type’. to have model fi les and drawing fi les using
the same number: ‘SH-CA-02-01-M 2-A-
00140’ and ‘SH -CA-02-01-DR-A-00140’. N ote
that the model and drawing fi les do not
necessarily correlate, as a drawing is o ?en
made up from many model fi les.
63
The ‘number’ is unique when For example, this also enables di fferent
concatenated with the ‘fi le type’ and ‘originators’ to use the same ‘fi le type’ and
‘originator’. ‘number’: ‘SH -RW-06-01-M 2-E-00140’ and
‘SH -N G-06-01-M 2-E-00140’.
The ‘number’ is unique when For example, this also enables di fferent
concatenated with the ‘fi le type’, ‘roles’ to use the same ‘fi le type’ and
‘originator’ and ‘discipline’. ‘number’: ‘SH -RW-06-01-M 2-E-00140’ and
‘SH -RW-06-01-M 2-M -00140’.
6.1.2.8 File-iden ? fi er examples
An example of a 2D model ‘fi le iden ? fi er’ would be:
SH-CA-01-LG1-M2-A-00001
‘SH’ is the project loca ? on

‘CA’ is the two- character code for the originator
‘01’ indicates that the model relates to Zone 01
‘LG1’ indicates that the model relates to the Lower Ground fl oor level 1
‘M 2’ indicates that the model is a 2D model
‘A’ indicates that the discipline that created the model is an architect
‘00001’ is the unique model number
An example of a 2D drawing ‘fi le iden ? fi er’ would be:
SH-CA-00-LG1-DR-A-00001
‘SH’ is the project loca ? on

‘CA’ is the two- character code for the originator
‘00’ indicates that the drawing covers more than one zone
‘LG1’ indicates the drawing relates to the Lower Ground fl oor level 1
‘DR’ indicates the drawing is a 2D drawing
‘A’ indicates the discipline that created the drawing is an architect
‘00001’ is the unique number when concatenated with ‘ fi le type’ and ‘discipline’
64
At th e sta rt o f t h e p ro j e ct , a m a ste r d o c u m e n t i n d e x ( M D I ) m u st b e c re a te d t h a t l i sts a l l th e
‘ fi l e id en ?fi e rs ’ fo r m o d e l s a n d d ra wi n gs th a t a re n e e d e d , a l o n g wi t h th e i r d e l i ve ry d a te s a n d ,
i f p o s s i b l e , i n te rm e d i a te m i l e sto n e s . Th e fo l l o wi n g d o cu m e n t p ro p e r ? e s ( m e ta d a ta ) s h o u l d
be i n cl u d e d : p ro j e ct , l o ca ? on , o ri gi n a to r, zo n e , l e ve l , fi le t yp e , ro l e , n u m b e r, d e s c ri p ? on /
? t l e a n d d e l i ve ry d a te .
Se e Ta b l e 17 in Ap p e n d i x A fo r an e xa m p l e of a te m p l a te fo r a m a ste r d o cu m e n t i n d ex
s p re a d s h e e t .
6. 1 . 3 File- iden ?fier metadata
Sta tu s d e fi n e s th e ‘ fitness ’ o f i n fo rm a ? on in a m od el , d ra wi n g o r d o cu m e n t. I t a l l o ws e a ch
d e si gn d i s ci p l i n e to co n tro l th e u se to wh i ch th e i r i n fo rm a ? o n m a y b e p u t. U n a u th o ri ze d u s e
o f th e d a ta i s n o t a cce p ta b l e i f co n tro l i s to b e m a i n ta i n e d a n d e rro rs o r a m b i gu i ? e s a vo i d e d .
Th e ‘sta t u s ’ is an a ? ri b u te de fi n ed in th e ? tl e b l o ck o f th e d ra wi n g sh eet te m p l a te , and
wi l l a l so be de fi n ed a s m e ta d a ta t h a t i s a s s o c i a te d wi th th e fi le i d en ?fi e r wh e n th e fi le is
u p l o a d e d i n to t h e d o c u m e n t re p o s i to ry.
Recommenda ? on : sta t u s a n d re vi s i o n s h o u l d not b e i n c l u d e d a s p a rt o f th e fi le name
a s t h i s wi l l p ro d u c e a n e w fi l e e a ch ? m e th o s e e l e m e n t s a re u p d a te d , a n d a n a u d i t
tra i l wi l l n o t b e m a i n ta i n e d .
SH-CA-00-LG1 -DR-A-00001 <Status code> <Revision code>

attribute attribute
Al l m o d e l s , d ra wi n gs a n d d o cu m e n t s wi l l h a ve sta tu s co d e s d e fi n e d a s l i ste d i n Ta b l e 9 .
An e xa m p l e o f a d ra wi n g th a t h a s a sta t u s = ‘ fi t fo r co n stru c ? on ’ :
S ta t u s = A
SH-CA-00-LG1 -DR-A-00001 A <Revision code>

Status attribute
65
Table 9: Status codes
Status Descrip ? on Model fi les Drawing fi les Documents

S0 I ni ? al status or WIP. O O O
M aster document index of fi le iden ? fi ers
uploaded into the extranet.
In the Common Data Environment

‘shared’ sec ? on
S1 Fit for coordina ? on. O N N

The fi le is available to be ‘shared’ and used
by other disciplines as a background for their
informa ? on.
S2 Fit for informa ? on N O O

S3 Fit for internal review and comment As required O O
S4 Fit for construc ? on approval N N O
In the Common Data Environment
‘Documenta ? on’ sec ? on
D1 Fit for cos ? ng O O O

D2 Fit for tender N O O
D3 Fit for contractor design O O O
D4 Fit for manufacture/procurement N O O
A Fit for construc ? on. RI BA states that ‘A’ is N O O
noted as to ‘ac ? on for construc ? on.’
B Par? ally signed-o ff. N O O

For construc ? on with minor comments
from the client. All minor comments should
be indicated by the inser? on of a cloud
and a statement of ‘in abeyance’ un ? l the
comment is resolved, then resubmi ?ed for
full authoriza ? on.
AB As built O O O
66
6.1.3.1 Status

When the ‘status’ code does not su ffi ciently convey the use of the informa ? on, the
informa ? on owner can de fi ne it in the ‘purpose of issue’ text string. For example, a drawing
for ‘planning’ submission is likely to have a status ‘S2’ or a ‘D’ status – for informa ? on, if
not fully approved at that stage – but the purpose for the informa ? on can s ? ll be clearly
indicated in the ‘purpose of issue’ box on the drawing sheet as ‘for planning’. The purpose
of issue should be the highest level of authoriza ? on. Table 10 de fi nes some examples for
‘purpose of issue’ that can be allocated.
Table 10: Examples for purpose of issue
Purpose of issue
For planning submission
For building control approval
6.1.3.2 Revision

The ‘revision’ is an a ? ribute de fi ned in the ? tle block of a model or drawing sheet template,
and will also be de fi ned in the document repository when the fi le is uploaded. The revision
shows the itera ? ve nature of the informa ? on as it progresses to completeness.
The revision and status is required to track the progression of a fi le or document to its
comple ? on and authoriza ? on. The revision and status code need to be part of the a ? ributed
metadata, not part of the fi le name. If it is included in the fi le name, then it e ffec ? vely
becomes another document when concatenated, and it cannot be tracked e ffec ? vely. In a
database solu ? on, the metadata can be used to track and retrieve the fi les or documents in
the most e ffi cient manner.
SH-CA-00-LG1 -DR-A-00001 <Status code> <Revision code>

attribute attribute
67
The ‘Status codes’ and ‘Revision’ numbers are allocated as follows:
• During WI P (Status S0), preliminary revisions and versions are P1.1, P1.2, or P2.1, P2.2,
etc. before release to ‘shared’.
• Before ‘authorized for construc ? on’ (Status S1–Sn), preliminary revisions are: P1, P2, P3,
etc.
• Once ‘authorized for construc ? on’ (Status A), revisions are: C1, C2, C3, etc.
• The authoriza ? on status codes are speci fi ed in – ‘GREAT BRITAI N : JCT 05 – M ajor Project
Subcontract (M PSub) – Subcontract. London: RI CS Books’.
6. 1 . 3 . 3 Versi o n
The version is a subdivision of the revision, and shows the itera ? ve progress of the fi le
during WI P and before release to ‘shared’. I t is necessary to track the itera ? ve nature of the
fi le, as extracts may be taken from the fi le as material schedules or area calcula ? ons. The
extracted fi le needs to know what revision/version it belongs to.
I n a database solu ? on, it will be necessary to track versions when the extracted data is
modi fi ed and reconnected to the spa ? al fi le. Tracking and upda ? ng will be a constant
ac ? vity, and the changing of a ?ached proper? es or a ? ributes to a fi le may be carried out
without changing the graphical or spa ? al nature of the fi le.
In WIP, the revisions and versions need to be tracked and, when released to the shared
area, the revision will be used to track the use. For example, when a number of model fi les
are combined/overlaid to create drawings, the model fi le names that were used to produce
the drawings should be stated in the notes column of the drawing, along with the revisions
of those model fi les.
6. 2 O ri gi n a n d ori e n ta ? on
6. 2. 1 Coordinates

CAD modelling systems assemble the model informa ? on needed to generate produc ? on
drawings, which are based on Cartesian coordinates of all relevant points needed to de fi ne
the project. In the following sec ? ons, we have shown a stylized 3D building to convey the
requirements of a fully coordinated system, which is applicable to either a 2D or 3D design
project.
68
Figure 28: Cartesian coordinate system
In Figure 28, the points 1, 2, 3 and 4 can each be precisely located in space by three
coordinates, which are given in rela ? on to three planes (normally two ver? cal and one
horizontal) at right angles. The point of intersec ? on of the three reference planes is called
the ‘origin’ of the coordinate system.
Generally, it is recommended that the loca ? on of the ‘origin’ is outside the area required
by the project so that all coordinates have posi ? ve values. The coordinates are some ? mes
referred to as ‘world coordinates’, and the space de fi ned by their posi ? ve values is known
as ‘model’ space.
6. 2. 2 Spa?al coordina ?on

Spa ? al coordina ? on is an essen ? al requirement of good- quality produc ? on informa ? on.
6. 2. 3 Building grids
To achieve a fully coordinated set of produc ? on drawings across all design disciplines, a
common building grid should be established and used by all members of the design team.
69
This will ensure that the di fferent design disciplines’ models achieve the same registra ? on
when coordina ? ng the models that relate to each individual building.
I t is common prac ? ce to de fi ne a building origin at the bo ?om le ?- hand corner of the building,
in plan view, as shown in Figure 29. This building origin must then be related to a site grid
where the site grid could be based on the Ordnance Survey (OS) grid or a site survey grid.
6. 2. 4 Site surveys

I t is preferable for the site surveys to be based on N orthings and Eas ? ngs that are related
to the known geospa ? al coordinates, as shown in Figure 30. For example, the geospa ? al
coordinates could be based on the OS grid.
In some instances, the survey origin may be based on an arbitrary site grid the surveyor has
chosen. The levels will relate to a local OS benchmark, or to a local temporary benchmark
(TBM ) established for the project.
6. 2. 5 Alignment of the building to real- world coordinates

To enable the building to be correctly located in real- world coordinates, it is necessary to

relate the origin and orienta ? on of the building grid to the origin and orienta ? on of the site
grid, as shown in Figure 31.
It is recommended that a major axis of a building (typically its length) is used to set out
the building grid rela ? ve to a site grid origin. The direc ? on of true north should also be
referenced.
Care should be taken when recommending OS coordinates. I n a number of so ? ware systems,

including CAD systems, large coordinates of six signi fi cant fi gures can produce erroneous
informa ? on when calcula ? ng areas and lengths.
I t is recommended that buildings be set out with reference to local site survey coordinates
to overcome the problem. The site is usually set out using the surveyor’s base lines and
permanent monuments, and these should be used for se ? ng out the CAD models. The site
survey can be referenced or related to the OS grid, and the coordinates are easily transposed
by the surveyor’s so ? ware when genera ? ng the ‘angle bibles’.
70
Figure 29: Building grid defi ni ? on
Figure 30: Site grid defi ni ? on
Figure 31: Alignment of the building to the real-world coordinates
71
? ? ? ? ? ?? ?
? ? ? ???? ?
??? ? ?? ? ? ? ?? ?? ? ? ? ?? ?? ? ? ? ???? ? ? ? ?? ??
?
?? ?? ??
?
?
?? ?? ??
? ?
?
??
? ?? ? ? ?
? ?
?? ??
? ? ? ? ? ? ? ??
??
? ? ?
?
? ?? ? ? ? ???
? ?
?
? ? ? ? ???? ?
??
?
?
?? ? ?? ?? ? ? ?
? ? ? ? ? ? ??
? ?
? ? ?
? ? ? ??? ??? ? ? ? ? ? ? ???

? ? ?
?
? ? ?
? ?? ??? ???
? ?
? ?? ? ? ? ???
? ?
?
?? ????
? ?? ?? ? ? ? ? ?
? ? ? ? ? ?
Figure 32: Building grid and se ng out points ?
?
Table 11: Se ng out a building grid
Point Grid intersec? on Eas? ng (m) Northing (m)

Site grid origin – 504,000.000 125,000.000
1 A1 504,030.000 125,010.000
2 D1 504,046.281 125,019.400
6. 2. 6 Exam ple of buildin g align m ent
Table 11 and Figure 32 show a typical example of the informa ? on that the lead designer
should agree when se ? ng out building grids rela ? ve to the Ordnance Survey N orthings and
Eas ? ngs.
6. 2. 7 Dim en sion al con sisten cy

M any of the problems that arise on construc ? on sites can be traced to errors and ambigui ? es
in the dimensions. Such errors occur when informa ? on is entered incorrectly, or dimensions
72
a re a d d e d a s te xt t h a t i s u n re l a te d to th e u n d e rl yi n g co o rd i n a te syste m . Th e u s e o f i n co rre ct
d i m e n s i o n a l i n fo rm a ? o n wi l l p re ve n t e ff ?
ec ve s p a ? a l co o rd i n a ? on .
Cre a te all m od el s a t a s ca l e of 1: 1 u s i n g re a l - wo rl d co o rd i n a te s , and ba se all d ra wi n gs o n
th e m o d e l i n fo rm a ? o n . D o n o t u s e ‘n o t to s ca l e ’.
D e ri ve all d i m en si on s a u to m a ?ca l l y fro m th e u n d e rl yi n g CAD co o rd i n a te s by u si n g th e
‘a s s o c i a ? ve d i m en si on i n g ’ fu n c ? on o f CAD syste m s . Do n ot e n te r d i m e n s i o n s as ‘te xt ’ as
t h e y a re p u re l y gra p h i c c h a ra c te rs wi t h n o re l a ? o n s h i p to th e u n d e rl yi n g CAD co o rd i n a te s ,
a n d wi l l co m p ro m i s e th e re l a ? ve p o s i ? o n s o f e l e m e n ts i n a d ra wi n g.
Th e p ro j e ct te a m sh ou l d a gre e co m m o n u n i ts of m e a s u re m e n t . Th e s e sh ou l d i n cl u d e
d i sta n c e ( e . g. m e tre s a n d m i l l i m e tre s ) a n d a n gl e s ( e . g. d e gre e s /ra d i a n s m e a s u re d c l o c kwi s e
o r co u n te r- cl o c kwi s e ) .
6. 3 Dra wi n g sh e et te m pl a te s
Th e d ra wi n g s h e e t te m p l a te s m u st b e u s e d a s th e sta r ? n g p o i n t fo r a l l d ra wi n gs , wi th th e
n e c e s s a ry m o d e l fi l e s re fe re n ce d i n to a vi e w c re a te d i n t h e d ra wi n g.
D ra wi n g s h e e t te m p l a te s i n A0 , A1 , A2 , A3 a n d A4 s i ze s a re a va i l a b l e . S e e Ap p e n d i x E fo r a n
e xa m p l e o f a d ra wi n g s h e e t te m p l a te . Ap p ro p ri a te i n fo rm a ? o n t h a t i s s p e ci fi c to th e p ro j e c t
ca n b e i n s e rte d i n to t h e ? tl e b l o c k o f t h e d ra wi n g s h e e ts , fo r e xa m p l e :
• c l i e n t n a m e a n d l o go ;
• o ri gi n a to r n a m e a n d l o go ;
• p ro j e ct n a m e ; a n d
• p ro j e ct n u m b e r.
A p ro j e ct n u m b e r re q u i re d b y e a c h te a m o ffi ce ca n b e a d d e d to th e d ra wi n g te m p l a te a s a
co m p a n y p ro j e c t n u m b e r, b u t i t i s n o t p a rt o f th e fi l e n a m e.
6. 3. 1 Drawing ?tle block a?ributes/tags

A ? ri b u te s in th e d ra wi n g ? tl e b l ock co n ta i n m e ta d a ta th a t is sp e ci fi c to e a ch i n d i vi d u a l
d ra wi n g. Th e m e ta d a ta th a t re l a te s to th e ‘ fi le i d en ?fi e r ’, ‘re vi s i o n ’ and ‘sta t u s ’ has been
d e s cri b e d i n d e ta i l i n s e c ? o n 6 . 1 o f th i s gu i d e .
73
The drawing number on a drawing sheet ? tle block must contain the ‘ fi le iden ? fi er’, with
the other metadata informa ? on being presented in the remaining sec ? ons of the ? tle block
as follows:
• project name;
• drawing ? tle;
• revision;
• status;
• purpose of issue;
• client authoriza ? on informa ? on; and
• revision descrip ? on (including what has changed and why) with check and approval
dates by the originator.
Figure 33 shows a drawing ? tle block containing the metadata informa ? on for the drawing
examples described in sec ? on 6.1 of this guide.
N ote that drawing fi les should not be named freely, but should follow the conven ? on for
de fi ning a ‘fi le iden ? fi er’ to avoid duplicate or inconsistent descrip ? ons. To ensure that valid
fi le iden ? fi ers are used, create a master document index (M DI ), which de fi nes all model
and drawing fi les and their associated descrip ? ons so that a document controller can pre-
upload the fi les into the document repository. See Appendix A for an example of a template
for crea ? on of a master document index.
When compiling any type of construc ? on document, ensure that the document is cross-
referenced accurately with other documents or speci fi ca ? ons, so that the full intent of the
document will be carried out.
With this in mind, label all drawings clearly with the fi le name and revision of any reference
models or documents used to compile them, and list them clearly in the notes column of
the drawing ? tle block, as shown in Figure 33.
In this example the ‘project number’ has been included in a separate box.
6. 3. 2 Model ?tle block
By de fi ni ? on, a model fi le is either an ‘M 2’ or ‘M 3’ fi le type and will only contain the actual
model informa ? on; therefore it will not contain any drawings or views of the model. A view
of the model will be created in a drawing fi le with a ‘DR’ fi le type.
74
I SSU ED FOR CON STRU CTI ON
C1
G.M.WHIPP 1 5/03/03
I SSU ED FOR CLI EN T APPROVAL
P4
G.M.WHIPP 21 /02/03 D.KERR 22/02/03 R.CHADWICK 23/02/03
I SSU ED FOR I N TERN AL REVI EW
P3
G.M.WHIPP 1 5/02/03 D.KERR 1 7/02/03 R.CHADWICK 1 9/02/03
I SSU ED FOR I N FORMATI ON
P2
G.M.WHIPP 08/02/03
KEY PLAN FI RST DRAFT
P1
G.M.WHIPP 01 /02/03
COMMENT
REV
DRAWN BY DATE CHECKED BY DATE APPROVED BY DATE
SCALES @ A1 ISSUING OFFICE PROJECT NUMBER
1 :200 MANCHESTER 1 234
CLIENT APPROVAL
X A - APPROVED
B - APPROVED WITH COMMENTS
C - DO NOT USE
STATUS PURPOSE OF ISSUE
A FOR_CONSTRUCTION
ORIGINATOR
NAME, ADDRESS and LOGO
Construction Risks Maintenance/cleaning Risks Demolition/adaptation Risks PROJECT
In addition to the hazard/risks normally associated with the types of work detailed
on this drawing take note of the above.
It is assumed that all works on this drawing will be carried out by a competent
PROJECT_TITLE
contractor working, where appropriate, to an appropriate method statement.
SAFETY HEALTH AND ENVIRONMENTAL INFORMATION BOX

NOTES
Th i s drawi n g con tai n s the fol l owi n g model fi l es:

SH -CA-01 -LG 1 -M 2-A-0001 . dwg [S1 ] [P5] TITLE
DRG_TITLE_1
SH -CA-03-LG 1 -M 2-S-0001 6. dwg [S1 ] [P5]
SH -RW-06-LG 1 -M2-M-0001 0. dwg [S1 ] [P2]
Th i s drawi n g to be vi ewed i n con ju n cti on wi th :

SH -RW-00-LG 1 -DR-M-0001 0. dwf
DRG_TITLE_2
DRG_TITLE_3
CLIENT
CLIENT NAME / LOGO

DRAWING NUMBER REV
SH-V1 -1 -A-CA-DR-0201 40 C1
Figure 33: Drawing sheet ? tle block
75
? M odel
? fi l e
? ? ??
?
?
??
REV COMMENT DR CH AP DATE

?

?
MODEL FILE IDENTIFIER REV
Figure 34: Model fi le
REV COMMENT DR CH AP DATE
STATUS PURPOSE OF I SSUE
S1 For Coordi nation
MODEL FI LE I DENTI FI ER REV
FI LE_I DEN TI FI ER REV
Figure 35: Model fi le ? tle block
I t is important to iden ? fy such model fi les with respect to their ‘revision’ and ‘status’ when
they are accessed or viewed in an environment, for example, a document repository that is
not managing a model’s metadata.
Figure 34 shows a typical model fi le that relates to a ‘zone’, with a model fi le ? tle block
located in the bo ?om right- hand corner of the model.
Figure 35 shows the model fi le ? tle block with its associated text a ? ributes in more detail.
76
6. 3. 3 Drawing sheet sizes

Ta bl e 1 2 : Dra wi n g sh eet si ze s
Si ze Di m en si on s
A0 1 1 8 9 × 8 41 m m
A1 8 41 × 5 9 4 m m
A2 5 9 4 × 42 0 m m
A3 42 0 × 2 9 7 m m
A4 297 × 210 m m
6. 3. 4 Drawing sheet scales

Al l d ra wi n gs m u st b e re n d e re d a n d p re s e n te d a t o n e o f a n u m b e r o f a p p ro ve d s ca l e s , wh i c h
a re t yp i ca l l y d e fi n ed b y th e ‘CAD M a n a ge r ’. S ca l e s o th e r th a n th ose a p p ro ve d sh ou l d n ot
be u sed .
Ta bl e 1 3 : Dra wi n g sh e et sca l es
Sca l e
1 : 2 5 00
1: 1250
1 : 1 0 00
1 : 5 00
1 : 2 00
1 : 1 00
1: 50
1: 20
1: 10
1: 5
1: 2
1: 1
77
Ta bl e 1 4: E xa m pl e o f l a ye r n a m e cod es
Fi el d Rol e E l em en t/ Prese n ta ? on De scri p ? on /
cl a ssi fi ?
ca on alias
Name A - G 23 - M2 _ S ta i rs
E xa m p l e Arch i te ct S ta i rs ( U n i cl a s s ) M o d e l gra p h i c s
( 2D)
6. 4 La ye r sta n d a rd s
A l a ye r n a m i n g sta n d a rd wi l l be a ppl i ed to all 2D and 3D CAD m od el s th a t wi l l be s h a re d
a m o n g th e d e s i g n te a m s .
Th e fo l l o wi n g co n ve n ? on ba sed u pon BS 1 1 92 sh ou l d b e a d o p te d to d e fi ne a l a ye r n a m e .
N o te th a t th e re a re h yp h e n ‘-’ d e l i m i te rs b e twe e n t h e fi rst t h re e m a n d a to ry fi el d s, a n d a n
u n d e rs co re ‘_’ d e l i m i te r i s u s e d b e twe e n t h e m a n d a to ry a n d th e a l i a s .
[Role] - [Element] - [Presentation] _ [Alias]
M a n d a to ry fi el d s:
• ro l e : t h e d i s c i p l i n e fo r th e o wn e r o f t h e i n fo rm a ? on ;
• e l e m e n t/c l a s s i fi ca ? on : u si n g U n i cl a s s cl a s s i fi ?
ca on co d e s fo r co n st ru c ? on e l e m e n ts or
d ra wi n g e l e m e n ts ; a n d
• p re s e n ta ? o n : i n d i ca te s th e wa y i n wh i c h th e e l e m e n t i s d i s p l a ye d .
An e xa m p l e o f a typ i ca l l a ye r n a m e co d e i s s h o wn i n Ta b l e 1 4.
Th e fi e l d s th a t fo rm th e l a ye r n a m e s a re d e s cri b e d i n d e ta i l b e l o w.
6. 4. 1 Role
Ta b l e 8 i n s e c ? o n 6 . 1 . 2 . 6 o f th i s gu i d e l i st s th e s i n gl e - ch a ra cte r ‘ro l e ’ co d e s re co m m e n d e d
i n BS 1192.
78
Table 15: Presenta ? on codes from BS 1192
Code Descrip ? on
D Dimensioning
H Hatching and shading
M M odel related elements
P Plot/page related elements
T Text
Addi ? onal to the BS 1192 de fi ni ? on, the M code can be extended to de fi ne speci fi c
requirements of M 2 to mean 2D and M 3 to mean 3D graphic fi les.
For large projects, a two- character ‘role’ code may be more appropriate. See sec ? on 6.1.2.6
of this guide above for a ‘caveat’.
6. 4. 2 Element/classifica ?on
The ‘classi fi ca ? on’ is a varying- length alphanumeric code.
Base the ‘element’ code on the U niclass classi fi ca ? on system, which allows for the
full classi fi ca ? on of element, speci fi ca ? on, materials, construc ? on aids, etc. See
www.uniclass.org.uk or www.CPIC.org.UK Uniclass Request Tool for details of the element
codes when using the Uniclass classi fi ca ? on system. Also see the Guidance Commentary
from BS 1192 below.
6. 4. 3 Presenta ?on
The ‘presenta ? on’ is a single or two- character code. Table 15 shows the presenta ? on codes
recommended in BS 1192.
79
6. 4. 4 Descrip ?on/alias
Recommenda ? on : append the ‘descrip ? on’ code to the layer name to assist layer
iden ? fi ca ? on.
Following an underscore delimiter character ‘_’, the ‘descrip ? on’ or ‘alias’ directly correlates
to the ‘Uniclass classi fi ca ? on’. The ‘descrip ? on’ should not be treated as a user- de fi nable
fi eld, but must be agreed and used consistently by the project team – even though this is
noted as ‘op ? onal’ in BS 1192. For Uniclass, this will be controlled by the ‘Uniclass Request
Tool’, and the aliases are consistent throughout with no ability to user- de fi ne.
Inconsistent use of aliases creates problems of expanding the material schedule, because
the naming of the alias has been user- de fi ned.
6. 4. 5 Extract from BS 1192

Table C.1 compares the layer naming required in 5.4.4 with those recommended in
BS EN ISO 13567-2.
Table C.1 Di fferences between interna ? onal and Bri ? sh layer naming fi elds
Mandatory/ Field name and order Number of Field name and Number of
op ? onal fi eld in BS EN ISO 13567-2 characters order in BS 1192 characters
M 1. Agent responsible 2 1. Role 1 then hyphen
M 2. Element 6 2. Classi fi ca ? on 2–5 then hyphen
M 3. Presenta ? on 2 3. Presenta ? on 1
O 10. User de fi ned Unlimited 4. Descrip ? on Underscore then

unlimited
C.2 Managing the rela ? onship between Bri ? sh and interna ? onal
structures
A UK organiza ? on working on an interna ? onal project, to which BS EN I SO 13567-2

code conven ? ons for layering are to be applied, can convert layers for export in
a straigh ?orward manner because the layer structure in 5.4.4 is a subset of the
80
I S O st ru c tu re . D a ta re ce i ve d fro m o ve rs e a s o rga n i za ? o n s ca n b e co n ve rte d to
th i s st ru c tu re , b u t s o m e l o s s o f l a ye r st ru ct u ri n g i n fo rm a ? o n i s l i ke l y to o c cu r. U K
o rga n i za ? o n s m i gh t th e re fo re b e o b l i ge d to u s e a m o re co m p l e x a n d u n fa m i l i a r
stru ctu re . I n su ch ci rcu m sta n ce s, i t i s u se fu l fo r th e p ro j e ct te a m s to a gre e a t a n e a rl y
sta ge h o w th e y wi l l a l l o ca te n a m e d co n ta i n e rs fo r s p e ci fi c p ro j e ct s , a n d d o c u m e n t
t h e s e . I t i s l i ke l y t h a t s o ? wa re wi l l b e u s e d fo r co n ve r ? n g b e t we e n t h e sta n d a rd s .
NOTE BS EN ISO 13567 parts 1 and 2 contain many detailed recommenda ?ons on
how to exchange data interna ?onally.
G U I DAN CE CO M M E N TARY o n 5 . 4. 1 o f B S 1 1 9 2
BS 1192 Tables 2 and 3 specify that the Descrip ?on in the layer containers is op ?onal; in
prac?ce, and when using the Uniclass codes, the descrip ?on should be consistent with the
classifica?on. In the revised Uniclass structure (see www.CPIC. org. uk Uniclass Request Tool),
the granula ?on of the classifica?on requires the classifica?on code and the descrip ?on to be
consistent to allow for specific reuse of the data for material scheduling and the applica ?on
of the specifica?on.
Because extracts from CAD/BIM files use the layer container as a means of producing lists
of elements, the schedule can be misleading. Example: a project defined a specific number
of bathroom module types (six). A library of the sub-models was made available to the
project teams. Each project team changed the descrip ?on associated with the classifica?on
number; it became user defined, which led to a schedule being produced of over 36 different
types of bathroom module. This required the models to be checked and the element layer
names had to be amended to get the correct schedule result.
It should further be noted that when conver?ng between interna ?onal and BS 1192
conven ?ons, problems will arise because there may be inconsistencies between the
descrip ?on fields of the ISO that could lead to mul?ples of the descrip ?ons in the BS, leading
to further problems.
6.5 Annota ? on
Th e ‘CAD M a n a ge r ’ s h o u l d a gre e th e te xt styl e a n d fo n t s to b e u s e d i n d ra wi n g ? tl e b l o cks ,
a n d a n y o th e r a n n o ta ? o n th a t i s a d d e d to a d ra wi n g.
81
6. 5. 1 Dimensions
All dimensions should be generated as associa ? ve dimensions and never added as text.
Dimension text must not be modi fi ed, and automa ? c or associa ? ve dimensions should
never be broken into their cons ? tuent parts.
6. 5. 2 Abbrevia ?ons
H istorically, abbrevia ? ons were used frequently in construc ? on documents as part

of standard prac ? ce. They were part of the drawing symbology, but led to errors of
interpreta ? on by contractors.
Abbrevia ? ons should therefore be controlled by an agreed ontology, since they are
frequently part of the normal vocabulary used by di fferent roles. For instance, ‘LTH W’ is
used to refer to a low- temperature hot- water hea ? ng system.
Rules for use of abbrevia ? ons:
• use upper- case le ?ering, without full stops;

• do not use spaces within an abbrevia ? on; and
• use the same abbrevia ? ons for singular or plural.
Abbrevia ? ons must be consistently applied by the design teams, and therefore a table of
abbrevia ? ons should be maintained. See Table 18 in Appendix G for an example of a list of
commonly used abbrevia ? ons.
6. 5. 3 Symbols
Standard symbols should be agreed by the project team. Some typical examples of standard
symbols are shown in Figure 36.
Recommenda ? on : establish a full symbols library for the project so that all par? es use
the same nota ? on and understand their meaning.
82
Luminaire Fall of ground

Any new tree
Pole Bank
Short standard
Arm
Half standard
Luminaire on
Light standard pole
Standard
Luminaire on
pole – mounted
arm
Tall standard
Selected standard Figure 36: Some standard symbols
83
U s e fu l s o u rc e s fo r a rc h i te c tu ra l a n d b u i l d i n g s e rvi ce s sym b o l s a re :
Construc?on drawing prac?ce recommenda?ons for symbols

B S 1 1 9 2 - 3 : 1 9 8 7 ( wi t h d ra wn ) , –
and other graphic conven ?ons

Graphical symbols for use on equipment index and synopsis
I S O 7 0 0 0: 2 0 0 4, –
Graphical symbols incorpora ?ng arrows synopsis

I S O 1 0 48 8 : 1 9 9 1 , –
Graphical symbols vocabulary

I S O 1 7 7 2 4: 2 00 3 , –
I EC Basic principles for graphical symbols for use on equipment Part 1:

8 0 41 6 -1 : 2 0 08 , —
Crea?on of graphical symbols for registra ?on

8 0 41 6 -2 : 2 0 01 , —
Form and use of arrows

8 0 41 6 -3 : 2 0 01 , —
Guidelines for the applica ?on of graphical symbols

NHS Estates publica ?on Engineering symbols and drawing conven ?ons A catalogue for
– –
the use in health care premises

7 Sp e ci fi ca ? on
M o st p ro j e ct s wi l l e m p l o y s e ve ra l d e s i gn d i s ci p l i n e s , e a c h o f wh i ch s h o u l d p re p a re th e wo rk
sec ? o n s o f th e s p e c i fi ca ? o n fo r wh i c h t h e y h a ve d e s i gn re s p o n s i b i l i t y – j u st a s t h e y p re p a re
t h e i r re s p e c ? ve d ra wi n gs .
Wi th i n e a ch d i s ci p l i n e , th e i d ea l a u th o rs o f th e re l e va n t wo rk s e c ? on s wi l l be te ch n i ca l l y
e xp e ri e n c e d p e rs o n n e l , wi t h d e ta i l e d kn o wl e d ge o f th e p ro j e c t a n d e xp e ri e n c e i n p re p a ri n g
s p e ci fi ca ? o n s , a n d wh o wi l l b e re s p o n s i b l e fo r th i s wo rk. Ve ry o ? e n , th e a u t h o rs wi l l b e th e
p ro j e ct a rc h i te ct s a n d e n g i n e e rs .
O th e r possi bl e a u t h o rs i n cl u d e d e d i ca te d i n -h o u se sp e ci fi ca ? on wri te rs , co n s u l ta n t
sp e ci fi ca ? o n wri te rs ( ra re i n t h e U K) , a n d co n s u l ta n t te c h n i ca l e xp e rt s ( e . g. m a n u fa ct u re rs ,
fa b ri ca to rs o r i n - h o u s e s p e ci a l i sts ) . M o re t h a n o n e o f th e s e a u th o rs m a y b e u s e d o n a gi ve n
p ro j e ct .
I rre s p e c ? ve o f th e s p e ci fi e r, ca re fu l ch e cki n g i s n e e d e d to e n s u re th a t a l l wo rk s e c ? o n s a re
co n s i ste n t a n d co h e re n t, re fl e ct th e p a r ? c u l a r d e s i gn re q u i re m e n ts o f t h e p ro j e ct , a n d a re
a l s o co n s i ste n t wi th th e d ra wi n gs .
As n o te d , wi d e kn o wl e d ge o f co n stru c ? on te ch n o l o gy is n eed ed . Th e s p e ci fi ca ?on fo r a
b u i l d i n g p ro j e c t o f a ve ra ge s i ze a n d co m p l e xi ty co n ta i n s a l a rge a m o u n t o f i n fo rm a ? on , a n d
re fe re n c e to a m u c h l a rge r vo l u m e o f p u b l i s h e d m a te ri a l ( e . g. to B ri ? s h S ta n d a rd s ) .
An e ve n l a rge r a m o u n t o f i n fo rm a ? o n , n o t i n cl u d e d o r re fe rre d to i n th e s p e c i fi ca ? on , n eed s
to b e co n s u l te d d u ri n g th e s p e c i fi ca ? o n p ro ce s s . Th i s m a s s o f p u b l i s h e d i n fo rm a ? o n c h a n ge s
co n sta n tl y – a b o u t 15 p e r ce n t a n n u a l l y fo r B ri ? sh sta n d a rd s re l a ? ng to th e co n st ru c ? on
s e cto r, fo r e xa m p l e .
Th e s h e e r vo l u m e o f t h i s i n fo rm a ? on m e a n s th a t a n i n d i vi d u a l d e s i gn e r ca n n o t a s s i m i l a te
a n d re m e m b e r i t a l l . Th e d e s i gn o ffi ce s h o u l d th e re fo re :
• e n co u ra ge i n d i vi d u a l s to d e ve l o p a n d m a i n ta i n e xp e r ? se on c e rta i n to p i c s , and to gi ve
a d vi ce to o t h e rs ;
85
S p e ci fi ca ? on
• m a i n ta i n a s u i ta b l e m a ste r s p e ci fi ca ? o n syste m ; a n d
• m a i n ta i n a n e ffi ci e n t te ch n i ca l l i b ra ry, su p p l e m e n te d b y a p p ro p ri a te i n fo rm a ? o n syste m s.
7. 1 M a ste r spe ci fi ?ca on syste m s
Re s e a rc h i n g a n d wri ? n g go o d - q u a l i ty s p e ci fi ca ? o n c l a u s e s fro m s c ra tc h i s d i ffi cu l t a n d ? m e-
co n s u m i n g , bu t som e ? m e s i t i s u n a vo i d a b l e . Ca re fu l re u s e o f sta n d a rd c l a u s e s ca n s a ve a
gre a t d e a l o f ? m e , a n d a l s o i m p ro ve th e q u a l i t y o f p ro j e c t s p e ci fi ca ? on s.
A co m p re h e n s i ve set of sta n d a rd sp e ci fi ca ? on cl a u s e s is ca l l e d a m a ste r sp e ci fi ca ? on
syste m . To b e e ff ?ec ve i n u s e , i t n e e d s th e fo l l o wi n g fe a t u re s :
• I t s h o u l d fo l l o w th e p ri n c i p l e s s e t o u t i n th i s gu i d e .
• Th e wo rk s e c ? o n s sh o u l d b e a rra n ge d b y CAWS ( Co m m o n Arra n ge m e n t o f Wo rk Se c ? on s) .
• Cl a u s e s s h o u l d b e a rra n ge d wi t h i n wo rk s e c ? o n s to fo l l o w t h e d e s i gn and co n stru c ? on
s e q u e n ce .
• Th e cl a u s e s s h o u l d p re s e n t a co m p re h e n s i ve a n d cl e a r s e t o f a l te rn a ? ve s th a t re l a te we l l
to th e a va i l a b l e d e s i gn ch o i c e s , wi th ga p s l e ? fo r i n s e r ? on o f va ri a b l e ( p ro j e c t- s p e c i fi c)
i n fo rm a ? on .
• It sh ou l d p ro vi d e h e l p fu l gu i d a n c e fo r s e l e c ? ng and co m p l e ? ng i n d i vi d u a l cl a u s e s and
fo r e a ch s e c ? o n a s a wh o l e .
• Cl a u s e s a n d gu i d a n c e s h o u l d b e th o ro u gh l y re s e a rch e d , we l l wri ? e n a n d ke p t u p to d a te .
• I t s h o u l d co ve r a l l co m m o n l y o cc u rri n g co n stru c ? o n syste m s a n d p ro d u c ts .
• Al te rn a ? ve s o ff e re d sh ou l d su i t va ri o u s p ro j e c t s i ze s and co m p l e xi ? e s, va ri o u s
p ro cu re m e n t ro u te s , a n d n e w- b u i l d a n d wo rk- to - e xi s ? n g.
P re p a ri n g a n d m a i n ta i n i n g s u c h a m a ste r s p e ci fi ca ? on syste m re q u i re s a h u ge a m ou n t of
e ffo rt, and m o st o ffi ce s sh ou l d co n s i d e r s u b s c ri b i n g to a co m m e rc i a l l y a va i l a b l e m a ste r
s p e ci fi ca ? on syste m . O ffi ce s sh ou l d be a bl e to u se su ch a co m m e rci a l syste m d i re ct l y fo r
t h e p re p a ra ? o n o f p ro j e ct s p e c i fi ca ? on s.
H o we ve r, th e syste m s h o u l d a l s o e n a b l e th e o ffi ce to p re - e d i t t h e b a s i c te xt , to p ro d u c e a n
o ffi ce -sp e ci fi c m a ste r s p e c i fi ca ? o n syste m . S u c h a n o ffi c e m a ste r wi l l :
• re l a te m o re d i re ct l y to th e te ch n i ca l p re fe re n c e s o f th e o ffi c e , c l i e n t o r p ro j e ct t yp e , e . g.
b y sta n d a rd i z i n g t h e c h o i c e o f m a n y p ro d u ct s ; a n d
• re d u ce th e ? me ta ke n in p re p a ri n g p ro j e c t s p e ci fi ca ? on s, by re d u c i n g th e n u m ber of
op ? o n s to b e co n s i d e re d a n d t h e a m o u n t o f te c h n i ca l i n ve s ? ga ? o n to b e u n d e rta ke n .
86
P re - e d i ? ng ca n i n vo l ve adding or va ryi n g sec ? on s, cl a u s e s and va l u e s in th e co m m e rci a l
m a ste r. I t ca n a l s o i n vo l ve i n s e r ? n g s u p p l e m e n ta ry gu i d a n c e co ve ri n g p re fe rre d p ro p ri e ta ry
p ro d u ct s , p ro d u ct s and p ra c ? ce s to be a vo i d e d , addi ? on a l a d vi ce on u se o f cl a u se s, and
s u g ge ste d te xt fo r s u p p l e m e n ta ry c l a u s e s .
M o d i fyi n g t h e co m m e rci a l m a ste r s p e c i fi ca ? o n syste m i n t h i s wa y ca n i n vo l ve a l o t o f wo rk –
n o t l e a st i n co p i n g wi t h u p d a ? n g. O ffi c e s s h o u l d co n s i d e r ca re fu l l y t h e e xte n t a n d n a tu re o f
s u ch m o d i fi ca ? o n to e n s u re t h a t th e e ff o rt wi l l b e re p a i d .
7.2 System so ?ware

A fe w s p e ci fi e rs s ? ll u se co m m e rc i a l m a ste r s p e ci fi ca ? on syste m s by m a rki n g up a p ri n t
co p y o f th e cl a u s e s , h a vi n g i t wo rd p ro c e s s e d b y a d m i n i stra ? ve sta ff, th e n ch e cki n g i t fo r
a c cu ra c y ( i f ? m e p e rm i ts ) .
Th e re co m m e n d e d p ra c ? ce fo r t h e m a j o ri ty o f U K s p e c i fi e rs i s to e d i t t h e text o n s c re e n ,
u si n g so ? wa re su ppl i e d wi th th e co m m e rc i a l m a ste r sp e ci fi ca ? on syste m . Th e u su a l
fe a t u re s o f s u ch s o ? wa re i n cl u d e :
• n a vi ga ? on a n d m a n i pu l a ? o n o f th e co n te n t wi th o n l y l i m i te d co m p u te r a n d ke yb o a rd ski l l s;
• s p e ci fi ca ? o n b e gi n s b y s e l e c ? n g wo rk s e c ? o n s re l e va n t to t h e p ro j e c t;
• cl a u s e s a n d re l a te d gu i d a n c e d i s p l a y a u to m a ? ca l l y s i d e b y s i d e ;
• th e sta t u s of te xt is d i s p l a ye d d u ri n g p re p a ra ? on of a s p e ci fi ca ? on , e . g. ‘s e l e cte d ’,
‘d e l e te d ’, o r ‘d e ci s i o n n o t ye t ta ke n ’ ;
• h i gh l i gh ? n g o r re p o r ? n g o f cl a u s e s th a t h a ve b e e n s e l e cte d b u t n o t co m p l e te d , e . g. th e y
re q u i re i n s e r ? on or d el e ? o n o f te xt;
• a u to m a ? c n u m b e ri n g o f u s e r- ge n e ra te d c l a u s e s ;
• e a sy i n s e r ? o n o f d a ta fro m o t h e r s o u rc e s a t a n y p o i n t, e . g. d ra wn d e ta i l s , s p re a d s h e e ts
a n d cl a u s e s fro m o th e r p ro j e ct s ;
• a u to m a ? c u p d a te o f d a ta a n d s o ? wa re , o n ce t h e d e ci s i o n to u p d a te h a s b e e n m a d e ;
• go o d ra n ge o f wo rd - p ro c e s s i n g a n d o u tp u t fe a t u re s , e . g . p ri n ? n g fu n c ? o n a l i ty;
• a d e q u a te s o ? wa re h e l p i s b u i l t i n ; a n d
• em bed d ed h yp e rl i n ks , to en a bl e u s e rs to a cc e s s s o u rc e s s u ch as we b s i te s , on l i n e
d o cu m e n t s a n d re s o u rce s , o t h e r wo rk s e c ? on s.
87
Ad d i ? on a l fe a t u re s of th e so ? wa re ( wh i c h som e o ffi ce s m ay re ga rd as essen ? al) m ay
i n cl u d e :
• a b i l i ty to c re a te o ffi ce m a ste r sp e ci fi ca ? on s, wi t h cl a u s e s a n d /o r gu i d a n ce a d d ed ,
d e l e te d o r a m e n d e d ;
• h i gh l i gh ? n g o r re p o r ? n g o f c l a u s e s a n d gu i d a n ce i n c l u d e d i n u s e r- ge n e ra te d s p e ci fi ca ? on s
t h a t a re a ff e cte d b y a syste m u p d a te , to fa c i l i ta te re vi e w;
• a b i l i ty fo r th e o ffi ce to co n tro l a c ce s s by di ffe re n t peopl e, e . g. to ‘vi e w on l y’ or ‘e d i t ’
u s e r- ge n e ra te d s p e ci fi ca ? on s; a n d
• a u d i t tra i l i n g o f u s e r- ge n e ra te d s p e ci fi ca ? o n s – wh o m a d e wh a t d e ci s i o n s , a n d wh e n .
In th e fu tu re , we ca n e xp e c t co m m e rci a l m a ste r s p e ci fi ca ? on syste m s to be co m p a ? bl e
wi th b u i l d i n g i n fo rm a ? o n m o d e l l i n g ( B I M ) . Th i s re q u i re s n e w fu n c ? o n a l i t y s u ch a s :
• b i d i re c ? o n a l l i n ka ge b e t we e n t h e s p e ci fi ca ? o n a n d o th e r p ro j e c t d o cu m e n ts ;
• i n te rro ga ? on of th e sp e ci fi ca ? on by t h i rd - p a rty so ? wa re ( e . g. fo r co st es ? ma ? on and
a co u s ? c si m u l a ? on ) ;
• a u to m a te d a s s e m b l y o f t h e s p e ci fi ca ? on ;
• i n te gra ? o n o f th e ch a i n o f wri ? e n d o cu m e n ta ? o n to o l s a l o n g th e e n ? re p ro j e c t ? m el i n e;
• a u to m a te d co m p l i a n c e a n d e rro r c h e c ki n g o f t h e s p e ci fi ca ? on ; a n d
• s u p p o rt fo r a wi d e ra n ge o f re p o rt s and vi e ws , i n cl u d i n g sp e ci fi ca ? on s ge a re d to th e
n eed s of a pa r ? cu l a r a u d i e n ce .
88
8 I m p l i ca ? o n s o f d e s i gn
m a n a ge m e n t
As fa r a s possi bl e, d e ta i l e d d e s i gn o f th e bu i l d i n g sh ou l d be co m p l e te b e fo re p ro d u c ? on
i n fo rm a ? on b e gi n s , and d ra wi n gs a n d th e s p e c i fi ca ? on sh ou l d b e co m p l e te b e fo re te n d e r
ac ? on and co n stru c ? on . H o we ve r, in p ra c ? ce th e p re p a ra ? on o f p ro d u c ? on i n fo rm a ? on
wi l l o ? e n o ve rl a p b o th d e ta i l e d d e s i gn a n d co n stru c ? on .
So m e ? m e s , o ve rl a p ca n b e a d va n ta ge o u s – fo r e xa m p l e , i n co m p re s s i o n o f o ve ra l l p ro j e ct
p ro gra m m e s and m a ki n g b e st u s e o f th e d e s i gn s ki l l s o f s p e c i a l i st co n st ru c to rs . H o we ve r,
o ve rl a p ca n a l so gi ve ri s e to poor te ch n i ca l and d i m en si on a l co o rd i n a ? on , re s u l ? ng in
wa ste fu l re wo rki n g a n d d e fe c ts .
D e s i gn is a h i gh l y i te ra ? ve p ro c e s s , wi th m a n y co m p l e x d e p e n d e n c i e s b e twe e n e l e m e n ts,
a n d m a n y ‘re vi e w a n d re vi s i o n ’ c ycl e s .
A b a s i c p ri n c i p l e i s th a t t h e p ro d u c ? o n i n fo rm a ? o n fo r a n y gi ve n e l e m e n t o r t yp e o f wo rk m u st
b e fre e fro m s u b s e q u e n t d e s i gn d e p e n d e n ci e s b e fo re i t i s p re p a re d a n d u s e d fo r co n stru c ? on .
Th i s p ri n ci p l e s h o u l d b e fu n d a m e n ta l to t h e p re p a ra ? on of a d e ta i l e d p ro d u c ? on pl a n fo r
th e p re p a ra ? on o f th e m od el fi l es and d ra wi n gs l i ste d in th e d ra wi n gs re gi ste r o r m a ste r
d o cu m e n t i n d e x.
Th e p l a n sh ou l d fo l l o w t h e p ri n c i p l e o f m u l ? d i s ci p l i n a ry b u i l d - u p o f d ra wi n gs d e s cri b e d in
sec ? o n 8 . 1 o f t h i s g u i d e . I t s h o u l d co n s i st o f a s e q u e n ? a l s e ri e s o f a c ? o n s , e a c h sta ? n g th e
i n fo rm a ? on to be a d d ed , in o rd e r to gu a rd a ga i n st o m i s s i o n s and wa ste fu l ‘b a ckt ra cki n g ’
d u ri n g p re p a ra ? o n o f t h e b u i l d i n g m o d e l s a n d d ra wi n gs .
Th e p l a n s h o u l d t h u s d e fi n e th e re q u i re d m o d e l fi l e s , stru c tu re d to gi ve t h e re q u i re d d e gre e
of fl e xi b i l i t y a n d p o te n ? a l re u s e o f t h e i n fo rm a ? o n . Th e p l a n s h o u l d a l s o s h o w t h e t ra n sfe r
of fi l es fro m on e d e s i gn d i s ci p l i n e to a n o t h e r, and th e ? m es fo r m o d e l fi le and d ra wi n gs
a va i l a b i l i ty ( i f u s e d , s e e s e c ? o n 8 . 1 o f th i s gu i d e ) .
Th e pl a n sh ou l d ta ke i n to a cco u n t th e re q u i re d s e q u e n ce fo r co m p l e ? on o f d ra wi n gs fo r
‘wo rk p a c ka ge s ’, i f u s e d . Th e co m p l e te d pl a n sh ou l d b e c h e c ke d to e n s u re th a t i t p ro vi d e s
fo r t h e co m p l e ? o n o f a l l d ra wi n gs i n th e d ra wi n gs re gi ste r.
89
Implica ? ons of design management
The mul ? disciplinary build- up of drawings from a BI M follows a similar pa ?ern from project
to project, and there will be much commonality between the produc ? on plans for di fferent
projects of similar type and size.
Design o ffi ces may fi nd it useful to prepare template checklists to help ensure that all
items of informa ? on to be added at each stage are remembered. Wherever possible, such
templates should be mul ? disciplinary.
8.1 Time and resource programming

The Produc ? on Plan should have determined the op ? mum sequence for preparing the
models and drawings, and this should be the basis for alloca ? ng resources and programming.
These decisions will be based on the availability of suitably skilled personnel from the
various design team organiza ? ons, and the requirements of the overall project programme.
The outcome of this process should be a ? me and resource programme (see Figure 37).
Historically, detailed programming has been based on es ? mates of ? me for each drawing,
but this will be unrealis ? c for the mul ? disciplinary build- up procedure recommended for
model fi le and drawing development.
Base es ? ma ? ng on the ac ? vi ? es set out in the produc ? on plan, grouped together as

required to give an appropriately coarse ‘grain’ to the programme.
A simpli fi ed but basically sound programme is far more valuable than a highly detailed but
cumula ? vely inaccurate one. Detailed planning of smaller sec ? ons of the master plan does
have advantages (last planner, lean processes, etc.).
The programme should make appropriate allowances for the detailed design and
documenta ? on inputs of all consultants and specialist constructors, and should be
coordinated with the programme for producing the speci fi ca ? on. I t should be agreed with
all par? es, including the major constructor (if known).
In order to make the change to the mul ? disciplinary Common Data Environment (CDE)
method described above, normal planning of model and drawing produc ? on giving total
number of models and drawings, produc ? on ? me and resource alloca ? on should be used in
the early stages of learning. However, as experience of the method is gained, it will become
apparent that drawing produc ? on is delayed while the model fi les are established and
90
PROJ ECT N AM E:
DRAWI N G PROG RAM M E
PROJ ECT VALU E:
ID Drafti n gs N am e Du ration Resou rce J an
I ni ti als T F M T S W S T F M T S W S T F M T S W S T F M T S W S T F M T S W S T F M T
1 L1 Si te Locati on Pl an 5 days BT
2 L2-L4 Fl oor Pl an s: Bl ock A 1 0 days BT
3 L5-L6 Fl oor Pl an s: Bl ock B 7 days BT
4 L7-L8 Factory Process Layou t 7 days BT
5 L9 Roof Pl an : Bl ock A 4 days LS
6 L1 0 Roof Pl an : Bl ock B 4 days LS
7 L1 1 -L1 2 Secti on s 8 days BT
8 L1 3-L1 4 El evati on s 1 0 days SS
9 L1 5-L1 7 Cei l i n g Layou ts: Bl ock A 5 days VS
10 L1 8-L20 Fu rn i tu re Layou ts: Bl ock B 5 days BT
11 0 days
12 S1 -S2 Door I ron mon g ery Sch edu l e 5 days SS
13 S3 San i tary Sch edu l e 5 days VS
14 S4 Wi n dow Sch edu l e 2 days SS
15 S5-S6 Fi n i sh es Schedu l e 4 days SS
16 0 days
17 A1 -A35 Wal l s Assembl y 25 days BT
18 A51 -A60 Stai rs Assem bl y 8 days VS
19 A1 01 -A1 1 9 Roof Assem bl y 1 0 days LS
I m p l i ca
20 A1 51 -A1 80 Open i n gs Assembl y 20 days SS
21 A201 -A21 3 Cei l i n g s Assem bl y 5 days VS
22 A251 -A260 Fi tti n gs Assembl y 5 days BT
?
23 A301 -A31 1 Extern al Wal l s Assem bl y 5 days VS
o n s o f d e s i gn m a n a ge m e n t
24 0 days
25 C1 -C50 Doors/Wi ndows Com pon en ts 1 0 days SS
26 0 days
27 0 days
28 0 days
29 B. Ti e Project Arch i tect 78 days
30 S. Su i t Archi tect 55 days
31 L. Ski rt Arch i tectu ral Techn ol og i st 32 days
32 V. Scruffy Arch i tectu ral Techn ol og i st 32 days
N OTES:
Figure 37: Simpli fi ed ? me and resource programme

91
coordinated. The delay is more than compensated for by the ease of genera ? on of large
batches of good- quality drawings in a short space of ? me.
This is because the fi nal stage of drawing ac ? vity consists of simply selec ? ng, saving and
annota ? ng views and fi lling in ? tle blocks. This methodology does not limit the drawing
set to the ini ? al Drawings Register: further drawings at greater or lesser scales can be
produced swi ? ly from the same data. Experience will lead to improved ? me and resource
programming.
8.2 Approval of informa ? on
To ensure that model and drawing fi les are adequately checked, some form of approvals
process needs to be in place to enable the design teams and the contractor (or client) to
approve and sign o ff the development of the design informa ? on for a project. The design
approval process should be speci fi ed, agreed and documented as early as possible in the
project.
This process should also include a full check of the data coordina ? on and registra ? on across
the whole data set before the design check proceeds. It should also include an assurance
that the data to be approved has been checked for compliance with the agreed Standard
M ethod and procedures. The physical method of checking should be adopted for the release
or publica ? on of M 2 and M 3 models, as well as DR fi les.
Table 16 shows the approval stages for ge ? ng a model to a status that is ‘fi t for internal
review’. At this stage, the model fi les can be used to create drawings.
Table 16: Approvals stages for a model fi le
Approval route Descrip ? on Revision Status

N /A Peer check PP1 S1 – Fit for coordina ? on
Stage 1 Lead Designer and Design PPn S3 – Fit for internal review
Coordinator sign o ff
92
To move a document to a status of ‘ fi t for construc ? on’ requires it to be submi ?ed for
contractor/client approval. Once the design is deemed ‘ fi t for construc ? on approval’, the
originator will submit all documents to the contractor or their representa ? ve, this may be
the Lead Designer. When the contractor or representa ? ve is sa ? s fi ed that the document
completely ful fi ls its purpose and is ready for use as a construc ? on document, they should
sign o ff the document as a fully coordinated piece of informa ? on, and issue it.
Status ‘A’ The document is approved for construc ? on purposes.
Status ‘B’ The document requires minor revisions before being moved to full
construc ? on status.
Status ‘C’ The document requires major work before resubmi ? ng for approval.
It is common for the following designa ? ons of approval to be given:
N ote that in addi ? on to approval statuses A, B and C, status D is used for unapproved
documenta ? on that is required by the contractor for some use other than construc ? on (see
Figure 13).
H aving reached status ‘A’, a document will be returned to the Originator who will enter
the status in the relevant status box on the document and issue for construc ? on with the
revision series ‘C1’ being noted. Further construc ? on issues will then be marked as Rev C2,
C3 and C4, etc.
Further issues and amendments will be marked with a revision cloud and the appropriate
descrip ? on for the revision entered in the revision box. For subsequent issues, the preceding
revision cloud should be removed so that only the revision under the revision amendment
is highlighted.
For a more detailed view of the approvals stages, see the process diagrams in Appendix B
and in par? cular B.7 and B.8.
93
Ap p e n d i x A
M a ste r d o cu m e n t i n d e x
te m p l a te
A m a ste r d o c u m e n t i n d e x ( M D I ) s h o u l d b e p ro d u c e d a t th e sta rt o f th e co n tra ct . Th e D e s i gn
Co o rd i n a ? o n M a n a ge r o r t h e CAD Co o rd i n a ? o n M a n a ge r s h o u l d e sta b l i s h th e d e l i ve ra b l e s
fo r t h e p ro j e ct a n d a gre e t h e s e wi t h a l l te a m m e m b e rs . Th i s s h o u l d b e co o rd i n a te d wi t h th e
p l a n a n d re s o u rce a l l o ca ? o n s i n th e d e s i gn m a n a ge m e n t s e c ? o n a b o ve .
Th e M DI wi th i ts m i l e sto n e s and d e l i ve ry d a te s sh ou l d be u sed to m a n a ge th e ? m el y
d e l i ve ry o f t h e m o d e l fi l e s a n d d o cu m e n ts /d ra wi n gs o th e rwi s e s e ri o u s d e l a ys wi l l re s u l t i n
d e l i ve ry o f t h e d e ta i l p ro d u c ? on i n fo rm a ? on . Th e m i l e sto n e s a n d d e l i ve ry d a te s wi l l n eed
to b e co o rd i n a te d wi th th e p ro j e c t a n d p l a n d e l i ve ry re q u i re m e n ts .
Wh e n t h e M D I i s u p l o a d e d to th e P ro j e ct e xt ra n e t, th e ‘Re vi s i o n ’ co d e s h o u l d b e s e t to = P 0
a n d t h e ‘S ta tu s ’ co d e s e t to = S 0.
95
Appendix A
96
Ta bl e 1 7 : M D I te m pl a te
Fi l e i d en ?fi er M od e l or d ra wi n g ? tl e Del i very d a tes
Project Originator Zone Level File Discipline N umber M ilestone M ilestone M ilestone M ilestone Etc.
type 1 2 3 4
WH RW 01 LG1 DR M 00002 Lower Ground Floor 1

Plant room and Riser
Loca ? on
WH RW 01 GF DR M 00003 Ground Floor Plant

room and Riser
Loca ? on
AW NG 02 GF DR E 10001 Electrical Services

Containment Layout
AW NG 02 GF DR E 10001 Electrical Services

Containment Layout
AW NG 03 ZZ DR E 10002 Power Distribu ? on &

Earth Schema ? c
SH CA 00 LG2 DR A 00001 1:500 Level LG2 Plan
SH CA 00 LG1 DR A 00002 1:500 Level LG1 Plan
SH CA 00 GF DR A 00003 1:500 Level G Plan
SH CA 00 01 DR A 00004 1:500 Level 1 Plan
AW AR 12 F1 DR S 08001 Founda ? on layout
AW AR 14 F1 DR S 08002 RC Retaining wall, ramp

and slab layout
Ap p e n d i x B
P ro c e s s m a p s
97
B.1 Crea ? ng a model fi le
Ap p e n d i x B
98
EXTRANET / EDMS Solution

Work I n Prog ress WI P
SHARED
N ote: Th e overal l project model i s spl i t i n to
secti on s/areas cal l ed 'Zones'. Each Zon e, for
START POI N T 1 exampl e Zones '01 ', i s of a su i tabl e si ze to en abl e
Arch. Model File:
effecti ve i nform ati on shari ng by th e vari ou s desi g n
Cli en t bri ef an d /or u pd ate Fi l e-i den ti fi er= SH-CA-01 -01 -M3-A-000001
team s.
m od el requ est
MDI list upload Revi si on= P0
Statu s= S0 (MDI upload)
The l evel is i n di cated by two ch aracters u su al l y 01 ,
I nitiate design in Fi l en am e= SH-CA-01 -01 -M3-A-000001 .txt
02 etc. I f thi s i s con fu sed with th e Zon e th en ‘Z’
response to the brief
cou l d be prefi xed to the zon e code to avoi d thi s.
Arch itect
Arch i tectu ral WIP

in form ati on Arch. Model File:
WI P Arch .
Fi l e-i den ti fi er= SH-CA-01 -01 -M3-A-000001
M odel fi l e Revi si on = P0
Create Arch. model file
Statu s= S0 (Fit for Coordination)
(e. g. for Zones=01 )
Fi l en am e= SH-CA-01 -01 -M3-A-000001 .dwg
Arch itect
Check & revi ew th e project pl an

I nternal check review
for l ate del i very. I n form pl an n ers
by designer
of l ate del i very.
Arch itect
Update pl an an d di stri bu te. Sh ow
new del i verabl es or i n crease
Ch ecked M odel fil e resource. Arch. Model File:
Model fi le Sh ared Revi si on = P1
U pload Arch. model fi le
Status= S1 (Fit for Coordination)
(e. g . for Zones=01 )
Archi tect’s
Docu ment Controller
Figure 38: Crea ? ng a model fi le

B.2 Sharing a model fi le

EXTRANET / EDMS Solution

START POI N T 2 Work I n Prog ress WI P
SHARED
Download Arch . M odel Sh ared M odel Fi l es
referen ced i n to th e Stru ctu ral
WI P Arch. Model File:
Stru ctural Eng ineer
Revi si on = P1
Fil en am e= SH-CA-01 -01 -M3-A-000001 .dwg
N ote: Th e Arch itectural Zone 01

may not be exactly the same
Arch Model File:
Fi l e-i denti fi er= SH-CA-01 -01 -M3-A-000001
Revi si on = P1
as th e Structural Zone 01

WIP
Struct Model File:
Fi l e-i den ti fi er= SH-AR-01 -01 -M3-S-000001
Develop Struct. Model Revi si on= P0
Devel op th e
(e. g . for Zones=01 ) with Status= S0
Stru ctu ral m od el
overlaid Arch . M odel i n Con text Fi l en am e= SH-AR-01 -01 -M3-S-000001 .dwg
Stru ctu ral Engineer
I nternal check review Ch eck & revi ew the project pl an for

by designer late del i very
Stru ctu ral Eng ineer

Update pl an an d di stri bu te. Sh ow
new del i verabl es or i ncrease
Ch ecked M odel fil e
resource. Struct. Model File:
U pload Stru ct. M odel file Revi si on= P1

M odel fi l e Sh ared Statu s= S1 (Fit for Coordination)
(e. g . for Zones=01 )
Fi l enam e= SH-AR-01 -01 -M3-S-000001 .dwg
Stru ctu ral

Docu ment Controller
Ap p e n d i x B
N ote: Thi s process i s carri ed ou t by
al l desi g n roles
Figure 39: Sharing a model fi le

99
B.3 Coordina ? ng model fi les
Ap p e n d i x B
1 00
START POINT 4 Work In Progress WIP EXTRANET / EDMS Solution
Download Arch. Model

Shared Model Files SHARED
Structural Engineer Arch. Model File:
Arch. Model File: File-identifier= SH-CA-01 -01 -M3-A-000002
File-identifier= SH-CA-01 -01 -M2-A-000002 Revision= P1
Revision= P1 Status= S1 (Fit for Coordination)
Status= S1 (FitWIP
for Coordination) Filename= SH-CA-V1 -1 -M2-A-000002.dwg
Take ownership of Struct Model File: Filename= SH-CA-V1 -1 -M2-A-000002.dwg
Structural objects File-identifier= SH-AR-01 -01 -M3-S-000002
(e.g. add column) and Revision= P0
create Struct. model Status= S0 (Work in Progress)00002.dwg
Structural Engineer Struct. Model File:

Struct. Model File with File-identifier= SH-AR-01 -01 -M3-S-000002
transferred layers Revision= P1
Status= S1 (Fit for Coordination)
Filename= SH-AR-V1 -1 -M2-S-000002.dwg
Upload Struct. Model file
Structural Inform Architect of Generate
Document Controller transfer of ownership GO TO START
any Drawing
POINT 5
Structural Engineer Renditions (DWF)
Download Struct.
Model
Architect updates Model File
Struct. Model File:
Architect File-identifier= SH-AR-01 -01 -M3-S-000002
Revision=WIP
P1
Arch. Model File: Status= S1 (Fit for Coordination)
File-identifier= SH-CA-01 -01 -M3-A-000002
Filename= SH-AR-V1 -1 -M2-S-000002.dwg
Delete objects that have Revision= P1 .1
been moved and Status= S0 (Work in Progress)
update Arch. model Filename= SH-CA-V1 -1 -M2-A-000002.dwg
Architect
Arch. Model File:
File-identifier= SH-CA-01 -01 -M3-A-000002
Revision= P2
Upload revised Arch. Arch. Updated Model file Status= S1 (Fit for Coordination)
Model file Filename= SH-CA-01 -01 -M2-A-000002.dwg
Generate
Architect’s Document GO TO START
any Drawing
Controller POINT 5
Renditions (DWF)
Figure 40: Coordina ? ng model fi les

B.4 Transfer of ownership

Work I n Prog ress WI P EXTRANET / EDMS Solution

START POI N T 3
SHARED
Sh ared M odel Fi l es:
Servi ces an d Stru ctu ral
Download other
referenced i n to th e Building Services Model File:
Arch itectu ral WI P Fi l e-i den ti fi er= SH-RW-01 -01 -M3-E-000001
Revi si on = P1
rol es’ M odels
(e. g. for Zones=01 ) Statu s= S1 (Fit for Coordination)
and overlay with Arch . Fi len am e= SH-RW-01 -01 -M3-E-000001 .dwg
M odel
Building Services Model File:
Fi l e-i den ti fi er= SH-RW-01 -01 -M3-E-000001
Arch itect Revi si on= P1
StructStatu s= S1 File:
Model (Fi t for co-ordi n ati on)
Fiden
Fi l e-i l enam e= SH-RW-V1
ti fi er= SH-AR-01 -01 -1 -M2-E-000001
-M3-M-000001.dwg
Stru ct. &
Revi si on = P1
Bu i l di n g Servi ces
Statu s= S1 (Fi t for co-ordi n ati on ) WIP
model s
ArchFi lModel File:
en am e= SH-AR-01 -01 -M2-S-000001 .dwg
Fi l e-i denti fi er= SH-CA-01 -01 -M3-A-000001 Struct. Model File:
Revi si on = P1 .1 Fi l e-i den ti fi er= SH-AR-01 -01 -M3-S-000001
Revi si on = P1
Coordinate Arch. M odel
Statu s= S0 (Work in Progess)
Fi l en am e= SH-CA-V1 -1 -M2-A-000001 .dwg Status= S1 (Fit for Coordination)
with oth er roles’ Fi l en am e= SH-AR-01 -01 -M3-S-000001 .dwg
overlaid Models
Arch itect
WIP
Arch Model File:
Remove an y l ayers th at Revi si on = P1 .1
are n ow own ed by the Status= S0 (Work in Progress)
stru ctu ral or M EP Fi l en am e= SH-CA-01 -01 -M2-A-000001 .dwg
en g i n eers. Exam pl e:
col s or beam s. Al so
Arch Model File:
Fi l e-i den ti fi er= SH-CA-V1 -1 -32-A-000001
revi se an d u pdate
Revi si on= P2
Arch i tectu ral M odel fi l e
and sen d to sh ared.
Fi l enam e= SH-CA-V1 -1 -M2-A-000001 .dwg
Ch eck & review th e project pl an
Ap p e n d i x B
GO TO START
POI N T 4 for l ate del i very
1 01
Figure 41: Transfer of layer ownership

B.5 Crea ? ng a drawing rendi ? on
Ap p e n d i x B
1 02
START POI N T 5 Work I n Prog ress WI P DOCUMENT REPOSITORY

Sh ared M odel s SHARED
Download any models
Archi tect
Arch Model File:
WIP Struct. Model File:
Ref.
Fi l e-i den ti fi er= SH-CA-01 -01 -M3-A-000001 Revi sion = P2
Revi sion = P0
m odels
Statu s= S3 (Fit for Internal Review)
Statu s= Struct.
S0 (Work Model File:
in Progress) Fi len am e= SH-AR-01 -01 -M2-S-000002.dwg
denti fi er= SH-AR-V1
l e-iSH-CA-01 -1 -M2-S-000002
Fi len am Fie=
Revi si on = P2
WIP -M2-A-000001
-01 .dwg
Extract views and compile drawings
Reference model(s) or Fi l en am e= SH-AR-V1 -1 -M2-S-000002.dwg
extracted views into

Arch. Drawing File (DWG):
Fi l e-i den ti fi er= SH-CA-01 -01 -DR-A-000001
Drawing
Revi si on = P0
Statu s= S0 (Work in Progress)
sheet template
Fi l en am e= SH-CA-01 -01 -DR-A-000001 .dwg

Arch itect
WIP
WI P Drawi n g
Arch. Drawi n g Ren di ti on (DWF) :
Generate Drawing ren di tion DWF fi l e SH-CA-01 -01 -DR-A-000001

Fi l e-i den ti fi er=
Revi si on= P0
rendition (. dwf, . pdf) fi le
Statu s= S0 (Work in Progress)
Fi l en am e= SH-CA-01 -01 -DR-A-000001 .dwf
Arch itect
Arch . Drawi n g Ren di ti on Fi l e (DWF) :
Team si g n off, peer revi ew

SH-CA-01 -01 -DR-A-000001
Revi si on =P1
Approval Rou te= STAGE 1
Sh ared Drawi n g
U pload Arch. Drawing
ren di ti on DWF fi l e
Fi l enam e= SH-CA-01 -01 -DR-A-000001 .dwf
rendition (DWF) file
Arch i tect’s
Docu ment Controller GO TO START
Design Team
sign-off process
POI N T 6
Approval Rou te: Stage 1
Figure 42: Crea ? ng a drawing rendi ? on

B.6 Design team sign-o process
ff
START POI N T 6 Work I n Prog ress WI P DOCUMENT REPOSITORY

SHARED
Design Team Sh ared Drawi n g Ren di ti on (DWF)
sign-off process
Approval Route: Stag e 1
Arch . Drawi n g Ren di ti on Fi l e (DWF) :
Desig n Teams and SH-CA-01 -01 -DR-A-000001
Design M anager Revi si on = P1

GO TO START
POI N T 2
NO
Approved? WIP
Arch. Drawing File (DWG):
X
N ot
Fi l e-i den ti fi er= SH-CA-01 -01 -DR-A-0001 00
YES
u pdated
Revi si on= P1
Categ ory= n/a
WIP
Fi l enam e= SH-CA-01 -01 -DR-A-0001 00.dwg
Arch. Drawing File (DWF):

Amend Title Block Revi si on = P2
Status= S4 (Fit for Client Approval)
Arch itect Fi l en am e= SH-CA-01 -01 -DR-A-000001 .dwf
Arch. Drawing Rendition File (DWF):

Revi si on = P2
U pload Drawing
Statu s= S4 (Fit for Client Approval)
Approval Rou te= STAGE 2
Rendition

Architect’s Docu ment
Controller
Ap p e n d i x B
GO TO START Client Approval process
POI N T 7 Approval Rou te Stage 2
1 03
Figure 43: Design team approval stage 1

B.7 Approval route – stage 2
Ap p e n d i x B
1 04
DOCUMENT REPOSITORY
START POINT 7 Work In Progress WIP SHARED
Client Approval process: Shared Drawing Rendition (DWF)

Approval Route Stage 2
Client Arch. Drawing Rendition File (DWF):
File-identifier= SH-CA-01 -01 -DR-A-000001
Revision= P2
Status= S4 (Fit for Client Approval)
GO TO START Filename= SH-CA-01 -01 -DR-A-000001 .dwf
POINT 2
NO
Approved?
WIP
X
YES Not
updated Arch. Drawing File (DWG):
File-identifier= SH-CA-01 -01 -DR-A-0001 00
Revision= P1
Status= S3 (Fit for Internal Review)
WIP 00.dwg
Filename= SH-CA-01 -01 -DR-A-0001
Arch. Drawing File (DWF):

Amend Title Block Revision= C1
Status= A (Fit for Construction)
Architect Filename= SH-CA-01 -01 -DR-A-000001 .dwf

Upload Drawing Rendition Revision= C1
Architect’s Document Approval Route= STAGE 3
Controller Filename= SH-CA-01 -01 -DR-A-000001 .dwf
GO TO START Pre-construction issue

POINT 8
sign-off process:
Figure 44: Approval route: stage 2

B.8 Approval route – stage 3

DOCUMENT REPOSITORY
START POINT 8 Work In Progress WIP
SHARED
Pre-construction issue Shared Drawing Rendition (DWF)
sign-off process:
Design Arch. Drawing Rendition File (DWF):

File-identifier= SH-CA-V1 -1 -DR-A-0001 00
Manager Revision= C1
Filename= SH-CA-V1 -1 -DR-A-000001 .dwf
NO
GO TO START
Approved?
POINT 2
YES
Approved Drawings fit for construction
DOCUMENTATION
Inform Designer to update
the Drawing Title Block Issue drawings to the
Construction team
Design
Manager
File-identifier= SH-CA-V1 -1 -DR-A-0001 00
Revision= C1
Filename= SH-CA-V1 -1 -DR-A-000001 .dwf
Update Drawing (DWG) WIP
Title Block to match
Drawing Rendition DWF Arch. Drawing File (DWG):
File-identifier= SH-CA-V1 -1 -DR-A-000001
Architect Revision= C1
Filename= SH-CA-V1 -1 -DR-A-000001 .dwg
Ap p e n d i x B
Visible to the
construction team
FINISH
1 05
Figure 45: Approval route: stage 3

Ap p e n d i x C
Co n s u l ta n t ’s te ch n i ca l
syste m s q u e s ? o n n a i re
Re fe r to th e PI X P ro to co l c u rre n t l y a va i l a b l e on th e Co n stru c ? on P ro j e ct I n fo rm a ? on
Co m m i ? e e ( CP I C) we b s i te .
1 07
Ap p e n d i x D
P ro j e c t te a m m e m b e r
q u es ? o n n a i re
Re fe r to th e PI X P ro to co l c u rre n t l y a va i l a b l e on th e Co n stru c ? on P ro j e ct I n fo rm a ? on
Co m m i ? e e ( CP I C) we b s i te .
1 09
Ap p e n d i x E
D ra wi n g s h e e t te m p l a te
111
Ap p e n d i x E
112
NOTE THE PROPERTY OF THIS DRAWING AND DESIGN IS VESTED IN (DESIGNER) AND MUST NOT BE COPIED OR REPRODUCED IN ANY WAY WITHOUT THEIR WRITTEN CONSENT
Ap p e n d i x E
KEY PLAN
Construction Risks Maintenance/cleaning Risks Demolition/adaptation Risks

In addition to the hazard/risks normally associated with the types of work detailed
on this drawing take note of the above.
It is assumed that all works on this drawing will be carried out by a competent
contractor working, where appropriate, to an appropriate method statement.
SAFETY HEALTH AND ENVIRONMENTAL INFORMATION BOX

NOTES
Th is drawing contain s the fol lowing m odel fi les:

SH -CA-01 -LG 1 -M 2-A-0001 . d wg [S1 ] [P5]
SH -CA-03-LG 1 -M 2-S-0001 6. dwg [S1 ] [P5]
SH -RW-06-LG1 -M 2-M -0001 0. d wg [S1 ] [P2]
Th is drawing to be vi ewed in con ju nction with:

SH -RW-00-LG1 -DR-M -0001 0. dwf
I SSU ED FOR CON STRU CTI ON
C1
G.M.WHIPP 1 5/03/03
I SSU ED FOR CLI EN T APPROVAL
P4
G.M.WHIPP 21 /02/03 D.KERR 22/02/03 R.CHADWICK 23/02/03
I SSU ED FOR I N TERN AL REVI EW
P3
G.M.WHIPP 1 5/02/03 D.KERR 1 7/02/03 R.CHADWICK 1 9/02/03
I SSU ED FOR I N FORM ATI ON
P2
G.M.WHIPP 08/02/03
FI RST DRAFT
P1
G.M.WHIPP 01 /02/03
COMMENT
REV
DRAWN BY DATE CHECKED BY DATE APPROVED BY DATE
SCALES @ A1 ISSUING OFFICE PROJECT NUMBER
1 :200 MANCHESTER 1 234
CLIENT APPROVAL
X A - APPROVED
B - APPROVED WITH COMMENTS
C - DO NOT USE
A FOR_CONSTRUCTION
ORIGINATOR
NAME, ADDRESS and LOGO
PROJECT
PROJECT_TITLE
TITLE
DRG_TITLE_1
DRG_TITLE_2
DRG_TITLE_3
CLIENT
CLIENT NAME / LOGO

DRAWING NUMBER REV
SH-V1 -1 -A-CA-DR-0201 40 C1
113
Appendix F
M easurements and bene fi ts
The bene fi ts of using the BS 1192 approach have been measured over many years. H ard
money, so ? cultural and social bene fi ts have been achieved. The measurements are
reported in a number of case studies, some from the Avan ? project and some from previous
government-funded research and live projects. Some examples are made available in this
appendix below.
F.1 Project results – overview report

F. 1 . 1 Introduc?on
This report has been produced for the Avan ? programme M anagement Board and
summarizes the headline results of the independent ‘M easure & M onitor’ undertaken by
Capita Symonds. The inten ? on is for this document to be reviewed by representa ? ves of
the Board so that they can provide any ‘accompanying or overview’ commentary they feel
appropriate.
The measured impacts are presented with no signi fi cant ‘post processing’ in order that
they can withstand rigorous examina ? on by third par? es (as is an ? cipated) and be directly
supported with audit trails back to the source data. As a result, the measurements tend to
re fl ect impacts upon business or project processes rather than summarized to high- level
project outcomes, i.e. impact on ‘design coordina ? on’ rather than ‘impact upon overall
project cost’.
To process these fi ndings into high- level project outcomes would require a number of
assump ? ons to be made, for example:
• Numeric – number of drawings per project, ? me taken to issue each drawing, number of
issue ac ? vi ? es, chargeable rates per person per day.
• Commercial – all poten ? al savings would be directly translated into cashable savings;
all such savings would be aggregated at the project level rather than by par? cipa ? ng
companies.
115
Appendix F
I t is felt that such assump ? ons would tend to undermine the quality of the results and so
this exercise has been excluded from this report.
The summary has been broken down as follows:
• key measured impacts – investment required, return on investment, commentary;

• emerging themes – 11 themes emerging from interviews, analysis and discussion;
• Appendix 1 – ‘dashboards’ for core projects; and
• Appendix 2 – measurement reports for core projects.
F.2 Key measured impacts

F. 2. 1 Investment required

I f CAD rework is required because the design team implemented the procedures late and/
or original informa ? on was poorly coordinated costs of up to £60,000, and possibly more
may be required. This will be typically self- funded by the individual company.
Where addi ? onal support, third- party audit, is required for compliance checking and 2D/3D
spa ? al coordina ? on checking the investment may be of the order of £100,000. This would
be typically funded by the client and/or the contractor, depending upon the form of contract
(see below for more informa ? on).
Does not include for:
• I nvestment during general disrup ? on/reduced produc ? vity/paid-for training or so ? ware

required while ge ? ng up to speed with Avan ? methods.
• Direct and indirect redesign e ffort where lack of coordina ? on were spo ?ed during
rework process – as this is correc ? ng an inherent fl aw rather than pure ‘rework due
adop ? on of Avan ? ’.
F. 2. 2 Return on investment

• 50–85 per cent saving in cost and ? me related to issuing and receiving informa ? on;
• 50–80 per cent saving in design coordina ? on and builders work coordina ? on;
• 50 per cent quicker turnaround of subcontract design packages;
• ‘£100,000 design rework “‘savings”‘ (see below);
116
Appendix F
• ‘£500,000+ site remedial work “savings”‘ (see below).
Does not include for:
• Return on investment from reduced disrup ? on where fewer design/coordina ? on issues

need to be dealt with on the cri ? cal path as they have been revised earlier (or by default
of reusing others’ informa ? on).
• ‘So ? issues’ bene fi ts, for example more sa ? sfying work, less abor? ve/confronta ? onal
work. See below for more examples.
F.3 Commentary

F. 3. 1 Investment required
The self-funded costs of CAD rework are extremely variable and the sooner Avan ? is
implemented, the less CAD informa ? on that has been generated that then needs to be
reworked in order to be ‘Avan ? CDE/SM P compliant’ (e. g. common origin, orienta ? on,
scale, layer names and fi le names). Three examples are noted for reference:
• £10,000 investment where adopted early in project lifecycle on small /medium- size
development of medium–low complexity.
• £60,000 investment where adopted at a later stage on a project of medium size and
complexity where the legacy informa ? on was not signi fi cantly coordinated.
• £24,000 investment where adopted late on a project of large scale and complexity, but
where scope excluded some key areas of the site, design and some legacy drawings that
would not be signi fi cantly reused by others.
The ‘addi ? onal support for compliance checking and 2D/3D spa ? al coordina ? on’ noted
in the above fi ndings refers to where those roles are supported by resources outside the
tradi ? onal project team service suppliers i.e. client, designers, contractor, subcontractors.
On the case study the design had evolved over a number of years and in an uncoordinated
manner. To bring the informa ?on up to date and coordinated such that a full set of signed
o ff informa ?on was available at contract sign o ff the client paid for the check to be carried
out.
Consultancy services are available for use in such situa ? ons and there is some evidence that
suggests such a role is e ffec ? ve in achieving signi fi cant savings on a project. This impact
117
Appendix F
and the extent to which such a role can be deemed ‘part of the Avan ? method’ is a point of
debate and further comment is included in the next sec ? on.
Disrup ? on during the adop ? on of Avan ? is impossible to predict ‘generically’ as there are
so many factors a ffec ? ng this criterion, for example: when Avan ? is adopted, the strategy
for adop ? on (push or pull), the level of change for the company and level of change for the
individuals e ffected. This cost is noted as being signi fi cant on at least some of the projects
reviewed and should be forecast in order to contribute to the decision to sign up to such a
business/performance improvement ac ? vity. To be very clear, this criteria has the poten ?al
to ‘make or break’ the adop ?on of Avan ? so needs to be properly managed to keep it to a
minimum.
I t is noted that this type of investment would be required for almost any such ac ? vity and
is not speci fi c to the Avan ? methodology if change is to be adopted.
Direct and indirect redesign e ffort where lack of coordina ? on, where spo ?ed during the
rework process, is not included in the cost of implemen ? ng Avan ? as this is viewed as
correc ? ng fl awed design informa ? on rather than pure ‘rework due adop ? on of Avan ? ’. I t
could equally be seen that the level of investment required in this ac ? vity is a direct – and
posi ? ve – measure of the bene fi t gained through Avan ? highligh ? ng design coordina ? on
issues that had previously not been spo ?ed and may have caused disrup ? on and delay on
site.
F. 3. 2 Return on investment
The savings in the processes of issuing and receiving informa ? on are a direct result of the
e ffec ? ve use of a project Extranet; however, the savings emerge from more than one
process:
• agreement to issue one set of paper informa ? on rather than 7–8 copies means saving in
the prin ? ng, prepara ? on and pos ? ng ac ? vi ? es;
• agreement to issue electronic informa ? on in lieu of paper informa ? on for all but key
contract documents further enhances this saving;
• access to latest versions of documents is seen as advantageous, as is freedom to access
‘all’ informa ? on rather than only that considered relevant to the par? cipant; and
• lack or reliance on the post for receipt of key informa ? on accelerates the sharing of
informa ? on.
118
Appendix F
It is noted, however, that if project Avan ? Standard M ethod and Protocol are not set up and
adhered to the process can become extremely frustra ? ng.
Examples include: not being able to fi nd informa ? on, having to download ‘all’ informa ? on
and lack of well- managed revision control. It is also noted that any savings achieved might
be reduced if excessive amounts of ad hoc prints are generated by project sta ff.
F. 3. 3 Request for informa ?on (RFI) analysis on a single core project
Though not included at this stage as results were not available from the Contractor, some
comment is required as there is a debate as to how and how much these results can be
a ? ributed to the Avan ? methodology. Key points for discussion are noted below.
Subsequent measurements were made available from one contractor and the impact of the
Avan ? method is fully a ? ributed to savings in excess of 10 per cent of construc ? on cost.
• ‘£100,000 design rework (poten ? al) savings’

– This measure is noted as a poten ? al saving (only) in this case as the issues were
iden ? fi ed (through compliance checking and spa ? al coordina ? on) on this project
rather than avoided at source. Comparison to other similar projects may show that
‘all this and more’ problems may typically have happened – hence the a ? ribu ? on as
poten ? al savings on other future projects where full compliance would mean the
rework is not required.
– This value does not include any measure of ini ? al rework ac ? vity during adop ? on
of Avan ? , which fl ushed out many more design coordina ? on issues that required
rework – as men ? oned in sec ? on F.2.1 of this appendix. On this core project, the
value of this rework was put at approx £100,000+ fee.
• ‘£500,000 saving in avoiding remedial works’
– This value of £500,000 is in lieu of the fi nal analysed value and can be seen as a
saving; however, some considera ? on is needed as to the likelihood of how many of
the iden ? fi ed issues would have had 100 per cent of the impact noted. It is likely that
many would be caught before needing remedial work. There were two key types in
issue noted:
b Clashing informa ? on (approx 30 per cent of issues) – this is clearly within scope for
‘compliance with Avan ? CDE/SM P’ as it s ? pulates reuse of package owners own
CAD layers. For example, the issue about there being three con fl ic ? ng loca ? ons for
rainwater down pipes would have been avoided if reuse of layers had been fully
complied with.
119
Appendix F
b M issing informa ? on (approx 70 per cent issues) – for example a dimension missing
from the se ? ng out of a steel beam centre line. This issue is less intrinsically
covered other than in the catch- all statement of fi t for purpose. If anything the lack
of dimension should not concern those reusing the informa ? on as the CDE/SM P
states all informa ? on should be drawn in the actual loca ? on, to common scale and
orienta ? on – so it should be in the right posi ? on.
• It is further noted that con fl ic ? ng informa ? on within a single discipline is also
not speci fi cally covered as Avan ? CDE/SM P typically focuses on the processes for
interdisciplinary sharing of informa ? on.
• Where missing or con fl ic ? ng informa ? on has been iden ? fi ed between plans and
eleva ? ons. However, if the spa ? al coordina ? on exercise was undertaken – possibly in 2D
but de fi nitely in 3D – those issues would have been spo ?ed.
F. 4 E m e rgi n g th e m e s
F. 4. 1 Belief

There is a signi fi cant level of belief that Avan ? is a good way forward, even if most temper
that belief with the prac ? cal reality that there is a more or less signi fi cant pain barrier to get
through. Examples are noted below:
• Client – Slough Estates/Wates have procured a subcontractor where the fi nal decision
was signi fi cantly in fl uenced by their ability to collaborate using I T.
• Contractor/client – Taylor Woodrow have commi ?ed to further projects using Avan ? as
part of a corporate strategy to roll out Avan ? as their standard.
• Design team – Capita Symonds/Capita Percy Thomas are adop ? ng it and other companies
are upbeat (for example Reid Architecture, RW Gregory LLP).
• Contractor – Costain commi ?ed to using Avan ? on more projects and Wates are pleased
with its impact.
• Supply chain – some companies are a li ? le indi fferent; however, some, such as N G Bailey
and ACL are showing interest in accommoda ? ng Avan ? .
F. 4. 2 Achieving payback on a single project

There are some poten ? ally interes ? ng trends here that would warrant further inves ? ga ? on
if more core projects are monitored as the bene fi ts appear to ‘follow the informa ? on fl ow’
through a project:
120
Appendix F
• Architects – they seem to break even soonest and most certainly on a single project,
likely because they are the highest creators and reusers of others’ informa ? on, so they
stand to gain if it works well.
• Engineers (Structural and Mechanical & Electrical) – it is not certain that they will reach
full payback on the fi rst project; however they are likely to ‘approach’ break even.
• Subcontractors – limited/early results suggest that the experience for subcontractors is
not ‘signi fi cantly nega ? ve’ with some showing that they are ‘approaching break even’
and others low investment and return means ‘indi fference’.
• Contractors – results vary with some showing net gains, some less op ? mism while s ? ll
going through the adop ? on process, and others repor? ng ‘indi fference’.
F. 4. 3 Fixed, single industry- wide Avan ? CDE/SMP or a flexible

approach?
This needs to be bo ?omed out among Avan ? partners and then made clear to the industry.
• Project view – is the team procured on the basis of complying with Avan ? ?
• Yes – then they have the opportunity to take a commercial view in bidding for the work
and should be required to comply (including any investment required as a result).
• N o – then possibly some fl exibility to make them converge on an ‘Avan ? - esque’ standard
as a stepping stone to full Avan ? compliance. This posi ? on should enable them to agree
a par? al Avan ? /Avan ? - oriented CDE/SM P on the project without larger investment/risk
that would have required agreement prior to contract award.
• Corporate/framework view
– For this scenario there can only be one sensible long- term posi ? on and that is to be
fully compliant with the industry standard. Any varia ? on from the standard will mean
ine ffi ciency and disrup ? on when working with others that are fully Avan ? compliant.
There would need to be a very good reason for not going with an industry standard.
– However, the only issue here is where a company works on a project where a par? al
implementa ? on of Avan ? has been rolled out that they have worked to accommodate
in their corporate standards. Such a company may be reluctant to go through a further
change process.
F. 4. 4 Model files and their impacts
This appears to be one of the main ‘technical’ impacts for project par? cipants as it improves
their ability to share well- structured CAD data. It is also an area where many of those involved
need coaching as it was a new principle (see item on necessity of coaching). Examples of
how it helped include:
121
Appendix F
• Avoiding the need to spend large amounts of ? me preparing informa ? on for interim
‘design development’ drawing issues as, instead of ‘? dying up everything for formal
paper issue’, the team can simply issue their CAD model fi les without any signi fi cant
preparatory work.
• This not only saves signi fi cant ? me – o ?en on the cri ? cal path – but also reduces the
amount of demo ? va ? ng and immediately superseded work that those designers would
otherwise have spent on that ac ? vity.
• For the subcontract design packages there is a sugges ? on that increased ability to reuse
design team and ‘other subcontractor’ design informa ? on means the e ffort required to
prepare the base drawing is signi fi cantly reduced.
• M any or most manual dimensional checks can be replaced with a visual check as all
par? es working in same orienta ? on scale and origin means design elements are in their
‘real’ posi ? on so gross errors are easily spo ?ed visually.
F. 4. 5 Level of challenge

For many there was discomfort experienced during the adop ? on of the Avan ? method. The
level of discomfort varied and we do not, as yet, have any clear data on this; however, there
were three posi ? ve results that are worthy of note:
• Bourne Steel was concerned that the scope of Avan ? was not as challenging as
they had hoped. Bourne Steel’s view on collabora ? on around design informa ? on is
that they prefer for share 3D models. Steel contractors have been using 3D steelwork
modelling systems for a number of years and Structural Engineers are increasingly
using similar systems to develop their designs for issue to and reuse by the Steelwork
contractor. The feeling is almost ‘why bother doing all this 2D- oriented process change
when we can simply share 3D models?’ As it happens Avan ? is fully extensible to 3D
models and the same issues apply when more than one ‘discipline/package’ needs to
share informa ? on.
• The Architects on Voyager Park had already implemented a corporate environment that
was based upon a predecessor to Avan ? , CPI C ‘Code of procedure’: 2003, and as a result
there were minimal changes required by them to be able to bene fi t.
• Solaglas felt that while Avan ? appeared to be a daun ? ng method to implement, on closer
inspec ? on they felt it readily usable without signi fi cant discomfort.
122
Appendix F
F. 4. 6 Increase in quality of informa ?on
There are two aspects worthy of note here:
• The Avan ? CDE/SM P provides a mechanism for ensuring good- quality informa ? on
is created and shared among the team. O ?en on projects there is no contractual or
procedural mechanism for addressing underperformance in this respect and as a result
many par? es will waste signi fi cant amounts of ? me ‘cleaning up’ others’ CAD data, or
simply ‘redrawing it’ from the paper copies.
• Also, where such informa ? on is co- located from both plans and details, the increase
in quality of informa ? on due to inherent coordina ? on through reuse of others’ CAD
informa ? on/layers for both of these levels of details is equivalent to an amount of e ffort
that would not be feasible (programma ? cally or commercially) to invest in or reproduce
tradi ? onally.
F. 4. 7 Consequen ?al bene fits
Although the value of disrup ? on during change could add signi fi cantly to the ‘cost’ element
of the cost–bene fi t equa ? on, the ‘consequen ? al bene fi ts’ arising from adop ? on of Avan ?
are poten ? ally enormous. The bene fi ts include:
• Avoiding disrup ? on of delay on the cri ? cal path – for any ac ? vity in design or construc ? on.
The highest tangible impact of this is with construc ? on ac ? vi ? es. I f disrup ? on due to lack
of design coordina ? on delays, for example, weather sealing of a site, then the impact
can be the costs of delays to packages not star? ng, cost of accelera ? on of works to try
and catch up and poten ? al cost associated with late aquired defects (L&AD).
• Ripple/wake e ffect – in addi ? on but less tangibly, the above scenario will distract all
involved from the ac ? vi ? es they were programmed to be undertaking. This can cause
further problems where the planned ac ? vi ? es become rushed (while fi re-fi gh ? ng the
ini ? al problem) and as a result may create new issues to be dealt with later. The alternate
view on this means having the ? me to do the job ‘properly’ meaning other packages
more likely to go smoothly.
• Less ? me spent on paperwork/issue resolu ? on means all par? es spend more ? me doing
the job they enjoy and so are more mo ? vated.
• Fewer ‘risk events’ on a project will generally mean all par? es are more likely to achieve
their expected pro fi t margins.
123
Appendix F
• Over ? me, lower risk projects will a ? ract lower risk con ? ngencies from all involved and
so pass on a saving to the client in more commercially compe ? ? ve fees/tenders.
The fi nal statement above is consistent with experience from the steelwork supply chain
where 3D models have been used to prepare design informa ? on.
F. 4. 8 Which projects are most likely to benefit from Avan ??

Some interviewees have suggested that smaller and/or one- o ff projects are less likely to
bene fi t from Avan ? . Others have suggested that where the complexity of the work is low
and the team well established they will not need Avan ? . There will certainly be projects
where the cost of change may well be more than is commercially feasible for individual
companies unless either paid for by others (e. g. the client) or as part of self-sponsored
corporate change (i.e. companies deciding to go that way anyway). Avan ? could do with
advice in this area to support teams inves ? ga ? ng whether to implement Avan ? on their
projects.
Addi?onal measurement outside the Avan ? project show that the process and procedure
once implemented can show significant savings on even small housing projects.
Larger projects and those where there is repe ? ? on – either of design or of project team
(e. g. design team/supplier frameworks) – appear to lend themselves to adop ? on of Avan ?
as there is a greater number of opportuni ? es to ‘redeem the value’ of the investment made.
F. 4. 9 Benefits and risks of a <100 per cent Avan ? implementa ?on

I t is evident that on the three core projects the base/core Avan ? CDE/SM P has not been
adopted 100 per cent. Areas of the site, packages of work, legacy design informa ? on, aspects
of layer/fi le naming, use of common origin, ‘actual’ reuse of CAD data/layers … all these
have been excluded in some way across one or more of the core projects. By inference,
therefore, there are signi fi cant bene fi ts to be generated from a ‘par? al implementa ? on’ of
Avan ? . This is not something that the custodians would advocate; however, the sugges ? on
is that a less than 100 per cent implementa ? on may be an appropriate ‘stepping stone’
to full implementa ? on where there is an acceptable level of risk and investment for the
project team.
124
Appendix F
The risk in the above statement is that, once the ini ? al step has been taken, no further steps
towards complete Avan ? compliance are made and – even worse – the teams involved felt
that they are fully compliant. Scaling this up from a single project to a wider industry view,
the risk is that we end up with a prolifera ? on of ‘par? al Avan ? ’ implementa ? ons.
Or even worse ‘my version’ of the standard. Personaliza ?on of the standard is a constant
problem where the team’s lack the background knowledge or acceptance of the problem
that the standard is rec?fying. The teams do not see or are not willing to see the holis?c
view only the ‘what’s in it for me’ and my responsibili?es.
To counter this, we suggest some restric ? on or monitor be placed upon the level of
compliance with the Avan ? ‘core CDE/SM P’ so that even if teams comply 100 per cent with
a par? al implementa ? on, they are aware that there are addi ? onal aspects that would need
to be addressed to become 100 per cent compliant with the core Avan ? CDE/SM P.
F. 4. 1 0 Need for ac?ve, independent support and coaching
Some of the par? es that have been involved in the adop ? on of Avan ? have been less
high- end users of CAD to date and as a result are not familiar (either at opera ? onal or
management levels) of certain concepts – such as reuse of CAD fi les, ‘xrefs’ or reference
fi les, use of layers, etc.
I n addi ? on, in some instances there are real and speci fi c technical issues that the users
or their CAD management do not have the skills to address. Examples include set- up of
specialist applica ? ons based upon AutoCAD; and use of ‘look- up tables’ to translate
automa ? cally established layer names to Avan ? - compliant ones on issue to the rest of the
team.
125
Ap p e n d i x G
Ab b re vi a ? on s
Ta bl e 1 8: E xa m pl e l i st of a bbrevi a ? on s
Term Ab brevi a ? on
Ab o ve O rd n a n c e D a tu m AO D
B a ck i n l e t gu l l y BI G
Bea m B ( p re c e d i n g a b e a m re fe re n c e )
B e n ch m a rk BM
B l o c kwo rk B LK
B o re h o l e BH
B ri ck wo rk BWk
B ri ? s h S ta n d a rd BS
Ca l i fo rn i a B e a ri n g R a ? o CB R
Ca tch p i t CP
Ce n tre l i n e CL
Ce n tre s CRS
Ch a i n a ge CH
Ci rc u l a r h o l l o w s e c ? on CH S
Co l u m n C ( p re c e d i n g a co l u m n re fe re n c e )
Co m b i n e d m a n h o l e C ( p re ce d i n g m a n h o l e n u m b e r)
Co n cre te gra d e C ( p re c e d i n g gra d e )
Co n tro l p o i n t CP
Co ve r l e ve l CL
Cro s s - s e c ? o n a l a re a CSA
Cu t-o ff l e ve l CO L
D a m p p ro o f m e m b ra n e DPM
D a tu m DAT
127
Appendix G
Te rm Abb re vi a ? on
Dead load DL
Degree DEG
Dense bituminous macadam DBM
Depth or deep DP
Diameter DI A
Disused DIS
Drawing DRG
Eas ? ng E
Electricity or electrical ELEC
Equal angle EA
Equally spaced EG
Exis ? ng EX
External EXXT
Figure FI G
Finished fl oor level FFL
Finished road level FRL
Foul manhole F (preceding a manhole number)
General Arrangement GA
Gradient GRA, 1 in 4, or 25 per cent
Grid line G/L
Ground level GL
Gully (unknown type) G
H eight H
H igh point HP
H igh tensile steel T (preceding bar diameter)
H ot rolled asphalt H RA
H ot rolled sec ? on HRS
I nspec ? on chamber IC
I nternal IN T
128
Ap p e n d i x G
I n te rs e c ? on poi n t IP
I n ve rt l e ve l IL
La m p co l u m n LC
Le ? hand LH
Le ve l LVL
Li ve l o a d LL
Lo n g L
Lo w p o i n t LP
M a n h ol e MH
M a xi m u m M AX
M e d i u m d e n s i ty p o l ye th yl e n e M DPE
M i l d ste e l R ( p re ce d i n g b a r d i a m e te r)
Minimum MIN
N o rth i n g N
N u m ber No
O ffset O /S
O ve rh e a d O /H
Pe tro l i n te rce p to r PI
Po i n t l o a d PL
Ra d i u s R AD ( fo l l o wi n g a d i m e n s i o n )
R a i n wa te r d o wn p i p e RWP
Re cta n gu l a r h o l l o w s e c ? on RH S
Re fe re n c e Re f
Re i n fo rc e d co n c re te RC
R i gh t h a n d RH
Ro a d gu l l y RG
Ro l l e d ste e l a n gl e RSA
Ro l l e d ste e l c h a n n e l RS C
Ro l l e d ste e l j o i st RS J
129
Ap p e n d i x G
Te rm Abb re vi a ? on
Ro o f l e ve l RL
Sec ? on S E CT
Se ? n g ou t poi n t SOP
S h e e t p i l e wa l l SPW
So ffi t l e ve l SL
S o i l ve n t p i p e SVP
Sp e ci fi ca ? on SP EC
S q u a re S Q ( fo l l o wi n g a d i m e n s i o n )
S q u a re h o l l o w s e c ? on SH S
S ta n d a rd STD
S ta ? on STN
S to rm m a n h o l e S ( fo l l o wi n g m a n h o l e n u m b e r)
S tru c tu ra l s l a b l e ve l SS L
Ta n ge n t p o i n t TP
Te m p o ra ry b e n c h m a rk TB M
Th i c k TH K
To l e ra n ce TO L, o r +5 –5
To p o f s e c ? on TO S
Tre e P re s e rva ? o n O rd e r TP O
Tri a l p i t TP
Typ i ca l o r typ i ca l l y TYP
U n d e r gro u n d U /G
U n e q u a l a n gl e UA
U n i fo rm l y d i stri b u te d l o a d U DL
U n i fo rm l y va ryi n g l o a d U VL
U n i ve rs a l b e a m UB
U n i ve rs a l b e a ri n g p i l e U BP
U n i ve rs a l co l u m n UC
Vo l u m e VO L
130
Ap p e n d i x G
Wa ste ve n t p i p e WVP
Wa te r l e ve l WL
We i g h t WT
Wh o l e c i rcl e b e a ri n g WCB
Wi d e o r wi d th W
Wi n d l o a d WL
Ya rd gu l l y YG
131
Ap p e n d i x H
Re fe re n c e s a n d fu rth e r
re a d i n g
Standards publica ? ons
EN I SO Technical drawings — General principles of presenta ?on — Part 21:

1 2 8-2 1 : 2 001 ,
Prepara?on of lines by CAD systems

BS 1 1 9 2 -1 : 1 9 84 ?
( wi t h d ra wn ) , ?
Co n st ru c— Recommenda?ons for
on d ra wi n g p ra c ce
general principles
BS 1 1 9 2 -3 : 1 9 8 7 Construc?on drawing prac?ce — Recommenda?ons for
( wi t h d ra wn ) ,
symbols and other graphic conven ?ons

BS Collabora ?ve produc?on of architectural, engineering and construc?on
1 1 9 2 : 2 007,
informa ?on — Code of Prac?ce

Construc?on drawings — Designa?on systems — Part 1: Buildings
B S E N I S O 41 5 7 -1 : 1 9 9 9 ,
and parts of buildings ? ( I t i s i d en ca l to I S O 41 5 7 - 1 : 1 9 9 8 )
BS EN I SO Construc?on drawings — Designa ?on systems — Part 2: Room

41 5 7 -2 : 1 9 9 9 ,
names and numbers ? ( I t i s i d en ca l to I S O 41 5 7 - 2 : 1 9 9 8 )
BS EN I SO ?
41 5 7 -3 : 1 9 9 9 , Co n stru cDesigna ?on systems Part 3: Room
on d ra wi n gs – –
iden ?fiers ?
(I t is id en ca l to I S O 41 5 7 -3 : 1 9 9 8 )
Technical drawings — Scales

B S E N I S O 5 45 5 : 1 9 9 5 , ? ( I t i s i d en ca l to I S O 5 45 5 : 1 9 7 5 )
BS 6 1 0 0- 1 . 0 : 1 9 9 9 Glossary of building and civil engineering terms —

( su b cl a u se 1. 5. 7) ,
General and miscellaneous — General

Graphical symbols for use on equipment Index and synopsis
I S O 7 0 00 : 2 0 04, –
BS Design management systems — Part 4. Guide to managing design in

7 0 00 -4: 1 9 9 6 ,
construc?on
Construc?on drawings — Simplified representa?on of demoli?on and
BS E N I SO 75 1 8: 1 9 99 ,
rebuilding
BS EN I SO Construc?on drawings — Representa ?on of modular sizes, lines
85 60: 1 9 9 9 ,
and grids
Graphical symbols incorpora ?ng arrows Synopsis
I S O 1 0 48 8 : 1 9 9 1 , –
Construc?on drawings — Landscape drawing prac?ce

BS E N I SO 1 1 09 1 : 1 9 9 9 ,
Technical product documenta ?on — Organiza?on and naming of

B S E N I S O 1 3 5 6 7 -1 : 2 0 02 ,
layers for CAD — Overview and principles
133
Ap p e n d i x H
Technical product documenta ?on — Organiza?on and naming of

BS E N I SO 1 3 5 67-2 : 2 002 ,
layers for CAD — Concepts, format and codes used in construc?on documenta ?on
Graphical symbols Vocabulary
I S O 1 7 7 2 4: 2 0 03 , –

8 0 41 6 -1 : 2 00 8 , –
Crea ?on of graphical symbols for registra ?on

I EC 8 0 41 6 -2 : Basic principles for graphical symbols for use on equipment Part 2:
2 0 01 , –
Form and use of arrows

8 0 41 6 -3 : 2 00 1 , –
Guidelines for the applica?on of graphical symbols
Other publica ? ons
Avan ? ICT Collabora ?ve Working: Toolkit documents

, , CP I C
CAWS CPIC Common Arrangement of Work Sec?ons

– ? , Lo n d o n , R I BA P u b l i ca on s
CI/SfB Construc?on Indexing Manual/Samarbetskommi?en for Bygganadsfragor

– , Lo n d o n ,
?
R I BA P u b l i ca ?
o n s ( 1 9 9 1 ) , Ab ri d ge m e n t o f Th i rd ( 1 9 7 6 ) e d i on
NHS Estates publica?on Engineering symbols and drawing conven ?ons A catalogue for
– –
the use in health care premises , Lo n d o n , H M S O, I S B N 01 1 3 2 1 48 8 X
PIX Protocol Guide and Toolkit , B u i l d i n g Ce n tre Tru st ( M a rc h 2 00 4)
Produc?on Informa?on A code of procedure for the construc?on industry

– , CP I C ( 2 00 3 )
I S B N 0 -9 5 1 2 6 6 2 -6 -8
Uniclass Unified Classifica?on for the Construc?on Industry

– , R I BA P u b l i ca ? on s
134
Ap p e n d i x I
Co n ta ct d e ta i l s
Th e fo l l o wi n g a re t h e co n ta ct d e ta i l s o f t h e a u t h o r o f th i s gu i d e :
M e rvyn Ri ch a rd s
Te l : + 44 ( 0 ) 7 7 6 8 9 7 7 3 40
E m a i l : M e rvyn . ri ch a rd s 1 @ n t l wo rl d . co m
135
Building Information Management
Mervyn Richards
The key to producing quality buildings within budget and on time is managing building information
throughout the construction process and into occupation with the full collaboration of the whole
construction team.
This book sets out the framework for a process for building information management that enables
greater productivity, risk management, improved margins and sustainability. It also explains how BS
1 1 92, when used correctly, can form a good basis.
The process is described step by step with key aspects highlighted and is applicable to every size of
project and practice. The three specific areas addressed in the production information process are: roles
and responsibilities; the Common Data Environment (CDE); and the Standard Method and Procedure
(SMP).
A move from a document-centric to an information-centric environment is enabled, thereby unlocking

the power of technology. The process is based on established information that has been tried and
tested in live projects and if adhered to without modification it is possible to achieve the following
benefits:
• Between 25% and 30% of the construction cost that is due to incomplete, inaccurate and
ambiguous production information can be saved.
• Figures of 1 8% reduction in drawing costs have been demonstrated and an overall cost benefit of at
least 1 0% on the contract sum.
• The process offers the potential for greater saving in the delivery of the lifecycle information and
the asset management data to be used and updated throughout the life of the facility or utility.
BSI order ref: BIP 2207
BSI Group Headquarters

389 Chiswick High Road
London W4 4AL
Mervyn Richards
www.bsigroup.com
• Between 25% and 30% of the construction cost that is due to incomplete, inaccurate and
ambiguous production information can be saved.
• Figures of 1 8% reduction in drawing costs have been demonstrated and an overall cost benefit of at
least 1 0% on the contract sum.
© BSI copyright
389 Chiswick High Road

London W4 4AL
www.bsigroup.com
© BSI copyright

Bip 2207-2010

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bip 2207-2010

Uploaded by

Copyright:

Available Formats

Building Information Management

A Standard Framework and Guide to BS 1 1 92

© Bri ? sh Standards Ins ? tu ? on 2010

Typeset in Calibri by H elius, www.helius.biz

Bri?sh Library Cataloguing in Publica ?on Data

Th i s gu i d e i n cl u d e s re l e va n t sec ? on s fro m th e a c kn o wl e d ge d gro u p s , bu t a l so i n cl u d e s

n e w i n fo rm a ? o n fro m c u rre n t l e a rn i n g b y th e Co n stru c ? o n P ro j e c t I n fo rm a ? o n Co m m i ? ee

Produc?on Informa ?on: A code of procedure for the construc?on industry, pu bl i sh ed by

PIX Protocol Guide and Toolkit, p u b l i s h e d b y t h e B u i l d i n g Ce n tre Tru st. N o w a va i l a b l e fro m

Ava n ? , I CT Co l l a b o ra ? ve Wo rki n g: To o l ki t d o c u m e n t s . Co n stru c ? n g E xce l l e n c e 2 0 04. N ow

M a n y o f th e i m a ge s in th i s gu i d e a re ba sed on th ose ﬁ rst pu bl i sh e d in CP I C ’s Produc?on

2 Produc ? on informa ? on for the construc? on industry 3

4 Roles and responsibili ? es 13

5 The Common Data Environment (CDE) 17

6 Standard Method and Procedure

8 Implica ? ons of design management 89

Appendix A Master document index template 95

Appendix B Process maps 97

Appendix C Consultant’s technical systems

Appendix D Project team member ques? onnaire 109

Appendix E Drawing sheet template 111

Appendix F Measurements and bene ﬁ ts 115

Appendix G Abbrevia ? ons 127

Appendix H References and further reading 133

Appendix I Contact details 135

3 : E xa m p l e wo rk-i n - p ro gre s s a rch i te cts ’ m o d e l s 24

2 1 : Co m p l e te d a rch i te ctu ra l sta i rca s e co re 56

stru ctu ra l fra m e a s s e m b l y 56

2 3 : Co m p l e te d st ru ctu ra l sta i rca s e co re 56

2 5 : D u ctwo rk + a rch i te ctu ra l + stru ctu ra l fo r two

4: Example of originator codes 51

6: File types – for drawings and models 61

7: File types – for documents 61

8: Role codes (from BS 1192) 62

10: Examples for purpose of issue 67

11: Se ? ng out a building grid 72

12: Drawing sheet sizes 77

13: Drawing sheet scales 77

14: Example of layer name codes 78

15: Presenta ? on codes from BS 1192 79

16: Approvals stages for a model ﬁ le 92

B ri ? sh S ta n d a rd B S 1 1 9 2 : 2 00 7 , Collabora ?ve produc?on of architectural, engineering and

‘b e st- p ra c ? ce ’ m eth o d fo r th e d e ve l o p m e n t, o rga n i za ? on a n d m a n a ge m e n t o f p ro d u c ? on

to th e sa m e fo rm and q u a l i ty – en a bl i n g it to be u sed and re u s e d wi th o u t c h a n ge or

or sch e d u l e s of wo rk. In a Bu i l d i n g I n fo rm a ? on M od el l i n g ( BI M ) wo rki n g e n vi ro n m e n t

• roles and responsibili ? es;

2. 2 Com m on Da ta E n vi ron m e n t ( CDE )

• coordina ? on of the project model ﬁ les in 2D as they develop;

• produc ? on of 2D drawings using 2D CAD dra ? ing so ? ware;

2.3 Standard Method and Procedure (SMP)

To implement this SM P, the following eight principles should be followed:

• La ye r sta n d a rd : a gre e a ‘l a ye r- n a m i n g sta n d a rd ’ ba sed on BS 1192 th a t i n cl u d e s a

• An n o ta ? o n : a gre e a sta n d a rd fo r a b b re vi a ? o n s , te xt d i m e n s i o n s a n d sym b o l s a n d e n s u re

co n s u l ta n ts , su ppl y ch a i n p a rtn e rs , e tc. ) m u st a gre e and co m m i t to i t. E a ch o rga n i za ? on

th a t a re ‘xre f ’ o r ‘re fe re n ce ’ ﬁ l es.

th a t a re ‘xre f ’ o r ‘re fe re n c e ’ ﬁ l es.

3 D vi s u a l i za ? on 3 D i m a ge s fro m th e 3 D CAD m o d e l o r a vi rtu a l

co n stru cte d ; u s e d fo r vi s u a l i z i n g th e p ro j e ct.

CAD sta n d a rd S ta n d a rd u s e d to p ro d u c e CAD m o d e l s th a t wi l l

CI AT Ch a rte re d I n s ? tu te o f Arc h i te c tu ra l Te c h n o l o gi sts .

syste m o ri g i n a ? n g fro m Swe d e n .

data Informa ? on not yet interpreted or analysed.

DGN File extension for Bentley Systems’ M icroSta ? on