SUSTAINABILITY ACTION PLANS GOVERNANCE · sustainability action plans governance revision v1.3 draft 11th july 2017 . department of defence sap governance version 1.2 (6th march 2017)

Version 1.2 (6th March 2017) Page 1

SUSTAINABILITY ACTION PLANS GOVERNANCE

REVISION V1.3 DRAFT

11TH JULY 2017

DEPARTMENT OF DEFENCE SAP GOVERNANCE


DOCUMENT STATUS

Version No.

Issue Date Amendment Details Amended by

1 29th Feb 2016 Issued for Use Alex McKenzie

(MWH)

1.1 23rd March 2016 Additions to Section 3 (hyperlink to NSP documents) and Section 6.2 (file name convention)

Alex McKenzie (MWH)

1.2 6th March 2017 Updated contact details in Appendix B of Program Manager for NSP

Daniel Brooke (MWH)

1.3 11th July 2017 Updated contact details in Appendix B of Program Manager for NSP

Daniel McLean (Stantec)



TABLE OF CONTENTS

1. DOCUMENT PURPOSE .......................................................................................................................... 4 2. SPONSOR .................................................................................................................................................. 4 3. CONTEXT ................................................................................................................................................. 4 3.1. GOVERNMENT POLICY ..................................................................................................................... 4 3.2. DEFENCE RESPONSE ......................................................................................................................... 4 4. PROCESS OVERVIEW ........................................................................................................................... 5 5. ROLES & RESPONSIBILITIES ............................................................................................................. 5 5.1. GOVERNANCE .................................................................................................................................. 6 5.2. OPERATION ...................................................................................................................................... 6 5.3. AUDIT ............................................................................................................................................. 6 5.4. STAKEHOLDERS ................................................................................................................................ 6 6. PROCESS STEPS ..................................................................................................................................... 7 6.1. INITIATION ....................................................................................................................................... 7 6.2. OPPORTUNITY DESCRIPTION ............................................................................................................ 8 6.3. PRIORITISATION ............................................................................................................................... 8 6.4. PLANNING ........................................................................................................................................ 9 6.5. IMPLEMENTATION .......................................................................................................................... 10 6.6. VERIFICATION ................................................................................................................................ 10 6.7. FINALISATION ................................................................................................................................ 11 7. RDMS ....................................................................................................................................................... 11 8. REPORTING ........................................................................................................................................... 12 APPENDIX A - RESPONSIBILITY TABLE .............................................................................................. 13 APPENDIX B - SAP USER GUIDE ............................................................................................................. 15



1. Document Purpose The purpose of this document is to define the way in which Sustainability Action Plans (SAPs) are used by Defence to achieve policy objectives relating to resource efficiency.

2. Sponsor The use of SAPs is sponsored by the Directorate of Energy Efficiency, Environmental Resource Management and Sustainability (DEEERMS). The most current version of this documentation will be available from the DEQMS website along with any supporting reference material or templates. Enquiries may be directed to:

Director Energy Efficiency, Environmental Resource Management and Sustainability

Brindabella Business Park

Canberra ACT 2600

Tel: (02) 6266 8209

3. Context

3.1. Government Policy The Australian Government’s Energy Efficiency in Government Operations (EEGO) Policy requires Defence to develop and implement a comprehensive energy management strategy that includes a metering, monitoring and management program. The National Sub-Meter Program is designed to meet these EEGO requirements. The data captured under the NSP is organised within Defence’s Resource Management System (RDMS) and is analysed to identify inefficiencies. Opportunities to address these inefficiencies are captured through the SAPs which are held within the RDMS.

3.2. Defence Response In response to government policy, Defence has a number of internal policy documents and programs to continuously improve the efficiency, effectiveness and sustainability of the Defence estate. The purpose of SAPs is to allow for the definition, prioritisation and implementation of energy efficiency measures across the estate.



4. Process Overview This document has been prepared on the basis that there will be a trigger event (e.g. site observation, meter data observation) that requires a SAP to be prepared (generally when there is a need for capital expenditure).

It should be noted that SAPs should not be used to document or track solutions that can easily be implemented without requiring capital expenditure (e.g. via changes to operational protocols without capital expenditure) or maintenance. There are a number of funding sources available for identified SAPs, each with their own requirements. This document does not replicate the specific requirements of each source.

5. Roles & Responsibilities This section describes the various roles and responsibilities associated with the SAP process. The general rule is that any Defence personnel or contractor can create a SAP (initiation/opportunity description) but DEEERMS is responsible for the prioritisation and tracking through to project finalisation in concert with project implementers. This simplifies the amount of interaction that the various stakeholders have with the RDMS. The roles and processes recognise that while DEEERMS has a vested interest in the identification and realisation of project benefits relating to resource and cost reductions, it does not always have direct control since it is not always the funding body. To this end there is a need for DEEERMS to have sufficient oversight of the SAP outcomes to ensure that the benefits are being realised and to allow future informed decisions about opportunity prioritisation.



5.1. Governance There are a number of governance activities that need to be undertaken at regular intervals to realise the benefits of SAPs. The responsibility for undertaking these actions rests with DEEERMS:

Objective Review: Consider whether the SAP process is meeting the resource saving objectives.

Documentation Update: Keep the documentation and associated guides current.

System: Make changes to the SAP component of the RDMS (refer to Section 7).

5.2. Operation In addition to the governance activities outlined in Section 5.1 there are regular activities required to ensure the smooth operation of the SAP process (with varying frequency/level of effort dependant on the volume of SAPs). The responsibility for undertaking these actions rests with DEEERMS:

Administration: Check that only SAPs that meet the criteria are approved and that the data has been entered correctly into each SAP.

Consistency: Check for duplicates within a site or with other Defence programs, look for opportunities for program aggregation.

Prioritisation: Prioritise the SAPs in accordance with the defined rules.

System Administration: Undertake system admin functions for SAPs on the RDMS (refer to Section 7).

Reporting: Prepare and distribute performance reports (refer to Section 8).

Training: Champion the SAP intent and provide training to users on the process/system.

5.3. Audit To ensure that Defence is realising the benefits from undertaking the projects described in the SAPs there is a need for independent measurement and verification. This role is responsible for keeping the SAP status up to date during the delivery lifecycle, planning the verification process, verifying in accordance with the plan and then preparing an assessment of the project against its original business case. This role occurs in parallel to the delivery process associated with each project. The responsibility for this role rests with DEEERMS however it may be delegated to a third party (under DEEERMS governance).

5.4. Stakeholders While there are theoretically no restrictions on who can initiate and define a SAP (assuming access to the RDMS) it is expected that most will originate from the Estate Maintenance and Operations Services (EMOS) contractors since they have operational responsibility for the Defence estate. It is expected that the EMOS contractors will need to be engaged during delivery of SAPs to ensure that any works are incorporated into the ongoing maintenance regime (to avoid a re-occurrence of meters being installed without asset tags). The Estate Upkeep Contracts also contain provisions around the identification and implementation of resource savings which provides alignment with the intent of the SAP process. The RESO role has a responsibility to identify projects across the estate and would be expected to complete SAPs. Other parties (e.g. Project Delivery Service (PDS) contractors) are primarily tied to specific project scope and there is no current contractual measure to require them to complete a SAP.



6. Process Steps The process that describes the steps and the associated roles from the identification of an issue that requires a SAP to solve through to the completion of the project is described below:

Phase

SAP Initiator DEEERMS

Implementation Contract

SAP Auditor

Initiation

Yes

Opportunity Description

Yes Yes

Prioritisation

Yes

Planning

Yes Yes

Implementation

Yes Yes

Verification

Yes

Finalisation

Yes

6.1. Initiation

Input: Identified opportunity

Reference: SAP Creation Rules

Process: Assess whether the SAP Creation Rules apply to the opportunity

Gateway: Opportunity meets SAP Creation Rules

Responsible: Person who identified the SAP opportunity

There are a number of ways an opportunity for resource savings could be identified including:

Observed anomalies

Site audits

Asset replacement

New ideas

Audits/consultancy projects Possible SAP opportunity drivers could include:

Changes to operating protocols on existing assets (that require capital expenditure to implement)

Installation of new assets

Replacement of existing assets

At end of working life to a higher standard

Prior to end of working life to a higher standard A SAP is only created if it passes the following SAP Creation Rules:

The project can’t be rectified through the relevant Estate Maintenance Strategy (e.g. Responsive Maintenance), due to scope and budget limits (e.g. required works may be greater than $10,000).

The project will reduce the whole of life cost of the estate (i.e. there must be a reduction in resource use, or a reduction in the cost of a resource, or a combination of both).



Anyone can identify an opportunity and test it against the SAP Creation Rules to determine whether it should proceed to the Opportunity Description phase.

6.2. Opportunity Description

Input: Confirmed opportunity

Reference: SAP opportunity description user guide

Process: Capture the SAP information about the opportunity

Gateway: SAP defined

Responsible: Person who identified the SAP opportunity (initiator) DEERMS (approval)

If an opportunity passes the SAP Creation Rules then it needs to be entered into the RDMS. This means a person with access to the RDMS needs to do the data entry (noting that access to the RDMS is granted for anyone that can demonstrate a need for it). The first check is to make sure that a SAP does not already exist that covers the opportunity. This can be done by reviewing the SAP list on the RDMS and filtering for the opportunity location. Depending on the type of opportunity a SAP may be implemented as a bundled package of works or as a series of individual projects. While a SAP could be split or combined later it is best to setup a SAP on the most likely implementation model. A SAP is created with the initial information and the status is set as Opportunity Description. The SAP then needs to be reviewed by DEEERMS. This review is required before the project can move to prioritisation to make sure that there is sufficient information to make an objective assessment. Options at this point are:

Approve the SAP to move forward to prioritisation (update the status to Pre-Prioritisation).

If there is insufficient information then the person who entered the SAP is contacted and the definition process is restarted. Alternatively, DEEERMS might require input from others (e.g. technical expertise) to develop an idea to a level that is sufficient for prioritisation.

Advise the person who initiated the SAP that it will not go forward for prioritisation and the reason why. Enter this information into the SAP and change the status to Closed Opportunity (this allows the information to be captured). This status could also be used for experimental concepts (e.g. EV charging stations) that may not proceed at this point in time.

6.3. Prioritisation

Input: Defined SAP

Reference: SAP Prioritisation model

Process: Use the SAP Prioritisation model to prioritise the SAP

Gateway: Prioritised SAP

Responsible: DEEERMS

Once SAP opportunities have been defined they need to be prioritised by DEEERMS for importance against a number of criteria. These include:

Service Delivery Division (SDD) Risk Evaluation and associated Risk Priority/Score (currently in line with the Estate Risk Assessment Guidance (ERAG) – documents external to the RDMS.

Identification of the relevant Strategy ID and Theme

Determination of the Activity Type and Driver This information is used by DEEERMS to assign a National Priority. After the SAP has been prioritised by DEEERMS the appropriate funding source is confirmed and the proposed funding source field is updated, if required. The SAP status is updated to Prioritised.



The outcome from this process step is that the SAP has been prioritised and can now be considered against all other SAPs that are sitting in the prioritised queue, awaiting funding. The SAP List should be consulted to check whether any projects of this type have been undertaken previously, and whether they achieved their objectives. DEEERMS should also review the Estate Works Program (EWP) to identify any overlap and to avoid undertaking projects on facilities that are about to be demolished.

6.4. Planning

Input: Prioritised list of SAPs

Reference: List of funding sources and their requirements

Process: Match prioritised SAPS with funding sources.

Gateway: Funded SAP with a Delivery Plan (as per funding source requirements) Verification Plan (SAP Auditor)

Responsible: SAP Auditor

There are a number of different funding sources available to SAP opportunities (additional information can be found on DEQMS):

ESD Program

National Sub-meter Program

Estate Works Program

EMOS/BIIP

Third Party Funding

Other. DEEERMS needs to have a calendar for the funding cut-off dates for each source (e.g. some will run on an annual budget basis, others may be ad hoc). Prior to the funding cut-off the prioritisation of SAPs needs to have been undertaken for that funding source. DEEERMS submits priority projects to the relevant funding source for consideration and if approved the project moves to the Planning phase. The SAP status is updated to Planning. The first step after funding approval is granted is for DEEERMS to appoint the SAP Auditor who then updates the planning section in the SAP table. The SAP Auditor needs to determine the measurement & verification requirements, document them in a SAP Verification Plan and communicate them to the Project Delivery party (including any cost implications). The planning phase continues until a detailed cost/benefit calculation has been prepared which may require additional investigation/design works to be undertaken. Once the cost/benefit has been determined then the information about the SAP is updated. This will normally be the funding gateway to confirm that the project will proceed to the Implementation phase. The SAP Auditor is responsible for ensuring that the cost/benefit has been undertaken and entered against the SAP. Once the cost/benefit analysis has been completed then:

If the project proceeds then the project status should be amended to Implementation.

If the project does not proceed then the project status should be amended to Closed at Planning. A decision might be made at this point to split the SAP or to combine two or more SAPs into a single project. If this occurs then a note should be made that links the SAP to provide historical context as to why the decision was made. The SAP Auditor is responsible for planning the verification process and documenting it in a Verification Plan. This assumes that the verification process will be separate to the delivery of the project (providing an independent assessment of the achieved savings). By way of example this could be done in accordance with the International Performance Measurement and Verification Protocol (EVO 10000 – 1:2012). The level of effort should be consistent with the potential savings. The funding source will define the delivery mechanism for the project. The delivery mechanism (contract) will be implemented with project delivery being the responsibility of the parties as defined by the funding source.



The Delivery Plan will be prepared by those parties, however it should describe any additional investigation work, the installation of any new assets, the commissioning and handover process and any ongoing operations and maintenance considerations.

6.5. Implementation

Input: Planned SAP

Reference: SAP Verification Plan, SAP Verification Checklist

Process: Implement the SAP Verification Plan

Gateway: Implemented Project


For projects that have been approved to proceed to Implementation the SAP Auditor is responsible for monitoring the implementation process to confirm that all works necessary for the verification process have been completed. Governance associated with the execution rests with the funding party, as does the approval of any variations to the scope, or changes in budget/schedule. At the end of the Implementation phase the SAP auditor verifies that all the required documentation has been completed and all assets are on the appropriate Defence systems (some items might need DEEERMS system access to verify). This is documented as part of the SAP Verification Checklist. The primary aim is to ensure that the ongoing operations and maintenance will occur. If there are any issues then they are first raised by the SAP Auditor with the implementation project manager, then escalated if required. Once the Implementation phase has been completed the project status should be amended to Verification.

6.6. Verification

Input: Implemented SAP

Reference: Verification Plan

Process: Measure the metrics defined in the SAP plan and take any corrective action.

Gateway: Verified Project


Once the project has been implemented its performance needs to be measured against the pre-defined metrics/intervals (Verification Plan), and an assessment made about whether the project is meeting/has met its objectives. This is documented in the SAP Verification Report which is attached to the SAP (there is no standard template for the Verification Report – this will be dependent on the requirements of the project). The SAP Auditor is responsible for undertaking the verification in accordance with the plan. If the verification identifies issues then the SAP Auditor needs to identify them to DEEERMS (who then have the responsibility to resolve the issues through the contractual arrangements of the Implementation phase). This could involve making remedial changes to the implemented solution (either under warranty or as new scope). Once the verification phase has ended then the SAP Verification Checklist is completed and the fields in the Verification section of the SAP are updated.



6.7. Finalisation

Input: Verified Project

Reference: SAP Verification Checklist

Process: Close out the SAP using the steps defined in the checklist

Gateway: Completed SAP

Responsible: DEEERMS

DEEERMS reviews the SAP list for projects with an actual completion date. The project needs to be assessed as to whether it met the objectives and whether any final actions are required before the project is completed. This includes a review of the completed SAP Verification Checklist which should have been attached to the SAP. If DEEERMS is satisfied that the project is complete and that no actions remain then the SAP is closed on the RDMS (status is set to Completed) with any fields in the Finalisation section being updated as applicable. The SAP status should not be set as Completed if some of the scope has not been finalised. Depending on the reasons for this then either the scope should be completed first, or a new SAP should be created for the balance of the scope. The SAP is then locked to prevent any further changes being made (it is still viewable). The name of the user that closed the SAP and the date that it was closed are shown.

7. RDMS The Resource Data Management System (RDMS) contains the SAP. It is a pre-requisite that someone must have access to the RDMS before they can create or modify a SAP. Access to SAPs is defined based on the navigation tree (i.e. if a user only has access to Queensland sites then they will only see SAPs pertaining to those sites and the Queensland Region). Users are assigned to one of four groups with the following permissions:

Admin: Full control over the SAP’s including deletion.

Estate: Create/edit SAPs at Estate/Region and Site level.

Region: Create/edit SAPs at Region and Site level.

Site: Create/edit SAPs at Site level. For additional information refer to the SAP User Guide which describes the process and system from a user perspective. This includes the data that needs to be entered at each stage. The NSP Program Manager is responsible for:

Assigning new users access to the SAP widget.

Defining user permissions to access Site, Region or Estate level SAPs.

Editing SAPs that were incorrectly assigned to the Estate/Region level.

Deleting SAP’s (this ability is restricted to admin only)

Setting the default view (which columns are shown on start-up)

https://edms.mwhtools.com/Default.jsp?Source=default



8. Reporting This section describes the types of reporting that can be undertaken by Defence using data from the SAP table:

New SAPs created in the last month

Current SAP list (breakdown by categories)

Project status report (shows the different projects by status)

Project funding report (shows the different projects by funding source)

Realisation of Benefits report (for completed projects)

Annual Reports. The current status of each SAP can be used to show where each one falls within the lifecycle for reporting purposes. Some resource efficiency works will be undertaken by EMOS since they fall within the scope of maintenance works under the Estate Upkeep Contract and therefore do not meet the SAP Creation Rules. Periodically this will require DEEERMS to compare EMOS contractual reporting and SAP reporting to determine how the value of efficiency works being done that fall outside the SAP process (i.e. EMOS Reporting + SAP Reporting = Total Efficiency Spending).



Appendix A - Responsibility Table

The following table summarises the tasks that need to be undertaken.

Phase Task Frequency Responsible

SAP Operation

Governance

Review SAP process

Update Documentation

Update RDMS System

Refresh SAP Verification Checklist

Annually

As Required

As Required

As Required

DEEERMS (Technical)

DEEERMS (Technical)

DEEERMS (Technical)

DEEERMS (Technical)

Administration

Program Consistency Checks (e.g. duplicates or aggregation

opportunities)

RDMS System Administration

Prepare any required reports

Monthly

As Required

Monthly/Annual/As Required

DEEERMS (Technical)

NSP Program Manager

DEEERMS

(Admin)

SAP Specific

Initiation

Identify Opportunity As required

Defence personnel or contractors


Create a SAP and set status to


Review any new SAP(s) for completeness and set status to Pre-Prioritisation or Closed Opportunity

Each time a SAP is

identified

Monthly

SAP Initiator

DEEERMS (Technical)

Prioritisation

Prioritise each new SAP and set

status to Prioritised.

Submit SAP for funding approval

Once a project is approved set the status to Planning

Monthly

Dependant on funding requirements

Once SAP funding

approved

DEEERMS (Technical)

DEEERMS (Technical)

DEEERMS (Technical)

Planning

Appoint Implementer

Approved SAP

Funding Source



Phase Task Frequency Responsible

Appoint SAP Auditor

Complete Planning section of SAP form and set status to

Implementation

SAP Verification Plan

Approved SAP

For each assigned SAP

For each assigned SAP

DEEERMS (Technical)

SAP Auditor

SAP Auditor

Implementation

Use the SAP Verification Checklist

Complete Implementation section of

SAP form and set status to Verification

Implemented Project

Implemented Project

SAP Auditor

SAP Auditor

Verification

Attach the Verification Report to the

SAP

Use the SAP Verification Checklist and attach to the SAP

Complete Verification section of SAP

form and enter Actual Completion Date

Verified Project

Verified Project

Verified Project

SAP Auditor

SAP Auditor

SAP Auditor

Finalisation

Identify projects with an Actual

Completion Date

Review the completed SAP Verification Checklist

Complete Finalisation section of SAP form and set status to Complete

Monthly

Completed Projects

Completed Projects

DEEERMS

(Admin)

DEEERMS (Admin)

DEEERMS (Admin)



Appendix B - SAP User Guide

July 2016

SUSTAINABILITY ACTION PLANS – Opportunity Description Sustainability Action Plans The purpose of Sustainability Action Plans (SAPs) is to allow for the definition, prioritisation and implementation of energy efficiency measures across the estate. SAP Creation Rules A Sustainability Action Plan is only created if it passes the following SAP Creation Rules:

The project can’t be actioned and rectified through the relevant Estate Upkeep Maintenance Strategy (e.g. Responsive Maintenance), due to scope and budget limits (e.g. required works may be greater than $10,000).

The project will reduce the whole of life cost of the estate (i.e. there must be a reduction in resource use, or a reduction in the cost of a resource, or a combination of both).

To create a SAP you need to login to the Resource Data Management System (RDMS). Resource Data Management System The RDMS holds Defence resource use data (e.g. electricity/water/gas) and also contains the list of SAPs. The RDMS can be found here (https://edms.mwhtools.com/) and for access contact: Dr Peter Moore Stantec Australia Pty Ltd Level 21, 141 Walker Street North Sydney NSW 2060 Tel: (02) 9493 9700 Email: [email protected]

Completing the Opportunity Description section of the SAP Login to the RDMS with your user name and password, then click on the Sustainability Action Plan tab:

Click on the Add button to open a new SAP form or use the Edit button on an existing SAP.

Complete the Opportunity Description section of the form with as much information as you can (the easier it is to understand what the project involves and the benefits the more likely it will be considered for funding). Hovering the cursor over the field names on the left side of the form will reveal some explanatory guidance about each field.

There is a Save button at the bottom of the form or click on the button to exit without saving. Additional information about the Sustainability Action Plans can be found in the RDMS Training Guide on the Support tab.

https://edms.mwhtools.com/

mailto:[email protected]

Documents

SUSTAINABILITY ACTION PLANS GOVERNANCE · sustainability action plans governance revision v1.3 draft 11th july 2017 . department of defence sap governance version 1.2 (6th march 2017)