Introduction and Industry Context

On Crossrail, the performance measurement regime was designed & developed to draw on the granular performance data provided at control account level. A data warehouse was also implemented to capture all performance data to act as the ‘single source of truth’ and electronic dashboards were used as a business intelligence tool. These tools enhanced the quality of data and encouraged proactive behavioural change.  This paper should be read in conjunction with Crossrail’s Performance Measurement Procedure.

Crossrail Approach to Earned Value

The aim of the Crossrail performance measurement regime was to provide a comprehensive, consistent, timely and reliable view of the programme’s performance that predicted performance, and triggered management action to positively influence the outcome. Earned Value (EV) was one indicator of performance and was used in the context of other meaningful indicators of performance.

The majority of the required performance measures were collected through established information collected within data systems. However, for Earned Value, a level of agreement was required between Contractor and Client to agree:

• The time profile and breakdown of budgeted cost against work scope
• What was measured and how
• The method for ‘earning’ completed work
• What person-hours are considered against what Indicative Units.

The Project Manager was responsible for establishing how Earned Value (EV) would be measured at Contract level in discussion with the Contractor. The Contractor was then required to submit an Earning Plan for acceptance within 4 weeks of the starting date, as part of establishing the Baseline Accepted Programme.

For Crossrail, the scope of works on a Project (comprising one or more Contracts) was modelled against a Work Breakdown Structure (WBS) which comprised Work Packages with one or more Activity Groups each of which had one or more Activities. Typically, a Work Package equated to a single Contract. Each Activity would typically map to many lower-level ‘tasks’ in the Contract schedule. The measurement of EV at Programme level was calculated from that reported and assessed at Contract level.

Figure 1 – Periodic reporting of EV figures against WBS

As work on the Contract progressed, assessment was made each period on two aspects:

• The % Progress corresponding to the agreements made in the Earning Plan
• The actual cost of the works in accordance with the Earning Plan.

Contingency (both Project- and Programme-level) only contributed to Contract- and Programme-level performance measures when it was drawn down into the Contract-level Current Control Budget (CCB). In other words, value was not earned, and actuals were not recorded against contingency, unless it was drawn into this budget at contract level.

Recording of actual performance was provided through the introduction of a common cost system. As part of the periodic reporting:

• The Contractor was responsible for reporting performance in line with the agreed methods for EV and Productivity. The percentage complete was calculated objectively, based upon installed quantities through the use of the QURR (Quantity Unit Rate Report).
• The Project Manager was responsible for assessing the Contractor’s reported performance and implementing revisions for inclusion in the period reports as deemed appropriate.
• The Programme Controls assured submitted data, and supported the projects teams through the provision of guidance documents and the standardisation of processes and approach.

The decision was also made that the main integrated programme would not be cost loaded, in order to free up the capacity of programme-level planners to assist in the planning of activities, rather than focusing on cost spreads. Contractor’s working schedules were cost loaded in order to inform the contractor’s periodic progress dashboard.

Data Warehouse and Electronic Dashboards

Performance data from a variety of systems was integrated into a data warehouse as shown in Figure 1 to enable quick interrogation and analysis to support management decision making processes. The data warehouse also acted as the ‘single source of truth’ with regards to performance data, meaning clarity was maintained. Earned value data was captured within PRISM.

The data warehouse represented the datasets as flat data files, meaning data could be interrogated easily in standard Microsoft Office applications. The flat nature of the data files also provided the opportunity to build dynamic electronic dashboards to further enhance communication, which could also be accessed from mobile devices.

Figure 2 – Crossrail Programme Controls Toolset

Lessons Learned

• Although contractors were responsible for determining the earning methodology for the contract, this led to inconsistencies in the methodology for common elements of the work breakdown structure – especially those elements outside of the coverage of the QURR such as preliminary items, risk and fee. In these cases, the Programme Controls team had to provide additional guidance, and prescribe earning methodologies to improve the consistency and integrity of the dataset
• Cost performance and schedule performance indices were adversely affected by the impact of unresolved change. For example, where project manager’s instructions were issued for works to proceed without the cost and schedule impacts being agreed, the contractor would incur cost in progressing the newly instructed works, without the ability to earn the value against budgets. To mitigate this, ‘what-if’ scenario modelling was established across key contracts to ascertain the true cost and schedule performance indices by estimating the impact of unresolved change.

Recommendations for Future Projects

• Time should be dedicated during the set-up phase to establish and agree the management information requirements, for both the internal management team, as well as external stakeholders in order that data requirements can be established
• The programme controls toolset should be designed based upon the agreed management information requirements
• The use of standard software applications provides the benefit of automatic upgrades from the software developers
• Consideration should be given to the link between earned value and governance – e.g. governance processes to approve additional budgets for change items may affect cost and schedule performance