Reliance on, and co-ordination of trade and consultant advice

Several claims have revolved around whether the architect was prudent or competent in applying the advice from others. A claim based on co-ordination issues is also likely to involve the architect. The corollary is that an architect is expected to have the competence to recognise when specialist input is required, and to communicate that need to the client.

In general terms an architect is not expected to be an expert in all things, but because the architect’s documentation usually co-ordinates the input of others, the architect is required to exhibit prudence and competence in that task. The level of skill required is that of a competent architect engaged on a similar project: it is not necessary to “second guess”, nor to take responsibility for the inputs of others.

Sources of information from “others” includes – but is not limited to – technical data from trade suppliers, input from specialist consultants (eg engineers), local body records and requirements, and the owners/clients/users. The limitations of such inputs are that the information may be of a generalist nature applicable to all projects; based on only a partial (and perhaps evolving) knowledge of project requirements; focussed only on the interests of the particular author or product; incompatible with associated construction elements; wrong, inadequate or inaccurate; require a level of accuracy or project resources beyond the usual; or some combination of any and all of these circumstances!

Examples from claims where this reliance and co-ordination has created a liability:

• The allocation of responsibility for co-ordination needs to be clearly acknowledged. To what extent does it fall to the project manager, or the architect, or is within the scope of other specialist consultants? Who is observing the contract (and to what level)? Who is administering it? Examples: geotech advice via structural engineer to architect or PM; QS input in relation to design constraints; PM/client instructions to design team; separate contractors versus sub-contractors or nominated subcontractors.

• Wind and corrosion zones affect weathering details and fixing requirements: those shown on the TA maps may not be appropriate to a specific site, or for a particular feature of the building.

• Minimum deck or roof falls permitted by trade data or building code compliance may not be appropriate. Consider (at least): moisture held by wind-blown detritus; substrate or structural deflection; applied finishes (perhaps tiling); construction tolerances; penetrations; perimeter detailing; expected level of installation workmanship; post-construction foot traffic; expected level of maintenance; faith in the likely performance of the product; possible heavy short-term weather events…..

• Standard details: Suppliers provide these to copy/paste into drawings but it is still necessary for the architect to be satisfied they are suitable. If it is necessary to “tweak” them to suit the project, they are no longer “standard” and may not fit within the compliance statements offered by the supplier. Similarly the details in the NZBC Acceptable Solutions.

• Certificates, Appraisals, Codemarks, warranties and guarantees: What will happen if these are required but not provided? Are they current, relevant, enforceable, applicable or worth anything? We have had claims where such things have been withdrawn or expired before (or soon after) design but before the product failed; others where the product was covered but not its installation; others where overseas documentation was not appropriate for NZ. Where such documents are subject to ongoing maintenance, that needs to be known to those responsible for it.

• Design-build: the integration and coordination of façade panel systems, roof sandwich panel systems, window assemblies and other elements may be dependent on preliminary information which may create later difficulties. Whilst the detailing of each element may work, mixing and matching them might not, and may prevent the issue of a completion statement. It is by no means unknown for design-build proposals to be withdrawn or substituted. Or unrealistic. These constraints need to be acknowledged ahead of time so that they can be resolved in the usual course of business, instead of being a problem later on.

• Dimensional tolerances: Where the installation of one item is dependent on another there is a need to accommodate variances and construction requirements. Structural deflections are a reality, as are dimensional deviations, moisture-induced movement and long-term creep. A well-considered design should be easier to build and continue to function as expected.

• The owner’s understandings of boundary positions, covenants and cross leases, relationships with neighbours, or applicable workplace/usage regulations may be inadequate or wrong. Where these are critical to the project, the architect needs to have the proper legal or surveying advice.

• When the architect’s conception of a suitable design/material/detail is supplanted by the client’s specific direction, it needs to be on record that the responsibility for that design decision lies with the client not the architect. Better still if the architect’s objection is made known along with the reasons for it. A similar situation may apply with project managers, other consultants, and to substitutions by the builder.

• When project documentation proceeds on the basis of outline information provided by a specialist consultant, it should be reviewed before work is done on site, and signed off on completion by that consultant. (Fire engineering is a typical example). If that is not done, there is a good chance the architect will become embroiled in the later shortcomings.

The short point is that the architect should not blindly accept and incorporate inputs by others, but in each case consider whether it is reasonable to do so. The role includes seeking clarification, weighing priorities where there are competing or conflicting issues, alerting others to their responsibilities, and refining the project parameters where necessary. To be blunt, it also requires good records to cover your backside if things go wrong!