Introduction

It is a truism that all railway projects require “operational input” throughout their lifecycle. This paper defines the role of the operator, and identifies the inputs which an operator could (or should) make during project development.

For the purposes of this paper ‘Operator’ is the entity which plans, monitors, resources and executes the train plan. The Operator implements recovery processes to return the railway to plan after a failure. The Operator is the custodian of the rules and procedures for the completed railway. For the completed railway the role of the operator may be accommodated within several different organisations (for example Network Rail and Train Operating Companies). Therefore the operational ‘guiding mind’ may vary during the course of the project. For example the ‘guiding mind’ for the Crossrail train operations rests with Rail for London, but will in due course rest with a concessionaire train operator albeit working to a framework determined by RfL. The disciplines within operations vary –strategic system view, passenger flow modelling, train service modelling, application of rules and standards, resourcing, incident management, and the emphasis will change over the course of a project.

Much in this paper also applies to the Maintenance Engineer. Operator and Maintainer will ‘own’ the completed system, and have an incentive to ensure that the output of the project can be delivered, and that the operational cost is understood. They will be there long after the engineers and designers have left for other projects.

‘Operations Input’ to a major project can vary from a high level view of the operability and feasibility of a project to agreeing and implementing the detailed rules and procedures for a completed system. The paper describes these varying roles and the differing operational skill sets required during project lifecycle.

Some major projects have suffered in the past through insufficient operator involvement at an early enough stage; for example although the engineering design for Thameslink 2000 was well advanced in the early 1990s, no detailed modelling is believed to have been done during Network South East (NSE) management to validate the core assumption of the scheme, that 24 trains per hour (tph) was feasible within the design assumptions then being made. The original designs for the Portbury Dock freight development in Bristol would have been inoperable if executed in their original form.

The Inception of a Project

Mega projects such as Thameslink, East London Line, HS2, tram schemes and Crossrail all depend upon political support. Political support is engendered, especially in the Treasury through presentation of a business case. The business case is primarily made by looking at the scheme, and by using established (and proven) techniques estimating the likely usage of the new infrastructure based upon assumptions of varying train service levels. This is influenced by the journey time (and counting both the benefits to existing users of the time saving as well as new journeys likely to be thus generated). The costs for the scheme will have been generated by engineers, and may well underestimate the requirements for operating the planned level of service, possibly underestimating enhancement to the existing network.

In the case of Thameslink 2000, and Crossrail, the enthusiasm of the Transport planners ran well ahead of the operators-see case study 1.

In case study 1, the Montague Report identified that the Richmond/Kingston extension did not work, a conclusion which could have been achieved far earlier if an outcome with success criteria (e.g “ a railway that can deliver 12 tph per hour to Richmond with 24tph in the central area and continued operation of 8 tph on the District line with 95% punctuality”) had been laid out and an ”operator” invited to validate the feasibility of the proposal against these requirements. For those within an organisation such as the embryonic Crossrail, identifying that a scheme is unworkable (and therefore condemn the scheme to oblivion) is not necessarily in their personal or organisational best interests, especially if stakeholder pressure has built up for a particular option. ‘Operability’ at this stage of the project is to some extent judgemental and proving inoperability can be difficult, since absolute proof requires a modelling, which to be accurate would require a host of detailed assumptions about track layout, signalling, rolling stock and other services which is simply not feasible to assemble at an early stage of a project and committing about 4 months to it. Stakeholders will often demand ‘proof’ that their chosen scheme will not work. Proving a negative is very hard, especially as there is often a subliminal belief that with a bit of (unspecified) tweaking the chosen scheme will ‘work’

It is inevitable that a ‘mega project’ will at its’ inception examine a variety of options. However if ‘operator involvement’ is to be meaningful (and potentially save a significant amount of money) any options for further development should be assessed against a formal set of requirements. Using the example above, it is possible (albeit unlikely) that if Crossrail had been conceived as a railway which only needed to convey 15 trains per hour through Central London, the outcome would have been different.

The inception of a scheme requires three operating disciplines;

1)    Planning expertise; to understand the likely flows and to dimension the stations and prepare an outline of the train service

2)    Strategic-identifying the likely impact on the network, and suggesting how any proposed scheme can most robustly be operated, and identifying scope that will be required to support the requirements.

3)    Detailed operating knowledge (such as the likely signalling system capability) to inform high level design decisions.

Project Development and Requirements

What follows on Requirements could be taken out of a Project Managers’ manual. But in hindsight, although Crossrail has been better than most projects, some of the hard learned lessons were not addressed from the outset. It is hard to understate the value of robust Requirements Management from an early stage, and in particular an understanding that any changes, however trivial, will impact on the project and the cost. Requirements define the technical output that operations (and maintenance) functions would expect at the end of the project in order to realise the client’s anticipated benefits .Requirements must be change controlled, and complemented by an assumptions register, also change controlled.

Crossrail’s requirements were articulated explicitly only after the Crossrail Bill had been deposited. Previously, there was an apparent consensus about what Crossrail was seeking to achieve, but nowhere was it written down in anything other than motherhood statements (“a significant increase in London’s transport capacity”). When the time came to write down the requirements in detail, it was clear that there was a wide range of understandings within the project; for example some people understood that the benefit of two way signalling was that a 24 hour service could be operated. If that had indeed been the intention then it would have changed numerous systems, for example ventilation fans would have to be able to support dirty works in one tunnel and a passenger service in the other.

It is imperative that everyone in the project is aware of, and works to, the Requirements which the operator endorses. This may appear to be self-evident; however a mega project such as Crossrail will be predominantly composed of civil engineering disciplines which may not be aware that some of their decisions will have an operational impact. In a mega project, it is a fact of life that operators will be many times outnumbered by engineering disciplines all anxious to ‘get on with the job’.

It is equally important that key strategic decisions (such as door configuration and escape strategy) are decided early because upon this a whole raft of other decisions sit. There is often huge pressure to ‘firm up’ requirements for the letting of long lead and civil contracts. In reality, these contracts are required for space proofing the finished railway. For a mega project the bulk of the detailed issues that an operator has relates to systems, which need to be finalised far later in the project life. Requirements which are concerned with system fit out are able to follow significantly later, when the project has built up sufficient systems expertise to allow the operators an appropriate professional dialogue.

Requirements have to be tangible from the outset, so that designers have a clear remit. Use of phrases such as “the ability to increase the train service from 24tph to 30 tph shall be considered” or “the ability to separately operate the station shall be considered”,   become entirely inappropriate early in the project lifecycle. Much better to make a requirement (“ the system shall without closure be capable of upgrade to accommodate a service of 30tph within 10 years of opening”) which can if need be challenged during value management, so that the cost of the requirement can be assessed. The most difficult of all requirements are those which are aspirational; Crossrail Ltd is required to deliver a “world class railway”. This can mean that facilities not strictly required to make the railway work can nevertheless be justified as being ‘world class’.

Requirements should not presume a solution; for example the length of a Crossrail train at opening should be expressed as 200m (nominal) and not as (for example) an 8 coach train, since the latter predetermines a rolling stock solution.

Keeping Options open costs money. The DfT as sponsors of Crossrail wanted to have the option of managing stations by a separate entity to LU (this was at the time that the PPP was still in place). Whilst this was only an option the subsequent integration of the Crossrail demise with that of LU at Farringdon, Whitechapel and Moorgate stations could have been avoided if a firm output (the stations shall be operated by LU) had been expressed form the outset.

With hindsight, it is clear that a project wide understanding of Requirements-their ownership, their control, and the way in which they were expressed was a slow learning curve for all. For many of those operators likely to be involved in a project such as Crossrail, the importance of this is probably not well understood, and may not be a discipline with which they have been familiar. In particular the difference between requirements and scope is ill understood. Requirements define the outcome. Scope defines how the engineer plans to deliver the Requirement.

There is also a subtle change in the skill set needed. Initial project consideration requires strategic and modelling skills, described in section 2.7. As design progresses, there is also a need for operators with recent ‘front line’ experience to contribute to the requirement setting process to ensure that the project is grounded and workable. Equally these individuals will not have been exposed to a major project and so the means of engaging with engineering colleagues in this structured manner needs to be formally trained.

Seeking authority

Once the project has developed sufficiently, it will need to seek powers- an Act or a Transport and Works order. A high profile project such as Crossrail, attracts petitions which impact on operations as the Bill progresses through Parliament.

These petitions can either be upon interested parties wishing to impose a solution (for example petitioners who wished to extend Crossrail west of Abbey Wood) or upon those who have an existing interest, which would be affected by the scheme (freight operators who felt Crossrail would impact upon their ability to grow the business).

The consent process is key because the process can impose a solution upon the project that is unsatisfactory; for example the creation of an International Station at Stratford not served by International trains. Crossrail was required to provide a straight and level alignment at Kensal Green for a future station, even though providing such a station would arguably not be in the best interests of the overwhelming majority using the route. Sometimes the operator and engineer are forced to respond to a petition overnight on a matter which at other times would be agonised over for several weeks.

In hindsight, there was an underlying assumption that because Crossrail was so important for London that other railway interests would be broadly supportive. Instead the scheme was used as a means for these interests to adopt a very combative position, partly to protect their existing rights, partly to secure enhancement that would benefit them, and partly to maximise their gains if Crossrail acquired their rights. This is an understandable consequence of the railway industry as it is now structured. However for the promoter of a project it requires significant operator input to think through the effect on existing users, and to some extent challenge the impact that the project will have on other users.

Value Management

A project will need to demonstrate value for money, and value management will challenge every element. Experience suggests that the elements of the project most likely to be proposed for value management will be those which are most difficult to build. In some cases VM will challenge the requirements (the Fisher St example below), but unless the

requirements exist in a robust form, the operator may be on weak ground to defend removal of scheme elements. However, even where a requirement does exist a robust operational response is still required, often explaining operational matters from first principles, in order to retain key project elements.

System Requirements

A railway is a uniquely difficult system to manage; unless a completely isolated system is built, any new project must integrate with the existing railway, either by sharing a (possibly) enhanced route, sharing expanded stations and interfacing at the boundary with legacy systems. How the railway is operated is influenced by who the ultimate duty holder will be; the development of Crossrail has highlighted numerous differences between National Rail and London Underground methods and approaches to operation. It is imperative that the planned duty holders are identified early on, and that they do not change, and that the embedded operators within the project correctly reflect the view of the final operator. The failure to nominate RfL as the body responsible for letting the concession for Crossrail (as opposed to the DfT letting a franchise because the DfT wished to keep options open) means that the project developed the specifications for the rebuilt stations on the existing network based on a ‘Best guess’ rather than by embedding the views of the final operator in the project.

Whilst the Requirements describe the output that is required, this does not provide the information on how it is expected that the railway will operate. Crossrail has described this in a set of so called “Operational Concepts” which describe in plain English how the systems are expected to integrate with one another. They do not supersede the requirements, although their authorship has in some cases influenced the Requirements.

The concepts are intended to have a profound influence through the project;

1) They evolved from step by step analysis of routine procedures- a so called “day in the life” that went through the procedures in minute detail- describing for example how a train is despatched- when does the driver know it is time to go, how is time recovered, what do staff on the platform see etc

2) They inform the procedures to be adopted in the event of certain system failures (for example how it is expected to evacuate a failed train). This is crucial to the systems integration function which needs to understand how it is intended that the systems fit together.

3) The concepts have proved to be an excellent means of checking the requirements, and validating as a ‘proof of concept’.

4) The concepts have been shared with all potential operators (including LU and NR) so there is confidence that if the railway is integrated in accordance with these concepts it will be readily accepted into use. Crucial to this process is understanding who the ‘end operator’ will be (see above)

5) The concepts have exposed some of the cultural and operational differences that exist between LU and main line railways- in some cases the same term means something different. They have allowed all those involved to have a deep insight into both metro and main line types of operation. It has allowed a cross check so that if there are several ways of doing a task (Driver only operation, see below) the optimal way can be chosen and specified. Equally if there is no compelling reason to change existing practice this is made clear.

6) They also reduce the system integration risk; because by their nature they describe how the systems will integrate in plain English. A governance process is then put in place to identify any gaps between the emerging designs (and their interfaces to other systems) and the operations concepts and associated requirements. The process involved in creating the concepts has, in itself required a forensic approach to every step of the operation

Crossrail is currently at the stage where the Requirements and Operational Concepts have been completed, and will be provided to systems contractors. For those contracts already in the course of discussion, the requests for information appear to indicate engagement, but their real worth during systems fit out has yet to be tested.

Paradoxically, it is whilst system design and execution are underway that the role of operations within the project should becomes less prominent; all the modelling to validate performance at the reference stage has been done and the requirements articulated. If the Operations Concepts and requirements are to have any value they should be stable, and only change if there is a compelling reason to do so. Endless tinkering only causes confusion. Whilst there is clearly a need for a ‘wise head’ to respond to operational issues, operations during system design should be responding not leading.

As the designs conclude, hazards will be identified which can only be mitigated by operational measures; some of these (such as fire evacuation) are already documented. However others (for example how tolerant the system can be to a pump failure) can only be determined as the designs emerge and the operator agrees the mitigations and procedures to be put in place for the completed system. The process intensifies as the project nears handover, with the operator being almost exclusively concerned with rules and procedures. In all probability the people who will be undertaking this work will be those who will be operating the finished system. Their experience will be in day to day operation; clearly there will need to be the continuity within the project to narrate why.

The process of developing operations concepts frequently identifies gaps in scope in the intended design, which have to be funded through change control. There is a danger that operations is seen as ‘gilding the lily’ or ‘changing their mind’ when in reality the gaps in scope frequently occur because explicit operations demands have not been met, or because the project was insufficiently mature to have defined the requirements.

The completion of Operations Concepts marks the conclusion of the design and specification phase of the project. For a mega project such as Crossrail, this was the culmination of 10 years work. The individuals involved have become very close to their engineering and maintenance counterparts, especially those involved in systems. It is inevitable though that those same individuals, well versed in the role of Requirements and working with engineers have, by definition become more distant from operators who have been more recently involved in the day to day operational railway. As the completed designs emerge, it is inevitable that there is a gradual migration to a different profile of operator- less theoretical, and more ‘hands on’ as the proxy to the final operator. This progressive migration requires a sensitive handover. It is important to avoid the ‘new blood’ wishing to revisit decisions embedded in the systems design, so there is a need for continuity; a project as complex as Crossrail has only a tiny number of people versed in end to end operation, and the reason why a given path has been adopted.

Summary

The paper has tried to make explicit the role of the Operator in the project. ‘Operations’ covers a variety of skills which are identified in Figure 1 below:

Figure 1 – Operational Input vs Project Phases

If the paper has only one message it is that disciplined Requirements Management in which the operator is deeply involved is imperative from the outset. A strong operations function will support engineering and avoid rework because of unforeseen operational consequences. The profile of operations support over time will vary, but the need for professional operations support aligned with those who will ultimately operate the railway is imperative.