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.
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.
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.
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.
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.
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.
Observations |
Discussion and conclusions |
---|---|
Intentions:
Implementation:
Outcomes: Appendix 99 of the project agreement achieved what was intended |
Strengths, what went well:
Weaknesses, areas for improvement:
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 |
Observations |
Discussion and conclusions |
---|---|
Intentions:
Implementation:
Outcomes: The RSMPs achieved the intended outcomes |
Strengths, what went well:
Weaknesses, areas for improvement:
|
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.
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