Introduction and industry context

Baseline development is a critical activity in any programme. The production of the Initial Control Baseline (ICB) was a major step in improving the certainty of the plan for the delivery of Crossrail. It allowed Crossrail and its partners to control programme delivery and supported Sponsor confidence in the programme. The final Baseline was approved by the Sponsors at the last Review Point and remained in place for the duration of the Programme, subject to formal change control.

Establishing the baseline

Review Points were established by the Crossrail Project Development Agreement (PDA) between Crossrail Ltd (CRL) and the Sponsors; the Department for Transport and Transport for London to provide a process to gradually provide CRL with increasing authority. At each Review Point the Sponsors reviewed the costs of the Project and any scope changes required.

The development of the Crossrail Programme Baseline was therefore an essential input to the information required to be provided at the Review Points.

A number of scope and cost summaries were prepared during the development phase. These were first drawn together in a comprehensive statement of the Baseline in the Initial Control Baseline which was approved by the Crossrail Board of Directors in January 2010.

The final Review Point, which gave the Project sanction to let major contracts, was passed in March 2011. The Baseline documented a full and final set of Programme requirements which were compliant with the Sponsors’ Requirements, the Project Development Agreement and the obligations within the Crossrail Act.

This was the final comprehensive re-baseline exercise, and the Baseline has been subject to change control since then. The Programme change control process is described in a separate micro-report: Change Control Process.

The products comprising the Programme Baseline are as follows.

Requirements

The four requirements documents are high level scope documents subject to formal Programme change control:

A detailed suite of operational and technical baseline requirements was developed from the above requirements, not controlled as part of the Baseline but maintained under version control, and subject to formal record of issue to contractors. The top level documents included:

• Operational concepts: documenting the line-wide operations, performance management and resilience plan
• Reliability, Access and Maintainability (RAM) requirements
• Maintenance strategy.

Scope

Scope documents:

Cost

A comprehensive cost estimate was frozen at Review Point 4 and established as the Programme budget.

Schedule

Cost budget and schedule

A relatively small number of key dates were defined as Anchor Milestones (circa 100 per year at peak) and controlled as part of the Baseline. The full schedule was re-baselined, usually at the start of each financial year. The schedule was not cost loaded.  Budgets and forecasts for capital works were time-phased by cost managers. The total value of budgets was subject to change control but budget phasing was not. A time phased annual cost business plan was approved by the Board for each financial year and outturn costs were monitored against this. 

Work breakdown structure

The work breakdown structure was subject to change control, managed by the central Programme Controls change team. The main building blocks of the structure were contracts, which were further subdivided into activity groups and activities. The WBS was mirrored in the organisation structure and the cost breakdown structure, which grouped contracts into projects and sectors. The structure was maintained in both the Prism cost management system and the SAP financial system. A master database was maintained to control and define the WBS as the single source of truth, to ensure consistency across all Programme systems. More detail on the work breakdown structure can be found in the Learning Legacy micro-report: Work Breakdown Structure

Figure 1 – Crossrail Scope Map

Sponsor changes to the baseline

The Project Development Agreement specified a formal process for implementing change to the Sponsors Requirements, the other elements of the Baseline, or the delivery methods of the Programme. This required a formal notice of proposed change, following which Crossrail was required to prepare a change appraisal. If the change was to proceed, a change confirmation notice would then be provided by Sponsors which included confirmation of any additional funding or extension of time.

Lessons learned

The Sponsor Change process provided a formal method for appraising and instructing changes to Sponsor Requirements. The process ensured that any potential changes were highlighted and managed to conclusion in a consistent and comprehensive manner.

The Work Breakdown Structure was maintained consistently across different systems by the use of the master data control system, leading to increased efficiency in reporting, better data integrity and flexibility in report design.

The Crossrail WBS was set at a relatively high level for scope and costs, with the lowest level being activity group within a contract. For lower levels the data was maintained in the main contractor WBS. Developing the Crossrail WBS to lower levels would have given an improved audit trail at a cost of greater complexity and investment in systems.

The Crossrail baseline documents were at a high scope level. This reduced the change control administration required, but allowed significant design development to take place without onerous scrutiny through the Programme Change process. Design change was classified as a Programme risk, and design change processes were in place which required that design change after approval gates should be referred to Programme Change. This did not always take place until after the design decisions had been taken, resulting in the opportunity to influence decision making being lost.

The schedule was not cost loaded, and the phasing of cost budgets and forecasts was developed manually.  This was to allow the Crossrail planning team to concentrate their efforts on managing the integrated schedule, rather than in cost profiling. Short term forecasting accuracy was monitored as a KPI through the commercial assurance function.

Recommendations for future projects

Agree an integrated control baseline as early as possible, and ensure alignment between scope, cost, schedule and risk in order to provide a basis for the management of change.

A decision on whether to cost load the schedule will need to be taken considering the requirements of funders. The criticality of accurately time phased cost forecasts will need to be considered against the resource (systems and people) required to maintain a valid cost loaded schedule.

Ensure the Work Breakdown Structure is established at an early stage. The WBS should be managed centrally and be replicated consistently across different systems.