Managing DA Conditions Across a Project

How the process typically works

A development approval is issued with an attached condition schedule. Conditions are typically grouped into categories: assessment manager conditions, referral agency conditions, and sometimes concurrence agency conditions. Each condition specifies what must be done, when it must be done, and in some cases, who must certify that it has been done.

Some conditions are triggered at specific points in the project lifecycle — prior to the commencement of works, prior to the issue of a compliance certificate, or prior to plan sealing. Others are ongoing obligations that run across the life of the development.

In a well-run project, the condition schedule is reviewed at the start, responsibilities are assigned to the relevant consultant or team member, and progress is tracked as each condition is addressed. In practice, this rarely happens as cleanly as it should.

The town planner usually takes ownership of the planning conditions. The civil engineer handles infrastructure and engineering conditions. The surveyor manages survey-specific requirements. The developer or project manager is responsible for contributions and financial conditions. On paper, the responsibilities are clear. In practice, the coordination between these parties is where things tend to break down.

Where projects run into issues

Most DA condition management problems aren't caused by difficult conditions — they're caused by poor information flow across the project team.

• The approval PDF gets filed and forgotten. The DA is issued, the PDF is saved somewhere, and conditions are addressed reactively as they become relevant. By the time plan sealing is being prepared, no one has a complete picture of what's been addressed and what hasn't.
• Conditions are interpreted differently by different parties. Complex or ambiguous conditions are read differently by the planner, the engineer, and the council officer reviewing the application. This produces back-and-forth correspondence that could have been resolved earlier with clearer documentation.
• Evidence isn't collected as it's generated. Compliance certificates, authority approvals, and payment receipts are produced throughout the project but stored in different places. When the plan sealing application is being assembled, the surveyor has to chase documents from five different parties.
• Staff turnover breaks the thread. When a planner or project manager changes mid-project, the informal knowledge of what's been done — held in emails and memory — is lost. Starting over on condition tracking is a real cost.
• Conditions near expiry aren't flagged. Development approvals in Queensland have a currency period. Conditions triggered by specific timeframes — such as obligations that must be met within two years of approval — can be missed if they're not actively tracked.

Improving the process

The core principle is straightforward: DA conditions need to be managed as a structured list from the moment the approval is issued, not assembled from scattered records when plan sealing is imminent.

This means breaking the condition schedule into individual, actionable items. Each condition should have a clear description of what's required, who's responsible for addressing it, what trigger point applies (prior to works, prior to plan sealing, etc.), and where the evidence will be stored.

Regular review of outstanding conditions — ideally tied to project milestones — keeps the list current and gives the project team early visibility of anything at risk of delay. Council referral conditions in particular benefit from early action: external authority responses can take weeks, and waiting until the plan sealing application is being prepared to request them is a common source of avoidable delay.

Clear documentation of how ambiguous conditions have been interpreted also reduces rework. When a condition requires a specific outcome but doesn't specify a method, documenting the agreed interpretation early — and confirming it with council if necessary — avoids disputes at plan sealing.

Using a structured system

Planease is built around DA condition management. The platform allows project teams to extract and structure conditions from approval documents, assign responsibility, and track compliance progressively across the project.

• — Import and structure conditions directly from DA approval documents
• — Assign each condition to the responsible party
• — Tag conditions by trigger point and category
• — Attach evidence and documents to individual conditions
• — Track outstanding conditions across the full project lifecycle
• — Use AI assistance to interpret and assess complex or ambiguous conditions

The goal is to make the plan sealing application a natural output of ongoing project management, rather than a document that needs to be assembled from scratch at the end.

Frequently asked questions