Introduction and industry context

Change control against an established baseline is a key project management process. The Crossrail process for controlling Programme-level change is set out in the Change Control and Budget Management Procedure and summarised in this micro-report.

CRL approach

The Crossrail Programme Baseline of scope, cost and schedule was established for the Sponsors’ final Review Point, as outlined in the micro-report on Programme Baseline Management. The Baseline was defined as:

• the suite of high-level scope documents, including the Scope Book and the Programme Functional Requirements
• the Standards Baseline
• generic sections of the contract Works Information which applied across the Programme
• Schedule anchor milestones
• The Programme level control budget – other than budgets delegated to Crossrail managers via the contingency management process.

The Programme Change Control process was established to control changes to the Programme Baseline. The objectives of the process were:

• To alert Crossrail management to early indications of potential variance to the current baseline during the execution of the projects, and allow corrective action to be identified and implemented.
• To apply strong governance to the allocation, expenditure and return of Programme Contingency, whilst providing timely and sufficient access to Programme Contingency to those managing delivery risks.
• To establish budgets including contingency which were affordable within the funding envelope and represented value for money.

The Baseline of scope and cost has remained in place from the final Review Point in March 2011 to date. All changes to high level scope, and all changes to budgets other than draw down of contingency budgets delegated to the Project Managers, have been made through the Programme Change Control process.

The schedule was normally re-baselined annually, at the start of the financial year on 1 April. The Programme level schedules included a relatively small number of critical milestone dates; the anchor milestones. Between schedule baselines, the anchor milestones were subject to Programme Change Control.

Top down scope / design change

Where scope changes required by the Sponsors have been made, the Sponsor change process in the Project Development Agreement was followed. This is a formal process of notification and appraisal, culminating in a Sponsor instruction in templated form which identifies whether any further Sponsor funding is to be made available. Sponsor changes were then processed through Programme Change, which allocated funding from Programme contingency to the relevant Project within the cost breakdown structure.

Any other scope or design changes required by the central Crossrail technical authority were similarly progressed through Programme Change.

The aim of the process is to protect delivery Projects from unfunded external change.

Programme change approval process

A structured approval process was established.   Proposed changes were captured on a standard template which was designed to define the issue and the impacts to cost, time and safety in a concise manner.  A dedicated team within Programme Controls performed quality control through a structured review process to ensure scrutiny and buy-in from all relevant internal disciplines and stakeholders. Authority to approve Programme Change was vested in a dedicated Sub-Committee of the CRL Board, which met bi-weekly.

While the major procurement stage was in progress, there were two key governance Sub-Committees, one to control procurement, and one to control investment approval and change. In the latter stages of the Programme these were combined into one Commercial and Change Sub-Committee. This enabled the key commercial change and budgetary decisions to be taken in one forum, with appropriate senior management attendance.

Change Systems

The Prism cost management IT system was key to the successful capture, processing, approval and recording of change.

The first step in the change process was the raising of a trend within the Prism system. A trend process has been used on a number of major programmes;  the Crossrail innovation was to embed the trend process in the IT systems as a change management record. A trend describes the issue and captures the assessment of cost and time impact.  It also captures control data including the control account within the cost breakdown structure. This defines the approval route for the trend within the organisation structure.  The cost system routes the trend for approval according to levels of delegated financial authority approved by the Board for post holders in the organisation.

An unapproved trend is “unresolved”, and the expected impact of Programme outturn cost was taken account of in the evaluation of risk.  Once a trend is approved, “resolved”, the cost was incorporated in the anticipated final cost of the relevant section of the cost breakdown structure.

A set of trend categories was defined to record the source of the change. Examples include: design change, ground conditions, and third party action. The risk management framework defined which risks were to be owned by which levels in the organisation structure: Project, Sector or Programme. The trend category followed the risk matrix and therefore determined the funding source (Change Control and Budget Management Procedure section 6.1).

For example:

• A Cost over-run would be classified as a Project risk, to be funded from Project contingency
• Interface between Projects in a Sector was a Sector risk
• Design change was a Programme risk, so a trend raised for design change represents a potential Programme Change.

Risks reserved to Programme included:

• Design change
• Major schedule change
• Catastrophic risks
• Over-site property development
• Global approvals from Infrastructure Managers or Industry partners, including Standards change.

Programme changes were recorded in a change log under a referencing system, covering change proposals submitted, and approved changes. Once approved the budget changes were processed in the Prism system by the central Programme controls team under a unique transaction type, referencing the change approval. Hence full audit trail was maintained.

The attached graphic (Figure 1) from section 4 of the Change Control and Budget Management Procedure summarises the process routes for changes.

Figure 1 – Change Management Process

Lessons learned

There was a single Programme Change process, which controlled change to both high level scope and to the Programme budget. There was a single change approval committee, which was Sub-Committee of the Crossrail Executive Committee, ensuring appropriate senior level scrutiny of changes. This Committee also exercised commercial authority.  Programme level governance and process was simple and well aligned.

Risks were allocated to the different levels of the organisation, and contingency budgets allocated accordingly.    So Project Managers were incentivised by limited budgets to identity issues defined as Programme risk and escalate these with a funding request through the Programme Change process. Accordingly issues such as design change were escalated to the appropriate senior level in the organisation.

However, at times there was difficulty in evaluating the impact of the smaller design development changes which occur at Project level. In some Projects there has been a relatively high volume of these changes to designs. In a limited number of cases this led to Programme Change approval being given retrospectively, after amended designs had been issued.

The trend process systematised the capture and recording of change, and had the potential to provide a detailed audit trail of the cost and cause of individual changes. The quality of system use at Project level varied, with some Projects recording changes at a good level of granularity, while others trended cost increases at a higher level with little causal breakdown. It would have been advantageous to mandate the level of detail required in Project level change logs and train cost staff accordingly.

Recommendations for future projects

Set up a process to capture and evaluate changes to designs and specifications at or before issue – identifying the cause of the change, the estimated cost and time impact, and the contractual entitlement. Designers should be required to maintain design change logs including an assessment of the impact of the change. Consider the appropriate level of granularity for design documents which are to be baselined. Where design change takes place at lower levels, ensure that governance processes are effective. It might be beneficial to require approval of the issue of new design documents by a team with appropriate expertise in cost and time estimation as well as the relevant engineering disciplines.   However the resource and time required to operate such a process would need to be balanced against the benefits in terms of improved predictability of cost and time.

Establish a formal process to control changes required by Sponsors or other external stakeholders to include impact analysis and identification of funding. Link this to the Programme’s internal change control process, such that top down changes are formally allocated to the delivery organisation with budget.

Support change control with IT systems to provide workflow, authority control and audit trail. Ensure the link to the work and cost breakdown structures.

Establish formal change approval structures, including authority meetings at frequent intervals with appropriate senior attendance.