Related Articles
— 11 min read
The role of an architect in construction

Last Updated Aug 30, 2026

Josh Krissansen
122 articles
Josh Krissansen is a freelance writer with two years of experience contributing to Procore's educational library. He specialises in transforming complex construction concepts into clear, actionable insights for professionals in the industry.
Last Updated Aug 30, 2026

The architect's role in construction spans design through to contract administration during the build, where they inspect work, certify payments, and manage variations on the client's behalf.
On many commercial projects delivered under AS 4000 or AS 2124, the architect is engaged as, or alongside, the superintendent, giving them defined contractual powers, not just design input.
In this article, we cover what the architect's role involves during construction, how it connects to the superintendent function, and how contract administrators can manage the relationship so that you can protect programme and payment through delivery.
Table of contents
What does an architect do during construction?
On a commercial project, architects have a number of responsibilities beyond initial drawings:
- Site inspections against design intent: These site inspections involve scheduled visits to check that work in progress matches the drawings and specifications. This differs from general site supervision, which remains the head contractor's responsibility.
- Reviewing shop drawings and submittals. These reviews involve checking product data, samples, and manufacturer information against the shop drawings before materials are ordered or installed, as catching a discrepancy at the submittal stage costs far less than catching it once the product is on site.
- RFI management: Responding to RFIs requires reviewing the question against the drawings, providing clarification or a design decision, and issuing a formal written response that becomes part of the project record. Verbal answers given on site do not carry the same weight if a dispute arises later.
- Variation management (where the architect is the superintendent): Assessing and instructing variations means reviewing a proposed change for design impact, then issuing a formal instruction if the change is approved. This is distinct from simply discussing a change on site, which does not authorise the work to proceed.
- Certifying progress payments. Where the architect holds that authority, this involves reviewing the value of work claimed against work actually completed and confirmed on site before releasing payment. Certification authority sits with whoever holds the superintendent role, so this function is not automatic for every architect.
- Defects list: Compiling the defects list at closeout requires inspecting completed work against the contract documents and listing any items that fall short before the building is handed over.
The limit on the architect's authority is clear: architects can identify non-conforming work but do not direct construction means and methods. That responsibility, and the associated liability, sits with the head contractor.
Distinguishing the architect's role from the superintendent's
The superintendent role under AS 4000 is a contractually appointed position with defined powers, including issuing directions, assessing extension of time claims, valuing variations, and certifying payment claims. The architect is frequently appointed as the superintendent, or the superintendent role sits within the architect's practice, but this is not automatic or universal.
The two roles separate on projects where a separate quantity surveyor or project manager holds the superintendent function, or on design and construct projects where the architect is novated to the contractor and holds design authority without certification authority. AS 2124 remains the older version of this mechanism and still appears on some public sector or legacy contracts.
The practical consequence here is that you should always confirm at contract execution, not during a dispute, exactly who holds the superintendent function.
How the architect's authority affects programme and payment
Each of the functions covered above carries a direct consequence for how the programme runs and when the head contractor gets paid.
Progress payments
The architect, or whoever holds the superintendent function, must assess the value of work claimed against work actually completed before certifying a payment claim.
If the architect disputes the amount claimed or the standard of work, they can certify a lower amount or withhold certification entirely, and the head contractor has no way to force payment on the disputed portion without going through the contract's dispute mechanism.
This means the head contractor's cash flow is directly exposed to a decision they do not control and cannot accelerate.Extensions of time
The architect must assess any extension of time claim against the delay events and the documentation supporting them, and this assessment depends on how quickly the architect responded to RFIs and design queries in the first place.
If the architect is slow to answer an RFI, that delay flows into the trades scheduled after it, and the effect compounds the longer the design response takes.
Whether the head contractor can later recover that time through an EOT claim depends on whether the delay caused by the architect's response time was documented as it happened, since the architect is also the party assessing whether the claim is justified.Variations
The architect must review a proposed change for its design and cost impact and issue a formal instruction before the head contractor can proceed with the changed work under the contract.
Programme pressure often means the head contractor starts the changed work before that formal instruction is issued, because waiting for it would delay the trade sequence. If the architect later disputes that the change was properly instructed, the head contractor is exposed on both the cost and time claimed for that work, since it was carried out ahead of formal authorisation.Non-conforming work
The architect decides whether completed work matches the contract documents or falls short of them, and that decision determines whether the head contractor must rectify the work at their own cost or whether it stands as an acceptable variation from the drawings.
Disagreement between the architect and the head contractor over which of these applies is one of the most common sources of dispute, because the assessment sits with the architect's judgement rather than a fixed measurable standard.
Common friction points between architects and head contractors, and how to resolve them
These consequences for programme and payment tend to trace back to the same handful of recurring issues, each of which has a practical fix.
Design response times that do not match the construction programme
The construction programme moves at a pace set by trade sequencing, while design responses move at the pace the architect can review and answer queries.
When an RFI sits unanswered while the programme keeps running, the head contractor is left choosing between delaying the trade or proceeding without design clarification.
RFI turnaround expectations should be set in the pre-construction meeting, before this pressure builds, and responses that fall outside that window should be escalated in writing, particularly on complex or heritage-sensitive projects where design decisions take longer to resolve.
Ambiguity over who holds certification authority
Not every project makes it clear from the outset whether the architect or a separate superintendent holds certification authority. This ambiguity often only becomes apparent when a payment claim is contested, leaving the head contractor unsure who has the power to resolve it.
This should be settled at contract execution, with the certifying party for payment claims and EOT assessments confirmed in writing before the project starts.
Verbal or informal instructions later disputed
Instructions given on site, in the moment, are often the fastest way to keep work moving, but a verbal instruction carries no weight if the architect later disputes that it was given or disputes what it actually covered.
All instructions should be confirmed in writing before the head contractor proceeds with the work, even where the initial direction was given verbally on site.
Site access and inspection scheduling not agreed upfront
Without an agreed inspection schedule, sign-off at critical trade stages depends on the architect's availability on any given day, which can hold up the programme at exactly the points where speed matters most.
A standing inspection schedule agreed at project kickoff, including expected frequency and notice periods, removes this uncertainty before it affects the programme.
Disagreement over non-conforming work
Whether work meets the standard set out in the drawings and specification is a judgement call, and the architect and head contractor do not always reach the same judgement from the same site observation.
Resolving this through on-site discussion alone tends to turn the disagreement into a matter of opinion. The contract documents and specification are the shared reference point that should settle it instead.
How to manage the architect relationship to protect programme and payment
The friction points above are avoidable with the right groundwork. Confirming authority, keeping records, and putting everything in writing early costs very little at the time and saves a great deal of argument later.
Confirm superintendent authority in writing at contract execution
Certification and EOT assessment powers do not automatically sit with the architect on every project.
Put the question to the architect and the client directly at contract execution: who certifies payment claims, and who assesses extension of time claims?
Get the answer recorded in the contract documents, not just discussed verbally in a pre-construction meeting. This gives the head contractor a clear name and role to direct every claim to from day one, so certification decisions can't stall on a dispute over authority partway through delivery.
Maintain a formal RFI and variation register from day one
Every RFI and variation raises a question later: when was this asked, when was it answered, and what did that delay actually cost?
A register that logs the date raised, the date answered, and the programme or cost impact against each entry builds that evidence as the project runs, when the detail is still fresh and easy to confirm. Set this up before the first RFI goes out, and assign someone to update it weekly rather than reconstructing it from memory when a claim becomes necessary.
Agree inspection and site visit scheduling early
Sign-off at a critical trade stage, such as before slab pour or before wall linings close over services, can only happen once the architect has physically inspected the work. If that inspection isn't booked in advance, the trade sits idle waiting for the architect to find a gap in their diary, and that wait falls directly on the programme.
Set an inspection schedule with the architect at project kickoff, covering expected frequency and how much notice each side needs before a visit. Where the programme includes trade stages that require sign-off before covering up work, flag those dates specifically so the architect can plan around them.
With this in place, the head contractor knows in advance when inspections will happen and can sequence the programme around confirmed dates instead of open-ended availability.
Escalate design response delays through formal written correspondence
An informal follow-up on a late RFI leaves no record that the delay was ever raised.
Once a response falls outside the agreed turnaround, send a written escalation that references the original RFI date and the expected response window, and keep a copy of every escalation alongside the RFI register.
If a delay caused by slow design response later needs to support an EOT claim, this correspondence is what demonstrates the head contractor flagged the issue as it happened instead of only noticing it in hindsight.
Set clear expectations on RFI turnaround times at the pre-construction meeting
Without an agreed benchmark, the head contractor and the architect are each working to their own sense of what counts as a reasonable response time.
Raise this directly at the pre-construction meeting and get a specific number of business days agreed and recorded in the minutes. Once that benchmark exists, any response that runs late is measurable against something both sides signed off on, which makes escalation a matter of fact instead of a judgement call.
Route all site instructions through written confirmation before proceeding
A verbal instruction given on site under time pressure is easy to give and hard to prove later.
Where an architect gives a direction on site, follow it up the same day with a written confirmation describing what was instructed and asking the architect to confirm. Hold the work until that confirmation comes back wherever the programme allows it.
This closes off the most common way variation claims get disputed, which is a disagreement over what was actually instructed versus what the head contractor understood.
Keep a running log of certified versus disputed payment claims
A single delayed certification can look like an isolated issue. A pattern of delayed or withheld certification across several claims is a different problem, and it is only visible if someone is tracking it.
Log each payment claim against what was submitted, what was certified, and what was disputed or reduced, and review that log at each progress claim cycle. Raising a pattern with the architect, backed by the log, carries far more weight than raising a single instance in isolation.
Review the contract documents and specification together with the architect early in the project
Non-conforming work disputes often come down to two parties reading the same specification differently.
Walk through the contract documents and specification with the architect before construction reaches the trades most likely to raise conformance questions, and confirm how ambiguous clauses will be interpreted.
Doing this early gives both parties a shared understanding to refer back to, so a disagreement on site can be resolved by pointing to that earlier conversation instead of re-litigating the specification from scratch.
Managing the architect relationship protects programme and payment on every commercial project
The architect's authority over inspections, RFIs, variations, and certification directly shapes how smoothly a project runs and when payment lands. Confirming who holds the superintendent function early and putting instructions and inspections in writing as the project goes, gives the head contractor a documented position instead of a dispute to untangle later.
Categories:
Written by

Josh Krissansen
122 articles
Josh Krissansen is a freelance writer with two years of experience contributing to Procore's educational library. He specialises in transforming complex construction concepts into clear, actionable insights for professionals in the industry.
View profileExplore more helpful resources

What Is a Provisional Sum in Construction? A Commercial Contractor’s Guide
On certain commercial projects, some work packages cannot be fully scoped or priced at tender. Design may be incomplete, ground conditions may be unconfirmed, and authority information may still be...

Managing progress payments in construction: Structuring cash flow across projects
Delayed and disputed progress payments are a common source of financial pressure in construction projects. When funding release is not aligned with completed and verified work, contractors experience extended cash-flow...

Understanding commercial construction: A guide for Australian project teams
Commercial construction is the design, procurement, and construction of buildings intended for business use, including offices, retail, hospitality, and mixed-use developments. Commercial projects carry different regulatory, contractual, and delivery demands...

Version control for construction: A guide for Australian project teams
Version control is the process of managing changes to project documents so that every person on a project is working from the same, current version at all times. On a...
