Preparing for operational readiness on your project will make or break the success of your projects. I had the pleasure of sitting down with David Tain to get his perspective and expertise on operational readiness.
Hello everyone. Welcome to today’s session. Today, I’m super excited to welcome David Tain to the Institute of Commissioning and Assurance. David is a project leader in Calgary, AB, Canada, and he’s working in the oil and gas industry and specializes in operational readiness. He’s an expert in building programs that ensure teams, systems, assets, and processes are all fully prepared and aligned for operational success at the end of projects.
And today, David is going to show us all the steps that are required to prepare your projects for operational readiness success. Welcome to the show, David. I’ll turn it over to you.
Well, thank you so much Paul, I mean, for this great opportunity and for the Institute of Commissioning and Assurance. And by the way, an amazing read actually over the standard, the operational readiness standard that was issued yesterday and a very well-needed document in this, especially in this particular area in this industry.
I want to thank all of you guys for coming along this morning to join us and get some appreciation for the importance of operational readiness in the commissioning and startup industry. Without more preamble, let’s just start rock and rolling. So why do we need operational readiness? Well, the most immediate cause is very evident, right. So operational readiness, trying to commission and start up a project with an insufficient understanding of the readiness, it’s definitely a lead cause of accident.
Another situation that we know is detrimental to the asset and why is that is the reason is very simple. As soon as we start moving from scope-based to a system-based, so all these system components are going to start working together in a way that if we did not anticipate their behavior, they’re going to become failure modes, right? So that’s essentially what’s going to put us in improvisation, in rework, and unnecessary costs and unnecessary stress in the project that if this had been anticipated, an operational readiness program would be prepared for that, especially when we enter the production phase.
You can see here that trying to control production profile is going to be extremely difficult because we didn’t, we’re trying to rework and try to troubleshoot situations that we did not anticipate. Of course, working as a result, we’re going to experience some erratic production profiles that are going to be super difficult to control. And of course, as I mentioned at the previous point, potentially we can end in a really failed situation.
Any complexity, any person who has been in commissioning understands that complexities emerge really rapidly, and we don’t know. And literally, we need to be prepared and not necessarily improvising if we don’t understand the behavior of the system. I came across a few years ago with a study, all the information, this study actually got my attention, and it was conducted by Deloitte, and they mentioned that about 30% of the value of a capital program is destroyed due to the efficiency in operational readiness.
The interesting portion of that story is that when you actually look at why all this happened, it is not necessarily the technical aspect that causes this failure, it is the human aspect, it is the interfaces, it is the communication and the integration, right. So that’s essentially the lead cause of the failure in operational readiness. So what are the objectives of operational readiness? Operational readiness is a critical process in the project life cycle that prepares the asset owners to receive the facilities on the execution.
Of course, that means that we ensure a robust and seamless transition for an efficient ramp-up and operation of the asset, right? So, making sure that it’s safe, profitable, and sustainable. And of course, that all occurs as we identify all the residual risks that could impact the startup and the operation. We want to encapsulate all these in one statement. I’m very reductionist. I try to always simplify and make all these concepts. We can say that operational readiness is the last integrated line of defence prior to asset startup.
Now, one of the key things that I always appreciate about all the operational readiness programs I have conducted is that we have professionals from different areas, we have construction, engineering, and operations professionals. And one of the things that I take my time with is just to harmonize perspectives. We all have our knowledge in our areas, we’re experts in our areas, but we have different perspectives. And that doesn’t mean that we’re wrong.
So, in order to harmonize perspective, let’s just say readiness, normally from the operational point of view, is defined as a level of functional completeness in an asset plus the management of the residual risks. So what do we mean? We mean by functional completeness, it means answering the question: is the scope that has been completed good enough to safely start up the asset and support initial operation? Not only just to push the button, it also needs to be sustainable.
And that comes as a function of the review and exhaustive review of the relevant areas of relevant tasks in your system procedures, interfaces. Each project is going to be unique and is going to have their unique requirements. When we talk about residual risks, essentially we’re talking about what is the impact of the remaining scope or any remaining activity on the startup and ramp-up in the operations. Can we actually sustain operations with that? And not only that, what is the timing? If we have something open, what is the timing to address the remaining items?
And I always use the analogy of a car here. So let’s suppose that I ordered a custom-made car, and I just go to the dealer the day he promised me to deliver the car. I say, well, you know what, David, I do have your car, but right now I don’t have the spare tire; that’s gonna come in one month. It is my particular situation where it’s going to define whether I take the car or not. Because if I have a fleet of 10 cars in my garage, probably I’m gonna say to the guy, you know, no, I can wait.
But if I need the car to Uber and bring food to my family, I’m really going to have to start entertaining managing my residual risks, right? So I’m going to absorb the risk, or I’m just going to rent a tire or whatever. The same thing happens in organizations. So the strategic significance of a project will actually dictate what is the level of tolerance that I’m going to have and what is the management of this residual risk I’m going to have. That strategic significance of that project can mean the sustainability of the organization, right?
So, and it’s not going to be the same as if I had just another train that I’m going to produce. And I can actually, I have plenty of cash flow in my organization going into the same area to harmonize knowledge. One of the things also that I mentioned is the difference between readiness and completeness, right? So, and I put here five key differentiators in terms of frame, control, goal, the nature, and the span.
When we talk about readiness, we’re talking about the frame is the operating asset plus the business, which is no more than the organization, the system, and the technology, right? So completeness itself is the actual scope, the completion of the scope. We control readiness with actual processes, whereas completeness is controlled with project-particular deliverables. So schedule, logs, execution plan, etc.
The objective of readiness is the startup and the sustainability of operations, whereas completeness is the pre-completion that actually leads us to think that readiness in nature is a continuous variable because readiness equates the owner’s tolerance, the risk tolerance. So essentially, are we ready to operate given the level of completeness that we have in our project? Completeness is just discrete because it’s tied to hard contractual milestones that we do or we’re not done.
And of course, when we talk about lifespan, readiness is reached until stable operations are reached. And it’s interesting because once you actually hand over the asset to operations in terms of readiness, you make sure that it’s stable and that it actually doesn’t interfere with the operational excellence efforts in the organization when you optimize, but you want to make sure that you deliver an asset that not only works but also can sustain technical operations, and the organization can take it over.
We all have seen this chart in projects, which is as we advance the progress, we have more knowledge, and of course, the risk identification decreases right along the progress line. We’re going to have a point where we’re going to call functional completeness, which is essentially what we’re discussing two slides ago. If this functional completeness means that I can push a button, the system’s going to work, everything I can energize, and notice that I didn’t mention they were safe. So the system is going to work.
Each owner is going to have a minimum readiness acceptable, a minimum level of readiness acceptable, and that’s going to depend on the particular situation of the organization, and that’s going to dictate the robustness of the mitigation of the residual risks. As we can see here, the longer or the closer this minimum readiness acceptable to the owner is to the pre-completion, the larger the window of the risk aversion is.
Eventually, we will like to end with an operational readiness evaluation, an exhaustive evaluation of all the items that we’re going to see in subsequent slides, and with a point where the senior leadership says yes, we authorize to start up to operate. And of course, we have full knowledge of all the residual risks that we’re facing ahead with this.
Now, let’s enter into the process and to define the operational readiness process; these are two key components we’re going to talk about: the hierarchization. Now we’re going to talk about a life cycle starting with a hierarchization. We can actually divide this one into four key levels, right? So we start with the domains, which is what are the business entities that are relevant to the project, to this particular project, based on the nature and the characteristics of the project, what are the functional areas?
So what areas within the domain need to be considered and evaluated in the projects, right? So I do have field operations, I do have, let’s say, work authorizations or maintenance. I’m gonna have now functional requirements as a subsequent level, which is the actual specific question that I’m going to ask to demonstrate readiness, right. And the deliverables, of course, evidently what is a tangible product that I’m going to use to produce assurance of that deliverable.
So, in terms of a life cycle, we have a model, but it’s in a three-stage model, a very simple model, but this can become as long as needed. But essentially, it can be reduced into three key stages, right? So we call it the APR: awareness, preparedness, and readiness. The first stage, awareness, is no more than defining the readiness, right? So what is exactly the front-end notification of the parameters of any risk tolerance? What is the value-driven tolerance based on the organization and the external contributors, right?
And also, besides defining readiness, we are going to also set the rules of the game. Essentially, you know, who’s doing what, what is the level of engagement for the organization, this readiness effort giving us the window or the gate to go to engage the actual preparedness with all the information captured. The next level is preparedness, where we actually orchestrate the resources and obtain the information. This is where the data is produced, and we integrate the analysis, and we produce dynamic reporting and proactive mitigation in the actual process.
And notice that I use the word orchestrate here and not coordination integration because, along the project life cycle, information is going to be produced in different stages, different maturities. And moreover, this is going to be in terms of the level of availability of information. In any project, there are going to be situations where we’re going to have to take a decision with incomplete information, right? So that’s the reason why we use the word orchestration.
Any person or entity in charge of the operational readiness effort needs to be 100% well-versed in that level of production and synchronize this information. You know that feeds the entire view of the operational readiness and understand how this affects the big scheme into the readiness of the asset. Finally, the readiness portion is the decision-making point, right? So it’s where we actually demonstrate the operability and sustainability of the potential of the asset, where we do all the verification, and we produce a confidence deliverable.
And notice that this is a process. This is not prescriptive. What deliverable each corporation is going to have their own particular strategy to demonstrate readiness, but it has to be something tangible that generates confidence to senior leadership, that provides the overall picture of the asset to push a button and start introducing energy.
Going to the awareness, the first stage, the foundation, so essentially what we do in this stage is we identify the operational readiness requirements, right? So what we see in the hierarchization, we identify the relevant domains, the functional areas, the deliverables. What are the criticalities of each of these deliverables to the project? We start calibrating the risk tolerances upfront with the asset owners and the operations entity.
And what are the external factors influencing the project? And this is also what we actually move from scope-based to system-based. I can have the most ready facility from the technical perspective facility, but if I’m depending on a delivery to be brought by rail and I don’t have it in place in my contracts, it doesn’t matter how ready I am, the feedstock is not going to allow me to sustain operations in a way that is reliable to the organization, right.
So that’s really, really important that this actually expands to anything that influences the project, internal and external. Of course, in this first stage, we set up the operational readiness program, and you know, we do the applicable elements. What are the evaluation criteria based on the criticalities? What is going to be the monitoring control strategy? How are we going to centralize and integrate the data?
That’s really important because now with all these cybersecurity issues, operational readiness is going to capitalize and manage a lot of confidential information. The reason why all the owners need to be really, really careful in how the data gets managed, centralized, and what are the solutions, right. So that is used to dictate what is going to be the infrastructure and the IT solution.
There’s a myriad of software in the market, but one of the key things that I always try to bring attention to is that you got to be really careful with how this confidential data pertaining to the organization and needs to be well managed. So that’s one of the key things in the program setup. And of course, all these need to be integrated with the corporate risk management ideally. Ultimately, the idea is just to produce an operational readiness plan that outlines at the minimum all these items that we actually have described here in the next stage, preparedness, right? So it’s no more than the analysis and the integration of information. This is where all the data gets synchronized, analyzed, and integrated into the overall operational readiness program.
So, and also that I emphasize here in the dynamic monitoring is because of the difference in time and different availability of this information that gets produced. So we need to understand the data availability, what is the progressive engagement, what is the stakeholder performance in producing this data? Stakeholder performance is one of the key items in operational readiness because it’s actually the source of the data, what is the correlation with external constraints, and how we synchronize and calibrate the information.
Of course, all this is going to be the inputs to identify and categorize the risks that are going to be ahead of us when we start pushing buttons, commissioning, and handing over a portion or the entire scope to operation. Ultimately, we’re going to define how we’re going to transition to operation, and we eventually would like to assemble any decision document, any decision package that creates the confidence in senior leadership to make sure that we can not only start up but also sustain operations until the plant or the facility is stable. Finally, we have the readiness, which is the final stage, the decision, and this is where we actually see the overall health of the asset on the execution. We see that the integrated startup of the domains and functional requirements. We understand very well the residual risk and the stellar threat, and we integrate all these with the business.
A very important point here is that any outstanding actions need to be broken down, and the closure times and who’s doing what. And that’s where things can start falling into the cracks because we don’t know when we transition. And a lot of projects don’t actually take that into consideration; they just lock the action. And they don’t really take into consideration who’s going to do what, when, what timing, and how detrimental that can be when we try to start up or sustain operations, right.
So, essentially, you know, we need to understand if it’s going to be the project, by commissioning, by the operation organization, or by the entity that the organization decides. And of course, ultimately, we’re going to end with a formal authorization to start up and operate the assets. Now, how do we do all this? So, in order to show all these concepts, this is a visual representation of how all these concepts play together. This is a fictitious project built on real experience and real projects. And you can see here how we have defined in the APR process what the domain is, what the functional area is, and functional requirement.
We can see here on the left side that we have a domain: field operations. We have functional areas like training and competency, work authorization, operational procedure, and so on. Under functional requirements, which is essentially the question, we can see here that in the work authorization, we do have, well, do we have a laser permit to work program to operate the facility? In the operational procedures, do we have for a particular system the startup, the shutdown, or the switch procedure for this system, right?
So, are we actually ready for that? So, once we actually define this upfront and we start engaging in the preparedness phase, we should end with something like this, right? So, I guess I say this is just a visual representation. You can see here in particular the field operations; we have a couple of abnormalities, right. So we have a yellow in the work authorization, and we’re going to see how actually that looks like in the lowest possible level of granularity.
And we have already in the asset management strategy, which is particularly spare parts. That’s my tire of my car that I couldn’t get, right. So I need to be able to decide based on my particular conditions whether I can operate without the spares or not. If we go to the lowest possible level of granularity, you can see here in the functional area work authorization, right, which is categorized as high.
So this project decided to ask: is there any integrated lockout system in place, lockout tagout? So this particular project decided that they’re going to implement an electronic tool, but at the time of the review, the electronic tool is 75% developed, right? So Mr. John Doe responded that the lockout system is currently working on a manual basis in a brownfield facility, right?
So the electronic tool to monitor is not yet fully implemented, which is leading me to these OR indicators, right? So the organization decided that this solution is going to come from the central team, the IT team, and, you know, the project is not going to be completed. But the outstanding action after startup is going to be to fully deploy the electronic tool that integrates with the residual risk with the risk management process in the organization. And it’s identified as a low minor integration issue prioritized in concurrent work because it’s actually manual paperwork in a brownfield facility. And you can see here that there is a specific risk attached to the risk register of the organization. The risk we put on the risk ORPM 004, you can see here that eventually we are going to end with a holistic view of the operational readiness program that is going to allow us to produce these confidence packages and deliverables going through all the domains.
The functional areas requirement, everything that we saw in the previous slides, and that is going to give us a good perspective on what are the recommendations, what is the overall readiness assessment of the asset, from the bottom up as we saw what they find: is what do we actually have a showstopper? What are the actions that we have, and who’s going to do it, right?
So, the residual risk, not only how we identify them, but also when we transition to operation, is that properly captured and integrated into the risk management process of the organization, and what is the transition plan to the organization, the operation organization, right, and so on. Essentially, this deliverable must be in place for the organization to confidently press buttons and start introducing commodities and declare that we are ready to commission, start up, and start operating the asset.
So, with that, we can see key takeaways, as I say, all this visual representation, and I always make a lot of emphasis on this particular slide. So, this is not a digital-first digital software. So, you’re going to see here in the market a lot of these solutions, which are amazing with this. I’m pro-digital solutions, but the right size, the right tool to the right project.
So, operational readiness is going to dictate what tool to use, not the other way around, right? So, operational readiness is an expertise-based decision-making methodology that is scalable to any project requirement, right? So, you’re going to use the tool that is suitable for you as long as you have a robust process that sustains that readiness for your assets.
Operational readiness ensures the safe transition of the asset to the operating organization because it orchestrates the functions and activities, right? So, you are pretty much engaging the right resources in a timely manner as the project approaches the operations phase. Of course, one of the key and most important attributes of the process is that you identify and control the residual risks as they emerge. It’s always better to define and address issues before the plant is alive and before we start seeing the behavior of the systems, right? So, we need to anticipate that behavior because, as I mentioned at the beginning, if we don’t understand the behavior of the system, it’s going to become a failure mode. Operational readiness sets the profitability path potential of the assets because essentially it allows us to go with the project life cycle under the deliverable at the function of the end goal, which is an asset in a safe, sustainable, and profitable operation.
And all this, of course, saves and avoids cost because we clearly define the requirements and accountability, proactively integrating all this process within execution. The reason why, upfront, I defined operational readiness as a critical process within the project life cycle. It’s always cheaper to define and address issues on time and avoid any scope creep.
And with this, we can conclude that operational readiness enhances project delivery and improves decision-making for safe, sustainable, and reliable operations. With that, again, I want to thank you guys for coming today, and I hope all this material has enhanced your appreciation and contributed to your knowledge about operational readiness. Thank you, Paul, again for the great opportunity, amazing for the Commissioning Assurance, and with this, I’ll turn over to you.
Thanks, David. That was excellent. David has given us a gold mine of information in this presentation, so I appreciate it for everyone watching. Now, we’ve got some time for some questions, and I see that there are tons and lots of interest in the chat here. So, we’ll go through each one of the questions. If you have additional questions, by all means, shoot them in the chat. This is your chance to get expert answers and advice from an expert like David Tain in operational readiness.
Q&A Section
Q: Is the presentation available? Can we get a copy of the slides?
A: Absolutely. The presentation is recorded, so it’s streamed on LinkedIn and YouTube. You can get the recording there, watch it anytime. Please share it with other people on your project because this is valuable information, and we need everybody working on projects to be able to understand this critical aspect of completing projects. I don’t know if you have anything else to add on that one, David.
A (David): No, no. It’s essentially one of the key things that one observes along my career in projects and operational readiness is that there’s a lot of importance in that and making sure the transition from scope-based to a system-based approach is critical. I mean, you can see here, and we all have seen, as we mentioned even before we actually started the presentation, how rewarding it is to see all these pieces of this thing working together. But at the same time, we have unfortunately witnessed that when things go wrong, and when things go wrong in this transition, they really go wrong super fast and super bad. We’re talking about commodities, we’re talking about systems with energy, internal energy, we’re talking about systems we don’t understand behaviors, and you know, a multibillion-dollar asset held by a small spare part that cannot be found, until six months ago, brought from Europe to America, right? So this is the kind of thing that operational readiness needs to ensure, and not only the most fatal things, the accidents, but also it can put you in trouble, particularly if your project has a strategic significance to your organization. Right. So you have seen that tons of times, one project, particularly, actually had to shut down for six months, which I was actually one of the most interesting, the smallest yet the most complex project that I’ve ever worked on. Also, as the Deloitte study reinforces, it was because of the human factors, right? So it was a tremendous amount of interfaces, and it was literally shut down for six months, and then the team had to be brought back, a different team with a different knowledge ramp-up curve, and every time that we talk about that, we talk about money and money and more money bleeding for the organization.
Comment (Paul): I really like your point during the presentation where you said the underlying process is fundamental, right? Software is a tool, and software can certainly help us. But if you don’t have a solid foundational process, then you can’t use software to scale a broken process. That’s only going to amplify the problems with your underlying process for commissioning and operational readiness is fundamental, and then you can use software to help you scale a process that’s world-class.
A (David): Absolutely, Paul. And in that line, I mean, just a final comment on that. Yes, that’s especially nowadays with all these cybersecurity issues, we have seen that happen in the market, right. So operational readiness manages a lot of confidential information. So any tool that you decide needs to be robust enough. I’ve seen tools, I mean, we have cases in the market that tools have been shut down, and the clients have been left hanging. I have a couple of examples of that. I mean, of course, for confidentiality reasons, I’m not going to mention that, but yes, they have been shut down. You know, they have left the clients in a really difficult situation with a lot of confidential information in a cloud or whatever. So it’s because these particular clients decided that the operational readiness is going to be conducted by an IT solution or solution itself as opposed to a process. And therefore, you know, they end in big trouble. So that’s a big word of caution that I use. I’m pro-tools, I know amazing completion management tools that work very well, but you need to right-size your tool to your project, right? So and make sure to check very well the robustness and the security of your tool.
Comment: The important thing is toolbox to understanding the planning activities for the project every day. Going into a deep understanding of the project at all team levels in the project must be understanding all details to participate in problem-solving.
A (David): Absolutely. I mean, another key argument that we made here and statement that we made is that operational readiness is a key and critical process within the project life cycle. It has to be integrated into the project. It is part of the project, right. So trying to just understand how the components of a system work at the very end and only just understanding how the scope works in my particular silo is one of the most dangerous things that can happen. And not only that, if you don’t understand and if for some reason you need to optimize your execution or let’s say that you need to bring cash faster to the organization, and you have 3-4 trains, and you better start up with only one train, you better understand very well how the systems work together. How do you isolate the system? How do you isolate that train and the key components to start bringing cash, bringing value to the organization as soon as possible. In the meantime, concurrently, you complete and finish the readiness for the other trains, and you declare readiness and overall scale. So that understanding that only an operational readiness program can give you. I mean, execution is focusing on execution, completeness is versus readiness. So yes, we’re all project professionals, we’re here, this is my task. But readiness is going to be the glue that amalgamates all these components and allows you to understand this transition.
Q: That’s a good point. So this question is related to, I think, the graph you had that showed risk and progress and the two intersecting lines.
A (David): So the question is, what is the time frame difference in both of these? That you think the time difference is between the one you declare readiness, that’s going to be dependent on the, as I mentioned at the beginning, on the specific attributes of the program, right? So you’re gonna reach a point where you have a level of functional completeness, which essentially, you know, and again, notice that I didn’t say safe, I say functional completeness. You’re gonna push a button, and everything is gonna start working together. Operational readiness is gonna tell you, Is it safe to push a button? And you actually, you know, I said it’s going back to the car, right? So you can actually, you know, you can start up the car, but you don’t have the actual wheel. So you can drive the car in different ways, but is it safe to do it, right? So it depends on the attributes and the needs and the requirements of the client and the owner-operator to determine that timing. And you can see here in that graph that, I mean, of course, that is an indicator of the risk aversion of the client, right? So the closer that time frame is to the pre-completion, the bigger the risk aversion is, or it can also be an indicator of the redundancy. As I said, I do have all the facilities that are bringing me cash. I have a healthy balance sheet in my organization. So yeah, I have the luxury to wait. Why not? And I have all my stuff. My corporation is on a healthy journey. I can wait. That’s going to be dependent. So that’s the reason why you have a time frame, but each project is going to define its particular time.
Q: This next question is an excellent one because we see this often on projects in early in your presentation. How much percentage of these functional chains actually gets broken down when the situation is a weak financial situation or with non-structured management? We see that often on projects where it’s maybe not as structured as it needs to be at the front of projects. But so in that situation, what do you do, or how do you break that down?
A (David): Well, I mean, I would say it’s hard to say, but I would actually say the front-end preparation is key on this, right. So when you actually start breaking down in terms of weak financial and non-structured management, the key attribute to operational readiness is the human factor, right. So I mean, when we don’t have that clear, when we don’t have strong structures that support these operational readiness processes, and when the organization is not serious, let’s put it that way, right. So when the organization is only execution-based, schedule-driven projects, right. So that actually can put you in trouble, right. So it is hard to pinpoint a percentage for the modes of failure, but it is really, you know, as you mentioned, we see 30% of the value destroyed based on the failures in operational readiness. But at the end of the day, you know, anything, you’re opening a Pandora’s box, right, as soon as you don’t understand the systems, right. So putting a financial, I mean, the sky’s the limit because essentially the lack of understanding is what is going to dictate your failure modes.
Q: Here’s another good question. Have you experienced cases in which the insurance company values the operational readiness process and actually reduces premiums?
A (David): Well, indirectly, yes. Not, I mean, I have never seen a corporate, an insurance company, asking directly about this operational readiness. There’s a reason why operational readiness is a concept that, although it’s not novel, has always been underappreciated and always embedded into different processes of the organization, right? So it is now that the industry is taking this traction. And as I mentioned in the beginning, it is amazing that ICxA developed and issued this first standard; it’s well-needed because operational readiness has existed in different modes, I mean reviews and different reviews, audits, but has never been in an integrated way. I think with this movement and this traction that we’re taking in the operational readiness function, insurance companies are going to definitely, I wouldn’t be surprised. Insurance companies are going to be looking at that in the same way that they’re actually looking at reviews, right? So to reduce premiums, and which makes a lot of sense because the premiums are a function of the risk that you have. The more mitigated the risk, the more controlled you have the risk, insurance companies are going to look at that as the more confident they are. And subsequently, I would expect that the premiums are going to be. But no, the straight answer is no. I have never seen a company, an insurance company, but I invite you to do that, right? So, looking at the operational readiness to reduce premiums.
A (Paul): That’s definitely closing the loop, right, when often the money drives the decisions, right. But if you close the loop on that, and you’re getting a reduction in insurance premiums because you’re instituting robust operational processes, it only makes sense that the owner benefits and values from that, right?
A (David): Absolutely.
A: Should an organization start by developing an operational readiness strategy and operational readiness guidelines before rolling out operational readiness on its projects, or can operational readiness principles be rolled out on a project without a corporate operational readiness strategy?
A (David): Well, that’s a really good question, right. So I mean, operational readiness needs to exist from the project inception, right? So that means that the operation, the organization needs to have in place operational readiness processes, standards, and practices, right. So I would expect a major corporation, energy corporation, or production corporation to at least have an appreciation of how to start deploying and developing an operational readiness program into the project. So, yes, to answer your question, operational readiness is a process that needs to be embedded into the organization and is a critical part of the project life cycle, meaning that you need to start deploying it even at the development of the project. So because that’s when you start seeing your processes, that’s when you start developing your PFD, your P&IDs, all your households, right? So all the operational readiness process is going to progress, start being fed with all this information. And the earlier you deploy that, the more effective and the more protected you’re going to be as an organization to transition to operations. So I think, yes, to answer your question, they should have an operational readiness at a corporate level, at least a minimum level of standardization of operational readiness, and then you start deploying, right. So depending on deploying as early as you can, as early as the development stage.
Comment: Hi, Mike, good to see you. Mike’s one of our experts in our certification program for commissioning. Mike wants to say hi. David, you are truly an expert in this field, and I really enjoyed working with you on previous projects and seeing you hone your skills and putting them to good use.
A (David): Oh, thank you. You know, it was a real pleasure working with Mike, and you know, thank you for that. I appreciate it.
Q: Have you experienced conflict with EPC and EPCMs? Typically, they love construction, buy tons of structures, and run away from assuming responsibilities which are inherent for commissioning and operational readiness. What are your thoughts on that one?
A (David): Well, Paul, yes, absolutely, and not indirectly in the operational readiness, but that actually comes in the interfaces. So I have been in projects where you don’t put these in the contractual terms, especially when you have mega projects, right? So, multi-billion-dollar projects, if you don’t anticipate that in the contractor relationship, you’re going to have multiple contracts, you’re going to start being hit with change orders, right? So I’m not supposed to manage these, I’m not supposed to report on that, or I mean, I’m here just to, especially when you have very highly specialized vendors, right? So they have proprietary information. If you don’t actually set up the rules of the game upfront in the program, you are going to really face a lot of interface issues. And that interface is going to be with the integration of the operational readiness program. Operational readiness relies a lot on integration. And if you don’t have a good grasp on that, yes. So the EPC, EPCMs, and moreover, vendors, specialized vendors, I mean, if you see an EPCM, yes, I have experienced that, but it’s manageable. It is when you actually go to very specific vendors that are either managed by EPCMs, depending on the model, or you are actually managing yourselves, trying to obtain information. And as I mentioned in the beginning, this information is going to be produced at different stages and different levels of availability. You’re going to have to take decisions with incomplete information or with not up-to-date information, or even more, you’re going to have to update information on the fly and understand how this impacts the overall operational readiness scheme. So a piece of information, we actually have a project where a Sulfrox trade technology from Shell package, and when we actually, based on some information that we had with the reservoir, when we actually started drilling just for final tests, we found that the mercaptan levels were too high, and the entire front package was pretty much thrown to the garbage. So it was a big, big miss. I would say it’s a big updating information. So then we actually had to rapidly deploy a capture package and so on. So you can see here that if you don’t anticipate, if you are not on top of the game in the operational readiness, you can actually run into troubles, specialized information, specialized vendors, and EPCM. So everything, the devil is not in the details, the devil is in the interfaces.
Q: So I’m not entirely really sure exactly what this question is asking, but let’s give it a try. What is your client within the end-user organization?
A (David): The organization itself, right? So the organization itself has to be in full control of the operational readiness process. So the clients are the owners. So now, specialized organizations in operational readiness, I mean, with the expertise of operational readiness, are the ones that provide the knowledge, but the clients are the owner-operators, right? I don’t know if that answers the question, Paul. I mean, it’s possible.
Q: So Thomas has a question somewhat related to the mining industry, but his experience is that a lot of this operational readiness has often been left to operations at the end of the project. So have you had a similar experience or examples of best practices on how it’s not all left to operations at the end of the project?
A (David): Yeah. I mean, not with this particular Amira Metal accounting code, so I’m not with that particular. But here, actually, we’re working in mining projects in oil sands mining. And one of the key things that upfront we define, this is one of the key requirements; the Amira Metal accounting code is one. That would be one of the key requirements to define upfront, right. So when we actually go in the awareness stage, any project that requires those requirements needs to be upfront, and of course, the SMEs and the right entities in the organization responsible for producing that need to be defined. And at the end, if the decision is being left to operation, well, we better define that at the beginning because then I need to, as I mentioned in the first statement in the key objective of operational readiness, is that it is to actively prepare the asset operations, the asset operator, to the sustained operation of the assets. So, if there’s something that the operational organization, that the organization decided that the operations entity is going to do, we’re ready to define it upfront to give them the resources to prepare them to receive and properly operate and act on any code or any information that they need to produce.
Q: Hi, Roberto, good to see you. So the question is, how do you propose to include this in the project process? Would this be through a consulting engagement, or would this be an in-house team that would be responsible for execution of operational readiness, or does this methodology just really need a sensible approach with the project owner? How would you approach this?
A (David): Well, that depends on the capabilities of the organization, right? So I mean, trying that, this is the reason I’m always hesitant to produce a silver bullet solution, right. So I suppose if this is a process that actually is going to dictate based on, so you’re gonna have a process, and this process is going to actually expose what are the capabilities of the organization. Probably, if your organization is mature enough, you probably have an operational team in the organization. If it’s not, you’re gonna have the need to bring consultants or bring experts in operational readiness, which actually are gonna subsequently expose items that you are lacking. So let’s say that you have an organization that is a small producer, and you’re pretty much producing maybe 30-40 thousand barrels a day facility, right? So you have a good grasp, but then all of a sudden you have a partnership with the bigger, and now you are designing a 100,000 barrels per day facility, right. So, and you are going to be the operator. So, well, you don’t have the capability to do that, right. So you bring the operational readiness process, and within this operational readiness expertise, you’re going to highlight that. Well, you know what, I need trainers. I actually need, you know, panel operators. I need to bring this particular vendor. Now my accounting system needs to grow, going back to the actual Amira Metal accounting code that was mentioned, right. So maybe now the volumes that I’m producing are larger. I need to upsize the organization just to tackle this, right. So yes, it’s going to depend on the capabilities of the organization, the particular situation, and the strategic significance of your project, right? So, but definitely needs to be deployed no matter the capabilities, no matter the size of your organization, operational readiness is something that needs to be deployed upfront. You need to define the parameters to avoid any surprises.
Q: This question is somewhat related. How does the operational readiness team integrate with the project team to ensure a vertical facility startup? The operational readiness team, how does the operational readiness team integrate with the project team?
A (David): Well, the operational readiness team, they actually work in integration, right? So I’m gonna give you an example. As soon as you’re building, let’s do an execution. So when you’re in the engineering stage, and you are doing your HAZOPs, your model reviews, you need to have somebody from operations there, right? So that’s actually, you know, something that needs to happen. You cannot just go engineering, go bring the construction experts, which actually you have to consider how this is going to be. You also mentioned constructability reviews, but a few people bring the commissioning people early enough in the project. And some people say, well, because it’s, you know, it’s just, you don’t need an army of people, you need to start progressively deploying, right? So something that you need to define upfront, right? So your operational readiness effort needs to be integrated into the project at a very early stage, right. So that way, it’s going to give you input on how to even more efficiently start up and sustain operation even at the inception phase; that’s even going to help you in optimizing your engineering and saving costs, right. So normally, what I’ve seen is that in successful projects, you start deploying commissioning, startup, operation experts, and operational readiness at the very beginning of the pre-FEED. So when you are at the 30% model review, you have to have somebody there from operations at the very early stages in development. You have to have somebody that has done something similar tell you, you know what, maybe this bypass doesn’t work, or even at the functional level, you know what, we don’t have the capabilities to do this. So we better start hiring more people for, you know, the supply chain because we’re going to have now multiple contracts that I’m not capable of managing with these two people that I have in the organization, right. So that’s how you actually do it.
Q: We’ve all got lots of commissioning horror stories of how projects have gone wrong. Maybe you can share one for Bernard. He’s asking, have you experienced cases where an industrial process facility fails to have a smooth startup even after integrating operational readiness within the project development?
A (David): Well, no, I mean, that’s actually the question, right. So when you actually integrate the cases that I’ve seen where you integrate operational readiness, and the organization takes that seriously and robustly, definitely I have seen smooth startups, right. So, and again, I can, for confidentiality reasons, I’m not gonna mention particular projects, but that can go from onshore to offshore projects, right. So when you actually review exhaustively all the aspects of the project, which is what the operational readiness process obligates you to do, an exhaustive review, you normally anticipate: are there new situations that are going to present when the commissioning phase starts? Absolutely. But now with the operational readiness process, you have the redundancy that I do that. So a hose blew up, right. So, well, you know, you actually anticipated that because you quantified your residual risks. On the converse side, and conversely, I actually see cases where the industrial facility fails to have a smooth startup. And this one of the smallest projects that I referred to, and yes, I mean, a lot of situations were non-anticipated. The readiness was not calibrated with the actual plant shutdown. It was a brownfield project, and the end result was we closed that up. So the entire team was, the operational readiness was non-existent there, and the entire team needed to be demobilized, brought back, but now with new people. So it was a really interesting experience that I own in my career, to say the least. Right. So I’ve never seen so many things. You know, it’s literally, it becomes a chain of events. It becomes a perfect storm when you actually do that. It’s interesting how, and going back to how the systems are working together, how one thing, as soon as you start calibrating the complexities, you calibrate one variable, and another one goes; the bottlenecks start moving around the system in ways that you cannot predict. You are open to anything, and eventually, actually, the worst-case scenario, you’re open to an accident.
Q (Paul): Interesting is a good way to put it. Yeah, of long 18-hour days trying to make everything work at the end there for sure. Which one or maybe who is the control point for operational readiness in the org chart structure?
A (David): It has to be, not independent, an operational readiness lead or operational readiness person or operation entity in charge; that operational readiness should overarch between a project and operations, right? So this is essentially the function that actually brings the project to life, which is actually, as we tell in the presentation, right. So your function as an operational readiness expert, lead, or whatever you want to call as an operational readiness practitioner is, is to bring that asset to life. So it is a real responsibility because you need to overwatch between the two organizations. You need to understand very well how the scope needs to be completed, what is the level of readiness that you have, the completeness you have, and you do understand the requirements for operations. So it is you, as an overarching entity between projects and operation, that is going to bring this baby to life and hand it over to the parents. It’s not a subcontractor, a sub-activity, or just another group you bring on site for a few minutes. It is an overarching function to make this transition for sure.
Q (Paul): Yeah. That’s good. I don’t want to see this as an isolated function. It is embedded, but it’s an overarching process that actually bridges between process at the project and operations. How do you see equipment commissioning affecting operational readiness?
A (David): Big time, big time. I mean, operational readiness is going to be, when you actually are doing in the preparedness phase, you are actually exhaustively reviewing the state of your equipment, key items that I had explained before, cleaning. So let’s say we’re going to do a chemical cleaning on a system. Are we gonna do just an air blow, right. So I’ve seen in this particular thing decisions that have been, well, we’re gonna save money on a chemical clean, we’re gonna do an air blow. We pretty much see a pump that needed to be, the entire pump sent from Fort Murray to Edmonton, and a big pump. So you know how long that takes to put your project ready for operations date in your party, right. So yes, equipment commissioning, you need that level of preparedness is what is going to put you in a good position to commission your asset and to make sure that you’re ready. And not only that, a lot of cases, you’re going to have very highly specialized equipment, right. So you have a particular software in a DCS, then you need to troubleshoot with automation, right? So at least if you have that unknown, you need to be able to mitigate that risk and have something that is super specialized. What is the redundancy I’m going to have in case that this unknown materializes? I think that’s the key, right? So equipment commissioning, not only equipment, I mean software readiness, either can affect potentially, and is it the role of operational readiness to determine and to define what are the failure modes that could be experienced.
Q: So these next two questions are related to AI. I’ll lump them together here. So Dr. Basil Ali says we did an AI closed system for maintenance management system regarding the oil wells to evaluate the cost control and time during shutdown. And then the next question is, have you managed any AI tools in the operational readiness phase, or do you have any tools AI-related that you could suggest?
A (David): Because that’s an interesting question, right? So AI right now is taking a lot of traction. AI, the limitation of AI is AI is the amalgamation of the knowledge that is available in the network, right? So this is one of the dangers of AI because AI can actually be, it can enhance in the front end always, but once you actually enter into the human factor. I don’t think right now AI is at the level of maturity that you can actually automate commissioning or operational readiness, right? So I’m pro-tools, I’m pro-technology only at the front end because it’s up to the expertise of the commissioning and operational readiness practitioners; that’s going to dictate what is your level of readiness, right? So I don’t think AI is going to give you only the best, the best possible combination of information that is out there. That is up to your particular project, your particular experts that are going to make you successful. So no, I cannot suggest you any tools. And it’s like any other tool, right? You need the right tool for the job, but you first need that underlying best process. You can’t use a tool to scale a broken process.
Q: All right, last question. And then I think we can close right on time here at the top of the hour, which issues can arise due to unclear command structures in operational readiness.
A (David): The same issues as any unclear command structure. So that is exactly the same issues. So as I mentioned, operational readiness is an overarching process, and it’s more about integration of the information, right. So more than command, I would say more, operational readiness is about integration, right? So the failure modes don’t come from the command structure; the failure modes come into the integration. So you can have the most robust command structure, but it’s up to how this information, the information will never lie. This is saying that if you turn to the data enough, the nature will confess, and that’s actually by a Nobel Prize in economics, Ronald Coase, and it’s exactly that, right. So you can have the best command structures, the best robust structures, but it’s the robustness of the data, the actual accuracy of the data that is going to dictate what exactly is going to happen, how the operational readiness effort is going to look, and how you’re going to sustain your operations.
Paul: Excellent. Thank you for that. Lots of great questions. I appreciate everyone’s interest. David, if people want to reach out to you or if they have additional questions, they want to get in touch with you. Where’s the best place to do that? Is the best place on LinkedIn?
A (David): LinkedIn, LinkedIn is the best place; we can start there. I’m more than happy, I mean, to answer and to be reached out, and I’m more than happy to continue discussing operational readiness. As I mentioned at the beginning, operational readiness is getting the traction that it deserves, and I can’t overemphasize how pleased I am to see that the Commissioning Association, the Assurance Association, delivered. Super pleased to see that well-needed, this operational readiness has the potential, the same as commissioning, to change the whole industry of how we execute projects to make them, you know, not only successful but also safe.
Paul: And I think that’s a key point. Yet everybody working on projects, we also be working towards the same goal, which is delivering a safe and highly reliable project that can be used for decades of reliable operations. So definitely appreciate your insight and expertise on this, David, appreciate the presentation, and appreciate everyone’s involvement in great questions and for joining the presentation live.
Paul: And I think that’s a key point. Yet everybody working on projects, we also be working towards the same goal, which is delivering a safe and highly reliable project that can be used for decades of reliable operations. So definitely appreciate your insight and expertise on this, David, appreciate the presentation, and appreciate everyone’s involvement in great questions and for joining the presentation live. Any closing comments before we conclude, David?
David: All the more, thank you for the opportunity, Paul, and amazing, you know, working with the ICxA, great initiatives, and I want to thank all everybody for joining from wherever they are in the world. Thank you so much for sparing the time, and I hope that we have contributed to your appreciation and knowledge in the operational readiness world and the importance of that, and that you consider, make sure that you encounter operational readiness as a key factor to your project success.
Thanks everyone, thanks for joining, and have a great day.
Are you ready to lead infrastructure projects with purpose and accountability? Join the movement at icxa.net and unlock exclusive resources, from global standards to project delivery reform and career development certification programs. Visit icxa.net for more information.
Recent Comments