Introduction and Industry Context

The work breakdown structure (WBS), in programme and project management terms is a deliverable-oriented decomposition of a programme or project into its smaller components. The WBS is the key deliverable that organises everything into manageable tasks and is perhaps the most important mechanism to understanding how, on a programme of the scale and complexity of Crossrail, the work is actually packaged up and delivered successfully.

Story

The scale and complexity of Crossrail has driven a programme built around the successful delivery of 35 individual major projects. As with all transport infrastructure development, the challenges evolve through the life of the programme, beginning in the early planning stages, dealing with land acquisition, getting the design concepts finalised before actually commencing detailed design and construction. Once construction has started, the challenges then move with the sequence of works, beginning with the heavy civil engineering before evolving into a systems integration programme and then finally, the testing and commissioning of the new railway.

Figure 1 – Complexity of a Crossrail station

In planning terms, the first priority for Crossrail Ltd (CRL), before any contracts could be procured, and alongside the design of the organisation itself, was to build and implement a coherent WBS that would form the backbone of how the programme would be packaged and delivered. The WBS was created by CRL and applied across the entire programme, forming a fundamental component of the contractual CRL Works Information document. It was envisaged that all parties responsible for direct works delivery would use the WBS consistently across their respective work scopes and data tool sets.

Figure 2 – Crossrail Hierarchy

The WBS is owned and maintained by CRL in conjunction with the Programme Delivery Partner. Identified below is the hierarchical structure for the CRL WBS:

• Level 0 – Crossrail Programme
• Level 1 – Geographical Area. (Switched to Sector Disciplines at 66% complete)
• Level 2 – Industry / Delivery Partner
• Level 3 – Asset type
• Level 4 – Location
• Level 5 – Function / Phase
• Level 6 – Contract
• Level 7 – Activity Group
• Level 8 – Activity

The process for agreeing the WBS was essentially led by the Head of Programme Controls, in consultation with all relevant functions around a basis desire to be able to track performance at a granular level across the whole programme. But it was recognised early on that some simple practical considerations would drive the team to an early adoption of a high-level geographical split between works in the west, centre and east of the programme. The figure below illustrates how splitting the programme into three geographical areas meant that each Area Manager could oversee works of a similar scale e.g. each section would have a minimum of two tunnel boring machines (Ada and Phyllis in the West, Elizabeth, Victoria, Ellie and Jessica in the Central section and finally Mary and Sophia in the East) and a reasonable split of the new stations to be built, with four stations in the West, three in the Central section and two in the East.

Figure 3 – Geographical split

Lessons Learned

Some of the key issues included:

• Aligning the procurement strategy to the WBS. Whilst CRL did procure the works in this fashion, we have still identified this challenge as it is a mistake that many projects routinely make in the procurement of their works.
• Building a Cost Breakdown Structure (CBS) that reflected the WBS. In the early phase of the programme, this was not completely aligned and so a separate exercise to realign Crossrail’s cost structure was needed.
• Bringing the projects up to speed with their understanding of the WBS and the importance placed on complying with the designed code structure within it. Throughout the life of CRL, we have tried to maintain a strict policy of adherence when project teams have wanted to vary away from the set structure, and in some cases projects have not complied with this, opting instead to adopt their own preferred structure at the lower levels. With the benefit of hindsight, we feel strongly that this should not have been allowed to happen and that the Central Programme Controls Team should have maintained control of all levels of the WBS and subsequent control accounts within the cost management system (PRISM). The variances that did occur resulted in challenges in making good cost comparisons across various elements of the works before this was resolved.
• Recognising when is the right time during the programme to evolve the WBS e.g. the shift at Programme Level to focus on disciplines (Sectors) instead of geographical “areas” was made whilst the Systemwide contracts were still ramping up. The switch happened in conjunction with an organisational change to ensure continuous alignment between the organisational breakdown structure (OBS) and the WBS. Making this switch was the right way to recognise the fundamental shift in the physical works on site, with much of the heavy civil engineering (tunnels, excavation, sprayed concrete etc.) completed and the mechanical and electrical fit-out quickly ramping up.

Control Accounts were initially created with the structure following the geographical areas, then sector, project, contract and finally account type. The accounts were created manually rather than using a coding structure of unique metadata within the cost system which would set the design of the Control Account number by the codes selected.

Programme reports were then ‘rolled up’ to geographical area so the initial method for creating the Control Account was sufficient for grouping and displaying the required data. As the Programme progressed, when it was deemed necessary to report by ‘sector’ rather than ‘area’, it became apparent that ‘Sector’ had not been included within the existing Control Account structure, nor was there a coding structure in place within the cost management system to allow for reports to be grouped in this way.

The solution was to use the coding functionality of the cost management system (PRISM) to create a unique coding structure (which included a code for Sector)  and apply this to each control account. With the codes designed and applied to each Control Account, it was then possible to group the control accounts by the coding structure without altering the original Control Account number and most importantly, maintain a reconciliation with historic data.

Recommendations for Future Projects

• Plan the WBS early.
• Build the WBS, followed by the CBS and finally the OBS and ensure all three are aligned
• Don’t over-complicate the WBS
  • If possible, stick to as few levels as possible; typically up to level 3 or level 4 at most for normal standard projects

Communicate the WBS to the entire team. Show everyone how it works and how it aligns to the procurement strategy and the organisation design.