Upload
phamdan
View
230
Download
0
Embed Size (px)
Citation preview
PRASA In-Cab Signalling
PICS Request For Proposal 1/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
PRASA In Cab Signalling
Project, Planning and
Activities Requirements
Specification
Document Management
This document has been approved for issue. The version history and approval cycle are available in the version stored in the QMS of the PICS project within Transurb-Focus consortium.
PRASA In-Cab Signalling
PICS Request For Proposal 2/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
Table of Contents
1. Introduction ................................................................................................................................................................ 4
1.1. Purpose of this document ........................................................................................................................... 4
1.2. Application domain ........................................................................................................................................ 4
1.3. Definitions, symbols and abbreviations ................................................................................................ 4
1.4. Reference documents .................................................................................................................................... 5
1.5. Appendices ........................................................................................................................................................ 5
2. Program and projects ............................................................................................................................................. 6
3. Typical Development subProject ....................................................................................................................... 8
3.1. Scope .................................................................................................................................................................... 8
3.2. Life Cycle ............................................................................................................................................................ 8
3.3. Deliverables ................................................................................................................................................... 11
4. The Pilot Line subProjects ................................................................................................................................. 13
4.1. Scope ................................................................................................................................................................. 13
4.1.1. Pilot Line 1 in Gauteng: GAU-01-PLP ......................................................................................... 14
4.1.2. Pilot Line in Kwa-Zulu Natal: PLP-KZN-01 .............................................................................. 14
4.1.3. Pilot Line in Western Cape: PLP-WC-01 ................................................................................... 15
4.2. Life Cycle and planning ............................................................................................................................. 15
4.3. Schedule ........................................................................................................................................................... 18
4.4. Deliverables ................................................................................................................................................... 18
5. The Roll-Out subProjects ................................................................................................................................... 21
5.1. Scope ................................................................................................................................................................. 21
5.2. Life Cycle ......................................................................................................................................................... 22
5.3. Schedule ........................................................................................................................................................... 22
5.4. Deliverables ................................................................................................................................................... 23
6. Dependencies between projects ..................................................................................................................... 23
7. Planning Procedure and tools .......................................................................................................................... 26
7.1. Reporting......................................................................................................................................................... 27
7.2. Revision ........................................................................................................................................................... 28
8. Requirements for the Tenderer ....................................................................................................................... 29
8.1. Time Schedule ............................................................................................................................................... 29
8.2. Work Breakdown Structure .................................................................................................................... 30
8.3. Workload management ............................................................................................................................. 31
PRASA In-Cab Signalling
PICS Request For Proposal 3/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
8.4. Project Deliverables .................................................................................................................................... 32
9. Requirements List ................................................................................................................................................. 33
10. Appendix 3: The planned development of the PRASA network .................................................... 35
10.1. From mechanical and relay signalling to electronic interlocking (2011- 2017)… ...... 35
10.2. Optical fiber network (2012-2014) ................................................................................................. 35
10.3. Radio digital signalling network (2012 – 2017) ........................................................................ 35
10.4. Asset protection program (today – 2014) .................................................................................... 35
10.5. New PRASA Rolling stock (2016 – 2027)...................................................................................... 36
10.6. PRASA In-Cab Signalling ...................................................................................................................... 36
PRASA In-Cab Signalling
PICS Request For Proposal 4/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
1. Introduction
1.1. Purpose of this document
This document defines the different projects inside the PRASA In-Cab Signalling program and
their interactions. It also defines the scope, the life cycle, the schedule and the deliverables of
each project. It yields the requirements to be answered by the Tenderer in this topic.
This document does not define the way the management will be carried out for these program
and projects. This is demonstrated by another document [REF.4], which is complementary to
this one.
1.2. Application domain
This document is part of the PICS Technical Request For Proposal and is applicable for the
Tendering Process. It shall be used as basis for the execution phase.
1.3. Definitions, symbols and abbreviations
For main definition, symbols and abbreviations see also [REF.1].
FTE Full Time Equivalent
FRS Functional Requirements Specification
GASC Generic Application Safety Case
GR Gate Review
IL Interlocking
PICS PRASA In-Cab Signalling Programme
PLC Project Life Cycle
PLP Pilot Line subProjects
PMBoK Project Management Body of Knowledge®
PMI Project Management Institute®
PMP Project Management Plan
RACI Responsible, Accountable, Consulted, Informed
ROP Roll-Out subProjects
SASC Specific Application Safety Case
SAT Site Acceptance Tests
SRS System Requirement Specification
SyAD System Architecture Description
TDP Typical Development subProject
V&V Verification and Validation
WBS Work Breakdown Structure
Note that the wording “Typical” is used in South Africa and can be understood as “Generic” in the
sense of the CENELEC norms. However, the Typical Development subProject is a larger than that,
as it includes also the activities to start the contract (setup of collaborative environment, etc.).
The PICS is seen as a program according to the definition in the PMI PMBoK and ISO21500:2012:
“a group of related projects managed in a coordinated way to obtain benefits and control not
PRASA In-Cab Signalling
PICS Request For Proposal 5/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
available from managing them individually”. However, in the frame of this contract, the PRASA
In-Cab Signalling contract is called a project and the projects will be called subprojects.
It must be noted, especially for this document, that the vocabulary used is the one coming from
the international standard ISO21500:2012 – guidance on “Project Management”.
1.4. Reference documents
References hereafter are always meant to be the last available version of the document, as
recorded in the Quality Management System.
Reference Name Title [REF.1] PICS_R_30006_RFP Glossary General Glossary of the RFP [REF.2] PICS_R_30072_Technical_RS Technical Requirements Specification [REF.3] PICS_R_30056_RAM_RS RAM Requirements Specification [REF.4] PICS_R_30055_PM_RS Project Management Requirements
Specification [REF.5] PICS_R_30053_Tech RFP PICS Technical RFP Master Document [REF.6] PICS_R_30098_Quality_RS Quality Requirements Specification [REF.7] PICS_R_30072_Technical_RS Technical Requirements Main Document [REF.8] PICS_R_30061_ETCS_RS ETCS Requirements Specification [REF.9] PICS_R_30077_Safety_RS Safety Requirements Specification [REF.10] PICS_R_30063_ProdEngineering_RS Production Engineering Requirements
Specification [REF.11] PICS_R_30071_TestAcc_RS Testing and Acceptance Requirements
Specification [REF.12] PICS_R_30062_Products_RS Products Requirements Specification [REF.13] PICS_R_30086_Installation_RS Installation Requirements Specification [REF.14] PICS_R_30097_Maintenance_RS Maintenance Requirements Specification [REF.15] PICS_R_30085_Training_RS Training Requirements Specification
1.5. Appendices
Appendices hereafter are always meant to be the last available version of the document, as
recorded in the Quality Management System.
Reference Name Title [APP.1] PICS_R_30021_Projects_RS_APP01_GeogScope Geographical Scope [APP.2] PICS_R_30021_Projects_RS_APP02_WBS WBS Template [APP.3] See section 10, p. 35 The planned development of the
PRASA network
PRASA In-Cab Signalling
PICS Request For Proposal 6/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
2. Program and projects
R0021_01. [CT] The Contractor shall carry out the PICS contract with strict observance of the
information (about organization, schedule, life cycle, etc.) given in this section 2 and
in the section 6.
The PICS is one part of the renewing programme of PRASA’s network. The context of the PICS
project (interaction with other projects by PRASA, goals of the renewing programme, etc.) can be
found in [APP.3].
R0021_02. [CT] The Contractor shall organize the PICS contract into 19 subprojects:
1. The Typical Development subProject (TDP);
2. The 3 Pilot Line subProjects (PLP) for the three regions: Gauteng (GAU-01-PLP),
Kwa-Zulu Natal (KZN-01-PLP) and Western Cape (WC-01-PLP);
3. The 15 Roll-Out subProjects (ROP) which are distributed amongst the regions as
followed:
a. 7 projects in Gauteng; (GAU-XX-ROP with XX from 02 to 08)
b. 3 projects in Kwa-Zulu Natal (KZN-YY-ROP with YY from 02 to 04);
c. 5 projects in Western Cape (WC-ZZ-ROP with ZZ from 02 to 06).
If the contract is awarded to multiple suppliers, the number of subprojects will be 21, as there
will be three different Typical Development Projects (one for each region). Except if stated
otherwise, all the requirements in the PICS Technical RFP are applicable in both cases (single or
multiple suppliers).
During the contract execution, any suggestion to adapt the project decomposition as proposed in
R0021_02 can be considered, as far as contractual agreement is reached between PRASA and the
Contractor.
R0021_03. [CT] The Contractor shall execute the PICS contract according to the following high
level time schedule (also illustrated in the Figure 11):
The Roll-Out subProjects (ROP) shall all be commissioned within 53 months
after contract award;
The Pilot Line subProjects (PLP) shall not take more than 20 months to be put
into service;
The Typical Development subProject (TDP) – without Updates & Upgrades
phase – shall not take more than 27 months.
1 The Figure 1 does not show the RAM monitoring periods nor the maintenance periods, nor the performance period as defined in the Volume 2 of the PICS RFP.
PRASA In-Cab Signalling
PICS Request For Proposal 7/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
Figure 1 : High-level time schedule of the programme
As seen in the high-level time schedule above, these subprojects are strongly related and some of
them are overlapping. The dependencies between them are defined and explained in section 6.
PRASA In-Cab Signalling
PICS Request For Proposal 8/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
3. Typical Development subProject
R0021_04. [CT] The Contractor shall carry out the PICS Typical Development subProject with
strict observance of the information (about organization, schedule, life cycle, etc.)
given in this section 3.
3.1. Scope
The scope of the Typical Development subProject (TDP) covers all the activities and supply
needed to:
define the conceptual design for the implementation of ETCS level 2 customized for the
PRASA network and get a generic application for PRASA;
get adapted products (RBC,…) to fit the PRASA needs and the necessary design and
testing environment (ETCS automated data preparation tool, laboratory testing
environment,…) to start the rollout;
start up the PICS project by setting up the needed tools (collaborative environment, fine-
tuning the planning and the processes, etc.).
The main high-level outputs of this project are:
A full conceptual design (architecture, functions, engineering and programming rules for
the rollout …), including the feedback coming from the pilot lines, for the implementation
of the ETCS level 2 trackside sub-system to be overlaid on IL subsystems in the different
PRASA regions;
A certified Generic Application Safety Case (GASC) for the ETCS level 2 conceptual
design;
ETCS products (RBC, anti-theft balise system,..) adapted to fit the PRASA needs and the
South-African context;
A development environment fully customized (automated ETCS data preparation tool,
processes,…) to be used for the production engineering for the PICS rollout projects;
Testing and validation principles and tools to be applied and used for the PICS rollout
projects;
A laboratory test environment in PRASA premises of each PRASA region.
This list is not exhaustive. The detailed technical scope of the TDP is mainly described in [REF.8].
3.2. Life Cycle
The TDP begins with the contract award and ends after the commissioning of the last Pilot Line
subProject. However, the Updates and Upgrades phase goes on until the end of the last Roll-Out
Project. The phases of the TDP are presented on Figure 2.
R0021_05. The Contractor shall organize the TDP kick-off meeting within two weeks after the
Contract Award.
R0021_06. The SW development and HW development phases are not bound to specific
milestones. The Contractor will plan these phases as it wishes in order not to
jeopardize the planning of the other phases. No payment shall be bounded to these
phases. Those SW development and HW development phases correspond with the
PRASA In-Cab Signalling
PICS Request For Proposal 9/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
customization of the ETCS products (i.e.: adaptation of the RBC to implement the
South African signalling principles and the standard Ixl-RBC protocol, the anti-theft
system for the balises, etc…), the development environment and the test
environment.
PRASA In-Cab Signalling
PICS Request For Proposal 10/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
Figure 2: Typical Development Project Life Cycle
PRASA In-Cab Signalling
PICS Request For Proposal 11/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
3.3. Deliverables
The Contractor shall deliver specific documents to the PRASA at each defined milestone. The
Table 1 defines which deliverables must be delivered for which milestone of TDP.
To successfully reach the milestone, each deliverable must be approved by PRASA. This approval
means a “notice to proceed further” and does not transfer any responsibility from the Contractor
to PRASA. The Contractor remains fully responsible as defined in section 4.2.
The list in Table 1 is an overview of the deliverables and conditions for the Typical Development
subProject. This list is not exhaustive and gives only an indication of the content expected at
each milestone; for example, it does not necessary include all the conditions and deliverables
expected from a professional way of working or from a classical development according to the
normative reference. However, each deliverable already identified is mandatory. This list must
be completed and agreed at the latest at the Preliminary Gate Review of the Typical
Development Project.
Milestones Deliverables Required in Preliminary GR Project Management:
Details of the Collaborative Environment finalized Program Management Plan Project Management Plan Project Management Plan template Exhaustive List of Deliverables (ELOD) – based on
this list Definition of parameters for the Earned Value
Management (EVM) Scope Baseline Schedule Baseline Documents Management Plan Requirements Management Plan Configuration Management Plan Risk Management Plan and Risk Register Stakeholder Management Plan Final form of the reporting
[REF.4]
RAM: Generic RAM PLAN
[REF.3]
Quality: Quality Plan Definitive List of equipment for review and
inspection Evidence of qualified and trained staff
[REF.6]
Technical: Development / Engineering Plan
[REF.7]
Safety: Generic Safety Plan HAZOP
[REF.9]
ETCS: Driving ergonomics proposal
[REF.8]
Testing & Acceptancy: Assessment and Certification Plan
[REF.11]
PRASA In-Cab Signalling
PICS Request For Proposal 12/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
Milestones Deliverables Required in Products: Environmental Plan and test evidences of product
compliance by independent laboratory EMC Plan Earthing Concept (can be included in EMC Plan) Procedure for KMAC keys approved
[REF.12]
Programme and planning Detailed Contract Programme
See section 7
Installation: Theft and Vandalism document Balise Theft-Test Campaign
[REF.13]
Generic Subsystem Design GR
Management: Tested and fully working Collaborative
Environment (must have been available 2 months after the Preliminary GR)
[REF.4]
Quality: Pre-manufacturing Review done Skills training plan Production planning and reporting in place
[REF.6]
ETCS design: Generic Application FRS (Functional Requirement
Specification) System Architecture Description Implementation of the Stop if in SR function by
GSM-R (first step)
[REF.8]
Engineering: Gradient Modelling Process Measurement Strategy, processes and tools
[REF.10]
Training: Training Plan
[REF.15]
Data Engineering Design GR
ETCS design: Generic Programming Rules
[REF.8]
Safety: All safety analyses and safety studies Generic Hazard Log Report with measures
implemented
[REF.9]
Testing Principles GR
Testing & Acceptancy: Overall Test Plan Migration Strategy Document Laboratory Test Environment Description
[REF.11]
Generic Case Validation GR
Safety: Generic Application Safety Case Generic Product Safety Cases + their certificate
[REF.9]
Testing & Acceptancy: Principles Validation Report ETCS simulator user’s manual and other
equipment user’s manual All assessment reports Intermediate Statement of Conformity ISA Discrepancies Register (draft version) NoBo Discrepancies Register (draft version)
[REF.11]
PRASA In-Cab Signalling
PICS Request For Proposal 13/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
Milestones Deliverables Required in Safety: Generic Hazard Log Report (records « closed »)
[REF.9]
All above mentioned documents updated to take into account the necessary adaptations (feedback from the pilot lines)
The all set of documents will define the first baseline for the Generic case ; therefore, all the needed documents to issue a Generic Case are mandatory at this gate review.
Generic Application Updates GR
All above mentioned documents updated to take into account the necessary adaptations (feedback and lessons learned from the subprojects) and produce a new generic baseline whenever needed
Recurrent Deliverables
Management: Adequate reporting and communication Risk Register (update if any) Planning and programme
[REF.4]
RAM: Annual Performance Monitoring Report (in
December) [REF.3]
Safety: Hazard Log
[REF.9]
Updates & Upgrades phase
Inclusion of all feedbacks and lessons learned from the subprojects
All above mentioned documents updated to take into account the necessary adaptations (feedback and lessons learned from the subprojects) and produce a new generic baseline whenever needed
Lessons Learned documents
Table 1 : Milestones and deliverables for TDP
The payment for the Typical Development Project shall be made at successfully reached
milestones as defined in the (non-technical) RFP.
4. The Pilot Line subProjects
R0021_07. [CT] The Contractor shall carry out the PICS Pilot Lines Projects with strict
observance of the information (about scope, organization, schedule, life cycle, etc.)
given in this section 4.
4.1. Scope
The scope of the Pilot Line subProjects (PLP) covers all the activities and supply needed to get a
commissioned and certified ETCS trackside subsystem on the identified pilot lines. Beside the
commissioning of the lines, the goal of the Pilot Lines is also to help validating the generic
principles and building a better generic design (in the Typical Development subProject) and, as a
consequence, to allow a faster and more reliable deployment of the PICS system on the PRASA
network.
PRASA In-Cab Signalling
PICS Request For Proposal 14/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
The main high-level outputs of these pilot projects are:
Safety and interoperability certificates of ETCS level 2 trackside sub-system on each pilot
line;
Specific Application Safety Case for the PICS system on each pilot line;
Acceptance and authorisation by the Railway Safety Regulator to put in operation the
ETCS level 2 on each pilot line;
Training session carried out for the users on each pilot line;
As-built documentation of the delivered ETCS level 2 installations for each pilot line;
Integration of the feedback from each pilot line into the generic design.
This list is not exhaustive. The technical scope of the PLP is described in the [REF.2] and all its
subdocuments. The geographical scope is defined in the following sections and in [APP.1].
4.1.1. Pilot Line 1 in Gauteng: GAU-01-PLP
The GAU-01-PLP is the Pilot Line for Gauteng PRASA region. The characteristics of this line are
summarized in the Table 2. This information is given for tendering purpose only.
Info Description From Station Houtheuwel included – KP 58.63
To Halt Tshiawelo included – KP 17.37 Track Double track track Length +/- 41.26 km Traction Power 3 kV DC Interlocking SICAS S7 from Siemens (installed in the frame of the re-signalling
program) located in each station on the line Computer Room In each station Stations Houtheuwel– 4 tracks
Residensia – 7 tracks Grasmere – 6 tracks Lawley – 4 tracks Lenz – 5 tracks Midway – 5 tracks
Layout The detailed layout can be found in [APP.1] of this document.
Table 2 : Pilot Line Gauteng region characteristics
4.1.2. Pilot Line in Kwa-Zulu Natal: PLP-KZN-01
The PLP-KZN-01 is the Pilot Line for KwaZulu-Natal PRASA region. The characteristics of this
line are summarized in the Table 3. This information is given for tendering purpose only.
Info Description From Station Pinetown included – KP 77.67 To Halt Umbilo included – KP 99.64 Track See [APP.1] Length +/- 21.97 km Traction Power 3 kV DC Interlocking. Computer room
Ebilock 950-R4 from Bombardier (installed in the frame of the re-signalling program) located at the new CTC centre in Rossburg.
Stations Pinetown – 5 tracks Northdene – 3/4 tracks
PRASA In-Cab Signalling
PICS Request For Proposal 15/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
Malvern – 2 tracks Bellair - 3 tracks Rossburgh – 4 tracks Umbilo – 4 tracks
Layout The layout can be found in [APP.1] of this document.
Table 3 : Pilot Line Kwa-Zulu Natal region characteristics
4.1.3. Pilot Line in Western Cape: PLP-WC-01
The PLP-WC-01 is the Pilot Line for Western Cape PRASA region. The characteristics of this line
are summarized in the Table 4. This information is given for tendering purpose only.
Info Description From Station Wynberg included – KP 12.88
and Halt Athlone – KP 5.74
To Station Simonstown included – KP 36.05 Track Double track Length 33.78 km Traction Power 3 kV DC Interlocking/ Computer room
LockTrac 6151 L905 from Thales (installed in the frame of the re-signalling program) located in Retreat station
Stations Wynberg – 4 tracks Plumstead – 3 tracks Wetton – 3 tracks Retreat – 8 tracks Muizenberg – 3 tracks Fish Hoek – 3 tracks Simonstown – 5 tracks
Layout The layout can be found in [APP.1] of this document.
Table 4 : Pilot Line Western Cape region characteristics
4.2. Life Cycle and planning
The phases of the PLP and ROP are presented on Figure 3.
PRASA In-Cab Signalling
PICS Request For Proposal 16/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
Figure 3: Project Life Cycle for Pilot Line subProjects (PLP) and Roll-Out subProjects (ROP)
PRASA In-Cab Signalling
PICS Request For Proposal 17/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
R0021_08. [CT] Within one month (30 calendar days) after PRASA sends a formal notice to
proceed for a PLP or ROP subproject, the Contractor shall organize the subproject
kick-off meeting. The formal notice to proceed shall take the form of a project
charter.
As a mandatory condition to start a subproject, the re-signalling must be completed for the
concerned area and the corresponding as-built documentation must be available.
R0021_09. [CT] The Contactor shall take the lead and the responsibility of the Project
Definition phase but the formal approval from PRASA shall be required. Therefore,
in order to successfully reach the Preliminary Gate Review maximum one month
after the Project Kick-off meeting, the Contractor shall be responsible to take all
necessary precautions to request PRASA approval on time. The period of time
between Project Kick-off and the Preliminary Gate Review shall not exceed one (1)
month.
R0021_10. [CT] The Contractor shall submit the detailed subproject programme for
Preliminary Gate Review. In order to successfully reach this milestone, the
Contractor shall submit the detailed subproject programme for review and
interrogation during the Project Definition phase (see also section 7).
R0021_11. [CT] The Contractor shall ensure that the period of time between the Preliminary
Gate Review and the Preliminary Acceptance shall not exceed twenty (20) months
for Pilot Line Projects and fourteen (14) months for Roll-Out Projects. The
Contractor shall take the lead of the needed Joint Workgroup with other suppliers if
needed (see [REF.7]) and shall take the responsibility to meet deadlines unless it is
proven that another supplier is faulty. The burden of proof lies on the Contractor
side.
R0021_12. [CT] At the Design Gate Review and Data Engineering Gate Review, the Contractor
shall be responsible to get the authorisation from PRASA to proceed but this
authorisation is neither an approval nor a review of the work carried out by the
Contractor. The Contractor shall remain fully responsible for the content of his work
until the Preliminary Acceptance milestone.
R0021_13. [CT] The Contractor shall ensure that the period of time between the milestones
Laboratory Validation and the Preliminary Acceptance shall be at least one (1)
month. As a consequence, the period of time between the Preliminary Gate Review
and the Laboratory Validation milestone shall not exceed nineteen (19) months for
Pilot Line Projects and thirteen (13) months for Roll-Out Projects.
R0021_14. [CT] The Installation and Manufacturing phases are not bound to specific
milestones. The Contractor shall plan these phases as it wishes in order not to
jeopardize the planning of the other phases. No payment shall be bounded to these
phases.
PRASA In-Cab Signalling
PICS Request For Proposal 18/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
The period of time between the Preliminary and Final Acceptance shall be two (2) years and shall
be used for the review of the performance and is described in [REF.3].
R0021_15. The Contractor shall organize six (6) Performance Gate Reviews, occurring every six
(6) months, during the Performance Monitoring phase which ends at the issue of
performance certificate (as defined in the Volume 2 of PICS RFP). The last
Performance Gate Review shall occur at the same time than the Final Acceptance.
4.3. Schedule
R0021_16. Within the high level schedule given in section 2 (Figure 1), PRASA will plan the
start date of the PLP according to PRASA needs and constraints (availability of the
interlocking, capacity needs, safety needs, etc.) and according to the dependencies
(see section 6). The Contractor shall be flexible to start at the set date and shall take
the responsibility of any delay due to the dependencies (e.g. TDP activities not
completed or done properly).
4.4. Deliverables
The Contractor shall deliver specific documents to the PRASA at each defined milestone. The
Table 5 defines which deliverables must be delivered for which milestone of PLP/ROP.
To successfully reach the milestone, each deliverable must be approved by PRASA. This approval
means a “notice to proceed further” and does not transfer any responsibility from the Contractor
to PRASA. The Contractor remains fully responsible as defined in section 4.2.
The list in Table 5 is an overview of the deliverables and conditions required within the whole
PICS Technical RFP for a Pilot Line subProject. This list is not exhaustive but gives already a good
indication of the content required at each milestone; for example, it does not include all the
conditions and deliverables expected from a professional way of working or from a classical
development according to the normative reference (e.g. the delivery of new ISO9001 certificate
after renewal). However, each deliverable already identified is mandatory. This list must be
completed for the Preliminary Gate Review of the Typical Development Project.
Milestone Deliverables Required in
Preliminary Gate Review
RAM: Specific RAM Plan
[REF.3]
Management: (Specific) Project Management Plan, including WBS,
RACI and planning Scope Baseline Schedule Baseline
[REF.4]
Safety: Specific Safety Plan
[REF.9]
Testing: Specific Verification and Validation Plan
[REF.11]
Engineering: Specific Application System Requirements
Specification (SRS) [REF.10]
PRASA In-Cab Signalling
PICS Request For Proposal 19/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
Milestone Deliverables Required in Quality: Specific Project Quality Plan Evidence of qualified and trained staff Reporting on the Production Planning
[REF.6]
Products: KMC Documentation
[REF.12]
Important remark: the deliverables of the Generic Subsystem Design phase must also be delivered and approved in order to start the PLP Detailed Design phase (see Figure 4).
Design Gate Review
Performance: RAM Analysis Specific RAM Plan
[REF.3]
Quality: Pre-Manufacturing Review conducted before starting of production
[REF.6]
ETCS design: Implementation of the Stop if in SR function by
GSM-R (second step) Track Data Collected
[REF.8]
Safety: Specific Safety and Risk Analysis Intermediate Hazard Log
[REF.9]
Design: Detailed Design Report Specific Design Documents Detailed Design plans and installation/execution
plans Earthing Plan Detailed Design System Interfaces Description
(SyID)
[REF.10]
Testing & Acceptancy: Specific Tests Specifications for the ETCS trackside
static SAT Interoperability Constituents Certificates
[REF.11]
Management: Updated Project Management Plan (incl. Scope
Statement and Planning) Updated WBS, RACI and planning
[REF.4]
HSE: Health Safety and Environment Plan
[REF.5]
Products: Products description
[REF.12]
Installation: Adapted installation plans (room plans, etc.) Products installation directives
[REF.13]
Data Engineering GR
Engineering: Subproject Data Engineering Report Data files for all equipment (RBC, balises, LEU if
any) Measurement Survey Report (shall be delivered to
PRASA one month after the end of the Measurement Survey, and at latest at this gate
[REF.10]
PRASA In-Cab Signalling
PICS Request For Proposal 20/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
Milestone Deliverables Required in review).
Testing : Specific Tests Specifications for all the tests phases
belonging to Laboratory Testing and Validation. [REF.11]
Quality: First Article Inspection review done (for the first
application and for after each product change)
[REF.6]
Safety: Specific risk analyses, if any Specific Hazard Log Report with measures
implemented
[REF.9]
Laboratory Validation GR
Testing : Specific Tests Specification for all the tests phases
belonging on site Testing and Validation. Specific Tests Reports for all the tests phases
belonging to Laboratory Testing and Validation Laboratory Testing and Validation Summary Report
[REF.11]
Preliminary Acceptance GR
RAM: Maintainability demonstration of every products
[REF.3]
Quality: First System Installation Inspection conducted
before the commissioning tests.
[REF.6]
Testing & Acceptancy: Specific Tests Reports for all the tests phases (as
defined in [REF.11]) belonging to on-site Testing and Validation.
On site Testing and Validation Summary Report Global Testing and Validation Summary Report ISA Discrepancies Register NoBo Discrepancies Register Certificate of Verification of the PICS CCS ISA and NoBo Assessment Reports, Certificates and
dossiers
[REF.11]
Safety: Specific Hazard Log Report (records “closed”) Generic and Specific Application Safety cases
[REF.9]
Products: KMC tool User Manual “Management of Track possession” function
documentation (User manual, procedures to be applied, etc…)
Data File Management Tool Documentation ETC maintenance server and Local RBC terminal
full documentation Portable Maintenance Tools full documentation
(user’s manuals, certificates, etc…)
[REF.12]
Maintenance: Maintenance documentation Maintenance tools received and working Maintenance Plan PRASA maintainers Maintenance Plan Contractor maintainers
[REF.14]
PRASA In-Cab Signalling
PICS Request For Proposal 21/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
Milestone Deliverables Required in Training: All needed training held Training report
[REF.15]
All above mentioned documents updated to take into account the necessary adaptations (after possible previous applications)
All information needed for PRASA to be able to operate the subproject put into service.
Performance GR RAM: Performance Monitoring Report Reliability and Availibility Demonstration Update of the RAM plan, if any
[REF.3]
Engineering: As-built plans (at first performance GR)
[REF.10]
Maintenance: Change Analysis on Maintenance Plans
[REF.14]
All feedbacks and lessons learned are sent to the Typical Development Project
Final Acceptance GR
RAM: (Final) Performance Monitoring Report
[REF.3]
Maintenance: Change Analysis on Maintenance Plans
[REF.14]
All feedbacks and lessons learned are sent to the Typical Development Project
Recurrent Deliverables
Management: Adequate reporting and communication Risk Register (update if any) Planning and programme
[REF.4]
All feedbacks and lessons learned are sent to the Typical Development Project
Table 5 : Milestones and deliverables for PLP
The payment for the Pilot Line Projects shall be made at successful milestones completion as
defined in the (non-technical) RFP.
5. The Roll-Out subProjects
R0021_17. [CT] The Contractor shall carry out the PICS Roll-Out subProjects with strict
observance of the information (about scope, organization, schedule, life cycle, etc.)
given in this section 5.
5.1. Scope
The scope of the Roll-Out subProjects (ROP) covers all the activities and supply needed to get a
commissioned and certified ETCS level 2 trackside subsystem on the identified lines. The main
high-level deliverables of these projects are:
Safety and interoperability certificates of ETCS level 2 trackside sub-system on each roll-
out project;
PRASA In-Cab Signalling
PICS Request For Proposal 22/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
Specific Application Safety Case for the ETCS level 2 trackside subsystem on each line;
Acceptance and authorisation by the Railway Safety Regulator to put in operation the
ETCS level 2 on each line;
Training session carried out for the users on each line;
As-built documentation of the delivered ETCS level 2 installations for each line.
This list is not exhaustive. The technical scope of the ROP is the application of the generic design
and is described in the [REF.2] and its subdocuments. The geographical scope is defined in
[APP.1].
The geographical scope of the Roll-Out subProjects is defined in the Table 6, according to the
phasing of the re-signalling (see [APP.1] for the information about the re-signalling phases).
Roll-Out subProject in Gauteng ROP-GAU-02 Phase 3 + Phase 5 + Phase 7 ROP-GAU-03 Phase 6 + Phase 8 ROP-GAU-04 Phase 2 + Phase 4 + Phase 9 ROP-GAU-05 North part Phase 10 + Phase 11 + Phase 12 ROP-GAU-06 South part Phase 10 + Phase 13 ROP-GAU-07 Phase 14 ROP-GAU-08 Phase 15
Roll-Out subProject in KwaZulu-Natal ROP-KZN-02 Phase 3a + Phase 3b ROP-KZN-03 Phase 4 + Phase 5 ROP-KZN-04 Phase 6 + Phase 7
Roll-Out subProject in Western Cape ROP-WC-02 Phase 1.3 + Phase 1.4 ROP-WC-03 Phase 3.1 + Phase 3.2 + Phase 2.3 ROP-WC-04 Phase 2.2 ROP-WC-05 Phase 1.1 + Phase 2.1 ROP-WC-06 Phase 4.1 + Phase 4.2
Table 6 : List of Roll-Out subProjects
The splitting of Gauteng phase 10 shall be around Schuttestraat.
5.2. Life Cycle
As the project life cycle is the same for pilot line subproject and for roll-out subproject, please
refer to section 4.2 for project life cycle and milestones. The whole section is applicable for ROP,
except where explicitly limited to PLP (e.g. for duration limits).
5.3. Schedule
R0021_18. Within the high level schedule given in section 2 (Figure 1), the ROP shall be
executed according to PRASA needs and constraints (availability of the interlocking,
capacity needs, safety needs, etc.). As a consequence, the Contractor shall be flexible
to adapt the “Program and Project Schedule Chart” proposed in its Tender if
required by PRASA for the Contract execution.
PRASA In-Cab Signalling
PICS Request For Proposal 23/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
5.4. Deliverables
The Contractor shall deliver specific documents to PRASA at each defined milestone of the ROP
as defined in [REF.4]. These deliverables are the same as for the pilot lines and the Table 5
defines which deliverables must be delivered for which milestone.
To successfully reach the milestone, each deliverable must be approved by PRASA. This approval
means a “notice to proceed further” and does not transfer any responsibility from the Contractor
to PRASA. The Contractor remains fully responsible as defined in section 4.2.
The list in Table 5, which gives an overview of the deliverables and conditions required within
the whole PICS Technical RFP for a Pilot Line subProject, is also applicable for a Rollout
subProject. Nevertheless, some of the deliverables identified in this table may be delivered only
once for the whole project (e.g. the product descriptions only during pilot lines). This list is not
exhaustive but gives already a good indication of the content required at each milestone; for
example, it does not include all the conditions and deliverables expected from a professional
way of working or from a classical development according to the normative reference (e.g. the
delivery of new ISO9001 certificate after renewal). However, each deliverable already identified
is mandatory. This list must be completed for the Preliminary Gate Review of the Typical
Development Project.
The payment for the Rollout subProjects shall be made at successful milestones completion as
defined in the (non-technical) RFP.
6. Dependencies between projects
As seen in the high-level time schedule (Figure 1 in section 2), the TDP, PLP and ROP are
strongly related and some of them are overlapping. The high-level dependencies between them
are listed here and illustrated in Figure 4:
The design of the pilot lines shall begin after the system design carried out at typical
level (Typical Development subProject).
The Validation of the Generic Principles (in the TDP – see section 3.2 for the definition of
this phase) shall not end before having taken into account the feedback of On-site
Testing and Validation phases from all PLP.
The TDP (without Updates and Upgrades phase) cannot end before the commissioning (=
Preliminary Acceptance) of all PLP2 and the consolidation of the Generic Case.
The ROP shall begin after the end of the TDP (not taking into account the Updates and
Upgrades phase of the TDP).
Each ROP shall feed the TDP Updates and Upgrades with the feedback before its end.
2 In case of multiple suppliers, this condition is limited to the applicable PLP.
PRASA In-Cab Signalling
PICS Request For Proposal 24/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
Figure 4: Dependencies between subprojects inside PICS project
More detailed dependencies between phases of the project are illustrated in Figure 5. The
following elements must also be taken into account to understand this figure and to define the
concept:
Each arrow from element A to element B implies that A must be finished to begin B. It is
a necessary condition but not a sufficient one. It is not a logical condition meaning that
finishing A implies that B begins.
The lighter blocks (i.e. SW Development, HW Development, Manufacturing and
Installation) are phases that are not fully delimited by gate reviews (milestones); the
supplier can manage and organize them himself without jeopardizing the planning of the
other phases.
PRASA In-Cab Signalling
PICS Request For Proposal 25/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
Figure 5: Dependencies between TDP and PLP project phases
PRASA In-Cab Signalling
PICS Request For Proposal 26/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
7. Planning Procedure and tools
R0021_19. [CT] The Contractor shall produce the required programme scheduling in ASTA
PowerProject planning software. Planning deliverables shall always be ASTA
PowerProject electronic file and a PDF version as well.
R0021_20. [CT] Before every Preliminary Gate Review (TDP, PLP or ROP), the Contractor shall
submit the related subproject (or project for TDP) programme (in ASTA
PowerProject electronic file) in order to allow review and interrogation. Sequencing,
logic, and resource allocations will be checked by PRASA to ensure the accuracy and
workability of the programme.
R0021_21. [CT] The Contractor shall use the following guidelines during the planning
activities:
The Contractor shall fully logic link the programme scheduling applying the
Contractor’s mind to the logic to ensure the logic is as complete as possible. The
Contractor shall not continuously add or delete logic links as the project
progresses. The full logic linking process shall be carried out completely by the
Contractor at the outset. The logic must be true between activities and have as
few or no dummy links between activities as possible.
The Contractor shall not use negative links as these can result in inaccurate
progress reporting and the requirement to insert the correct logic later to
correct this error.
The Contractor shall use Start and Finish constraints only where there is no
suitable logic link that can be applied. In such instances a start constraint date
may be inserted but may need to be adjusted as the project proceeds or a
‘Dummy’ link is inserted so as to allow this string of activities to move in
relation to other relevant strings once progress is calculated. This logic may
require adjustment as the project proceeds.
The Contractor shall include contingencies for inclement weather for site
installations. Contractor is required to submit a schedule of rain days assumed
or as a minimum the number of days allowed for within the programme. The
Technical Advisors to PRASA will discuss and seek agreement on the allowance.
The Contractor shall include within the programme procurement of equipment
and materials which identifies pricing/tendering periods, award, placement of
order, any shop drawings or supplier design periods, manufacturing periods,
factory acceptance testing, shipping times, customs clearances and delivery to
yard or site. Progress reporting on these activities is required to ensure
compliance with the site installation date and identify possible time risks early.
The subproject programme must refer back to the project programme and must
fall within the time frame of the project programme. Should it be found that the
periods or sequence within the project programme is unworkable the
subproject programme must either be crunched if this area sits on or near the
critical path or the subproject programme used as a basis for the revision of the
project programme.
PRASA In-Cab Signalling
PICS Request For Proposal 27/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
In line with international standards the Contractor shall use the float as
belonging to the project and not solely to either party.
The procedure for carrying out the progress update on the software will be to
standard practices, that is, to define the progress cut-off date or Status Date and
calculate incomplete and activities not started to commence or finish after this
date. The use of constraint dates to predict the end or start of activities during
the life of the programme should only be used in the cases where activities such
as delivery dates are known in writing.
R0021_22. [CT] With every programme submitted throughout the project lifecycle, the
Contractor shall include within the electronic copy of the programme the key
resources required to execute the plan. The resources required will include key
designers/teams and extend through to site installation. The Contractor shall submit
resource histograms for each resource to demonstrate that the programme has been
constructed with resources in mind and resources levelled prior to submitting the
programme to ensure that a workable programme has been compiled. The
Contractor shall also submit a detailed Approach Paper describing the sequence and
methods and the reasons for the chosen strategy.
R0021_23. [CT] For subproject programmes (short term), the Contractor shall deliver a
detailed method statement indicating sequencing, anticipated resources,
reasoning for sequencing and methods chosen, access routes, public protection,
occupations anticipated and type of occupation. This serves to ensure that the
Contractor has thoroughly thought through the work to be undertaken. Also
activities sensitive to weather should be protected by including suitable weather
allowance within the programme. Key resources must be considered in the
programme to ensure a workable programme.
7.1. Reporting
R0021_24. [CT] The Contractor shall submit monthly progress updates in electronic format
for interrogation. This reporting shall be derived from the global programme in
ASTA PowerProject format. Once on site operations begin the progress updates will
be carried out jointly and agreed prior to the formal issue of the progress update
and report. In this way bottle necks and planning issues can be identified
immediately and plans put in place to mitigate any delay or disruption. This
reporting shall be done by the Contractor with respect to the following guidelines:
Progress will be recorded both against the critical path and an ‘S’ curve
The progress trend will be shown against an “S-Curve” based on an activity
count or so as to track against percentages, actual percentage achieved against
planned. Although the critical path is the key mode of measurement for the end
date the S-curve will give a trend and establish a pictorial view of the work
volumes achieved or not achieved as the case may be.
The progress report must include the reasons for time gain or loss for key
activities while a record of gains and losses or changes for each affected activity
should be kept in the notes column of the programme
PRASA In-Cab Signalling
PICS Request For Proposal 28/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
The aim of the Progress Report is to establish exactly where the project is and
not where it is thought to be either at the time of the report or sometime in the
near future.
This progress report shall be combined with the monthly report as defined in
[REF.4].
Once the progress has been calculated it is often the case that the result no longer reflects
current events or developments thereby producing a result that is too far behind programme or
indeed too far in front.
R0021_25. [CT] The Contractor shall record the result of the progress calculation and
communicate it to PRASA and the correction and the reasons for the correction
recorded in the ‘Programme Change Log’. The logic or duration change must be
agreed with the PRASA. Where progress has fallen behind, a mitigation statement
shall be produced by the Contractor detailing how the time will be recovered and
with what resources and accompanied by a programme showing the recovery.
Where the programme falls behind the Contactor is urged to not only address the
Critical Path but also the volume of work on non-critical activities as the increase in
work volumes will cause the Contractor to address too many fronts and lead to
inefficiencies and a higher risk of failure in the future.
R0021_26. [CT] Where the Contractor is faced with several options to save time or work more
efficiently than that originally envisaged, or PRASA needs to review the impact of
possible future instructions, the Contractor shall produce a series of ‘what-if’
programmes to ascertain a better understanding of the benefits in time for each
option available. Where such action is required the Contractor is to notify PRASA
and submit the ‘what-if’ programmes and the attractors and detractors of each
option. The purpose of this review is to constructively comment and offer a possibly
different viewpoint or option to consider.
7.2. Revision
R0021_27. [CT] Revisions to the Contract Programme must be agreed prior to formal issue.
The Contractor shall clearly state the reasons for change in a Programme Change
Log produced and submitted for record purposes. This Change Log shall identify the
activities affected stating what changes have been made to sequence, duration and
any logic changes for each affected activity.
It is accepted that the programme may, at some point during the life of the project, no longer
represent what will transpire or what needs to be achieved either through new understanding
or changes to scope or sequence for various reasons. It is not the intention that should the
contractor pull significantly ahead or fall behind programme that the programme is revised. A
well constructed, robust programme regardless of substantial progress gains or losses, should
still be able to provide accurate progress feedback and be able to remain the working document
that the Contractor can organize the tasks and resources to execute the works, and therefore not
require change.
PRASA In-Cab Signalling
PICS Request For Proposal 29/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
R0021_28. [CT] Where an extension of time is requested the Contractor shall submit the
programme clearly showing the effects of the delay against the project programme
along with other supporting evidence that is required under the terms of the
contract. All claims and their effects on the Critical Path must be clearly
demonstrated to justify any extension of time. It is not sufficient to adjust and
extend existing activities. The Contractor shall insert the events, and possibly
correspondence trail, leading up to the delay as new activities in the ‘What If’ or
Delay Demonstration Programme, and linking these events to the relevant activities.
Where the delay cannot be clearly shown on the project programme the subproject
programme in operation at the time shall be used by the Contractor to demonstrate
that the subproject programme falls within the framework of the project
programme and that the subproject programme has been vetted by PRASA3 prior to
its use.
8. Requirements for the Tenderer
R0021_29. [EV] The Tenderer shall deliver a dedicated document named “Program and
Project Schedule”. This document shall address all the topics considered in the
present document about the planning of the projects. In appendix to this document,
the Tenderer shall deliver:
a “Program and Project Schedule Chart” (in ASTA PowerProject format and
in PDF format as well) as defined in R0021_30;
a “Work Breakdown Structure Chart” (in MS Excel “.xlsx” format) as defined
in R0021_36 (and following).
A “Company Structure”, as required in document [REF.5].
The “Key CV”, as required in document [REF.5].
The requirement R0021_29 is the subcriterion “Program and Project Schedule” as defined in
[REF.5]. Its evaluation by PRASA shall be carried out regarding the expected content of the
“Program and Project Schedule” document and its appendices, as described throughout this
document (i.e. requirements about the time schedule, the WBS, the workload analysis and the
project deliverables). It must be noted that the sub-criterion “Company Structure”, “Team
Structure” and “CV” will be evaluated separately and are not part of the evaluation “Program and
Project Schedule”.
8.1. Time Schedule
R0021_30. [CP] The Tenderer shall deliver a “Program and Project Schedule Chart” (as
defined in R0021_29) of all activities related to the TDP, PLP and ROP. This overall
schedule shall respect all requirements presented in this document. The “Program
and Project Schedule Chart” shall be fully explained (assumptions, rationales, links
between projects or milestones, topics identified in the following requirements, etc.)
in the “Program and Project Schedule” document.
3 It is not the intention PRASA to vet weekly or monthly programmes unless they have the possibility of affecting PRASA/Metrorail operations or indeed may affect the ‘Master’ or Baseline programme.
PRASA In-Cab Signalling
PICS Request For Proposal 30/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
R0021_31. [CP] In the “Program and Project Schedule Chart”, the Tenderer shall use the
same activities as defined in the overall WBS (see section 8.2).
R0021_32. [CP] The Tenderer shall give a description of each new milestone it proposes and
what it commits to deliver at these milestones. These milestones must help PRASA
to accurately follow the project.
R0021_33. [CP] For TDP and each of the PLP, the Tenderer shall show the four levels (as
defined in R0021_37) in its “Program and Project Schedule Chart”. If the Tenderer
is able to propose a shorter time for the PLP, the Tenderer shall do so and explain in
detail how this shorter period is to be achieved.
R0021_34. [CP] For ROP, the Tenderer shall discuss and optimize the duration of the project
life cycle (i.e. all phases and activities) in the frame of the dependencies given in
section 6. The discussion and optimization shall take into account at least the
following elements of a project: complexity, PRASA regions, location, PRASA
operational needs (as far as possible), workload peak, available resources, critical
path, buffer time, etc. As a conclusion, the Tenderer shall define different types of
project duration and shall allocate each Roll-Out Project to one type. The number of
project type shall be maximum five (5).
In the “Program and Project Schedule Chart”, the Tenderer shall show the four
levels for at least one project of each proposed type. Other projects can be simplified
to the first level (start and end dates).
R0021_35. [CP] The proposed schedule shall take into account the discussion made to
answer the requirement R0021_45 (estimated workload and resources) in the limits
of the constraints mentioned in this document. Proposals which do not respect any of
the constraints given in this document may not be included by the Tenderer in the
proposed planning.
8.2. Work Breakdown Structure
R0021_36. [CP] The Tenderer shall deliver an overall work breakdown structure of all
activities related to the TDP, PLP and ROP. This overall WBS shall respect all
requirements presented in this document. It shall be based on the template given in
[APP.2]. The template, the layout and the first levels of this document shall be
respected. This overall WBS shall be given in the “WBS Chart” (as defined in
R0021_29) and fully explained (assumptions, rationales, links between projects or
milestones, WBS dictionary, etc.) in the “Program and Project Schedule”.
R0021_37. [CP] In the overall WBS, the Tenderer shall use four levels for the activities: (1)
Subproject, (2) Phase, (3) Topics and (4) Work Package (also used for milestones).
The activities identified in the WBS shall correspond to the ones identified in the
overall schedule.
Note that this Overall WBS is a WBS to be used by PRASA as a base to follow the project. The
internal WBS of the Contractor may and should probably be more detailed. However, it is
PRASA In-Cab Signalling
PICS Request For Proposal 31/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
strongly recommended that the internal WBS of the Contractor is in line (i.e. use the same
structure) with the Overall WBS.
R0021_38. [CP] The Tenderer shall give a description (WBS dictionary) and the
dependencies of each activity (phase, topic or work package) in the “Program and
Project Schedule”.
R0021_39. [CP] In the overall WBS, the Tenderer shall propose one instance of the WBS for
the three PLP, as the three projects must have the same WBS.
R0021_40. [CP] In the overall WBS, the Tenderer shall give as many instance of the WBS as
the number of ROP type identified (see R0021_34 for the type), as they can be
(slightly) different. If the WBS does not vary from one type to another, the Tenderer
shall clearly mention this and is allowed to reduce the number of instance to the
minimum needed.
8.3. Workload management
R0021_41. [CP] In the “Program and Project Schedule” document, the Tenderer shall develop
a dedicated section called “Workload management” where it includes the answer to
all the requirement of the section 8.3.
R0021_42. [CP] The Tenderer shall propose a way to ensure an efficient collaboration
between TDP team and PLP team(s) if they are different. This proposal shall
describe:
the organization of the different projects;
how the human resources are shared between them;
the processes to be put in place.
The Tenderer proposal shall have a dedicated section to thoroughly cover this topic.
If accepted by PRASA, this proposal shall be fully part of the contract and the non-
respect of it will lead to penalties.
R0021_43. [CP] The Tenderer shall give an estimation of the workload of the program. This
estimation shall contain a graph of the FTE needed in function of the time and shall
be fully explained and discussed (assumptions, explanations of figures, etc.) in the
“Program and Project Schedule” document. Workload peaks shall be clearly
identified and mentioned by skill category (e.g. data prep engineer, design engineer,
test engineer, etc.)
R0021_44. [CP] The Tenderer shall give information about his current and planned human
resources, by skill category (like data prep engineer, design engineer, test engineer,
etc.) relevant for this project. The Tenderer shall mention when and how many
engineers will be available for the PICS program should the Tenderer be successful.
R0021_45. [CP] The workload estimation and the available resources shall be presented by the
Tenderer in a way that allows PRASA to make a comparison between these two data.
PRASA In-Cab Signalling
PICS Request For Proposal 32/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
The Tenderer shall discuss the “estimated workload vs available resources”
question. The following elements shall, at least, be addressed:
The action plan to ensure the availability of the resources (hiring: when, where,
what type of profile, etc.);
The adaptations of the planning in order to limit the workload peaks by
resource levelling techniques;
Any proposal to fulfil the program requirements in a more optimal way4.
8.4. Project Deliverables
R0021_46. [CP] The Tenderer shall check the lists of deliverables (Table 1, Table 5 and Erreur !
Source du renvoi introuvable.) and notify every modification proposal he finds
useful to PRASA through a section called “Deliverables” within the “Program and
Project Schedule” document. PRASA holds the right to refuse any proposal.
R0021_47. [CP] The Tenderer shall give a list of the inputs he will need for each activity
(normally only for WBS level 4: Work package or milestones). This list can be in the
“WBS chart” or in the “Program and Project Schedule” document. PRASA holds
the right to refuse an element of the list and delete it, if he judges it not needed or if
it requires activity (like engineering) at the PRASA side. The Tenderer shall
particularly pay attention to the inputs needed for the first phases of the Typical
Development Project and the Pilot Line Projects, as they are critical for the start of
the PICS program. This list of inputs from PRASA may be updated after Contract
Award on mutual agreement.
R0021_48. [CT] During Contract execution, the Contractor shall not expect more from PRASA
than the document identified in this list.
4 Any proposal which do not respect any of the constraints given in this document (e.g. not respecting the deadline of May 2019) can be discussed with PRASA but shall not be accepted before the Contract Award, in order to ensure the comparability of the Tenders. As a consequence, the Tenderer shall take this situation into account to deliver his offer.
PRASA In-Cab Signalling
PICS Request For Proposal 33/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
9. Requirements List
The requirements from this document are listed in Table 7 and the type of the requirement is
given in the last column. Explanation about the “type” is given in [REF.5].
Requirement Name Type R0021_01 Contract executed according to the requirements Contractor R0021_02 Decomposition into 22 subprojects Contractor R0021_03 High Level Time Schedule Contractor R0021_04 Typical Project executed according to the requirements Contractor R0021_05 TDP Kick-Off Contractor R0021_06 TDP SW development and HW development Contractor R0021_07 Pilot Lines executed according to the requirements Contractor R0021_08 Project Charter Contractor R0021_09 Project Definition Phase Contractor R0021_10 Detailed Program for subproject Contractor R0021_11 Time duration for phases (I) Contractor R0021_12 Responsibility during phases Contractor R0021_13 Time duration for phases (II) Contractor R0021_14 Installation and Manufacturing phases Contractor R0021_15 Performance Monitoring Phase Contractor R0021_16 Start date of PLP Contractor R0021_17 Roll Out executed according to the requirements Contractor R0021_18 Start date of ROP Contractor R0021_19 ASTA PowerProject Format Contractor R0021_20 Subproject and project programme for Preliminary GR Contractor R0021_21 Guidelines for planning activities Contractor R0021_22 Key resources and histograms Contractor R0021_23 Detailed method statement Contractor R0021_24 Monthy progress updates Contractor R0021_25 Progress calculation and change log Contractor R0021_26 What-if programmes Contractor R0021_27 Revision of programme Contractor R0021_28 Extension of time Contractor R0021_29 Delivery of “Program and Project Schedule” document
and its appendices [subcriterion Program and Project Schedule]
Evaluation
R0021_30 Overall Schedule Compliance R0021_31 Planning: four levels of activity Compliance R0021_32 Planning: requirements for TDP and PLP Compliance R0021_33 Planning: requirements for ROP Compliance R0021_34 Planning: duration discussion Compliance R0021_35 Planning: estimated workload and resources discussion Compliance R0021_36 Overall Work Breakdown Structure (WBS) Compliance R0021_37 WBS; four levels of activity Compliance R0021_38 WBS: description and dependancies Compliance R0021_39 WBS: instance for PLP Compliance R0021_40 WBS: instance for ROP Compliance R0021_41 Workload: specific section Compliance R0021_42 Workload: collaboration between TDP and PLP Compliance
PRASA In-Cab Signalling
PICS Request For Proposal 34/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
R0021_43 Workload: estimation of the workload Compliance R0021_44 Workload: current and planned human resources Compliance R0021_45 Workload: workload estimation vs human resources Compliance R0021_46 Deliverables Compliance R0021_47 List of inputs needed Compliance R0021_48 Limitation of inputs in execution phase Contractor
Table 7: Requirements list
PRASA In-Cab Signalling
PICS Request For Proposal 35/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
10. Appendix 3: The planned development of the PRASA network
10.1. From mechanical and relay signalling to electronic interlocking
(2011- 2017)…
PRASA is currently implemeting re-signalling program to the three main Metroline networks
within South Africa which includes the following in each region:
PRASA Regional CTCs;
Bidirectional traffic;
Suppression of the bottlenecks;
Communication through a fibre optic network;
Replacing the old technology (mechanical, relays).
The re-signalling program is the first building block for the future Wireless Signalling System.
Indeed, the implementation of electronic interlocking offers the possibility to overlay with an
ATC/ATP system to achieve In-Cab signalling on the PRASA network as well as to achieve semi-
automatic train operation.
10.2. Optical fiber network (2012-2014)
In parallel with the re-signalling program, PRASA is installing optical fibers in order to complete
the ring for high reliability communication required in Signalling.
The optical fiber network will become the main mean of communication in signalling eliminating
most of the copper cables.
The Optical Fiber Network program is the second building block for the Wireless Signalling
System as it offers high reliability communication which is required for Signalling.
10.3. Radio digital signalling network (2012 – 2017)
A new GSM-R network is being installed to replace the obsolete analogue trunk radio.
The GSM-R program is the third building block for the Wireless Signalling System as it supports
signalling transmission.
10.4. Asset protection program (today – 2014)
Theft and Vandalism is a major concern for PRASA. Besides the technical choices done in the
frame of the re-signalling (e.g.: copper cables are eliminated as much as possible), an asset
protection program is ongoing comprising:
Lobby for change of legislation for scrap dealers (one regional dealer for
Eskom/Prasa/Gautrain, heavy punishment for asset thieves)
Protect rail land (brick & electric fence, alarms, video)
Code and chip the outside assets starting with copper cables (dot tint, invisible paint)
PRASA In-Cab Signalling
PICS Request For Proposal 36/36 2016-04-18 Project, Planning and Activities Requirements Specification PICS_R_30021_Project RS_3.0_ISSUED.docx
10.5. New PRASA Rolling stock (2016 – 2027)
PRASA has launched a significant renewing program for the commuter trains fleet as a contract
for 600 trains was awarded. The contract requires the trains to be ERTMS equipped ensuring:
Radio communication through the GSM-R network;
Safe train movement (ATC/ATP functions) with in-cab signalling provided that the ETCS
signalling information is sent to the trains.
10.6. PRASA In-Cab Signalling
The PRASA In Cab Signalling project aims at:
moving the PRASA commuter network from the lineside signalling to the wireless In Cab
signalling improving significantly the safety of the train movements ;
making possible future technical evolutions towards semi-Automatic Train Operation
and Virtual blocks;
helping make the network more secure and less prone to theft and vandalism in the
future with the removal of the lineside signalling.
The implementation of In-Cab signalling shall also take into account current
considerations regarding theft and vandalism.