Contents of the Functional Design Brief

Overview

The contents of the Functional Design Brief are flexible and will differ between projects depending on the:

  • Type of project
  • Procurement approach
  • Government’s experience in delivering similar projects
  • Scale of the project
  • Project’s technical characteristics.

Generally, the Functional Design Brief should not duplicate the material provided in the Business Case for the project, but it should complement and supplement the Business Case. In this way, iCBR should read the Functional Design Brief in conjunction with the Business Case to ensure consistency and deliverability. The delivery team may then read the Functional Design Brief as a stand-alone document that does not require reference to the Business Case. The Functional Design Brief should provide the technical detail of a project, where available, to meet the objectives above.

The sections below provide a guide to the information the Project Team should include in the Functional Design Brief. The Project Team should include detail on:

  • The Agency and the roles and responsibilities of the Project Team delivering the project
  • Previous due diligence
  • Precedent projects or guidelines
  • Objectives and outcomes
  • Scope of works, services and/or design
  • Previous projects within a Program or Precinct that have already been delivered, if applicable
  • Approvals granted
  • Project assumptions and constraints
  • Delivery risks and issues
  • Relationship and interdependencies with other projects, if applicable.

The Project Team should also include reference to the Agency’s generic Functional Design Brief/specification where appropriate and available.

Agency and Project Team delivering the project and previous due diligence

The Project Team should include a brief description of the Agency and the composition of the Project Team that will be delivering the project and its role. This information should include details of any previous technical due diligence or pre-planning (i.e. blocking and stacking) that has already been undertaken for the project and the ultimate asset owner, manager or user.

Where relevant, the Project Team should also include details of other key contacts related to the project, such as:

  • Other teams within the Sponsoring Agency with a role in capital works planning processes
  • Individuals or teams providing technical support in the delivery of projects
  • Individuals or teams providing input into workshops or documents.

Precedent projects

If the project is similar to other recent projects that were successfully procured and delivered in the ACT by the Project Team, the Project Team should note how these similarities will provide, or are likely to provide, additional assurance or confidence that this project is ready for procurement.

Where similar projects have been procured in the past and are referred to, the Project Team may provide, or refer to, a generic Functional Design Brief while providing a less detailed project-specific Functional Design Brief.

Objectives and outcomes

The Project Team should outline the project objectives and the outcomes desired to meet those objectives, including how the project is planned to be procured and the number and form of contracts to be used. This should include:

  • Project objectives: The Project Team should summarise the objectives of the project
  • Outcomes: The Project Team should provide the desired outcomes of the project in practical terms. These are the design, works, benefits or other long-term changes that the project seeks to achieve, based on the project’s objectives. In detailing the outcomes, the Project Team should:
    • State project requirements and provide information on how they will be achieved
    • Detail the specific outputs of the desired outcomes. This may include documenting the changes proposed to existing assets or detail of the design requirements. For example, for the outcome ‘decrease waiting times for access to emergency health care’, outputs may include additional health care staff and an expansion to existing services.

Scope of works, services and/or design

The Project Team should include further information on the scope of works, scope of services and/or the design of the project. This information should be sufficiently detailed to demonstrate the project’s readiness to progress to Stage 3 – Procure and to inform the preparation of the necessary procurement documentation.

Documentation that the Project Team may provide in the Functional Design Brief includes (if available):

  • A record of the assets that will be affected by the project and how they will be affected
  • A detailed record of the scope of requirements and design of the project (both the scope of works and scope of services), such as:
    • Design objectives
    • Operational requirements
    • Functional requirements
    • System requirements
    • Spatial needs, including any associated spatial requirements
    • Furniture, fixtures and equipment requirements
    • ICT and security requirements
  • Any existing or previous design work undertaken for the project, including the Safety in Design report (if applicable)
  • Any previously completed existing condition reports or investigations, such as Hazardous Materials Survey, site surveys, geotechnical investigations/reports
  • Building Owner/Landlord requirements if the project site is a leased property
  • Requirements to obtain all necessary statutory approvals
  • Detail on how the project will meet the requirements of the Climate Change Strategy and information on the sustainability ratings. At a minimum, this should include information on the rating tool the Project Team is using and the level of rating they are seeking
  • Compliance with the relevant Australian standards, such as the National Construction Code
  • Compliance with any specific Agency specification, standards, codes or guidelines, such as EDIS or TCCS standards or specific Territory Policy.
  • Attention to specific legislation, such as the Education Act.

The Project Team should outline any matters that require further analysis, are unknown or unconfirmed. The Project Team must discuss and agree who will undertake these works and the timeline for their completion, with the Project Sponsor and the Agency responsible for progressing the project through Stage 3 – Procure and Stage 4 – Implement.

Previous projects within a Program or Precinct that have already been delivered, if applicable

This section is only applicable for Programs and Precincts.

The Project Team should provide details of any individual projects within the Program or Precinct that have already been delivered, including a list of reference documents for this project based on the previous work undertaken. Examples are a Business Case for project development funding or concept design, or further information on the site selection process.

Approvals granted

The Project Team should include any detailed records of consultations with the Environment, Planning and Sustainable Development Directorate (EPSDD), the National Capital Authority (NCA) or other Commonwealth agencies (where applicable). The Project Team should also clearly note any approvals that have already been granted relating to the project.

Project assumptions and constraints

It is essential that the Project Team recognises and records the assumptions and constraints made during the development of the Business Case. This may include those relating to:

  • Cost
  • Scope
  • Timeline
  • Whole of Government policy and priorities
  • Legislation
  • Resource availability
  • Environmental requirements
  • Technology
  • Security.

Delivery risks and issues

To complement the Risk Register, the Project Team should include information on the key issues that may affect the procurement and implementation of the project. This may include:

  • Any known risks or due diligence documentation that is held by the Project Team, including all known information that could be required to inform the Safety in Design report
  • Detail on significant risks associated with interrelated projects (see below)
  • Further information regarding potential environmental or contamination issues
  • Any known issues with development applications or approvals for the project
  • Any risks or issues relating to substantiating reports, plans or surveys, where relevant, that may affect the procurement and/or the delivery of the project
  • Climate change risks affecting the infrastructure and its function.

The Project Team should consult with iCBR, or the relevant delivery agency, on any supply chain or industry capacity risks or constraints that may affect the project delivery.

Relationship and interdependencies with other projects, if applicable

Where relevant, the Project Team should include detailed information on the relationship and interdependencies of the project with other Government operations or services. This may include:

  • Any land management/ownership or land zoning issues
  • Interdependencies with other Agencies
  • Conditions that are attached to any approvals
  • Any additional road works, other civil works or site servicing required for the project but not included within its scope (including associated staging, network capacity, funding and timing constraints)
  • For projects that impact on land development activities, any flow-on impacts to other Government services that are not outlined in the Business Case (e.g. education, healthcare, public transport, land release etc.)
  • Any other adjacent projects or developments.

Footnotes: