Question:
Hi QPWS&P team,

Does QPWS&P have a preference for a software solution from a specific vendor (E.g. Microsoft or ESRI) for reasons such as ease of integration with QPWS&P's broader environment and/or leveraging broader software licences?

Is QPWS&P open to a bespoke solution to meet specific functional and non-functional requirements? Or is there a stronger preference for configuration based (low code)? Even if that means needing to be flexible (trade offs made) with some functional and non-functional requirements?

Answered on 07/Jan/2026 03:41 PM:


Please see Addendum 1 - EOI ITPR20261732 - QPWS&P Estate Register

Question:
We note the requirement for “two UAT/staging environments.” Can you confirm whether separate UAT environments are mandatory, or if an equivalent approach (e.g., secured preview/draft review, version control) that has been accepted by other government customers will be considered compliant?

Answered on 07/Jan/2026 03:43 PM:


Please see Addendum 1 - EOI ITPR20261732 - QPWS&P Estate Register

Question:
1. Sharing of EOI Documents and Requirements

The EOI conditions state that confidential information may not be disclosed except to a Respondent's "personnel on a need to know basis for the purpose of responding to the Expression of Interest".


Question: Are Respondents permitted to share the EOI documents (including requirements, user stories, and high-level requirements) with potential implementation partners for the sole purpose of enabling them to provide accurate input, such as indicative costing and details for the response forms (e.g., Support and Maintenance or Professional Services costs )?

2. Submission of Multiple Responses for the Same Solution

The EOI encourages the submission of "alternative solutions and innovative ideas" , and the Customer reserves the discretion to "accept non-conforming responses, alternative or innovative responses, responses in part, or multiple responses". Furthermore, Section 4.3 notes that for multiple systems, "a separate response form must be completed for each system".


Question: Is a single Respondent permitted to submit multiple, separate responses for the same core system/solution if the submissions detail materially different implementation approaches, commercial models, or partner arrangements (e.g., Option A vs. Option B), with each response using a separate Respondent Response Form?

Answered on 07/Jan/2026 03:43 PM:


Please see Addendum 1 - EOI ITPR20261732 - QPWS&P Estate Register

Question:
The EOI request includes a high-level functional requirement for “Workflow and Status Management”. Can you please expand upon requirements in this area to provide a sense of the practical processes that will need to be supported?

Answered on 07/Jan/2026 03:44 PM:


Please see Addendum 1 - EOI ITPR20261732 - QPWS&P Estate Register

Question:
Hello

Thank you for providing respondents with the opportunity to ask questions on this tender. We have several questions we would like to ask.

1. Please confirm the top five day-to-day user tasks the Estate Register must support (e.g., workflow/status progression, spatial viewing, spatial editing, reporting, data correction).

2.Is the Estate Register expected to support map-based spatial editing of parcel/estate geometry (create/update boundaries), or is spatial functionality primarily view-only visualisation with geometry maintained in upstream authoritative systems?

For each of the following, please confirm the intended system of record (source of truth): (a) parcel geometry, (b) park/estate boundaries, (c) estate attributes/tenure/type, (d) gazettal workflow status, (e) documents/attachments.

Where an estate record must be created before authoritative cadastre/geometry is available, is QPWS&P expecting (a) capture of approximate geometry (e.g., sketch polygon), or (b) a non-spatial placeholder record until authoritative geometry is ingested?

How frequently are boundary/geometries expected to change (daily/weekly/monthly), and are changes typically (a) attribute-only updates, (b) boundary adjustments, (c) merges/splits, or (d) creation of new features?

Does QPWS&P require formal spatial versioning and/or the ability to view and compare spatial boundary history as discrete versions over time?

Can QPWS&P provide (or confirm) the expected gazettal workflow stages/statuses, approval points, and any role-restricted/hidden statuses, including whether rework loops and parallel approval paths are required?

For ESRI integration, please confirm the preferred approach: (a) consume ArcGIS Feature/Map Services (read), (b) write-back to Feature Services, (c) direct geodatabase integration, or (d) other (please specify).

Please identify the key reporting portals/tools and downstream consumers the Estate Register must feed, and preferred interface patterns (API, scheduled extract, event-driven updates).

Are there any mandated non-functional constraints that should drive platform choice (e.g., hosting model, identity provider, audit logging, availability targets, and environment separation including UAT)?

Answered on 27/Jan/2026 11:28 AM:


Please see Addendum 2 - EOI ITPR20261732 - QPWS&P Estate Register

Question:
Sorry re-submit because there are multiple questions which have come out confusing on my initial submission

1. Please confirm the top five day-to-day user tasks the Estate Register must support (e.g., workflow/status progression, spatial viewing, spatial editing, reporting, data correction).

2. Is the Estate Register expected to support map-based spatial editing of parcel/estate geometry (create/update boundaries), or is spatial functionality primarily view-only visualisation with geometry maintained in upstream authoritative systems?

3. For each of the following, please confirm the intended system of record (source of truth): (a) parcel geometry, (b) park/estate boundaries, (c) estate attributes/tenure/type, (d) gazettal workflow status, (e) documents/attachments.

4. Where an estate record must be created before authoritative cadastre/geometry is available, is QPWS&P expecting (a) capture of approximate geometry (e.g., sketch polygon), or (b) a non-spatial placeholder record until authoritative geometry is ingested?

5. How frequently are boundary/geometries expected to change (daily/weekly/monthly), and are changes typically (a) attribute-only updates, (b) boundary adjustments, (c) merges/splits, or (d) creation of new features?

6. Does QPWS&P require formal spatial versioning and/or the ability to view and compare spatial boundary history as discrete versions over time?

7. Can QPWS&P provide (or confirm) the expected gazettal workflow stages/statuses, approval points, and any role-restricted/hidden statuses, including whether rework loops and parallel approval paths are required?

8. For ESRI integration, please confirm the preferred approach: (a) consume ArcGIS Feature/Map Services (read), (b) write-back to Feature Services, (c) direct geodatabase integration, or (d) other (please specify).

9. Please identify the key reporting portals/tools and downstream consumers the Estate Register must feed, and preferred interface patterns (API, scheduled extract, event-driven updates).

10. Are there any mandated non-functional constraints that should drive platform choice (e.g., hosting model, identity provider, audit logging, availability targets, and environment separation including UAT)?

Answered on 27/Jan/2026 11:29 AM:


Please see Addendum 2 - EOI ITPR20261732 - QPWS&P Estate Register

Question:
Is there a preference for a COTS system or custom build?

Answered on 27/Jan/2026 11:29 AM:


Please see Addendum 2 - EOI ITPR20261732 - QPWS&P Estate Register

Question:
Does the DETSI have a preference for a SaaS or perpetual software licensing?

Does the DETSI prefer to deploy the software in a DETSI managed server environment, or one managed by the vendor?

The EOI provides an overview of the expected number of DETSI system users. Are there any requirements for third-party / public access (eg from First Nations / Traditional Owners etc) or by staff from other government departments?

The proposed new system is required to integrate with Loc8 for the site-level data. Is there an API available for Loc8, or can you provide further details regarding the proposed integration?

Approximately how many 'active' estate records are maintained in the Excel sheets, and how many estate transactions are undertaken on a monthly basis?

Are there unique keys recorded in Excel and the accompanying GIS data to easily import and link the data records?

Does the DETSI have documented business processes for all workflows that would be required in the proposed system, or would the supplier be required to provide services to do this?

Will the DETSI be responsible for internal change management within the department, or will the supplier be responsible for this?

Does the DETSI anticipate awarding the contract and commencing the project in the 2025-26 financial year, or in the 2026-27 financial year?

Does DETSI have aspirations to provide billing capabilities for lessees out of a replacement system?

Does DETSI have interest in providing a public-facing portal interface for lessees and other interested parties to interact, accessing self-service capabilities for applications and payments?

Answered on 27/Jan/2026 11:30 AM:


Please see Addendum 2 - EOI ITPR20261732 - QPWS&P Estate Register

Question:
Hi Team

What version of Oracle 19c is the Estate Register database?

Kind Regards

Answered on 27/Jan/2026 11:30 AM:


Please see Addendum 2 - EOI ITPR20261732 - QPWS&P Estate Register

Question:
Q1. What is the approximate size of the data currently present in the databases and spreadsheets along with its historical data? (Approx. size of initial data load)

Q2. Can QPWS&P ensure the reliability of existing data before entering into the system? Including the data present in Oracle (until 2018) and Excel sheet (After 2018)

Answered on 27/Jan/2026 11:30 AM:


Please see Addendum 2 - EOI ITPR20261732 - QPWS&P Estate Register