A/E/C Construction Documents -- international standards of practice

[Lomarandil]

Hello all --

I'm curious to hear about the standard of practice for "100%" or "construction" drawings in your regions of the world. What types of drawings are considered the standard practice to provide to a contractor? What is considered a bonus (nice for the contractor to have, or used to clarify something unusual, but not commonly included)? What would be considered deficient if omitted?

I'm most specifically interested in the A/E/C world, although anecdotes from other disciplines are welcomed.

A few examples from my experience:
[ul]
[li]In the western US, I believe it is most common to provide structural engineering drawings with rebar called out, hooks and splices noted, but not to provide bar bending schedules. I believe that in AUS/NZ, bar bending schedules are more commonly included in the designer's submittal.[/li]
[li]In the eastern US, I understand that it is somewhat common for connection design and detailing to be omitted and delegated from the structural EOR to another party.[/li]
[li]In Cambodia, electricians typically work from an electrical schematic design, and maybe a panel layout. Details are usually left to their discretion.[/li]
[li]The use of 3D views and BIM models (outside the design team) seems to vary widely.[/li]
[/ul]

Thanks!


----
just call me Lo.

 

[jayrod12]

Central Prairies north of the border here.

- Call off rebar, bends, hooks, etc. Type of splices expected at each instance. Otherwise no bending schedules or anything like that. All of that is on the rebar supplier to detail on his shop drawings. Four sided closed stirrups are the norm.
- For steel, connection design and detailing is delegated 100% of the time. You show an intent, and give the loading(if you're a better engineer, the regular guys just have them designed for wl/2), and let the steel supplier have their connection engineer design everything.
- Usage of BIM models is gaining traction, however everyone is a bit gun shy on the liability standpoint. Who's at fault for errors in the model? So the printed contract documents still are the gospel (which includes the specifications)
- Precast concrete design is also 100% delegated. We show a thickness expected, and a connection intent, and let the precasters figure out the rest. They hire an engineer to design and seal everything including their product's connection to our structure. Good engineer's detail the connection intent such that there is no confusion as to how everything is intended on being supported, the bad engineer's show some convoluted combination of embed plates and steel angles, call nothing off, and say connection by precaster. It gets a bit messy who's on the hook for what.

 

[phamENG]

Mid-Atlantic coast, US -

Exactly what jayrod12 said.

BIM models are very popular, but again the same. Written drawings are the sealed, final product and rule the contract. There are a handful of architects who want to disagree. They spend 98% of their time on getting the model perfect, and then just seal whatever convoluted 2D mess Revit spits out with minimal post processing or cleanup.

 

[PROFR]

jayrod12,
If you are acting as the EOR, you still the one with the upper hand in everything. In the precast design case, do not assume that the precast design engineer is aware of everything. You have to be super-careful of his/her output, especially if the precast elements are supported by elements you designed or the other way around. I have acted in both seats (EOR & Precast Eng.) and I can tell you that many of the precast engineers are "element" focused, i.e., not globally concerned.

 

[Agent666]

I believe that in AUS/NZ, bar bending schedules are more commonly included in the designer's submittal.

In New Zealand this isn't the case at all (can't speak for Australia, but I've never done in it the smattering of aussie jobs I've been involved in). In European practice it is common.

We have the following guideline which in broad terms outline various responsibilities and indirectly what is expected in terms of deliverables at various design and construction stages.

http://nzcic.co.nz/resources/guidelines/

I think the litmus test is basically what does a competent contractor need to know to independently construct whatever it is you designed from your documents. If they need it, put it on the drawings.

There seems to be a move towards providing no dimensions on drawings round these parts, to the general detriment of coordination and taking responsibility for one's design. I try to stress to others I work with if something structural isn't on a grid, then dimension it appropriately and/or check that the architect has appropriate setout provided for the structure.

 

[Settingsun]

I've never done a bar schedule working in Australia. The state roads agencies make you give each bar group a unique identifier and use bar shape codes, but don't require the schedule. I like this level of detail as the shape code sometimes saves a section or detail and the identifier makes communication much clearer.

Outside those clients, just bar size and spacing/number is given. Then you provide sufficient views and details to show the extent and shape.

The general level of detail seems to depend on the industry (commercial, bridge, private infrastructure etc) and company culture. I read an article where one consultant supposedly admitted (anonymously) to not providing any details other than the company's typical details until an RFI was received. That was their view of what the fees in the overcrowded market stretched to.

 

[jayrod12]

If you are acting as the EOR, you still the one with the upper hand in everything. In the precast design case, do not assume that the precast design engineer is aware of everything. You have to be super-careful of his/her output, especially if the precast elements are supported by elements you designed or the other way around. I have acted in both seats (EOR & Precast Eng.) and I can tell you that many of the precast engineers are "element" focused, i.e., not globally concerned.

Oh well aware, hence why I indicated, perhaps too nicely, the difference between good and bad engineers.