Novation - A Guide for Architects

Christopher Larcos , 17 April 2019

Novation can create confusion for architects and builders alike. Christopher Larcos offers a legal primer to the contractual rights and obligations of a novated project.

Novation forms part of a procurement model that was developed to shift risk from the developer of a project to the builder. Novation entails a shift in the role and responsibilities of the architect. To work effectively in novated contexts, architects need to be aware of the differences in procurement models, their rights and responsibilities, and the characteristics of a well-structured novation. This helps ensure that architects are well placed to negotiate contractual agreements that ensure their role and work is not compromised.

Background – from traditional procurement to design and construct

Traditional procurement

In a traditional procurement structure, a developer[1] would engage the architect, and the architect (along with the other consultants) would develop and document the design. Once the documents had reached a sufficiently advanced level, the project would be tendered and the winning tenderer would enter into a works contract with the developer.

In this model, the developer retains the design risk, which means that the builder is not responsible if there is a problem with the design. This is because the developer has provided the design (in the form of working drawings) to the builder. The builder’s responsibility under the works contract is to build what is documented in the working drawings.

Design problems would typically manifest themselves in the following pattern:

  • a defect would become evident – for example, a leaking window;
  • the developer would approach the builder, who would say that what was built was what was documented and, therefore, the leak must be because there was a problem with the way it was documented by the developer’s consultants; and
  • the developer would then approach the architect, who would say that there was nothing wrong with the design or the documents and, therefore, the leak must relate to a defect in the way it was built.

This left the developer in a most unsatisfactory situation in trying to sort out where the problem lay and, from there, who was responsible.

Design and construct procurement and novation

One mechanism to avoid these complications is to move the design risk from the developer to the builder. In this scenario, the construction contract is no longer a works contract; it becomes a design and construct contract, with the builder becoming responsible for both design and construction problems.

In the leaking window scenario outlined above, the builder would not be able to avoid liability for the leaking window for the simple reason that it no longer matters whether the leak arises from a design (including documentation) problem or a construction problem.

One of the key features of a design and construct structure is the novation of the architect (and, often, the other consultants) to the builder. This occurs so that the builder can manage the design risk that is assumed under the building contract.

“Novation” (or, sometimes, “assignment”) describes the following situation:

  • an architect is initially engaged under a contract (such as a client-architect agreement) by a client such as a developer; and
  • at some point, the architect’s counterparty under the contract – the developer – is said to step out of the contract and is replaced by a new client, typically a builder.

Managing novation – a guide for architects

As with most things, design and construct procurement can be well-structured or poorly structured. The structure of the relationship has a substantial impact on the architect’s role and the quality of the built outcome. From an architect’s perspective, the starting point (and, for that matter, the finishing point) is the initial client‑architect agreement between the architect and the developer. This agreement determines what form a novation will take. It is vital that architects understand the consequences of the agreement from the very beginning, and understand their rights and obligations under different client‑architect agreements.

Standard client-architect agreements, such as the pro-forma documents from the ACA or the Australian Institute of Architects, do not include a mechanism for novation. More specifically, there are no contractual provisions that

  • oblige the architect to accept a novation if so directed by the developer; or
  • detail the contractual arrangements that will govern either the novation or the terms of the proposed contract between the architect and the builder.

In the absence of a specific obligation in the initial client‑architect agreement to accept a novation, the architect is, simply, not obliged to respond to any instruction from the initial developer‑client to accept a novation to the builder. Certainly, the architect may choose to do so, but that is quite different to being (contractually) obliged to do so.

The freedom to choose carries with it enormous power in negotiating the terms of the novation. This is further enhanced when one considers that intellectual property rights in the design may remain with the architect. This means that a licence to use the design may not pass to the builder from the developer if the architect remains unwilling to accept a novation.

Poorly structured novation can occur when the contracts used to establish the developer-architect relationship do not include a mechanism for novation, and when the conditions of novation are not effectively negotiated by the architect if and when novation occurs.

Well-structured novation

A well-structured novation is organised through the following documents:

  • an initial client-architect agreement that includes an express obligation on the architect to accept a novation to the builder if so directed;
  • a building contract that includes an express obligation on the builder to accept the novation of the architect if so directed; and
  • terms of the novation governed by something like a “Deed of Novation”, which will be annexed in identical terms to the client-architect agreement and the building contract.

Broadly, therefore, the novation of the architect from the developer to the builder is triggered when the developer directs the architect and the builder to proceed with the novation pursuant to the developer’s power to do so under both the client-architect agreement and the building contract. All three – the developer, the builder, and the architect – will sign the “Deed of Novation.” From this point on, the architect’s client is the builder.

It is often thought that the act of novation involves the builder replacing the developer under the client-architect agreement. In fact, the old contract (between the developer and the architect) comes to an end, and is replaced with a new contract (between the builder and the architect) on the same terms as the former contract.

Liability

In well-structured novation, liability is distributed as follows:

  • the builder will assume an obligation to carry out any of the obligations previously imposed on the developer that remain incomplete as at the date of the novation;

  • on payment by the developer of all outstanding fees, the architect will:
    o   release the developer from any and all claims the architect may have had against the developer; and
    o   accept the liability of the builder in place of the liability of the developer
  • the builder will step into the shoes of the developer as if the builder had been originally named in the client-architect agreement instead of the developer.
Design integrity

Historically, one of the concerns with novation is that the developer‑client loses control of the quality of design; the design integrity. Once the novation has occurred, and the architect is no longer the developer’s direct consultant, the builder may be at liberty to cut corners by, for instance, stripping out architecturally significant detailing or by rationalising materials. This need not be the case, but mechanisms to ensure design integrity must be built into the novation arrangement and the building contract from the start.

In a well-structured novation the “Deed of Novation” will impose an obligation on the architect to report, on a regular basis, to the developer on any proposed design changes and the impact those changes may have on the design intent.

In addition, there is typically an obligation in the building contract for the builder to provide the developer with a design certificate signed off by the architect. These will be (or should be) provided on a monthly basis as part of the payment process.

The obligation on the builder to provide a design certificate to the developer under the building contract, when coupled with the direct reporting of the architect to the developer, re-balances the commercial relationship between the builder and the novated architect. In effect, the builder is no longer at liberty to compromise the design integrity of a project because:

  • the architect will report the matter to the developer under the reporting obligations in the Deed of Novation; and
  • the architect may decline to provide the monthly design certificate to the builder, thereby compromising the builder’s ability to be paid under the building contract.
Deed of Release

Strictly, deeds of release have nothing to do with novation. There is no reason for a contractual obligation to accept a novation to go hand-in-hand with an obligation to provide a deed of release towards the end of the project. However, in some instances architects have been requested to provide a deed of release. This means that it is important for architects to understand the role and background of these documents and check any contract for such requirements.

Historically, deeds of release were documents that builders were obliged (under the building contract) to provide to their developer‑clients. Sometimes they were to be provided at practical completion and sometimes they were to be provided at the expiry of the defects liability period along with the final payment claim. They were not limited to design and construct contracts.

The purpose of such documents is to ensure that the payment claim then being submitted was the final claim the builder was entitled to submit; it was designed to protect developer‑clients from a never‑ending series of (sometimes quite speculative) claims for payment. Mainly, they are one-way documents: the builder releases the developer‑client from any further claims, but the developer‑client remained at liberty to pursue the builder for any claims the developer‑client might have, or might have in future.

The contractual structure typically linked the submission by the builder of an executed deed of release (in a particular form that was appended to the building contract) with the release of part or all of the builder’s security. Thus, any delay by the builder in providing it would delay the release of the security, thereby creating commercial pressure to expedite providing it to the developer‑client.

When applied to consultancy agreements – such as client-architect agreements – deeds of release operate in the same way. That said, and in light of the discussion above on novation generally, any obligation for an architect to provide such a document is purely a creature of contract. Unless the obligation can be found in the client-architect agreement, or the deed of novation, then there is no obligation and architects need not provide one.

Concluding remarks

The purpose of this article has been to provide an overview of novation in the hope that architects can better understand and therefore manage the process. Design and construct as a procurement model, and novation within that model, need not be detrimental to the quality of the architecture or to the financial well‑being of the architect. The key is to understand the structure and thereby negotiate contractual arrangements that empower architects.

 


 

Footnote

1. In this article, the word “developer” is used to refer to the proponent of a project. In private industry, proponents are typically developers, but in public projects the proponent will typically be a government entity.


Christopher Larcos is a Special Counsel with Moray & Agnew Lawyers. He is also a registered architect with over 20 years’ experience and an adjudicator for security of payment matters. Prior to his present role, he spent a decade as a front-end construction lawyer at King and Wood Mallesons and Allens Linklaters.