NIPR-2695 Design Management Rev 1

Network infrastructure
PROCEDURE
Disclaimer:
Design Management
This document has been
prepared by V/Line for internal
use and must not be used or Design
relied on by any other party Application:
without V/Line’s prior written Management
consent.
V/Line shall not be liable to Document Number: NIPR-2695
unauthorised users of the
information for any loss, Date of Issue: 27/03/2018
damage, cost or expense
incurred or arising by reason Revision Number: 01
of unauthorised use of this
document or relying upon the This document has been endorsed and approved in
information in this document, accordance with the requirements of procedure SAPR-
whether caused by error, 16 “IMS Controlled Documents”. The record of approval
negligence, omission or is maintained within the V/Line Document Change
misrepresentation in this Request (DCR) system.
document.
Authorised use of this
document by an external party
shall be subject to the terms of
the relevant contract with
V/Line.
Document Number: NIPR-2695
PROCEDURE Date of Issue: 27/03/2018
Revision Number: 01
Design Management
TABLE OF CONTENTS
1 REVISION HISTORY .......................................................................................................... 4
2 PURPOSE ........................................................................................................................... 5
3 SCOPE ................................................................................................................................ 5
4 DEFINITIONS ..................................................................................................................... 5
5 RESPONSIBILITIES ........................................................................................................... 6
6 GENERAL ........................................................................................................................... 7
6.1 Introduction to Design Process .................................................................................... 7
6.1.1 Reference Designs ......................................................................................................... 8
6.2 Safety in Design ........................................................................................................... 8
6.3 Design Verification and Validation ............................................................................... 9
6.4 Drawing Format and Standards ................................................................................... 9
6.4.1 As-built Drawings.......................................................................................................... 10
6.5 Engineering Significance and Proof Engineering ...................................................... 10
6.6 Type Approval ............................................................................................................ 10
6.7 Compliance to V/Line Standards and Procedures ..................................................... 10
6.8 Pre-existing Conditions .............................................................................................. 10
6.8.1 Correlation of Pre-Existing Design Documentation....................................................... 11
6.9 Systems Engineering Approach ................................................................................ 11
6.9.1 Consideration of Future States ..................................................................................... 11
6.10 Competency ............................................................................................................... 11
7 DESIGN PROCESS .......................................................................................................... 12
7.1 General Requirements ............................................................................................... 12
7.1.1 Design Breakdown ....................................................................................................... 12
7.1.2 Design Planning ........................................................................................................... 13
7.1.2.1 Reporting Progress Against the Schedule of Design Deliverables ................ 13
7.1.3 Design Reviews ............................................................................................................ 14
7.1.4 Reports and Specifications ........................................................................................... 15
7.1.4.1 As Design Inputs ........................................................................................... 15
7.1.4.2 As Part of Design .......................................................................................... 15
7.2 Design Stage Gates ................................................................................................... 15
7.2.1 Concept Design Stage.................................................................................................. 16
7.2.2 Preliminary Design Stage ............................................................................................. 16
7.2.3 Final Design Stage ....................................................................................................... 16
7.2.4 Approval and IFC Stage ............................................................................................... 16
7.3 Systems Engineering by Stages ................................................................................ 17
7.3.1 Concept Design ............................................................................................................ 17
7.3.1.1 Mission Analysis ............................................................................................ 17
7.3.1.2 Stakeholder Needs and Requirements Analysis ........................................... 18
7.3.1.3 Functional Analysis ....................................................................................... 19
7.3.1.4 Concept of Operations .................................................................................. 20
7.3.1.5 Capability (Gap) Analysis .............................................................................. 21
7.3.1.6 Options Analysis and Assessment ................................................................ 22
7.3.2 Preliminary Design ....................................................................................................... 22
7.3.2.1 Resolution of Design Issues and Risks ......................................................... 22
Approved By: EGM Asset Management | Printed copies are uncontrolled Page: 2 of 39
Revision Number: 01
Design Management
7.3.2.2 Functional and Capability Analysis ................................................................ 22

7.3.2.3 Preliminary Design Review ........................................................................... 22
7.3.3 Final Design.................................................................................................................. 23
7.3.3.1 Validation through modelling ......................................................................... 23
7.3.3.2 Critical Design Review .................................................................................. 23
7.4 Design Stage Framework .......................................................................................... 23
7.4.1 Stage Design Development Process. ........................................................................... 24
7.4.2 Design Registers .......................................................................................................... 24
7.4.3 Variance to V/Line Standards and Procedure .............................................................. 24
7.4.4 Variance to the Project Requirements .......................................................................... 25
7.4.5 Systems Engineering Review ....................................................................................... 26
7.4.6 Independent Design Review ......................................................................................... 27
7.4.6.1 Independence from Design ........................................................................... 27
7.4.6.2 Partial Independence from Design ................................................................ 28
7.4.7 Safety in Design Workshops......................................................................................... 28
7.4.8 Stakeholder Review...................................................................................................... 28
7.4.8.1 Time for Stakeholder Reviews ...................................................................... 28
7.4.9 Engineering Change Meeting and Review ................................................................... 28
7.5 Reference Designs .................................................................................................... 28
7.6 Engineering Change Management ............................................................................ 29
7.6.1 Engineering Change Notice .......................................................................................... 29
7.6.2 Engineering Change Meeting ....................................................................................... 30
7.6.3 Engineering Change Review ........................................................................................ 30
7.7 Proof Engineering ...................................................................................................... 31
7.8 Use of Designs ........................................................................................................... 31
8 THIRD PARTY DESIGNS ................................................................................................. 31
8.1 Responsibilities within V/Line .................................................................................... 31
9 SAFETY IN DESIGN ......................................................................................................... 32
9.1 General ...................................................................................................................... 32
9.2 SiD Planning .............................................................................................................. 33
9.3 SiD Stages ................................................................................................................. 33
9.4 All Stages ................................................................................................................... 35
9.5 Registers and Reports ............................................................................................... 35
9.6 SiD Communications ................................................................................................. 35
10 SMS REQUIREMENTS .................................................................................................... 36
11 REFERENCES .................................................................................................................. 36
Revision Number: 01
Design Management
1 REVISION HISTORY
Revision Date Description of Change

01 27/03/2018 First Revision
02
Approved By: EGM Asset Management | Printed copies are uncontrolled

Revision Number: 01
Design Management
2 PURPOSE
This document sets out the requirements for the management of design, including safety
in design.
3 SCOPE
This standard applies to the design of all infrastructure managed by V/Line Infrastructure
under the Regional Infrastructure Lease (RIL).
4 DEFINITIONS
Please refer to the NIMG-2600, Infrastructure Definitions and Terminology for
abbreviations and terms used in this Standard. Additional abbreviations and terms
specific to this document are listed below.
ARTO Accredited Rail Transport Operator
AVA Approved Variation to Accreditation
Design Element An element of design, usually of one design discipline
associated with one region/section as defined in the Work
Breakdown Structure. For staged implementation, it may
include all work associated with a temporary or permanent
change to the rail network.
Design Package A logically-combined package of design elements which is
processed through the review process prior to IFC as
defined in each Design Management Plan.
Design Package Status The status of a Design Package which defines the progress
of the design through the design process.
Design Review The submission by the Designer of a Design Package
which is required to be reviewed by stakeholders including
ARTOs (following this standard).
Design Management Plan A detailed plan complying with this standard setting out the
resources, timelines and process of design development
specific to the design scope.
Design Verifier A person independent from the design team for a Design
Package, who reviews the design for suitability and
compliance with the requirements.
Designer The entity that develops and completes the design.
CHAIR Construction Hazard Assessment Implementation Review,
a critical part of Safety in Design (Safety in Design)
assurance.
HAZID A tool for “Hazard Identification” (a qualitative
technique/method for the early identification of potential
hazards and threats effecting people, the environment,
assets or reputation).
IFC Issued for Construction (design documentation).
MoC Management of Change (a process by which an ARTO
safely introduces significant change).

Revision Number: 01
Design Management
ONRSR Office of the National Rail Safety Regulator.

Project Entity The entity accountable for the delivery of the project.
Project Manager The person responsible for the management of a project as
set out in COPR-100 “Project Management Methodology”.
Proof Engineer A person independent from the design team for a Design
Package, who verifies the design outputs for compliance
with the requirements, without reference to the process,
assumptions or calculations used to formulate the design.
RAMS Reliability, Availability, Maintainability and Safety
SFAIRP So Far As is Reasonably Practical. A concept enshrined
within Rail Safety National Law and has the meaning as set
out in that statute.
Safety in Design A critical outcome of the design management process for
assurance relating to safety in all aspects of the design
product lifecycle, from creation to disposal.
SMS Safety Management System (of an ARTO as the basis of
its accreditation).
V/Line Representative For this Procedure, the V/Line Representative refers to:
 For third party projects, V/Line refers to an authorised
V/Line representative as referred to the third party.
 For a State Project under the terms of the Regional
Infrastructure Lease (RIL), V/Line refers to the
nominated V/Line Representative.
 For a V/Line internal project, V/Line refers to the
V/line Project Manager.
WBS Work Breakdown Structure.
Work Package A section of a Project managed discretely within the
Project.
Work Package Manager The responsible manager of the Work Package
5 RESPONSIBILITIES
The responsibility for complying with the requirements of this standard is with the Project
Manager, and where delegated, the Work Package Manager.
The Project Manager is responsible for Validation of the design, ensuring that the
specification and requirements for design meet the project objectives and produce
outcomes that meet the needs of customers and relevant stakeholders.
Each project will have a Design Manager responsible for delivery of the design process
from inception through to project handover. The Design Manager is responsible for
Verification of the design, ensuring that the design meets the specification and
requirements.
The Design Manager will coordinate Work Package design activities, ensuring that:

Revision Number: 01
Design Management
 All designs comply with the project requirements, V/Line standards and the
V/Line Safety Management System.
 A design plan and design program are developed and approved in accordance
with the Project Management Methodology (COPR-100).
 Designs are managed in accordance with this standard.
 Design complies with the design plan and program.
 Derogations to standard are approved in accordance with NIPR-2000 “Technical
Standards: Development, Change and Derogations” before being incorporated in
any design.
 Approvals are obtained for all design inputs and outputs in accordance with this
standard and Project Management Methodology (COPR-100).
Persons used to manage and deliver the Safety in Design (SiD) sub-process must have
relevant industry experience and risk management qualifications. They must be
competent, appropriately skilled and adequately resourced to address the health and
safety issues likely to be involved in the design; and to check controls, monitor risks,
improve controls and communicate effectively about risks and their management to
stakeholders.
6 GENERAL
6.1 Introduction to Design Process

The engineering Design Process is the set of steps that start with identifying a problem
or need, and end with creating and developing a solution that solves the problem or
meets the need. The broad steps are listed below:
 Define the Problem
 Do Background Research
 Specify Requirements Define the
 Create Alternative Solutions Problem
 Choose the Best Solution Do the Additional

Background Research as
 Do Development Work Research Required
 Produce the Design

Specify Ammend
 Verify and Validate the Requirements Requirements
Design (including
Stakeholder engagement) Choose the Choose the
Best Solutions Best Solutions
 Proof Engineer the Design
(where significance Do Do Do
warrants) Development Development Development Proof Engineer
Work Work Work
 Approve the Design
 Construct the Design Produce
Produce
Preliminary
Produce Final Approve the
Concept Design Design Design
Design
These broad steps are presented in
Figure 1, for each of the principle Verify and Verify and
Verify and Construct the
design phases of: Validate the Validate the Validate the
Design
Design Design Design
 Concept Design

Revision Number: 01
Design Management
 Preliminary Design; and Figure 1 - Broad Design Process

 Final Design
The broad design process principles set out above are detailed in section 7.
The design process is undertaken within the Planning and Development stage of the
Project Management Methodology (COPR-100).
6.1.1 Reference Designs

In the case of complex designs, a reference design may be developed and form part of
the requirements. A reference design will also require each of the broad steps listed in
Section 6.1 (with the exception of construction of the design). A reference design must
also be approved prior to being incorporated into the project requirements.
The process for development of a reference design is undertaken within the Feasibility
stage of the Project Management Methodology (COPR-100).
6.2 Safety in Design

Legislative obligations under Section 27 of the Occupational Health and Safety (OH&S)
Act, and the Rail Safety Act (RSA), require that safety in all aspects are integrated into
the design process. Compliance with the requirements set out in this document
ensures:
 A consistent approach to managing Safety in Design (SiD) is achieved across all
areas of Project delivery and Asset Management; and
 Safety in Design is achieved, and V/Line is assured of compliance with OH&S
legislation and Management of Change (MoC) requirements under the RSA.
Safety in Design shall address, but is not limited to, rail system safety, construction
safety and public safety under construction, normal operating and emergency conditions.
This procedure, and the requirements detailed in section 9:
 Set-out V/Line’s requirements for design compliance with risk management
protocols contained within V/Line’s Safety Management System (SMS).
 Detail the project design process and associated activities involved in delivering a
safe design.
 Ensure process is in place that complies with regulatory requirements.
 Set-out the requirements for the Design Manager (whether internal to V/Line, a
Contractor, or a third party) to collaborate and work with the broader business to
administer the Safety in Design process, inclusive of communications, record
keeping and reporting at each stage of design development.
 Set-out the evidence and other requirements for review of a design prior to the
Design Package being Issued-for-Construction (IFC), in order for V/Line to be
assured that the design requirements are met inclusive of assured Safety in
Design.
 Reinforce Contractor and third-party compliance with V/line’s Design
requirements and reinforce Contractor and third-party obligations to comply with
their duties under legislation.

Revision Number: 01
Design Management
 Ensures that the design process provides all necessary outcomes in support of
any Application for a Variation to Accreditation (AVA) for any approved temporary
or final states resulting from the design.
 Ensure that design responsibilities include obligations beyond the execution
phase of a project, including reduction in health and safety risk SFAIRP of those
who will operate, maintain, repair, clean, refurbish, use, interface with, and/or
eventually remove or demolish all or part of the designed element or system.
 Set out the requirements for design review for assurance of Safety in Design.
6.3 Design Verification and Validation

Design verification and validation is required in accordance with this document, relevant
standards, AS 4292 Rail Safety Management and AS/NZS ISO 9000 Quality
Management and Assurance Standards.
Validation shall be achieved by confirming that the specification and requirements meet
the expectations of the customer and relevant stakeholders. Verification shall be
achieved by ensuring the design package meets the specifications and requirements.
Verification is established by the review process set out in section 7.1.3, and shall occur
where specified in the design process (Refer to section 7.4), which is either at the
completion of each design stage for major projects or at the completion of the design
task for minor projects. Design verification is to ensure that the design output for each
design stage is consistent with the design input (requirements) for that stage.
Verification and Validation are mandatory activities and a pre-requisite for design
approval. The Project Manager shall ensure that all designs are Validated and Verified.
Verification throughout the design process and Validation of the final design is required
to ensure that:
 the design output conforms to specified requirements.
 the design has been completed in accordance with the appropriate procedures
and standards.
 the design has considered all applicable aspects listed in the design
specifications, configuration change requests, design checklists or the
proceedings of a technical review, including test results where appropriate.
 supporting calculations and decisions for defined critical systems have been
checked and verified.
 the requisite approvals have been obtained from regulatory authorities.
 the design has been properly documented.
Design Verification shall be carried out by suitably qualified and competent persons
appropriately independent of those having direct responsibility for the design work. As
an additional validation, the design shall also be subject to systems engineering reviews
covering elements such as for constructability, in accordance with Section 7.3 of this
document.
6.4 Drawing Format and Standards

Engineering drawings shall comply with VRIOGS 007.02 “Infrastructure Drawing
Standards”.

Revision Number: 01
Design Management
6.4.1 As-built Drawings

As built drawings must be certified, authorised and booked into the PTV DMS within
three (3) months of substantial completion of any works.
6.5 Engineering Significance and Proof Engineering

Designs have various complexity and significance to the safety and reliability of the
infrastructure. All design works shall be independently Verified and Validated
irrespective of significance. Subject to engineering significance, Proof Engineering of a
design may be required.
Where design works are not of a complex nature and are for components and outcomes
that have differences materially insignificant to previous design works that have been
undertaken and implemented on the V/Line network, proof engineering of design will not
be required.
However, where a design is complex in nature, or contains components that are
materially different to components that have been previously designed and implemented
on the network, and the Commercial or Safety Risk cannot otherwise be demonstrated
to be mitigated so far as is reasonably practicable (SFARP); the design shall be proof
engineered.
Where there is any doubt as to whether a design is to be proof engineered under the
requirements of this document, it shall be referred to the General Manager Network
Engineering who shall either:
 Direct that proof engineering is performed; or
 Establish that the risks have been managed SFARP in accordance with the
requirements of the V/Line Enterprise Wide Risk Management Process; and that
proof engineering is not required.
6.6 Type Approval

All components used in design must be type approved in accordance with NIPR-1310
“Type Approval”. Where a design proposes to use a component that is not currently
Type Approved, the Design Manager must apply for and receive Type Approval for the
component prior to the final design. Where Type Approval is not granted, the design
must be amended accordingly prior to final design.
6.7 Compliance to V/Line Standards and Procedures

Designs shall comply with all standards and procedures as documented in the V/Line
Safety Management System (SMS). Deviations from V/Line standards and procedures
must only be incorporated into the design where a derogation is approved.
Derogations to standard must be approved in accordance with NIPR-2000 “Technical
Standards: Development, Change and Derogations”.
6.8 Pre-existing Conditions

Prior to undertaking any design interfacing with or altering existing assets, a dilapidation
study must be undertaken. The study shall document all non-conformances of the
existing assets to both the project requirements and to V/Line Standards. For each non-
conformance and dilapidation issue, it must be identified if the design is to correct or not
correct the issue.

Revision Number: 01
Design Management
Where the design does not intend to correct an issue (i.e. the issue is outside of the
project requirements), this must be reported to V/Line who shall risk assess and mitigate
so far as is reasonably practicable (SFAIRP). Where V/Line does not wholly eliminate
the issue, the residual issue/risk must be considered as part of the safety in design
assessment.
6.8.1 Correlation of Pre-Existing Design Documentation

For all designs based on existing design, the existing design documentation must be
correlated and verified against the in-service condition prior to any design progressing
based on changes to existing design documentation. Correlation of pre-existing design
drawings to in service arrangements is a critical activity, especially for signalling design.
6.9 Systems Engineering Approach

All designs shall follow a Systems Engineering approach, which considers the entire
lifecycle of the design, from production (construction) through to deployment, operation,
and retirement stages. The Designer shall have a documented Systems Engineering
Process.
Designs must be developed through an interdisciplinary approach that includes:
 Integration of Work Packages.
 Integration of disciples.
 Integration with existing systems and not only those implemented as part of the
design.
 Impact analysis on existing systems, organisations and services.
 Impact of design outcomes over the lifecycle of the product of the design.
6.9.1 Consideration of Future States

All designs must consider their impact and effect on potential future states. Where
future states are known, the design must facilitate further future development for the
future state and where possible, be developed specifically for the future state. Where
future states are uncertain, the designer shall undertake a probabilistic assessment of
likely future states through consultation with stakeholders. Examples of future states
include without limitation:
 Changes in track classification (hence operating speed and conditions)
 Changes in capacity (e.g. increases in train numbers, changes to operating
rules, increase in patronage)
 Changes in use (e.g. Regional DMU to Metropolitan EMU operation)
 Future capital development (e.g. adjacent suburban development, new tracks or
structures for rail operations)
 Changes in rollingstock or operating conditions (e.g. Heavier loads, faster
speeds, longer trains)
6.10 Competency
The Designer shall ensure that all staff involved in the design are competent in the tasks
they undertake.

Revision Number: 01
Design Management
Designers, reviewers, and all other staff involved in the design shall hold required
competencies, licenses or registrations as required by law, and as also otherwise
defined in V/line’s Safety Management System to perform their respective functions for
the design.
The Designer shall provide resumes of all key design staff to V/Line before the staff are
engaged in any design. For all staff, the Designer must provide:
 A current Curricula Vitae (CV) describe the person’s academic, technical and
trade qualifications, overall experience, and relevant experience on design,
construction, testing etc. CVs shall be appropriate for the classification of staff.
 The role that staff will undertake in the design and whether the Designer
considers that staff are sufficiently proficient to work autonomously on the design,
or whether the staff will be supervised. Where staff are supervised, the CV if the
Supervisor must also be provided.
Specifically, for signalling design the Designer must provide for all staff:
 A Work Experience Record (WER) form, Log Book, or other equivalent document
agreed with V/Line. Verification signature(s) by applicable supervisor/mentor
must accompany each record;
 A signed statement of competency.
Persons carrying out safety critical design or design review must have their qualifications
reviewed and approved by V/Line prior to those persons performing any design work.
For avoidance of doubt, persons carrying out signalling, structural or geotechnical design
must be approved by V/Line.
7 DESIGN PROCESS
7.1 General Requirements
7.1.1 Design Breakdown

Design for large or multidiscipline projects shall be managed by segregating the design
into a Work Breakdown Structure (WBS). The WBS shall be established to best manage
the project and design, and may be by:
 Location (regions and sections, e.g. track sections or geographic area);
 Implementation stage involving all disciplines required as part of an application
for an occupation and/or a MoC submission.
 Disciplines (e.g. drainage, signalling, earthworks etc.); or
 Significant assets such as a structure.
Within the WBS, design elements shall be identified, and design packages determined.
Design packages may include one or more elements within a WBS. For each Design
Package, a manageable Schedule of Design Deliverables shall be developed.
Each Design Package shall have a unique identifier.
The WBS, Design Packages, and the Schedule of Design Deliverables shall be included
in the Design Management Plan (DMP) (See Section 7.1.2).

Revision Number: 01
Design Management
7.1.2 Design Planning

Each Design Package Manager is required to produce a Design Management Plan
(DMP) for the Design Package. The DMP is to be submitted for acceptance by V/Line
prior to design commencement.
The DMP shall include planned dates for submission to V/Line of each of the Design
Deliverables at each stage of the design process. These dates are to enable ARTO
design reviewing resources to be planned. The DMP shall also include planned dates
for submission of the end stage designs for Engineering Change Management (Refer to
section 7.6).
The DMP will cross reference the SiD risk management approach and will outline the
output format from the applied process (Refer to section 9.2).
The planned IFC submission dates must be consistent with the Construction Program.
To meet the Design and Construction Program, it may be proposed that the
development of a Design Package continues concurrently while the Design Package or
associated Design Packages (see section 7.4.5 regarding the systems engineering
approach) are being reviewed and not wait until the Designer and Design Manager
receive comments from V/Line and stakeholders. In such cases, the Designer (and as
the case may be, the Project and Contractor) proceeds at It’s own risk in terms of design
costs, and time for completion, and progress in design will not be considered as grounds
to not rework the design in response to V/Line or other stakeholder review.
Each Designer must submit to V/Line, its proposed Schedule of Design Deliverables
(DPs, technical reports, specifications, etc.) for each Design Package which are collated
by the Design Manager into the Master Register and Schedule of Design Deliverables.
This register is dynamic as circumstances may change during the design period of the
project. Changes to design schedules and deliverables must be managed in accordance
with COPR-100 “Project Management Methodology”. Examples of reasonable
circumstances leading to reconstitution or rescheduling of Design Packages may
include”:
 To better meet the timely requirements for construction;
 To comply with work method statements of the construction teams; or
 Due to staging and interfaces with other Work Package teams.
7.1.2.1 Reporting Progress Against the Schedule of Design Deliverables

It is recognised the Schedule of Design Deliverables can be dynamic and subject to
change as packages are re-constituted to better meet construction and staging timelines
etc. and interfaces with other WPs.
The Design Package Manager will issue weekly updates (unless otherwise agreed) of
the Schedule of Design Deliverables defining Design Package development, SiD
workshops (incorporating ARTO Rail Safety Accreditation Risk Assessment) and review
dates for each Design Package and stage of design development. These dates are to
enable ARTO stakeholders to plan the logistics, resourcing, conflicts with other work
pack activities and to ensure the required end user risk and safety consultation
obligations are delivered.

Revision Number: 01
Design Management
7.1.3 Design Reviews

Each project requires designer, Internal and external reviewers of design packages
during the development of each design package.
Designer reviews to be conducted by the design team include:
 Designer scope and technical check.
 Designer QA.
 Safety in Design (refer to Section 9).
 Design validation and verification.
Project Internal reviews include:
 Validation against the Project Requirements.
 Constructability (the ability of the design to be effectively fabricated and
constructed) [a specific subset of Systems Engineering].
 Safety in Design.
 Economic (cost) evaluation (whether the design is economic in its configuration,
for both fabrication and construction) [a specific subset of Systems Engineering].
 Systems Engineering Review (Refer to section 7.4.5).
Design reviews must be for the purposes set out above and must not contribute to the
design solution.
Where the Project in whole or part is contracted to a second party, the Contractor forms
part of the internal project team (refer to COPR-100) and must also undertake all internal
project reviews, either in addition to or in concert with other members of the internal
project team.
Project external reviews are undertaken by the asset owners and managers, and by
major stakeholders impacted by the design. Some external reviews are mandated by
legislation or by the project requirements. In the case of all projects, V/Line functional
areas shall be afforded the opportunity to review the designs where impacted. In the
case of Third Party Projects or State Projects, V/Line must establish a review team for
the design outcomes of those projects.
External reviewers include:
 Proof Engineering entity (refer to Section 7.7).
 V/Line Stakeholder Review (Considering aspects such as operational impacts and
implications of the design to the reliability and availability of assets and services,
both in its final state and during construction)
 Impacted Stakeholders
Irrespective of whether V/Line is delivering the project or is a stakeholder, V/Line must
ensure so far as is reasonably practicable that the project delivery and outcomes are
safe and fit for purpose. All projects will be subject to engineering change management
to ensure that design reviews have been executed in accordance with this procedure
(Refer to section 7.6).
Table 1 - Principal Design Reviewer Responsibilities
Reviewer Responsibilities
Design Review Types
Designer Internal External

Revision Number: 01
Design Management
Designer Scope and Technical Check X

Designer QA X
Safety in Design X X
Design Verification X
Design Validation X X
Constructability (subset of Systems Engineering) X
Economic (cost) evaluation (subset of Systems Engineering) X
Systems Engineering Review X
Proof Engineering X
Stakeholder Reviews X
7.1.4 Reports and Specifications
7.1.4.1 As Design Inputs

Reports and specifications may be a pre-requisite for a design package or be prepared
as part of the project requirements.
Such reports and specifications constitute design works but will not be part of the final
IFC design, but influence the design outcome. As such, the development of these
reports and specification shall follow the design process up to stage 3 (Refer to section
7.2).
7.1.4.2 As Part of Design

Where reports and specifications are developed in the execution of a Design for a
Design Element, they shall be included in the Design Package for the project. Reports
and specifications that are not required for the documentation of the final design in IFC,
are not required to progress beyond stage 3 (Refer to section 7.2).
7.2 Design Stage Gates

There are four main stages in the design production process:
 Concept Design.
 Preliminary Design.
 Final Design.
 Approval and IFC.
Each of these stages is described below. The broader process flowchart is provided in
Attachment 1.
The design stages align to the stages set-out in COPR-100 “Project Management
Methodology”.
All stages of design management are to be processed in the Project’s document
management system.
The concept, preliminary, and final design processes shall comply with the process
shown in Figure 4 and as described in section 7.4.

Revision Number: 01
Design Management
7.2.1 Concept Design Stage

The concept design stage follows the project feasibility stage within COPR-100. It is the
earliest stage of the design process, determining and outlining the broad form and
function of the design.
The concept design is a critical stage in the development of the design, as good design
starts with a good concept. The concept design must first understand the needs and
requirements of all stakeholder and bring these together into an integrated design
concept that meets their collective needs, whilst achieving the project requirements.
The decisions made at the concept design stage generally set the constraints for future
options.
The concept design is reviewed from a Systems Engineering viewpoint but does not
require an independent technical review as it does not contain a high level of technical
detail.
7.2.2 Preliminary Design Stage

The preliminary design stage focuses on the further development of a system-level
design. It builds on the concept design to produce a moderate-level design that
evaluates and develops all design solutions necessary for the delivery of a holistic
design to meet the project requirements. It reviews and integrates stakeholder
comments from the concept design stage into the design.
Almost all of the pure design activities are undertaken in the preliminary design stage,
including all engineering and technical design measurements, assessments,
calculations, and determinations. Drawings and design documentation are sufficiently
detailed so as to communicate the design effectively but may omit lower level detail
necessary to accurately build or fully exercise the design.
7.2.3 Final Design Stage

The final design stage expands the preliminary design down to the lowest level required
to accurately build or execute the design. It elaborates on all aspects of the design
providing a complete and detailed description of all designed elements in the form of
drawings, specifications, reports and instructions. It reviews the stakeholder comments
from the preliminary design stage and makes any required adjustments the preliminary
design prior to detailing the design further.
7.2.4 Approval and IFC Stage

The stakeholder reviews of the final design are evaluated by the Designer and the final
design amended as required. The Designer shall ensure that the design comments from
all stakeholders at all stages of the design have been closed out.
The final design documentation incorporating all changes made as a result of
stakeholder comments is presented to the Approval Authority for approval. Subject to
whether approval is given or is not given, there may be several cycles of minor design
iteration and resubmission prior to approval being granted. Once approval is granted, the
drawings shall be marked “Issued for Construction” (IFC).
The Approval Authority for designs may differ between projects. Where the Approval
Authority is not specified, approval rests with the Project Manager.
Design documents may not be marked IFC unless the Engineering Change Review for
the final design has been endorsed in accordance with section 7.6

Revision Number: 01
Design Management
7.3 Systems Engineering by Stages

As a minimum, the Designer’s systems engineering processes shall include the
processes setout herein for each stage. This document does not set out a
comprehensive systems engineering methodology, and the requirements herein are
minimum requirements only. The requirements outlined herein are scalable and the
breadth of analysis should be tailored to the design task.
7.3.1 Concept Design

The concept design as a minimum, shall be subject to a Mission Analysis, and a
Stakeholder Needs and Requirements Analysis as set out in this section.
V/Line considers the Capability (Gap) Analysis to be most critical aspect within the
Mission Analyses, and the development of a Concept of Operations to be most critical
aspect within the concept design process. As such, specific requirements for each are
also set out in this section.
7.3.1.1 Mission Analysis

The Mission Analysis is a broad process of Mission Analysis
understanding the mission in terms of the problem to
be solved and the opportunity/advantage to be gained; Strategy Analysis:
and exploring the solution space for solutions that  Strategy, mission, vision
solve the problem and maximise opportunities and External Context Analysis:
advantages.  Benchmarking
 Political, Economic, Social,
The mission analysis shall cover four principal areas of Technology, Environmental,
analysis: and Legal Contexts.
Internal Context Analysis:
 Strategy Analysis  Capability (Gap) Analysis
o Review and understand the mission, vision  Business KPI’s
and operations of V/Line and other  Value Chain Analysis
interfacing and impacted ARTO’s. SWOT Analysis
o Review and understand the mission and

vision for the change to be implemented from the design, and (where the
change is initiated external to V/Line) its compatibility with the current
mission/vision and operations of V/Line.
 External Context Analysis
o Review and assess the operations, processes, innovations, performance and
practices of similar organizations and scenarios to identify design
opportunities and solution elements, and further opportunities for the design
to lead to improvement. Compare and implement the findings to the design
solutions as they are developed (Benchmarking).
o Review and assess the political, economic, social, technological,
environmental and legal contexts, and how each may impact on potential
design solutions.
 Internal Context Analysis
o Review and assess capability to deliver, operate and maintain the design
(refer to section 7.3.1.4)
o Assess the required and potential usage of the design, considering all

Revision Number: 01
Design Management
possible operating states and, approaches and modes of usage.

o Undertake an analysis of the value chain and the impact of the design within
the value chain, considering process inputs and outputs, and the relationship
between the design and primary and support activities within the value chain.
For V/line, the principal broad value chain relationships are outlined in Figure
2. The designer must consult with V/Line to determine more specific value
chain elements influenced by the design.
o Assess the Key Performance Indicators for V/Line and align the design to the
achievement of performance targets.
 SWOT Analysis
o Considering the context of the design, assess the strengths and weaknesses
internal to V/Line and the opportunities and threats external to V/Line.
Optimise the design in respect of these threats, weaknesses, opportunities
and threats in the context of the overall mission.
Safety
Infrastructure
Activities
Support
Human Resources
Technology Development – Continuous Improvement, IT, Innovation
Procurement
Asset Service
Primary Activities
Customer
Management Delivery
Asset Availability,
Service Schedule, Marketing Customer
Reliability,
Performance, and Experience,
Comfort and
Reliability Sales Customer Service
Performance
Figure 2 - V/Line Broad Value Chain

All decisions leading to a concept design solution must be supported by the above
analysis and an Options Assessment (see section 7.3.1.6).
7.3.1.2 Stakeholder Needs and Requirements Analysis

The Stakeholder Needs and Requirements Analysis
Stakeholder Needs and
shall consider the needs and requirements of Users
Requirements Analysis
(Operators, Maintainers), Customers, and affected
stakeholders both internal to V/Line and external. Stakeholder/Customer Assessment:
 Mission
The Stakeholder Needs and Requirements Analysis,  Needs
and the Mission Analysis are closely related, as the  Constraints
missions and needs are interdependent. Operational Concepts:
Stakeholder needs must be determined in the earliest  Operational States
stages of the design process through a structured  Potential usage
approach. Once stakeholder needs are determined,  Operational Constraints
they will form the basis for the stakeholder Stakeholder Processes (future state)
requirements, against which the design outcomes

Revision Number: 01
Design Management
must be validated.
The designer must:
 Identify all stakeholders who will be involved at each stage of the lifecycle, from
construction/production through to retirement.
 Implement a structure process to attain customer, user, and other stakeholder
needs, as well as their missions and constraints. Processes that may be applied
include: brainstorming, surveys, meetings and interviews, review of standards and
other documented requirements, modelling, lessons learned reports from similar
design activities/infrastructure changes, obtaining the stakeholders missions, KPI’s
and Targets, and through various functional and diagrammatic tools. In assessing
needs, care must be taken to obtain not only those needs that are expressed by
stakeholders, but also the underlying real needs that may exist, but are either
taken for granted/assumed or have low awareness, and therefore are seldom
expressed.
 Assess the Stakeholders operational concepts by determining the end operational
states needed, the potential usage factors, and the stakeholder operational
constraints.
 Consider the likely future state/s and the needs of stakeholders for that/those
future state/s.
 Prioritise the stakeholder needs by criticality and relative importance to the design
outcomes. The prioritization criteria will be mission dependent. The designed
shall demonstrate the methodology use to prioritise the stakeholder needs to
V/Line on request.
 Transform the prioritized needs into stakeholder requirements.
 Validate the stakeholder requirements against the criteria for broader system
requirements (To the extent already developed during project feasibility, the
business case, or in reference to a similar best practice project), ensuring that all
relevant requirements are covered and valid such as Functional Requirements,
Performance Requirements, Usability Requirements, Interface Requirements,
Operational Requirements (Refer to COFO-117), Adaptability Requirements,
Environmental Requirements, Logistical Requirements, and time, cost and
physical constraints, or constraints mandated by legislation.
7.3.1.3 Functional Analysis

When exploring new concepts, the functional analysis Functional Analysis
is a fundamental process that aids both in discovering
Functions Identification:
new concepts and defining their architecture. It
 Functions Tree
applies across all levels and phases of design
 Function Criticality
(Concept, Preliminary and Final Design), as the
 Basic Function Derivation
functional analysis deepens as detail is developed
Function Fulfilment:
within the design.
 Basic product identification
The designer shall implement a functional analysis  Systems Identification
process to explore all required functional elements of  Products and Systems Tree
the design. For each of the functional elements
required, the designer shall identify products or

Revision Number: 01
Design Management
systems that will satisfy one or more of these functions and integrate these into the
design.
The designer’s functional analysis process shall consider the criticality of each function
to the overall mission, and prioritise design elements accordingly.
The functional analysis process employed by the Designer shall include as a minimum:
 Identification of top-level functions to meet the mission objectives.
 Include a systematic identification process to determine the basic functions
required. This process must systematically break down the top-level functions
progressively into subordinate functions until a comprehensive list of basic
functions is obtained. This process can be achieved by a diagrammatic flow chart
or an outline numbered list (each may be referred to a functions tree) that
diagrams the functional breakdown through to the basic functions (which are the
ends of each branch on the flowchart or outline numbered list). An example of a
simple function tree is as follows (Basic functions are presented in red text.:
1.To…Top-Level Function
1.1. To...Function
1.1.1 To...Function
1.1.2 To...Function
1.1.2.1 To…Function
2.2. To…Function
2.To…Top-Level Function
2.1. To…Function
 Identify the basic products or sub-systems that will satisfy each of the basic
functions. One basic product or system may satisfy the requirements of more
than one basic function.
 Examine the links that may exist between the basic products and systems.
These links may be because of any interaction of interface that would be
expected between any two basic products or systems. For example, a train
control system would need to interact with train detection system. The
interactions can be complex with multiple connections between basic products
and systems.
 Working backwards for each basic product or sub-systems identified, and
considering their interactions, determine the higher-level subsystems and
systems that will form the basis for the Design. This should be presented in the
form of a products and systems tree, similar to that described for the functions
tree.
The functional analysis identifies the basis products and systems required to meet the
functional requirements and must not identify specific market products or solutions in
detail. To do so may constrain the design, resulting in a suboptimal design solution.
7.3.1.4 Concept of Operations

The concept design process must establish a Concept of Operations that describes the
product or systems characteristics (as the case may be) for a proposed product or
system from a user's perspective. A Concept of Operations is mandatory for all designs.

Revision Number: 01
Design Management
The Concept of Operations document is scalable, and its development and content can
vary subject to the system or product being designed. Notwithstanding such variances,
it must as a minimum describe the proposed system product in terms of its utility and
operation by the users, its relationship to existing processes, systems or procedures,
and the core operational parameters.
In general, the Concept of Operations will document the following:
 A declaration of the goals and objectives of the design activity.
 All operational rules, standards, policies and constraints effecting the product of
system.
 All interactions by all relevant stakeholders (including organisations, employee
roles, and customers) with the product or system.
 Any specific qualifications, competence or authority required to operate or
interact with the product or system; and
 Specific operational processes for the product or system.
 A description of operation. Railway operation is based on fundamental operating
principles documented within V/line’s Safety Management System (SMS) and as
mandated by legislation. These principles have a core purpose of enabling the
safe and reliable transportation of people and products. The Concept of
Operations must describe the operational processes and specific implementation
of the principles.
7.3.1.5 Capability (Gap) Analysis

The Designer shall review and
assess the capability of all relevant Stakeholder
stakeholders to deliver, operate, Capability Analysis
maintain and decommission the

Market Capability
design. The general process is Analysis
described in Figure 3.
INNOVATION
Design Solution Design Solution
Where any part of the lifecycle of Available within
No
Available within
No
Project to Risk
Assess and Re-
Stakeholder Market
the design is to be performed/used Capability Capability
Assess
Business Case
by a supplier or contractor, the Yes
design shall review and assess the Yes
capabilities available within the Design Options
Development
Yes
Innovation
Green Light
market. If the design solution is
innovative, capability to delivery, Options
No
operate, maintain or decommission Analysis and End

Selection
the design may not reside within
either the stakeholder or the Capability Gap
Analysis
market. In this case the design
option is to be referred to the CLOSE GAPS
(Training,
Project Manager for risk Gaps Identified? Recruitment,
assessment and reconsideration of Procurement,
Development)
the business case. The Project No
Manager shall through the Project
End
Management Framework (PMF),
obtain the view of whether the
innovation should be further
Figure 3 - Integration of Capability Analysis into the
Concept Design process
Revision Number: 01
Design Management
developed for consideration in the design option (and capability developed), or not
considered.
The outcomes of the capability analysis shall be considered for all design options and
weighed against other factors in the Options Analysis and Assessment (section 7.3.1.6).
For the selected concept design option, a Capability Gap Analysis must be performed,
and the outcomes of the analysis shall by referred to the Project Manager. The project
manager shall ensure that the capability gaps are closed, typically through training and
development activities, or through the recruitment or procurement of people, resources,
equipment or other items required to effect capacity.
7.3.1.6 Options Analysis and Assessment

All concept design options shall be subject to an options analysis in accordance with the
processes set out in COPR-100. The designer shall provide the outcomes of all analysis
undertaken in the concept design stage to the Project Manager for the options Analysis
and Assessment, along with the technical details and documentation for each design
option.
The designer shall participate in the options analysis.
7.3.2 Preliminary Design
7.3.2.1 Resolution of Design Issues and Risks

Throughout the preliminary design stage, design issues and uncertainties should be
resolved. The completed preliminary design must have resolved all critical system
issues and all other major issues and risks prior to progressing to the final design stage.
7.3.2.2 Functional and Capability Analysis

The functional and capability analysis described in sections 7.3.1.5 and 7.3.1.3
respectively shall be further expanded in the preliminary design stage, with expanded
detail required for the increased features identified in further detailing the design.
7.3.2.3 Preliminary Design Review

The Preliminary Design Review is an assessment that ensures that the system design is
effective and meets the required outcomes within the acceptable risk, time and cost
tolerances of the project. It establishes the required assurance for proceeding with the
final design.
Specifically, the Preliminary Design Review must:
 Establish that all base functions have been allocated to a system design and are
resolved in design configuration items (products and systems).
 Confirm that the design meets the project objectives.
 Confirm that the preliminary design is feasible to implement, including validation
of the Capacity Analysis (evidence of feasibility).
 Confirm that the design can be accomplished within the approved project
tolerances of time and cost (review schedule and cost estimates based on the
design).
 Ensure that risks are managed within the acceptable limits as defined in the
V/Line Enterprise Wide Risk Management (EWRM) system, and where risk is

Revision Number: 01
Design Management
related to rail safety, is reduced so far as is reasonably practicable (SFAIRP).
7.3.3 Final Design
7.3.3.1 Validation through modelling

Where specified by V/Line, design validation through modelling must be performed.
Modelling may be theoretical (scenario assessments, computer modelling, or
simulation), or practical (such as the development and testing of a prototype)
7.3.3.2 Critical Design Review

The Critical Design Review is a multi-disciplined approach to assessing whether the
system will meet the required outcomes and performance requirements; and satisfy the
time, cost and risk constraints of the project. The Critical Design Review ascertains
whether the project can proceed to execution based on the outcomes of the final design.
Specifically, the Critical Design Review must:
o Confirm that the final design meets time, cost and performance requirements;
o Confirm the integration and
compatibility of the final
design elements/packages Project
Prior Stage Requirements
with other design
V/Line
elements/packages, Standards
Stage Design
considering all elements Stakeholder
Development
Consultation
including communication, Process
Not Approved
people, existing and Not Approved
proposed new assets and Variance to
V/Line
Yes Procedure
equipment, buildings and Standards?
NIPR-2000
facilities, computer software, Approved
and the configuration of
other systems. Variance to V/Line
Project Yes Procedure
Requirements? COPR-100
o Determine and assess risk Changes
Accepted
associated with the final
Design
design, including the Documentation
technical risk; and cost and
time impacts on the project Systems
Engineering Review
budget or schedule.
o Assess the constructability Independent Design
Review
(or ability of design elements
to be produced) of the Sid Workshop
(CHAIR)
design.
o Assess the adequacy of the Engineering Change
Notice NIFO-2695.1
design documentation (is it
complete, unambiguous,
Engineering Change Stakeholder Review
user friendly?) Meeting Meeting/s
7.4 Design Stage Framework V/Line Engineering

Stakeholder Review
Change Review
Each design stage shall comply with No
Update Review
the framework set-out in Figure 4. Comments Register
Change STAGE
Endorsed? GATE
Next Stage
Revision Number: 01
Design Management
7.4.1 Stage Design Development Process.

V/Line recognizes that organizations undertaking design have proprietary systems and
processes for managing design. The designer shall demonstrate to V/Line that it has the
systems and processes in place that meet the following minimum requirements:
 Compliance with ISO9001 Quality Management Systems requirements, including
but not limited to systems for:
o Managing and verifying competence of employees;
o Document control;
o Verification that designs comply with specifications; and
o Validation that the final product meets requirements.
 Has systems in place to record and manage review comments from both internal
and external parties.
 Manages and reports on
program and progress.
Figure 4 - Stage Design Process
 Documents, controls, and
manages noncompliance, exceptions and derogations to the project
specifications and requirements.
 Documents, controls and manages project issues and risks.
 Incorporates a Systems Engineering approach to design.
7.4.2 Design Registers

As part of the Designer’s stage design process, the Designer must maintain all design
and document control registers necessary to comply with ISO9001. The Designer shall
as part of its management system, maintain separate registers for:
 Design Issues
 Design Risks
 Design Review Comments
 Requests for derogations to specifications and project requirements.
These registers shall be provided to V/Line on request. Each register shall include the
relevant minimum information as shown in Table 2, and for each item maintain a status.
The status must clearly identify whether the item is “Open” or “Closed”, although it is not
necessary to use those specific terms. There must be no ambiguity to the status of an
item, which must be set out in the Designer’s management system. Where items are
“Closed”, they must clearly document the final agreed and approved outcome.
Note that design risk relates to specific uncertainty that can affect design outcomes and
the potential for designs to comply with the Project Requirements. It is not to be
confused with safety risk, which is managed in accordance with section 9 of this
procedure.
The management of risks and issues shall comply with the requirements of COPR-100
“Project Management Methodology”.
7.4.3 Variance to V/Line Standards and Procedure

Revision Number: 01
Design Management
Where within the Designer’s stage design management process, the Designer wishes to
incorporate a nonconformance to V/Line Standards or Procedures within the design, the
designer shall obtain authorization from V/Line in accordance with NIPR-2000 “Technical
Standards: Development, Change and Derogations”.
Non-conformances to V/Line Standards or Procedures must not be incorporated within
designs unless a Derogation is approved by V/Line in accordance with NIPR-2000.
Where approval is conditional, the design must incorporate those conditions.
7.4.4 Variance to the Project Requirements

Where a design is proposed to deviate from the project requirements, the Designer shall
seek approval from Project Manager for a variation to the project requirements in
accordance with the terms of the contract between the Designer and the Project Entity.
Where a project is delivered by V/Line, V/Line shall manage the variation request in
accordance with its Integrated Management System and COPR-100.
Where a project is delivered as a State Project and V/Line has a minor role, the Project
Manager shall assess if any decision to vary from the project requirements has the
potential to impact on V/Line operations, obligations, or any aspect of rail safety. Where
a decision impacts on V/Line, the Project Manager shall consult with V/Line. Where the
decision impacts on rail safety, the Project Manager shall ensure that all aspects of
Safety-in-Design are undertaken, the rail safety risk is reduced so far as is reasonably
practicable, and approval is obtained from V/Line.
The Designer must not incorporate any deviation to project requirements within a design
unless approval has been issued to the Designer by the Project Entity.
Table 2 - Mandatory Content for Specific Design Registers

Register Type Register Content
 A unique identifier for each issue
 Description of Issue
 Person who Raised the Issue
 Reference number of the issue report (if any)
Design Issue
 The Date the Issue was Raised
 The action proposed to resolve the issue (as amended from time to time)
 The impact rating of the issue, reflecting its importance and priority
 The issue status
 A unique identifier for each risk
 Description of the Risk
 Reference number of the risk report (if any)
 The Date the risk was identified
Design Risk
 The risk rating
 The treatment/controls determined to mitigate the risk
 The Risk treatment status
 The residual risk rating
Design Review  A unique Identifier for each comment
Comments  The name of the commentator

Revision Number: 01
Design Management
Register Type Register Content

 The Entity the commentator work within
 The detail of the comments
 Affirmation of whether the comments are considered within or outside of the
project requirements.
 The impact rating of the comment on the design outcome
 The proposed or final actions to resolve the comments
 The status of the comments
 Designer Unique Identifier for each request
 V/Line unique Identifier for each request, as advised by V/line
 Summary of the detail of the request
 The specific standard or project requirement against with the derogation is sought
Derogation
Requests  The paragraph number within the standard or project requirement against which
the derogation is being sought
 The status of the derogation request
 Summary of any conditions associated with the final status.
7.4.5 Systems Engineering Review

Where a Project is complex, involves the integration/harmonization of designs covering
multiple disciplines, or has a significant impact on existing systems (whether related to
products, services or the organisation generally), the project must engage a Systems
Engineering Manager to manage systems engineering reviews; and to coordinate and
integrate design packages and affected systems.
The systems engineering review shall follow the framework outlined in Table 3.
Table 3 - Systems Engineering Review Framework

Stage Systems Engineering Reviews
Concept  Mission Analysis
Design The review shall confirm the mission analysis and the appropriateness of the
concept design in the context of the design mission. It shall as a minimum consider:
o Does the concept design provide a solution that adequately covers the primary
purpose (mission) of the design activity?
o Has the design adequately considered the current state, and the impacts of the
design on the current state (change) or the current state on the design
(constraints)?
 Stakeholder Needs and Requirements Analysis
o Does the solution satisfy the needs and requirements of stakeholders?
 Functional Analysis
o Have all base functions been identified and allocated to a system design?
 Concept of Operations
o Is the concept of operations feasible and does it conform to the mission?
o Does the concept of operations cover all stakeholder operational interfaces?
 Capability Gap Analysis
The review of the capability gap analysis:
o Do all stakeholders have the capability of executing the design solution?
o What are the capability gaps? Should the design be amended to eliminate to

Revision Number: 01
Design Management
gaps or should capability be increased?

Preliminary  Preliminary Design Review
Design The Preliminary Design Review shall demonstrate that all project requirements have
been met by the preliminary design prior to progression to the final design stage. It
shall ensure that:
o All base functions been identified and allocated to a system design and been
resolved into design configuration items.
o The design meets the project objectives.
o The preliminary design is feasible to implement.
o The design can be accomplished within the approved project tolerances of time
and cost.
o Risks are managed within the acceptable limits
o All critical system issues are resolved.
Final  Critical Design Review
Design The Critical Design Review ascertains whether the project can proceed to execution
based on the outcomes of the final design. It shall ensure that:
o The final design meets project time, cost and performance requirements;
o The final design elements/packages are integration and compatible with related
design elements/packages.
o A final risk profile has been established and assessed, whereby rail safety risk
in reduced SFAIRP and all other risk is within acceptable constraints.
o The design is constructible.
o Design documentation is complete, unambiguous, and usable.
7.4.6 Independent Design Review

All designs at each stage must be subject to an independent design review. The
independent design review is a technical review to ensure that:
 The Design complies with all technical standards and requirements as set-out in
the project requirements document and the V/Line Safety Management System;
 The design complies with all legislative provisions;
 That design calculations and assessments are without error, and complete, and
are appropriate to the design element they have been applied;
 The technical drawings and documentation are complete, unambiguous and
without error.
The review of signaling designs shall also comply with NIST-012.1 “Standard for
Signaling Design and Documentation”.
7.4.6.1 Independence from Design

Persons performing the independent design review (the reviewer) must not have been
involved in the design development at any stage of the design process, other than as an
independent reviewer. The reviewer must not have:
 A conflict of interest which would bias the review outcomes; or
 Commercial or employment incentives, pressures or penalties related to the
design outcomes or greater project delivery.
Where a Reviewer works for an entity that has participated in developing a design or
otherwise is involved in the project, the Reviewer must work independently and must
have different line management from the design team, and where relevant, any team
involved in other activities within the project.

Revision Number: 01
Design Management
In respect of signaling design, the Reviewer is not independent if the Reviewer works for
an entity that has participated in developing a design or is otherwise involved in the
project. The Reviewer may be accepted subject to section 7.4.6.2.
7.4.6.2 Partial Independence from Design

Where a Signaling Reviewer Is employed by an entity who has other employees
engaged in the design or wider project, including where the entity is wholly responsible
for the design, the Reviewer is Partially Independent.
Where a Partially Independent Reviewer can demonstrate the degree of independence
as set out in section 7.4.6.1, the Reviewer may be accepted by V/Line. Acceptance is
subject to written approval by V/Line and V/Line may approve or reject a Reviewer at its
absolute discretion.
7.4.7 Safety in Design Workshops

Safety in Design workshops must be held on substantial completion of the design stage.
Refer to section 9 for further detail on conducting Safety in Design workshops.
7.4.8 Stakeholder Review

The stakeholder review is the critical final review in the stage design process. This is
where the stakeholder can validate the design against their specific requirements.
By this stage, the Design should have incorporated all the needs and requirements of
the stakeholders, which are naturally very specific to each stakeholder. As the design
may be large and complex, it is recommended that the designer conducts a design
walkthrough meeting with each stakeholder during the review period, specifically
pointing out how the design meets their needs; and why some elements which may
appear superfluous to the stakeholders needs, are critical to the needs and requirements
of other stakeholders.
This can reduce the number of comments received by clarifying and justifying the
design.
7.4.8.1 Time for Stakeholder Reviews

All Stakeholders shall have 15 business days from the receipt of any design
documentation for review. Failure of stakeholders to reply or make comments on design
documentation must not be assumed to be an endorsement or acceptance of the design
documentation, however, following the expiration of the stakeholder review period
above, the designer may progress the design (Subject to Signoff of the Engineering
Change Notice as set out in section 7.6).
7.4.9 Engineering Change Meeting and Review

Refer to section 7.6.
7.5 Reference Designs

Reference designs shall follow the design processes as set out in this document with the
following notable changes:
 The reference design stage shall be as per the preliminary design. The reference
design does not complete a final design;

Revision Number: 01
Design Management
 An intermediate approval process is completed following the reference design;

and
 The intermediate approval process does not include approval of drawings as
issues for construction.
The process comparison between the standard design process and a design process
that creates and utilises a reference design is shown in Figure 5.
Figure 5 - Reference Design Process
The Designer of a reference design may be different to the designer who produces the
final design. Irrespective of When progressing the reference design to a final design, the
Designer shall revisit the design through the preliminary design process, with a goal to:
 Improve meeting stakeholder needs and requirements;
 Provide additional value to stakeholders; and
 Improve project delivery in terms of time, cost or quality.
7.6 Engineering Change Management

Each stage of design shall be subject to Engineering Change Management as V/Line
assurance that design have been undertaken in accordance with this standard, and in
compliance with the V/Line SMS.
7.6.1 Engineering Change Notice

The Designer shall complete an Engineering Change Notice (Form NIST-2695.1) at
each stage of design. An Engineering Change Notice shall be provided for each Design
package (Refer to section 7.1.1). The Engineering Change Notice documents:
 Details of the Design Package and It’s scope of work.
 A summary of the key elements of the design.
 Evidence that consultation has been performed with relevant stakeholders.
 The status of all variations proposed to V/Line standards.
 The status of all deviations proposed to the project requirements.

Revision Number: 01
Design Management
 A summary of residual risks and the proposed treatments.

 Type approval status for all new equipment/systems introduced by the design.
 Design verification activities.
 All interfacing Design Packages and design activities outside of the Design
Package the subject of the Engineering Change Notice.
This Engineering Change Notice must be accompanied by all relevant design
documents, including but not limited to:
 A Design Report relevant to the applicable design stage.
 An Engineering Change Risk Report relevant to the applicable design stage.
 The Design Comments, Issues and Risks Register (As distinct from SiD risks).
 The Safety in Design Risk Register (Refer to NIPR-2695 “Design Management”
for detail of the required process).
 Independent review and/or proof engineering certificates.
 All applicable Design Documentation including but not limited to: Operational and
Functional descriptions; Drawings; Design Calculations.
The Engineering Change Notice must be endorsed by V/Line Network Engineering prior
to design progression to the next stage. The Designer’s quality assurance processes
shall include the Engineering Change Notice endorsement by Network Engineering as a
Hold Point in their quality assurance process/system for the design package.
Endorsement by Network Engineering of the proposed change shall not be deemed as
approval of the design, or as confirmation that the design meets the project or legislative
requirements. It remains the responsibility of the Designer and the Project to ensure that
the design meets stakeholder needs and requirements, and the project and legislative
requirements.
Endorsement by Network Engineering of the Engineering Change Notice means that
based on the evidence provided by the Designer, Network Engineering has formed a
view that the requirements of this standard and the V/Line IMS have been sufficiently
satisfied for the design to progress.
7.6.2 Engineering Change Meeting

Following submission of the Engineering Change Notice, the Project should facilitate a
meeting with the Designer and V/Line Network Engineering to discuss the stage design
status and to guide Network Engineering through the information contained within the
Engineering Change Notice. A walkthrough by the Designer of the processes and
outcomes of the design stage may assist in streamlining the Engineering Changer
Review.
7.6.3 Engineering Change Review

Network Engineering shall review the documentation set-out in section 7.6.1, and within
15 business days of receipt of the Engineering Change Notice shall either endorse, or
not endorse the change notice. Where a change notice is not endorsed, Network
Engineering will document the justification and work with the Project to remove the
constraints or non-conformances that have resulted in the Engineering Change Notice
not being endorsed.

Revision Number: 01
Design Management
The design may not progress to the next stage unless the Engineering Change Notice is
endorsed.
7.7 Proof Engineering

Where engineering significance warrants (Refer to section 6.5), Proof Engineering is a
mandatory activity and a pre-requisite for design approval. The process shall be
accomplished by an Independent entity and person(s) within that entity who have not
previously been involved in the project for any purpose other than proof engineering.
Where Proof Engineering is not required, the design Verification and Validation process
is sufficient.
Proof Engineering shall include a full and independent assessment of all factors
influencing the final integrity of the specified components of the works.
Proof Engineering shall be based on the designer’s final drawings and specifications and
without reference to the designer’s computations. The proof engineer shall be
independent of any other commitment or obligation to the person or entity carrying out
the design.
The Proof Engineer shall stamp and sign all relevant drawing(s) and documents and
provide a Certificate of Compliance as evidence of the Proof Engineer’s detailed check
and acceptance prior to their issue for construction. Any amendment to the design after
the issue of the Proof Engineering Certificate of Compliance shall be referred to the
proof engineer for review and written confirmation that the certificate remains valid.
7.8 Use of Designs

All designs must be marked as being “Issued for Construction” prior to any construction
proceeding.
8 THIRD PARTY DESIGNS

In respect of 3rd party project works designs by third parties shall comply with this
standard where they:
 Alter or replace existing assets within the Regional Infrastructure Lease (RIL);
 Create an additional asset on, over or under the land subject to the RIL,
notwithstanding what entity owns or manages the asset;
 Physically or operationally interfaces with the assets on the RIL.
The 3 party may separate out that section of the overall 3rd party designs that meet the
rd
above criteria as a separate work and Design Package/s. Only those Design Packages
within the overall design that meet the above criteria are required to comply with this
standard.
8.1 Responsibilities within V/Line

All third-party access for works are monitored and managed by Access Engineer’s. The
Access Engineer’s shall ensure that all designs in respect of third party works are
managed in accordance with this standard, including that all relevant stakeholder
reviews are performed within V/Line, and review comments are closed.
The Access Engineer shall ensure that adequate wavers and protections are in place
against liability of V/Line for the 3rd party design outcome so far as permitted by law.

Revision Number: 01
Design Management
The GM Network Engineering shall assign a reviewing engineer for each 3rd party design
by use of the outlook task management system. The reviewing engineer shall undertake
an additional detailed review as part of the stakeholder review process, focusing on
technical and asset management contexts. A copy of the technical and asset
management review, which shall nominally be in the form of a written report or as
marked-up design drawings, along with any additional review documentation shall be
provided to the Access Engineer, who shall ensure that the findings and requirements of
the design review are incorporated into the works.
The review of 3rd Party design by the Network Engineering area is not design advice to
the third party other than to the extent that it documents non-conformances with the
V/Line Integrated Management System, unacceptable safety hazards, or operational
impacts. The reviewing engineer shall not offer advice as to solutions or design
methods other than to refer the third party to the issue/objection and/or the required
standards.
Where, subject to assessment as set out in Section 6.5, the reviewing engineer
assesses that the 3rd party design should be proof engineered; the Engineer Access
shall require the third party to undertake proof engineering in accordance with Section
7.7.
The Access Engineer shall ensure that the findings and comments of the V/Line
Stakeholder and Technical reviews are implemented or (by agreement with V/Line)
waived by the third party prior to approval and final IFC.
9 SAFETY IN DESIGN
9.1 General
Designing for safety requires identifying hazards and risks and eliminating or minimising
risks to SFAIRP through design.
For large and geographically disperse projects, design for the project is managed by
dividing it into a Work Break-down Schedule (WBS) by location (regions and sections),
and design elements or blocks (disciplines) (See section 7.1). The WBS is then
structured into specific or bundled Design Packages and described in a Schedule of
Design Deliverables. Design development will be 4 stages in accordance with Section
7.2. Small projects may have a single Design Package.
The SiD process shall be applied iteratively across all Design Packages and stages of
design development - and activities will ensure hazards and risks are reduced SFAIRP
and that the system and construction is designed to be safe and without risks to health if
it is used for the purpose for which it was designed.
To satisfy the requirements of the Rail Safety Act, stakeholders will exercise robust
hazard identification, risk assessment and appropriate analysis and design risk controls
for all phases of a project from concept to testing, commissioning, handover and over
the life of the Operations. SiD activity output will also demonstrate to V/Line’s
satisfaction that design hazards and risks have been comprehensively identified and
ameliorated SFAIRP and that design risks are either closed out SFAIRP or being
managed before project procurement and construction commences.
The applied SiD risk assessment process will meet the requirements of V/Line’s
Enterprise Wide Risk Management framework and related supporting standards –
AS4292 Rail Safety Management - Parts 1 through 5, ISO 31000: 2009 Risk
Management - Principles and Guidelines ISO 31010: 2009 Risk Management - Risk

Revision Number: 01
Design Management
Assessment Techniques; AS/NZS 4801-2001, Occupational Health and Safety

Management Systems; WorkSafe Designing Safer Buildings and Structures December
2005 (within Victoria); WorCover Safe design of structures code of practice July 2014
(within NSW); and were relevant with the The International Tunnelling Insurance Group’s
A Code of Practice for Risk Management of Tunnel Works.
V/line’s Enterprise Wide Risk Management framework and processes are documented
within:
 LEST-3 V/Line EWRM Risk Assessment Standard Ratings Criteria
 LEST-2 Enterprise-Wide Risk Management Framework
 SAPO-7 Enterprise Wide Risk Management
 SAPR-9 Enterprise Wide Risk Management (EWRM) Process
 SAPR-9 Health Safety & Environment Risk Assessment Procedure
9.2 SiD Planning

The Design Management Plan (DMP) developed for each WP (see section 7.1), must
incorporate a section for the Risk Management Plan (RMP). The RMP section will
incorporate the approach to managing SiD which shall comply with this procedure.
9.3 SiD Stages

The SiD process and workshop format must follow the CHAIR process described within
the WorkCover NSW Safety in Design Tool 2001.
The SiD process shall incorporate input from all relevant stakeholders, including but not
limited to: Designers, Constructors, Maintainers, Safety Representatives, Operators; and
affected V/Line divisions (principally the Asset Management, Service Delivery and
Customer; but also, where relevant, V/Line support areas such as safety and information
technology), and 2nd and 3rd parties.
For each of the four main stages in the design development process, the SiD review
shall be as set out in Table 4.
Table 4 - SiD Reviews Throughout the Design Stages
Design
Review Status Gates Comment
Stage
 Performed at Concept design stage
 The Designer, or a third party, in isolation should not perform a
CHAIR-1 study.
Concept
Design CHAIR 1  A systematic and formalised “brainstorming” workshop is required,
Design
which involves the appropriate stakeholders (designers,
construction, maintenance, safety representatives, etc.), and is led
by a facilitator who is independent of the design (but could belong
to one of the stakeholder organisations).
 Performed at Preliminary/Reference design stage (dependant on

the design strategy).
Preliminary
Design CHAIR 2  Manages constructability review and closure of residual risks.
Design
 The step focuses on ways in which a design can be modified to
eliminate or reduce construction and/or demolition hazards.

Revision Number: 01
Design Management
 It does not replace Job Safety Analysis or Safe-work Method

Statements which are performed by the construction organisation
and outline all the safety controls to be employed to control the
risk.
 Conducted as the design draws closer to completion of documents

and demonstrates the appropriateness of operational systems,
construction OH&S risk management and the safe maintainability
of the holistic system.
Final Design Design CHAIR 3
 Chair 3 must be demonstrated before JSAs and SWMs are
rd
submitted for construction rail access permits (for 3 Parties), or
nd
access to site is granted for construction activities by 2 parties
under contract to V/Line.
Issue for
 ARTO approval and transfer of residual risks
Construction
All stages of SiD are to be processed in the project document management system and
where hazards and risks have a rail safety context they must be administered, and risk
assessed and analysed in accordance with V/Line’s SMS EWRM.
Following development of each agreed design phase, but prior to issuing the Design
Pack for V/Line formal review, the Design Package Manager will co-ordinate and
facilitate a SiD workshop. ALL relevant stakeholders including rail safety, designers,
constructors, operators, and maintainers participate in the workshop. The workshop will
utilise the following steps;
i. Present the design package(s) (risk context, design documentation, objectives,
assumptions and interfaces)
ii. Identify hazards and risks using:
a. Preliminary Hazard Assessment with aid of guidewords.
b. HAZID, HAZOP and CHAIR2 techniques and other techniques, as
required.
c. Human factor considerations.
d. WP interfaces.
e. RAMS requirements (ease of maintenance and low maintenance systems
will maximise operational availability by reducing recovery times after
failure, minimise the lifecycle cost of the system, and reduce the time that
employees are exposed to operational risk).
f. Tender Risk and SiD Registers prepared by stakeholders and ARTOs.
iii. Prepare, identify and record and evaluate and analyse risks using risk register
(refer: Risk Register Template SAFO-81, LEST-3 V/Line EWRM Risk
Assessment Standard Ratings Criteria) identifying risk location, source, event,
and impact etc.
iv. Develop mitigation measures based on hierarchy of controls (refer SAPR-9) and
record in risk registers and/or risk reports the controls that either eliminates or
reduces the risk to an acceptable level for operator and maintainer risks or
SFAIRP for health and safety risks. This may require qualitative and/or
quantitative assessments, cost benefit analysis of the options etc. (refer to
V/Line’s requirements). Record the decision-making process, justification of

Revision Number: 01
Design Management
accepting or rejecting risk control measures, impact on stakeholders (if any) and
outcomes.
v. Identify ownership of risks and individual treatments and responsibility for
implementing risk mitigation measures along with action completion dates that
align to project milestones/deliverables.
vi. Record SiD outputs in the form of Risk Registers (SAFO-81), Risk Report and
supporting reports, as required.
vii. On completion of the SiD process (following Design approval and IFC), designers
are then to transfer agreed residual risks and controls to the relevant risk and
control owners, with rail safety, operator and maintainer contexts to transferred to
V/Line and other relevant ARTO’s.
On completion of the SiD process (CHAIR 3) and prior to issue of the final design for
review, the Design Package Manager must prepare a Summary Risk Report in
accordance with NIPR-2695.2 and the record keeping requirements of V/Line’s EWRM
Risk Management Framework (LEST-2). The aim of these activities is to highlight to
V/Line residual risk items and agreed controls that will be transferred to V/Line.
9.4 All Stages

To meet the Project Design and Construction Program and timing, it is essential the
Design Package Manager in consultation with the Designer plans the SiD workshops as
an integral part of design development. The workshops must occur and outputs
incorporated into designs before each DP(s) is issued for stakeholder review at each
phase of design development.
Any comments to be added during a review must be entered in the cumulative
comments sheet which is to be collated and maintained by the Design Package
Manager. The cumulative comments sheet remains with the Design Package in
perpetuity, even as part of as-built documentation. This is necessary so that reasons for
design decisions can be traced as part of the ARTO Safety Management System (SMS)
of which the MoC process forms a part.
All aspects of the SiD process must be fully documented and will be audited by the
ARTO, as required.
9.5 Registers and Reports

Risk Registers and Reports, in accordance with SAFO-81 and NIFO-2695.2, shall be
produced as outputs of the SiD process. The registers and reports shall be updated at
each subsequent design development stage to record the development and
implementation of mitigation measures.
Technical reports, including quantitative analysis (e.g. Cost Benefit Analysis), as
required, may be necessary to assess risk mitigation measures against SRAIRP
requirements in support of Risk Registers and Reports.
The documents described above will form part of DP’s submissions for review.
9.6 SiD Communications

Designers will regularly (at agreed intervals) supply adequate information to V/Line
concerning the purpose or purposes for which the system was designed; the results of

Revision Number: 01
Design Management
any testing or examination; and any conditions necessary to ensure that the system is
safe and without risks to health if it is used for the purpose for which it was designed.
At least monthly, Work Pack SiD Managers will review with V/Line, the SiD Program and
relevant risk registers.
The Project will ensure continual communications and highly visible, comprehensive and
frequent reporting of risk management performance to all relevant stakeholders as part
of their accepted governance processes (Refer to COPR-100).
10 SMS REQUIREMENTS
All designs shall comply with standards and requirements set-out in V/Line’s Safety
Management System. The following standards and guidelines refer to those elements of
the V/Line SMS that have higher precedence to the performance of design:
NIST-012.0 VRIOGS 012.0 Victorian Signalling Principles
NIST-012.1 VRIOGS 012.1 Standard for Signalling Design and Documentation
OPMG-18 Station Design Principles
NIST-2616 Railway Structures Design Requirements
NIST-2618 Track Design
11 REFERENCES
LEST-3 V/Line EWRM Risk Assessment Standard Ratings Criteria
LEST-2 Enterprise-Wide Risk Management Framework
NIFO-2695.1 Engineering Change Notice
NIFO-2695.2 Summary Risk Report
NIST-012.0 VRIOGS 012.0 Victorian Signalling Principles
NIST-012.1 VRIOGS 012.1 Standard for Signalling Design and Documentation
NIST-2616 Railway Structures Design Requirements
NIST-2618 Track Design
OPMG-18 Station Design Principles
SAPO-7 Enterprise Wide Risk Management
SAPR-9 Health Safety & Environment Risk Assessment Procedure
SAFO-81 V/Line HSE Risk Assessment Tool
ISO 31000:2009 Risk management - Principles and Guidelines
ISO 31010:2009 Risk Management - Risk Assessment Techniques
HB 467 Risk Management Guidelines
AS 4292.1-2006. Railway safety management - General requirements
AS 4292.2-2006. Railway safety management - Track, civil and electrical
infrastructure
AS 4292.3-2006. Railway safety management - Rolling stock

Revision Number: 01
Design Management
AS 4292.4-2006. Railway safety management - Signalling and telecommunications

systems and equipment
AS 4292.5-2006. Railway safety management - Operational systems
AS/NZS 4801-2001 Occupational Health and Safety Management Systems
WorkSafe Designing Safer Buildings and Structures December 2005
WorkCover Safe design of structures code of practice July 2014
WorkCover NSW Safety in Design Tool 2001
The International Tunnelling Insurance Group’s A Code of Practice for Risk Management
of Tunnel Works.

Revision Number: 01
Design Management
ATTACHMENT 1 - OVERVIEW OF DESIGN MANAGEMENT PROCESS
Concept Design Preliminary Design Final Design Approval
COPR-100 Stage Project COPR-100 Stage Project Stakeholder Project

Update Design
Project Feasibility Requirements Planning & Development Requirements Consultation Requirements
for Final
V/Line Comments
V/Line V/Line
Consultation
Consultation
Stakeholder
Stakeholder
Concept Standards Preliminary Standards Standards
Consultation
Stakeholder
Design Design Final Design
Development Development No Comments
Development
Process Not Approved Process Not Approved Process Not Approved Register Closed
Not
Not Approved Not Approved Approved Yes
V/Line V/Line V/Line Drawings IFC
Variance to Variance to Procedure Variance to
Yes Procedure Yes Yes Procedure
Standards? Standards? NIPR-2000 Standards?
NIPR-2000 NIPR-2000
Approved Approved Approved Design Variation
Variance to V/Line Variance to V/Line Variance to V/Line
COPR-100 Stage
Project Yes Procedure Project Yes Procedure Project Yes Procedure
Changes Execution
Requirements? COPR-100 Changes Requirements? COPR-100 Requirements? COPR-100
Accepted Changes Accepted Design Variation During

Accepted Execution
Design Design Design
Documentation Documentation Documentation No COPR-100 Project
Change Approval
Systems Systems Systems

Engineering Review Engineering Review Engineering Review Project Design
Where a Reference Variation
Design has been Approved?
Independent Design Independent Design
provided, the Concept
Review Review
Design process is not Yes
required Amend Design per
Sid Workshop Sid Workshop Sid Workshop
(CHAIR 1) Final Design
(CHAIR 2) (CHAIR 3) Process
Engineering Change Engineering Change Engineering Change Approval

Notice NIFO-2695.1 Notice NIFO-2695.1 Notice NIFO-2695.1 Process
Engineering Change Stakeholder Review Engineering Change Stakeholder Review Engineering Change Stakeholder Review As-Built
Meeting Meeting/s Meeting Meeting/s Meeting Meeting/s
COPR-100 Stage
V/Line Engineering V/Line Engineering V/Line Engineering
Stakeholder Review Stakeholder Review Stakeholder Review Closure
Change Review Change Review Change Review
No COPR-100 Update
No No
Update Review As-in-Service
Update Review Update Review
Comments Register Documentation
Comments Register Comments Register
NIST-007.2 –
Certify and
Change STAGE Change STAGE Change STAGE Register Drawings
Endorsed? Yes GATE 1 Endorsed? Yes GATE 2 Endorsed? Yes GATE 3 in DMS
Revision Number: 01
Design Management
This Page is Intentionally Blank

NIPR-2695 Design Management Rev 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NIPR-2695 Design Management Rev 1

Uploaded by

Copyright:

Available Formats

Network infrastructure

7.3.2.2 Functional and Capability Analysis ................................................................ 22

Revision Date Description of Change

Approved By: EGM Asset Management | Printed copies are uncontrolled

Approved By: EGM Asset Management | Printed copies are uncontrolled

ONRSR Office of the National Rail Safety Regulator.

Approved By: EGM Asset Management | Printed copies are uncontrolled

6.1 Introduction to Design Process

 Choose the Best Solution Do the Additional

 Produce the Design

Approved By: EGM Asset Management | Printed copies are uncontrolled

 Preliminary Design; and Figure 1 - Broad Design Process

6.1.1 Reference Designs

6.2 Safety in Design

Approved By: EGM Asset Management | Printed copies are uncontrolled

6.3 Design Verification and Validation

6.4 Drawing Format and Standards

Approved By: EGM Asset Management | Printed copies are uncontrolled

6.4.1 As-built Drawings

6.5 Engineering Significance and Proof Engineering

6.6 Type Approval

6.7 Compliance to V/Line Standards and Procedures

6.8 Pre-existing Conditions

Approved By: EGM Asset Management | Printed copies are uncontrolled

6.8.1 Correlation of Pre-Existing Design Documentation

6.9 Systems Engineering Approach

6.9.1 Consideration of Future States

Approved By: EGM Asset Management | Printed copies are uncontrolled

7.1 General Requirements

7.1.1 Design Breakdown

Approved By: EGM Asset Management | Printed copies are uncontrolled

7.1.2 Design Planning

7.1.2.1 Reporting Progress Against the Schedule of Design Deliverables

Approved By: EGM Asset Management | Printed copies are uncontrolled

7.1.3 Design Reviews

Approved By: EGM Asset Management | Printed copies are uncontrolled

Designer Scope and Technical Check X

7.1.4 Reports and Specifications

7.1.4.1 As Design Inputs

7.1.4.2 As Part of Design

7.2 Design Stage Gates

Approved By: EGM Asset Management | Printed copies are uncontrolled

7.2.1 Concept Design Stage

7.2.2 Preliminary Design Stage

7.2.3 Final Design Stage

7.2.4 Approval and IFC Stage

Approved By: EGM Asset Management | Printed copies are uncontrolled

7.3 Systems Engineering by Stages

7.3.1 Concept Design

7.3.1.1 Mission Analysis

o Review and understand the mission and

Approved By: EGM Asset Management | Printed copies are uncontrolled

possible operating states and, approaches and modes of usage.

Figure 2 - V/Line Broad Value Chain

7.3.1.2 Stakeholder Needs and Requirements Analysis

Approved By: EGM Asset Management | Printed copies are uncontrolled

7.3.1.3 Functional Analysis

Approved By: EGM Asset Management | Printed copies are uncontrolled

7.3.1.4 Concept of Operations

Approved By: EGM Asset Management | Printed copies are uncontrolled

7.3.1.5 Capability (Gap) Analysis

maintain and decommission the

operate, maintain or decommission Analysis and End

7.3.1.6 Options Analysis and Assessment