Skip to main content.

Learning lessons where organisations intersect

Introduction

Most of us are familiar with fishbone or Ishekawa analysis, using a structure like Figure 1, as a technique for recording causes, identifying lessons and developing action plans for improving outcomes. This simple form of root cause analysis is successful because it imposes a structure on thinking about what, when and where a success or failure has occurred.

This case study demonstrates a different but equally simple structure used for the same purpose, to look back at what happened in a completed project and develop recommendations to ensure lessons were understood, disseminated across the organisation and improvements were ‘locked in’ for future projects of a similar kind.

Figure 1: Generic fishbone structure

Background

The project

The project involved the construction of underground road tunnels in an urban area. Part of the route passed below an important underground railway corridor, not far from an underground station complex and transport interchange. The focus of this case study is the interface between the construction of the road tunnels and the existing rail assets, outlined in Figure 2 and Figure 3, and the inter-relationships between the organisations involved.

Figure 2: Project schematic – plan

Figure 3: Project schematic – elevation

The organisational interfaces were very important. Some of the main organisations were:

  • The Government rail agency RailA that owned the rail assets, which was the client for the work described here
  • The Government road agency RoadA that had commissioned the road project
  • The construction company RoadCo contracted to build the tunnels and roads
  • The state Government that was the ultimate funding and approval authority
  • The municipal council that had statutory authority over some aspects of planning and development consents.

The importance of the railway and the risks associated with nearby construction were recognised at an early stage of the development of the project concept and governance structure. In particular, an oversight committee was established for the project, with representatives from the state Government and senior members of the teams with direct accountability for the project in the road agency, the rail authority and, after award of the contract, the construction company.

Purpose of the post-completion review

The review was a component of the rail agency’s formal Project Completion Report. It specific purposes were to:

  • Identify what the rail agency did well in the project, and what it could have done in a better way
  • Investigate the root causes and describe the main lessons learned
  • Develop recommendations to ensure the lessons and associated improved ways of doing things became standard practice for future, similar projects.

Analysis and outcomes

Structure of the analysis

Figure 4 illustrates the structure of the analysis. The description in this case study is concerned with the preparation and workshop phases, to the point of developing suggestions for the future in the form of specific recommendations. The development and implementation of action plans was a later task for the rail agency.

Figure 4: Analysis steps

Preparation

It is in the interest of all concerned that workshops should be effective, so they generate the desired outcomes, and efficient, so they make best use of resources and don’t waste people’s time. In our experience, detailed preparation is the key to this.

Preparation was particularly important here, as there were many project documents. Taken together, they provided some of the information required for the workshop but not all of it, and much of it was not directly relevant. We followed an iterative process, rather more explicitly than usual, to collect the information needed:

  • We conducted an initial scan of the project documents and developed an initial set of topic areas that seemed important
  • We discussed the topics with the project manager and senior project personnel, and agreed an outline priority sequence for them
  • We reviewed selected project documents in more detail and conducted interviews, attaching key extracts and notes to topic headings in an information summary
  • After a further review with the project manager, we finalised the topic structure and the information summary in the form of a briefing note for participants in the workshop.

The topics are outlined in Figure 5, with the main components (sometimes called key elements) of the first topic shown in more detail to illustrate the structure of the information. The structure indicated:

  • The sequence in which the five main topics would be addressed in the workshop, numbered in Figure 5, as the basis for the workshop agenda
  • Specific priority elements for detailed discussion, marked with a tick
  • Related elements that might be relevant for the discussion, marked with an information icon.

Figure 5: Workshop topics

Lessons learned workshop

We conducted a one-day lessons learned workshop. Participants were members of the rail agency’s project team, selected specialist advisers, a workshop facilitator and a workshop recorder.

During the workshop, topic areas that reflected key aspects of the project were considered in turn. For each topic, the participants were encouraged to:

  • Provide their observations about the topic area and the way it was addressed, from inception through to completion of the project
  • Discuss the strengths and weaknesses of the approach adopted and any conclusions to be drawn
  • Develop recommendations for future projects of a similar kind.

The discussion was recorded in a template like the one in Figure 6.

Figure 6: Recording template

Workshop outcomes

The workshop examined 23 priority topics drawn from the expanded version of Figure 5, but not all of them generated useful lessons or recommendations. There were 39 specific recommendations, with supporting information in the form of completed data templates like Figure 6.

Table 1 and Table 2 illustrate the kinds of outcomes generated in the workshop and the level of detail of the discussion.

Table 1: Analysis of Appendix 99, Rail requirements

Observations

Discussion and conclusions

Intentions:

  • To ensure that prevention of adverse impacts on rail assets and railway operations was a priority
  • To generate mandatory specifications and standards to be met and hence provide certainty to RoadCo about the expectations of RailA
  • To provide clear technical standards in a written form, something that had not been done previously in a formal way
  • To provide a clear definition of RailA’s technical requirements in advance, i.e. taking a proactive rather than a reactive approach

Implementation:

  • An outline framework was developed, documenting the technical requirements that needed to be achieved and monitored, with acceptable limits for them
  • Implementation was difficult, as it was an unfamiliar process for RailA

Outcomes:

Appendix 99 of the project agreement achieved what was intended

Strengths, what went well:

  • The collaborative effort between RailA and RoadA helped to ensure that an appropriate level of scrutiny was applied
  • Some personnel had experience in similar types of projects
  • A contractor was engaged to manage RailA’s risks associated with project construction and monitoring
  • A new approval mechanism was developed for Rail Safety Plans
  • Appendix 99 did not change during negotiations
  • Appendix 99 was effective and appropriate
  • Quality standards assisted in uncovering issues not otherwise identified (e.g. potential effect of placement of rock bolts on future rail projects)

Weaknesses, areas for improvement:

  • The size of the task was not recognised initially
  • The multi-disciplinary team, with a wide range of interests, was not organised quickly enough, and the right levels of management were not engaged early enough
  • Providing detailed technical inputs for Appendix 99 was difficult and took a long time
  • Initial technical tolerances and limits were not being met in current rail operations and so were not always appropriate

Summary:

Overall, the effort generated a good outcome with wider application

Recommendations

Appendix 99

Recommendation 1

Develop Appendix 99 into a standard document for RailA to use as a template for future projects, and review it from time to time

Recommendation 2

Review the technical standards that were defined in Appendix 99 to re-evaluate their effectiveness and appropriateness for a particular project depending on the conditions

Recommendation 3

Ensure the RailA project budget includes time and resources to develop and review Appendix 99 or its equivalent in the early stages of a project

Recommendation 4

Ensure that compliance with Appendix 99 or its equivalent is included as a contractual requirement in similar future projects

Regulations

Recommendation 5

Incorporate the requirement to take account of rail requirements into municipal planning instruments, legislation and other mandatory controls

Recommendation 6

Where possible and relevant, ensure RailA’s interests are included in development consent conditions

Table 2: Rail Safety Management Plans (RSMPs)

Observations

Discussion and conclusions

Intentions:

  • To ensure that RoadCo took the issue of rail safety seriously
  • To force attention on key safety matters at appropriate times
  • To ensure the RSMPs incorporated the requirements of Appendix 99
  • To give RailA absolute discretion on rail safety matters
  • To define the process for inspections and activities and establish alert and stop work limits within the rail corridor

Implementation:

  • An engineering assessment and specified monitoring requirements were provided
  • Monitoring processes were developed and fully implemented for the project
  • An expert panel was established to monitor the development and implementation of RSMPs and advise about rail safety requirements

Outcomes:

The RSMPs achieved the intended outcomes

Strengths, what went well:

  • RSMPs were tailored to the construction methodology for each interface between rail and the project
  • There was no need to have all of the RMSPs done at the same time, only when necessary for the project program
  • RoadA included a Condition Precedent in the Road Project Agreement that required RoadCo to prepare an initial RSMP approved by RailA
  • Having an approved initial RSMP gave some certainty to RoadCo about what future rail safety plans would contain
  • RailA had power over rail safety matters and used it responsibly
  • The RailA process for administering rail safety was robust
  • RoadCo engaged a consultant that understood the railway environment

Weaknesses, areas for improvement:

  • RailA failed to communicate adequately to RoadA and RoadCo the lead times for rail possessions and access

Recommendations

Recommendation 7

Make the preparation of an initial Rail Safety Management Plan a Condition Precedent for any particular project that might interact with the rail system

Recommendation 8

Ensure RailA has the resources to administer rail safety matters and interact with the contractor throughout the project

Recommendation 9

Develop monitoring processes into a standard format that can be used and tailored for other projects and implemented in an economically sustainable way

Lessons

Value of post-completion reviews

Post-completion reviews offer many benefits to the organisations that conduct them. They facilitate the identification of what went well and what could have been done in a better way, and why those outcomes arose. This leads to actions targeted at improving outcomes for future projects, by locking in the precursors or causes of successful results and avoiding or reducing the causes of poor results.

All of the organisations involved in this project could have benefited from a review like this one. We were working with the rail agency, but the road agency and the road contractor would have benefited from similar reviews within their own organisations; they may have done so, but we have no knowledge of this.

The outcomes of this review, and particularly the outcomes relating to rail safety, were important for the rail agency. It had specific statutory obligations for safety under its enabling legislation, a feature that is common to rail organisations in many jurisdictions. Almost all of the technical requirements in Appendix 99 had their basis, in some form, in the need to ensure the safe operation of the railway.

Workshop topics

The topics identified in Figure 5 were valuable for structuring the workshop. As well as setting the agenda and timing, they shaped the participants’ approach to the discussions. They focused initial attention on governance, contract structure and relationship matters that would have general applicability to many projects like this one, and only later getting into technical engineering detail that was more specific to this particular context.

Not all elements generated useful observations, lessons and recommendations.

  • After discussion, some elements turned out to be less important than initial analysis suggested or members of the team had thought. Nevertheless it was important to have reviewed them, to ensure a comprehensive approach and avoid inadvertently missing anything that might have been important.
  • As anticipated in the notes for the major topics in Figure 5, some of the detail associated with later elements had been covered already in the discussion on earlier ones.

Lessons learned process

Fishbone or Ishekawa analysis, in a format like Figure 1, and cause and effect trees, are common approaches to recording root cause analyses, from which lessons learned can be derived. There are a number of reasons that these approaches are useful:

  • They are participative processes, involving people having knowledge and understanding about the topic being analysed
  • They impose a structure on the way the participants think
  • They allow facts to be recorded within a framework of some kind, a simple set of categories for fishbone analysis or with more detailed linkages and relationships for cause and effect trees
  • Neither one generates lessons directly, although cause and effect trees allow root causes to be identified explicitly in a way that allows lessons to be extracted more easily from the analysis.

The process described here, and outlined in Figure 4 and Figure 6, also provided a structure for thinking and recording information about the topics of interest in a participative, facilitated process. Figure 6 is a simpler template than a fishbone like Figure 1, but it served the same purpose of structuring and recording the workshop discussion. It was a fit-for-purpose simplification in this case:

  • It was not necessary to drill down into the fine detail of root causes in every case to arrive at meaningful lessons and associated recommendations
  • It allowed a broad span of 23 topics to be addressed in a one-day workshop, without rushing or compromising the discussion
  • It allowed 39 specific and useful recommendations to emerge from the workshop and be agreed by the participants.

The chosen recording structure here was not a default or lazy option. It arose from a deliberate decision, made jointly by the facilitator and the project manager.

Comparison with the international standard for RCA

It is instructive to note that the process used here, illustrated in Figure 4, is broadly comparable with the generic steps in a root cause analysis advocated by the international standard IEC 62740-2015 Root cause analysis (RCA), illustrated in Figure 7. (Note that IEC 62740 was published after the case study described here.) The steps in each process align, as shown in Table 3, but IEC 62740 stops after the presentation of results, whereas the process we used includes the development of action plans that ensure the workshop outcomes, recommendations in our case, are the focus of targeted implementation efforts. Unless action is taken, the analysis can have little value to anyone other than the workshop participants, and that may be only fleeting.

Figure 7: RCA process, adapted from IEC 62740

Table 3: Comparison of process steps

This case study, Figure 4

IEC 62740-2015 Root cause analysis (RCA), Figure 7

Review the activity and its outcomes

Develop a set of topics to be examined

Step 1. Initiation

Document the key observations

Step 2. Establishing facts

Discussion and conclusions

Step 3. Analysis

Step 4. Validation

Suggestions for the future

Step 5. Presentation of results

Develop and implement action plans

Outcomes

This case study generated 39 recommendations in a one-day workshop. There were several reasons for the successful outcome:

  • The early preparation was vital, to sift through and select relevant information for the workshop, to develop the topic structure in Figure 5 and to prepare and issue a briefing note
  • The workshop participants were selected for their ability to contribute to the discussion, they were well prepared and they were disciplined in their approach to the review
  • The workshop was led by an experienced facilitator, with a recorder to capture the discussion in the template structure
  • The participants had a high-level view of the rail agency, the road agency and Government processes, so they were able to generate and agree quickly on recommendations arising from the project that would be general enough to have wide applicability, would be feasible to implement within foreseeable organisational and commercial structures, and would be seen as sensible by all parties.
Client:
Government rail agency
Sector:
Roads and highways
Rail
Services included:
Independent review
Root cause analysis
Project risk management