Communique December 1999

Why Claims Happen (1)

Reviewed June 2009, updated Feb 2017It is probably obvious, but nevertheless worth re-stating, that claims arise because the client considers that the architect’s poor performance has caused the client loss.Less obvious is that the “trigger” is the client’s perception of events, combined with their assessment of the chances of making a recovery from the architect. That raises several issues:

• Managing client perceptions
• Understanding causation – and the contribution of others in the process
• Recognising and managing risks
• Producing documentation to minimise adverse outcomes

A considerable part of an architect’s workload is anticipating and planning for failure - or rather using aesthetic and/or technical strategies to optimise success! Overwhelmingly we are successful in that endeavour, despite the Claims Committee witnessing some of the fallout.For all the potential risk areas, apart from doing what you can as well as you can, perhaps the single most important risk management strategy is to ensure that open, intelligent and informed “good faith” communication is maintained by all, throughout the project. By this means, prospective problems have a far better chance of being addressed before they expand to a confrontation, dispute and claim.Over the life of NZACS, records have been kept of the incidence of failures, and we have the data (fault analysis) necessary to seek some patterns. Alas, the patterns are few, and perhaps that is an inevitable reflection on the complexity and variety of our work. There are perhaps three these, but which are remarkably similar in the number of claims they generate and are listed in order of the architect’s ability to control them:

1. Claims over which the architect has some direct control and which arise as a result of technical or procedural shortcomings.
2. Claims that arise because of the failures of others involved in the production of projects - consultants, contractors, suppliers
3. Everything else: mostly beyond the control by the architect, perhaps as a result of the clients (or officials’) actions or attitude, misplaced (or inept) “expert technical” or legal advice; perhaps just random “Acts of God”.

Claims over which the architect has some direct control

Of category (I) the actual technical failures are relatively few: perhaps because we are terrified of them, we can, and usually do identify areas of potential risk. When they do become claims, occasionally they are a result of ignorance and stupidity, more often the result of a failure to check and follow up on critical aspects of work, and sometimes they arise from new technology or circumstances that could not have been reasonably foreseen.Apart from the technical issues, the procedural aspects of work are where architects can best control their exposure to risk. Yes, all that management stuff:

• Managing risk means anticipating failure and planning how to deal with it. Managing communication (surely a core business?) must anticipate misunderstanding.
• Managing relationships must recognise potentially negative outcomes.
• Planning for risks is as important as planning for anything else: think ahead, lay the groundwork in good documentation, and prepare thoroughly when a dispute arises.

There is a major potential for conflict or risk arising from interfaces: these are where relationships, communication and responsibilities meet - or not - and overlap. Consider:

• Objectives and relationships within client organisations;
• Objectives and relationships between client and architect; and consultants;
• Transfer of client interests to buildable documentation;
• Interpretation of documentation by producers
• Fragmentation of producers by sub-trade, expertise and objectives;
• Changing composition, roles and responsibilities of project team members.

Failure to manage these interfaces gives rise to oft-heard criticisms that the architect was arrogant or lacking objectivity, did not recognise and protect the clients interests, failed to communicate critical project aspects, or failed to control the contractor or consultants. When that happens, the client looses confidence in the architect, and the negative spiral heads for a showdown.It may not at first be obvious that the claim is based on “procedural grounds” and the immediate manifestation may appear to be “technical”; such claims may arise in many different guises:

• Fragmentation of client objectives (or from inexperienced committees)
• Partial services: inability to reconcile site operations with documentation
• Cost over-runs
• Scope of services not adequately specified in terms of engagement
• Failure to document progress of and changes to the scope of works - both during design and when under construction
• Sloppy, incomplete, or inaccurate administration
• Inadequate site information, or failure to use it properly
• Failure to perform, or to meet the client’s expectations
• Failure to satisfy statutory of territorial authority controls
• Poor communication between project participants
• Poor selection and management of the client and project participants.

Claims from the failures of others

Inevitably there is overlap with design and observation failures by the architect, but overwhelmingly the technical failures arise from failures by others - notably poor workmanship - for which architects are blamed on the basis that they “failed to adequately supervise the works”. There will be time when the architect’s details are defective and the tradesman responsibly points out the fact before construction. However, if the architect is only offering partial services – ie is not involved in the construction phase – there is a higher probability that potentially defective details will not be raised for review.It is the unfortunate lot of the architect that if there is a claim against any of the involved consultants, the architect is likely to become involved. To some extent this exposure can be minimised by carefully choosing who you work with, having input into how they are appointed, checking their PI cover, and routinely reviewing how their outputs relate to yours.

Claims from miscellaneous sources

Tops in this field is the “try on” by the client looking to recoup some money from the apparently bottomless pocket of the insurer, or at least to shave the architect’s fees. Such claims are frequently triggered if the architect applies pressure upon a difficult client for fee payment; particularly if there have been some (possibly inevitable) problems during the project.Also in this category are insolvency of client or contractor, copyright issues, loss of documents (fire, computer crashes), mis-measurement of leased areas, and problems with architects also operating as developers.And, let’s face it, some clients are just impossible to please!Some claims arise directly from site operations, or during the progress of the contract. Only rarely do they arise before construction, and then on the basis that the client has foregone a potential benefit (usually “profit”) because of the architect’s failure, or is unwilling to face up to the reality of being able to “get what he wants”. More usually, claims arise some time after completion, or at a late stage in the build, perhaps after a difficult and prolonged project. Many an architect has received a letter from a client or lawyer apparently “out of the blue” well after completion.You can’t protect against random events - fires, storms - which have given rise to several claims when they exposed hitherto unknown defects.