BMS Technical Review and Improvement Services

Closes in 22 daysSubmission deadline: 06 November 2026, 02:00 PM Australia/Sydney

About this tender

Overview The Campus Environment Division, on behalf of the Australian National University, is issuing this Request for Tender to procure specialist technical services to review the current Building Management System (BMS) architecture and identify opportunities to improve its operational performance and long-term suitability. Scope BMS Architecture Review Consultant Scope The University is seeking to engage a suitably qualified Building Management System (BMS) consultant to undertake an independent technical review of the University's existing BMS architecture. The review is intended to assess the design, resilience, scalability, integration capability, and long-term suitability of the current BMS environment. The successful consultant will be provided access to relevant BMS architecture diagrams, network diagrams, system topology drawings, server architecture, controller layouts, integration documentation, and other relevant technical information required to complete the review. This engagement is not intended to be an operational performance review. The University is not seeking a review of day to day BMS operation, maintenance practices, operator performance, alarm handling, or building-level control strategies unless these matters directly relate to the underlying system architecture. Architecture Robustness Assess whether the current BMS architecture is robust, resilient, and fit for purpose, including: Server architecture and redundancy arrangements Network topology and communication pathways Segmentation between BMS networks, IT networks, and field device networks Single points of failure within the architecture System scalability for future campus growth Resilience of critical monitoring, alarming, and control functions Suitability of current architecture for research, teaching, and critical infrastructure environments System Integration Review the current integration approach across BMS platforms, controllers, metering systems, analytics platforms, and third-party systems, including: BACnet, Modbus, Haystack, API, and other integration pathways where applicable Data flow between field controllers, supervisory servers, analytics platforms, and reporting systems Interoperability between different BMS vendors and legacy systems Risks associated with proprietary systems, unsupported controllers, or vendor lock-in Opportunities to improve integration standardisation across the campus Technology and Product Opportunities Identify any products, tools, software modules, drivers, gateways, or platforms that could strengthen the current BMS environment, including: Analytics and fault detection capability Metering and energy reporting integration Alarm rationalisation and alarm management tools Cybersecurity monitoring or hardening tools Integration drivers such as Niagara, Haystack, BACnet, Modbus, DALI, or API-based connectors Data visualisation and reporting platforms Remote access, monitoring, and diagnostic tools Asset condition monitoring or predictive maintenance capability System Efficiency and Optimisation Provide recommendations on how the BMS architecture could be improved to support greater efficiency, including: Improved data quality and standardised point naming Better use of trend logs, historical data, and analytics Reduction of duplicated infrastructure or duplicated data pathways Improved supervisory server load distribution More efficient alarm routing and escalation pathways Enhanced energy monitoring and optimisation capability Improved support for fault detection, diagnostics, and performance reporting Cybersecurity and Access Control Cyber security considerations are limited to the BMS Field Level Network (FLN). This includes controller-level communications, field device connectivity, protocol exposure, controller access, network segmentation at the field level, and risks associated with BMS field networks. Server-level security, enterprise network security, firewall management, remote access controls, patching, identity management, and broader IT infrastructure security are managed by the University's IT team and are outside the scope of this review, except where these items directly interface with or impact the BMS Field Level Network. Review the architecture from a BMS cybersecurity and access-control perspective, including: User access levels and privilege management Remote access arrangements Network segregation and firewall boundaries Exposure of BMS servers, controllers, and gateways Secure vendor access arrangements Backup, restore, and disaster recovery provisions Alignment with good-practice OT cybersecurity principles Alarm System The University will provide the successful tenderer with the current alarm system architecture for review. The tenderer will be required to facilitate a workshop with relevant stakeholders to understand existing system constraints, operational requirements, current limitations, and opportunities for improvement. Campus Building Requirements Manual (CBRM) The Campus Building Requirements Manual (CBRM) is an internally developed document that outlines the University's design and installation requirements for contractors and suppliers. The consultant shall review the BMS section of the CBRM and provide recommendations to ensure it aligns with current industry standards, with particular attention given to the specified BMS brands. The review shall also identify opportunities to improve flexibility and reduce vendor dependency. Future-State Recommendations The consultant is expected to provide practical recommendations for improving the BMS architecture, including: Short-term improvements that can be implemented with minimal disruption Medium-term improvements requiring planning, budget, or staged implementation Long-term strategic recommendations for future BMS architecture Risks associated with maintaining the current architecture unchanged Priority ranking of recommendations based on risk, cost, complexity, and operational benefit Required Deliverables Deliverables are structured in three stages: Stage 1: Program of Works The consultant shall provide a draft program of works outlining the proposed review methodology, key activities, stakeholder engagement requirements, information required from the University, and indicative timeframes for completing the review. Stage 2: Stakeholder Engagement and Technical Review The consultant shall meet with relevant University stakeholders to understand the current BMS architecture, system constraints, integration requirements, known risks, and future operational needs. Stakeholder engagement may include representatives from BMS, engineering, facilities management, IT, and cybersecurity where required. The primary focus of the cybersecurity review shall be on the Field Level Network, including controller networks, communications pathways, segmentation, device access, and exposure of field devices. Engagement with the University cybersecurity team may be required where server-level security, remote access, network boundaries, or broader IT/OT interfaces are relevant to the review. Stage 3: Final Delivery The consultant shall provide a written technical report that includes: Summary of the current BMS architecture Key architectural risks and limitations Identification of single points of failure Assessment of scalability and future readiness Recommended technology additions or architecture changes Prioritised improvement roadmap High-level cost and complexity assessment for each recommendation Executive summary suitable for senior management Technical appendix suitable for engineering and IT review Final presentation to executive team Reporting The consultant shall provide draft reports at agreed stages of the review for University review and feedback. Work on the next stage shall commence once the relevant draft report has been reviewed and feedback has been provided. The purpose of staged reporting is to ensure alignment between the University, stakeholders, and the consultant throughout the engagement, and to reduce the risk of misunderstandings regarding scope, findings, and recommendations. Contractor Requirements Evidence of relevant experience for assessment, including references from similar BMS architecture review projects previously undertaken Preference will be given to consultants who have completed comparable reviews within large, complex organisations, particularly within the higher education sector Experience undertaking similar work for a Group of Eight (Go8) university in Australia will be highly regarded

How to respond to this tender

A strong tender response is clear, compliant, and backed by evidence. These steps apply to most Australian and New Zealand public tenders.

Read the requirements in full

Open the official listing and download the full tender pack. Note the response schedules, evaluation criteria, mandatory conditions, and the exact closing time and lodgement method.

Confirm you are eligible and it is worth bidding

Check licences, insurances, certifications, and any conformance requirements before you commit. A quick bid or no-bid decision saves days of wasted effort on a tender you cannot win.

Answer every criterion with evidence

Respond to each evaluation criterion directly and back your claims with concrete examples, referees, and past performance. Address the buyer’s stated need, not a generic capability statement.

Lodge early through the official portal

Submit through the source portal well before the deadline. Late or incorrectly lodged bids are almost always rejected, so leave time for uploads, portal errors, and last-minute questions.

Ready to write winning tenders?

Sign up today, what a relief.

Sign up