Paul: Hello, everyone. Welcome to today’s discussion. I am your host, Paul Turner, and today I am joined by David Tain. David is our Chairman of the ICxA technical committees and the Regional Governance VP for Latin America. How are you doing today, David?
David: Good morning, Paul. Thank you so much. I am doing well. I am happy to be here with you and the team. Good morning, good evening, and good afternoon to everyone watching us from around the world. I am happy to be here.
Paul: Great. Today we have a great discussion on operational readiness. That is David’s specialty, and he has spent many decades working on it across projects. For today’s discussion, David is going to walk through what we have put together at ICxA regarding the ICxA standards. This has been about two years in the making. It is the final culmination of my efforts, David’s efforts, the Advisory Council’s efforts, the entire ICxA team’s work, and contributions from industry experts around the world. Over the last two years, they have contributed global expertise across multiple countries and multiple industries.
This is really the collection and gathering of their wisdom into the three standards we have put together. Today’s discussion is on operational readiness, and David will show you what we have built over the last two years. A few housekeeping rules: we will have a Q&A at the end of the discussion. As we go through, if you have any questions about what David is presenting, please put them in the chat, and we will answer them at the end. Some of the slides we are going through have a lot of information. If you would like a copy of the slides, please send a DM directly to David Tain, and he will be able to send you a PDF copy afterward. Of course, he is also available for any questions you have about operational readiness.
With that, I will turn it over to you, David, to explain the operational readiness standards we have put together.
David: That is right, Paul. Again, thank you so much. You are absolutely right. One of the key things I want to emphasize is my gratitude to everyone who, in one way or another, has been with us along this journey. This is the result of months and months, almost two years, of collecting fragmented knowledge from around the world. One of the key mandates of the technical committee is to grow the body of knowledge by first gathering all this fragmented knowledge. This is the result of the research we have done.
These standards are built on the collective knowledge of professionals from multiple industries and from extensive feedback. I want to thank and congratulate everyone involved because this is a global milestone for operational readiness and the whole industry. I could not be prouder of it, and everyone who contributed to this important milestone in one way or another should be proud as well. The first and most fundamental question is: why do we need a standard? It comes from the fundamental distinction in projects between delivering a project and being ready to operate.
As we advanced our research and asked different corporations and industries what operational readiness means, we found a lot of interpretation depending on the industry, the type of project, and other variables. There is significant inconsistency, and that exposes organizations to risk.
Essentially, there is no common language and there are inconsistent approaches to what this transition should look like. There is also a strong focus on completion, which eventually leads to poorly managed transition risk. Those risks often emerge at the last minute, when they are least expected. They put organizations in a reactive position instead of allowing them to have visibility and control. That is also the product of limited assurance, which is something the standards emphasize strongly. The consequences are the ones we normally see in projects: rising costs, ramp-up delays, production targets not being met, and credibility issues. The most important consequence for me is safety. There are things you can recover from, but when you have a fatality, that is irrecoverable.
Operational readiness is a major mitigation mechanism to avoid situations that can be unrecoverable not only for the company, but also for the people. That is why we decided the industry needed a global standard. We embraced that ambitious journey for almost three years, gathering the best possible knowledge from around the world and distilling it into one standard.
David: The standard is essentially composed of four key documents. The first is 2200, which describes the “why” and the “what.” It establishes the foundation and the key concepts needed to understand what the standard is about. The second document is 2201, which contains the mandatory requirements. This is the document that prescribes what is required and defines what is needed to plan, assess, assure, and decide exactly what operational readiness capabilities are required for the project and for the transition itself.
We also have 2202, which is the vocabulary. This is important because it establishes a common language for operational readiness across the industry. We must remember that this is an industry-agnostic standard.It is applicable and scalable across industries. That was the reason for launching the research program: to gather knowledge from around the world and across industries. Finally, we have 2203, which provides guidance and implementation examples. This is a guidance document and an annex that explain how the standard can be applied in particular situations and what items should be considered when deciding where to start.
Together, these documents form a fully harmonized framework. Operational readiness now means establishing a common definition of demonstrated capability. This is important because the standard moves the industry from a prescriptive documentation approach to a capability-building approach. When we gathered all these approaches from around the world, we were able to distill them into four core organizational capabilities: people, the organization itself, processes and systems, and the technical asset. The goal is to build the capability to safely, reliably, and sustainably perform the intended operational outcome. This is the main differentiator between a fragmented approach within organizations and a true capability-building mechanism. With these standards, we intend to go beyond completion.
We are strongly establishing the evidence base for risk-informed decisions. We are making sure that the evidence is present, traceable, and adaptive. It is scalable to any project in any industry. That is one of the key attributes of the approach we adopted while building the standard and gathering the knowledge. We were able to distill it into these four core capabilities. Speaking of that, we also have the conceptualization. As Paul mentioned at the beginning, we are more than happy to send the slides because there is a lot of information in them. One of the key things we wanted to make sure people understand is how this is conceptualized and what the theoretical backbone of the standards is. We have defined states of readiness to ensure this becomes a capability-building mechanism.
We define the operational life cycle in three readiness states: awareness, preparedness, and readiness. These states show how mature the data, information, and approaches are across the four core organizational capabilities. Essentially, we connect what must be true, meaning the level of maturity across these three readiness states, with what must work together to deliver outcomes. That is one of the key items ICxA is trying to emphasize through the standards. This is not simply a collection of knowledge. It is a structured theoretical process that supports all the knowledge we were able to collect into one document. Another key point is the importance of front-end work. This translates the idea of readiness and the idea of transition into actual implementation. The standards therefore emphasize the definition of the readiness envelope.
That also leads to the creation of the readiness charter, which establishes the governing intent, and ultimately to a well-controlled operational readiness plan. We move from clarity of scope to governance and accountability, and ultimately to a mechanism that allows us to control execution and the transition to operations. Everyone talks about the importance of bringing readiness into the front-end phases of the project. The standard emphasizes that and puts a clear structure around the front-end work that must exist in the readiness effort.
David: Another important point is that, across the life cycle, we structure how the readiness effort should flow from the beginning. That starts with the front-end work and the definition of the criteria. It then moves toward the required evidence and the establishment of appropriate controls. The purpose is to assemble traceable and relevant evidence that is verified. This is very important because it becomes the backbone of what readiness will look like at the moment of transition, when the project moves from a controlled environment into live operations, where everything can start changing quickly.
The evidence we control is what develops the integrated capability status across the four main capabilities of the organization. That allows us to determine the readiness risks ahead of us and, ultimately, allows the readiness leader and readiness organization to recommend how to proceed, whether to proceed, what the risks are, and what items need to be resolved before transition. Ultimately, this is a risk-based decision-making mechanism. It provides sufficiency of evidence and ensures that the organization understands the readiness status and level of each of the four capabilities. Through the standard, we make sure risk is a clear mechanism for identifying decision-relevant risks, as well as the required conditions and mitigations.
This is important because we are using a capability-building mechanism. The standards are intended to move the industry away from what it has been failing at: creating indiscriminate project-specific and prescriptive checklists. Each project will have checkpoints, but a standard should never simply be a checklist. It should guide how to transition and how to build the capabilities that ensure projects and organizations know what they are receiving, know what they are facing, and identify the risks they will encounter as soon as a project goes live. That is one of the most important things we want to emphasize. The standard is not a checklist. It provides a governed transition to operations. Through the standard, we define key governance components, including evidence management, what the readiness review should look like, and the criteria for operational acceptance.
It also defines the credibility and confidence that the operating organization should have based on risk management, the key role of independent evaluation, and what authorization should look like based on each organization and the characteristics of each project. The whole intention is to make sure that, when we transfer a project, it is under full control. We know what is ahead, and we have full accountability and knowledge of the risks for the safe, sustainable, adaptable, and reliable performance of the asset. It is governed by outcome assurance principles, which are also defined by our standards and our Level 3 standard. It is outcome-focused. That is one of the key premises behind the creation of this global standard.
David: What does this change? Globally, as I mentioned at the beginning, this is a milestone for the industry. To the best of my knowledge, based on the research we have done through ICxA and on years of practice outside ICxA, I have not seen anything beyond fragmented standards for specific industries. This is the first standard built for operational readiness, and it is a defining milestone at a global level. I cannot thank enough all the contributors, researchers, and professionals around the world who helped integrate this into one standard.
We are establishing a common language and consistent requirements to ensure decisions are properly governed. There are several implications for projects. The standards provide clearer readiness and stronger delivery. They support more predictable delivery and better project outcomes. For the project itself and the operating organization, the impact is strong. We can talk about readiness teams and readiness assets, and we can decrease the risk of how assets are received. The impact is stronger start-up and faster, more predictable stabilization of operations.
That is one of the key things we want to ensure: that both the project and the operating organization experience a robust transition. But there is something even more important for the profession itself. We are trying to set the stage and provide an avenue for one standard that gives global recognition to the profession. With this, the institute provides greater guidance, greater professional credibility, and global influence across industries. This is more than a set of standards. I was reflecting on this when preparing the slides: this is the global foundation for the discipline of transition to operations.
That is something we should all be proud of. I am thankful for the privilege of working with professionals around the world, integrating this work with you, and seeing the end result. I am looking forward to the next revisions, the learnings, and the implementation of these standards around the world.
With that, thank you. I want to thank you again, Paul, and hand it back to you.
Q and A
Paul: Thanks, David. That was excellent. Again, anyone who wants a copy of the slides can send David a DM on LinkedIn directly, and he will be able to send you a PDF copy and answer any questions you may have. For anyone who would like to see the standards themselves, you can go to icxa.net. There is a link at the top of the homepage where you can access a preview copy of the ICxA standards. We want to get these standards into the hands of as many people as possible. Go there, and at no cost you can get a preview copy. Enter your name and email, and we will send you a copy right away. That gives you the operational readiness standards, as well as the commissioning standards and the outcome assurance standards. You can see the entire suite on governing projects from completion to an operational system. Definitely check that out.
We have some time for Q&A, and I am going to get things kicked off with a few questions for you, David. For anyone watching live, if you have any questions, this is your chance to put them in the chat and ask David anything you want to know.
Paul: In the past, I have heard you mention first-order, second-order, and third-order capabilities. You have referred to operational readiness as a second-order capability. What do you mean by the orders of capabilities, specifically for operational readiness?
David: That is a really important question, Paul, because it comes back to the conceptualization of the epistemology of readiness. When we talk about first-, second-, or third-order capabilities, we are talking about the ability of an organization to enact. When we talk about commissioning as a first-order capability, we are talking about execution and field execution capabilities. These are the capabilities that allow the organization to ensure efficiency in operations and in day-to-day activities.
Commissioning and execution are first-order capabilities. They are the ones you can tangibly see in the field and in day-to-day operations. When we talk about second order, we are essentially talking about readiness. Readiness is how you generate, improve, and create new capabilities. We are talking about how the organization can improve and adapt first-order capabilities, and how the organization can modify its resources and processes to create the capabilities needed to execute and materialize value. That is why readiness is second order. It is the capability to create those capabilities.
Finally, outcome assurance is at the top because it dictates the strategic level the organization reaches. It defines what the organization wants to achieve in the industry and what value it wants to generate for customers, stakeholders, and the industry itself. That is why outcome assurance is the third-order capability. It defines where the second-order capability should go in order to adapt, seize opportunities, and transform the organization so that first-order capabilities are executed efficiently. It is about doing the right things in the right order and ensuring that only what is required is done to generate value at the field level.
We definitely want all groups involved in project execution to progress from first-order to second-order to third-order capabilities, so that projects operate at the level required to meet objectives and deliver successful outcomes.
Paul: All great stuff, David. Next question: what is the most consequential readiness gap you see that some organizations may not be recognizing correctly, and that is impacting the outcome of their projects?
David: One of the most material things I have seen, particularly by observing differences across organizations around the world, is the lack of consistency about what readiness is. That is why we are putting so much emphasis on the standards themselves and on the front-end work of defining the readiness envelope. When you do not have the end in mind, and when you do not engage the right resources early enough in the organization, you can start facing difficult situations. These can involve the definition of roles across the project, but the most important issue appears when you are turning systems live and individual components that were expected to work in isolation start working together.
The failure modes you observe can be totally different from what you predicted during design or even during simulation. One of the key things I see is the level of improvisation. I have had the unfortunate experience of witnessing what can go wrong in projects when improvisation appears. In some projects, fortunately not here in Canada but in other parts of the world, I have seen unfortunate fatalities when improvisation occurs. You are trying to react to a live system without fully understanding how it behaves.
To me, transition to operations is the most critical stage in a project. We talk about value and early engagement, but it is only when you see the transition in action that you realize how important all the front-end actions were and why you should not reduce the effort required to ensure that the transition and residual risks are properly identified. In essence, Paul, this is risk mitigation. What we are doing here is mitigating risk and increasing predictability in operations.
Paul: Risk mitigation, of course, is the name of the game, so that we do not stack all the risk at the end of projects. When we mitigate risk earlier, we have a much higher chance of delivering successful projects at the end.
Here is a question from the comments for you, David: what are you most excited about for the future of operational readiness with the release of this standard?
David: It is interesting because there are so many things that excite me about this. It is not only one thing. It excites me to see how the industry will implement this at the field level. It excites me to see the data that will be produced as technology advances, because these standards will progressively advance as technology advances. Everyone is talking about AI and how artificial intelligence can change projects, and there has been substantial progress. We have attended different conferences and seen how this technology is advancing.
From a technology perspective, it excites me to see how transition to operations will evolve. From a knowledge perspective, it excites me that this is building from fragmented practice into a formal discipline and a professional body of operational learning across the world. It excites me to see how all this data will be integrated and cross-pollinated from projects and industries to improve not only the standard, but also the body of knowledge we are building. It also excites me to see how different industries will apply operational readiness. When I say different industries, I do not only mean project industries. It excites me to see how the finance world, for example, will implement these conceptualizations into different requirements.
Overall, what excites me is how the world is now seeing readiness as a transitional process. The world is appreciating how risky transition to operations can be beyond project completion, beyond a KPI, and beyond anything shown on a dashboard. People are appreciating how complicated things can become as soon as you push buttons and start seeing what is not working, or when an organization is not ready to receive assets. You can have an amazing process and an amazing project, but the organization itself may not be ready to receive it.
That is what excites me: the integration, the advancement of the profession itself, and where all of this is going.
David: It is interesting because there are so many things that excite me about this. It is not only one thing. It excites me to see how the industry will implement this at the field level. It excites me to see the data that will be produced as technology advances, because these standards will progressively advance as technology advances. Everyone is talking about AI and how artificial intelligence can change projects, and there has been substantial progress. We have attended different conferences and seen how this technology is advancing.
From a technology perspective, it excites me to see how transition to operations will evolve. From a knowledge perspective, it excites me that this is building from fragmented practice into a formal discipline and a professional body of operational learning across the world. It excites me to see how all this data will be integrated and cross-pollinated from projects and industries to improve not only the standard, but also the body of knowledge we are building. It also excites me to see how different industries will apply operational readiness. When I say different industries, I do not only mean project industries. It excites me to see how the finance world, for example, will implement these conceptualizations into different requirements.
Overall, what excites me is how the world is now seeing readiness as a transitional process. The world is appreciating how risky transition to operations can be beyond project completion, beyond a KPI, and beyond anything shown on a dashboard. People are appreciating how complicated things can become as soon as you push buttons and start seeing what is not working, or when an organization is not ready to receive assets. You can have an amazing process and an amazing project, but the organization itself may not be ready to receive it.
That is what excites me: the integration, the advancement of the profession itself, and where all of this is going.
Paul: This advancement is really just at the beginning, similar to past transitions. In the 1970s, safety processes were established. Through the 1980s and 1990s, quality processes became embedded in the industry.
I think you are right. People are realizing that readiness needs as much focus as project execution, construction, safety, and quality. This is the next phase of development, where readiness is established as a global discipline for delivering successful projects.
David: Something important, Paul, that we are mentioning here and that I have seen building with a lot of excitement is how this grew from a very ambitious idea a couple of years ago: the idea of a technical arm and technical research through the ICxA technical committees. It is impressive how robustly it is growing, how much interest we are getting from professionals around the world, and how the contributions to the technical arm are growing. The level of research and information we are receiving is making the technical agenda stronger.
I remember when we founded the technical committees with the main vision of gathering fragmented knowledge from around the world and translating it into something useful. In a blink of an eye, people were eager to contribute, and we were able to integrate all that fragmented knowledge. There is a lot of fragmented knowledge. As I mentioned in one of our past chats, we have a very diverse industry. We have input from the nuclear industry, from oil and gas, and from industries I learned existed only after I joined ICxA, such as aquaculture. I always mention aquaculture because our Vice President in Scandinavia, James, has commissioning experience in that industry. When you look at those perspectives, you see not only industries that you may not have known existed so robustly, but also the processes they go through to commission and transition projects to operations.
We are also getting a lot of traction in renewables, particularly in Canada and Europe, including wind projects. We have wind experts who contributed to this standard. We are progressively incorporating hydrogen projects as well. You name it. Even though there is a lot of diversity across industries, we are able to distill that everyone needs the same thing: predictable operations and risk-managed, decision-based processes. Everyone needs the same foundation.
Paul: You mentioned the interest in the standard, and there certainly has been a lot of interest, particularly in the operational readiness standard. Just in the time we have been on this call, I have seen multiple people access the standard, look for information, and reach out. We are quite pleased with the amount of interest in what we are putting together to help the industry align on delivering readiness on projects.
I have another question, and then I see there is another question in the chat. David, what do experienced project teams routinely do differently that closes the readiness gap, compared with other project groups?
David: Normally, everything comes down to the organization. I always mention this: all processes are only as good as the organizational support behind them. When I see readiness teams that are successful, it is because the organization gives them support. I want to make sure we understand that supporting is different from enforcing. When an organization goes into enforcement mode, what it gets is compliance. We are full of that. That is one of the key reasons we moved toward a capability-based approach rather than a prescriptive approach. When you design standards on a prescriptive basis, you enforce compliance. Compliance is necessary, but it is not sufficient to ensure transition.
Compliance can be used when you are completing projects, items, and tasks. But when you are moving into environments that are changing by nature, and when you are bringing live operations to life, you need more than compliance. You need capability building. You need teams not only to react, but also to predict. That comes from the organization providing the right guidance, the right tools, and the right empowerment for people. This needs to be an organization-led effort. I have seen two types of situations. One is when an organization assigns a readiness lead or readiness manager and says, “You are in charge of this. Do whatever you have to do to make sure this is ready to operate.” That is when the organization fails.
Readiness is an organizational responsibility. You need someone who integrates the effort. You need someone knowledgeable enough to integrate, produce, evaluate, and put together the programs. But ultimately, the support and endorsement of senior leadership is what makes the process successful.
That is where I see success.
Paul: Joseph has a comment here: good point about AI. I wanted to expand on that a little more. We see all these powerful tools coming our way, and we know they will be transformative and helpful for projects. But technology can only help so far. We need to scale the right model, and many project delivery models we see are focused on construction progress. The transition process is often somewhat omitted from project delivery.
AI is going to be a very powerful tool, but only if it is applied to scale the correct model. That is why we need transition and readiness to be key aspects of projects. Once the underlying structure and model are correct, AI will be a very powerful tool to scale that successful model.
David: AI is progressively penetrating many areas, and readiness will certainly be influenced by it. One area where I already see AI being incorporated and helping readiness is in simulations. Depending on the type of project, readiness requires particular tasks to ensure readiness, especially in assurance. AI is going to help assurance when you conduct tabletop exercises, simulations, and scenario planning. That is where AI can increase confidence in transition. Readiness itself will remain human-dependent. Even though it will be helped significantly by AI, it is ultimately the power of human intelligence and experience that AI does not have. That human intelligence will define how the transition should look and how it will materialize.
AI is already helping define scenarios, accelerate thinking, support simulation exercises, and support ideation sessions. It will accelerate the work and provide more platforms so human intelligence can take over and capitalize on expertise based on the data AI makes available. I see AI more as a predictive model. It will help, and it is already helping. But because transitions involve ambiguity and a predictive nature, AI can only provide probabilities and scenarios. The decision-making process is human, and it always will be.
Paul: AI will be powerful, but there will always be a human in the loop to make the final decision or provide stage-gate assurance. That is the nature of projects. People want to see that a human has made the final sign-off. AI will gather information and bring it to the human, but the human will ultimately still make the final decision, in my mind.
Next question: can a project reach transition to operations when readiness problems may unfortunately have been locked in years earlier in the project? What early decisions create these problems on projects?
David: That question drives at something that organizational theory calls dominant logic. When you study organizations at a highly theoretical level, one of the key concepts you encounter is dominant logic. Dominant logic is the set of premises, habits, and beliefs an organization has developed over time about how things should be done. It is the belief that the way things have been done in the past is the best possible way. You can hear people say, “This is the way we have always done it,” or, “If it is not broken, do not touch it.” That can be useful when you are dealing with production lines and similar environments, but when you are talking about transition, it is one of the most dangerous premises.
One of the key questions we asked when assembling the standards was this: everyone talks about bringing the commissioning team and the operations team in early. Bring them early, bring them early. But it is more than that. Yes, you need to bring them early, but you also need to define the parameters. What exactly are you bringing early? If you bring in a team early and it does exactly the same thing you have done in the past, you are moving again toward compliance mode.
In that case, you are satisfying the organization’s dominant logic. You need to challenge those premises and move toward capability building, where the organization can adapt, enhance what it does well, and cover blind spots created by dominant logic. This is normally the basis for continuous improvement, but it is more than continuous improvement. It is the adaptability of the organization to new concepts. As technology advances and projects become more complex, dominant logic can become an impairment to these transitions.
Bring in capabilities early. Make sure the organization is open not only to change, but also to adaptation. That is the main premise.
Paul: Last question from me before we conclude. If an organization adopts the ICxA standards but continues making decisions exactly as it has always done on past projects, what has it likely missed in its governance structure?
David: That draws on the same line of thought. You can buy books, but you cannot buy knowledge. I always tell my kids that. What matters is the capability to assimilate knowledge and translate it into tangible action. An organization can adopt the ICxA standards, but if it continues doing the same things, the standard becomes a beautiful document resting on a bookshelf. I invite organizations to assimilate it, understand it, and challenge themselves with it.
They need to ask how they can improve their operations. This returns to the premise I mentioned about compliance. Organizations are extremely good at compliance. They have excellent processes to ensure compliance, quality control, and continuous improvement. But unless you embrace transformation and the transition itself, and unless you understand how the transition should look and what can go wrong, you will miss the value. You need to put the effort in at the front end to make sure you understand what is ahead.
Yes, an organization can get the standard. But if it remains in a compliance state to satisfy dominant logic, its transitions remain at high risk.
Paul: Thank you for sharing all this information and for announcing this huge milestone from ICxA: the release of the ICxA standards. I am sure the audience found this very helpful. If you are watching this as a replay after the live session has ended, please reach out.
If you have any questions for me or for David, email info@icxa.net. We would be happy to get you the operational readiness knowledge and information you need to apply it to your projects.
Any last words, David, before we conclude?
David: My last words are mostly what I mentioned at the beginning. I want to reiterate my gratitude to everyone who contributed to this. This is accumulated and aggregated knowledge from multiple areas. We should feel proud of this great milestone for the whole industry. I want to thank ICxA for this tremendous opportunity, for allowing us to establish the technical committees, and for building the research agenda that will help projects transition in a safer, more sustainable, and more profitable way.
Again, thank you. I am very happy and very proud, and I am looking forward to what is to come with the continued advancement of the technical committees.
Paul: Thank you, David. For anyone who would like to check out the standards, go to icxa.net. You can access a preview copy of the standards there. Please check them out, and if you have any questions, feel free to reach out.
Thanks, everyone, for joining. This was a great discussion, and we are happy to share this information with you. We have another webinar coming up in the next couple of weeks, so watch your email and LinkedIn to join that one. We will have another great discussion then.
Thanks, everyone, and have a great day.
David: Have a great day.
Visit icxa.net for more information.