I’d like to welcome David Tain to the Institute of Commissioning and Assurance. David is joining our ICxA Advisory Council and is also taking the position of Vice President of Latin America. I had the opportunity of sitting down with David to speak about operational readiness and the future of project delivery.
Paul Turner: Welcome, everyone. Welcome to the Institute of Commissioning and Assurance. I’m Paul Turner, Founder and CEO of ICxA, and today I’m super pleased to introduce a new member of our Advisory Council and the Regional Vice President of Latin America, David Tain.Paul Turner: David is a project leader with extensive experience across engineering, commissioning, startup, and operations, and a recognized expert in operational readiness for both onshore and offshore assets. David, it’s a real honor to welcome you for today.
David Tain: Thank you so much, Paul. I mean, the pleasure is mine. I’m super happy to be here and thanks for everybody that’s joining us, you know, wherever they are in the world.
Paul Turner: Absolutely. And for those that are watching live, if you’ve got any questions, now’s your chance to ask experts like David to get your questions answered. Shoot them in the chat as we’re going through the discussion here if anything comes up, and we’ll get David to answer your questions at the end. So, let’s start maybe with your story. David, how did you first move into project execution and operational readiness? What sparked your passion in this wild world of complex projects?
David Tain: Well, that’s a really interesting question. So, a lot of points in my career found my passion. I had the privilege, as soon as I got out of engineering school—I think it’s interesting because I wanted to be an earthquake engineer, and I started my master’s in earthquake engineering. Then, all of a sudden, I started to work. I found a job in the oil and gas industry in a construction corporation. As soon as I saw oil and gas facilities, I literally felt, you know, a feeling of love. I mean, it’s normal passion. Seeing all this equipment and all the processing facilities, how the technologies worked, it was fascinating. That’s the first point of fascination. I still remember, as I said, the first time I entered and saw that huge flare at the access road. I couldn’t believe it, right?
So, I reshaped my career to focus on processing facilities, and of course, I wanted to know more than just construction. I started getting involved with more and more operations folks, at all levels, right. I was really curious about how this worked. That company brought me to a lot of places in Venezuela. That’s how I started, working in exploration and production projects, midstream pipelines, downstream refineries, and offshore. My first offshore projects were naturally marine terminals in Venezuela. That first touch gave me the passion for understanding technology. So, I started getting intentionally informed. It was also then, when I started working abroad in Canada and Europe, that I realized my passion was not only the technical portion, but also the complexities of how to make this work within such complex organizational environments, right.
I started developing a passion not only for new technologies and the scale of these projects at a global level, but also for how these organizations, as socio-technical systems, start working together, the integration, and what it takes to bring all these big components together and bring them to life. That fascination indeed took me back to school. I started defining what I wanted in that realm, beyond the technical component of the oil and gas and energy sector, right.
I went back to school and did my master’s; my specialization was in strategic organization. I took some studies in strategic decision and risk management and even in complexity theories and systems thinking. With that, I had the privilege, as I was increasing my responsibilities and escalating positions in different organizations, to have amazing leaders who allowed me to implement all this new knowledge that I was gaining.
I was thirsty to implement and test how they worked. Some of them didn’t, but a lot of them worked. That’s how I started inheriting that operational readiness function, progressively, from project readiness to operational readiness, as I got more involved in operations. Since then, it’s been a big learning curve, shaping processes, shaping organizational understanding, and realizing that not everything is the same.
Deploying more and more robust operational readiness processes across organizations. That passion started 25 years ago and continues, right? Right now, my passion is to the point that I’m entertaining—although I’m not an academic—topics like what is the role of artificial intelligence in operational readiness programs.
How does the human component become so important in operational readiness programs? Why can’t you automate these processes, but you can probably, in the future, capitalize on artificial intelligence. That’s essentially it—you can see I could stay hours and hours speaking about this because it’s pretty much my passion. Readiness is more than that.
The technical risk, the cost of awareness, and systems thinking essentially come with you for life. The fact that you can combine the technical component with organizations, right? It’s something really interesting, as I mentioned, as a socio-technical system that organizations and projects are. In summary, that’s what it is.
Paul Turner: That’s a pretty good summary. You mentioned systems-based thinking and how that incorporates into the organization. Those key aspects need to come together, and they’re key for project success. You’ve led some projects, some huge projects from all dimensions, including some of Canada’s largest projects, the world’s largest energy assets. What is it about operational readiness that you believe makes or breaks a project’s transition into operations? Is it operational ownership? I think the keyword there is ownership, right?
David Tain: Operational readiness is a process that builds bottom-up, right? Even though it’s built bottom-up, it is strategically implemented from the top and sponsored from the top. That strategic accountability is what makes the key success factor of the program, right?
It’s essentially the function that bridges projects and operations, right? What does that mean? In the front end, the integration needs to happen with a well-framed outcome assurance mindset, right? Where you clearly define all the requirements, and in this foundational stage, you build in the collective knowledge, right? It’s a really critical stage. Trying to deploy operational readiness without this level of integration, without procuring that level of integration, is not only risky, it’s really risky. I’ve seen that, but it also turns the entire program into a data compilation audit exercise that is driven by compliance.
Paul Turner: Yep, I like that. Strategic accountability, strategic ownership, those are key. On some of the projects you’ve managed, onshore and offshore projects, what are some of the unique challenges you’ve seen in that regard for strategic outcomes and strategic ownership? How do you approach integrating readiness across such complex environments?
David Tain: When you’re depending on where you go, with pure offshore assets, right, the knowledge plays a key component. The maturity of the technology you’re using, of course, when you are onshore, the environments are clearer. I want to make a caveat. I don’t want to simplify because you can have a highly technological project onshore, but when you go offshore, the challenges increase.
It’s not the same thing blowing a hose here in northern Alberta, where you can go to Home Depot, as blowing a 50-cent hose 300 miles from the coast where you have nothing, and that can put you in big trouble. The level of rigor you have to have in operations probably increases a bit more when you are offshore because you need to check and double-check. Again, I don’t want to downplay onshore projects, but offshore offers challenges in terms of systemization, the capacity you have for reaction in that environment, right? You’re 300 miles from the coast, so you really need to be super tight on any processes that you have.
Paul Turner: Operational readiness plays a key role in that. Yes. Even if the technical complexity is very similar, the logistical challenges just make things that much more precise. That technical rigor you mentioned is just critical because there are so many things that can go wrong. I completely agree with that. When you go through some of these projects, what are the common failure points in operational readiness, and how can project leaders address some of these pain points or reduce or mitigate some of these issues earlier in projects?
David Tain: I think everything gets reduced, Paul, to inadequate integration and asynchronous flow of information, right? That translates into a lot of deficiencies, like unaddressed interfaces, lack of cooperation of specialized resources, right? In the commissioning world, you can see that they call commissioning at the last minute, or they don’t plan ahead.
Schedule recoveries. Now you’re facing additional costs, and you’re trying just to make it up. Of course, the most important thing, in the worst-case scenario, is any safety incident. When you don’t have that level of integration and information, you’re going to produce information in the project at different stages, at different levels. In different maturities as the project advances.
When you have a scope completion mindset as opposed to an outcome assurance, systems-based approach, you can’t see the interfaces and the transition process properly. As the execution advances, you’re at the mercy of unanticipated risks that could have been avoided, right? That can erode the value and the reputation of the organization. That’s essentially the first thing.
Another important point that I always say, and that causes a bit of heartburn when I mention it, is the blind reliance on software, solutions, and experts. There are a lot of them out there. It’s interesting because these software solutions, if not properly owned by the organization, are going to put you in trouble because they provide a quantitative view with beautiful dashboards and previous databases from other projects.
Your project is unique. At the end of the day, you’re going to prove compliance, right? Suppose you’re driven by outcome. I can’t emphasize enough the danger of these silver bullets. I’m pro-technology, really pro-technology, but the right technology with the right expertise at the right time. The owners need to identify what is the right problem for them in operational readiness, the requirement, the definition of the requirements, and embrace the process first.
That will tell you the best way to avoid this is to adopt a robust stage-approach methodology. It’s nothing different from what the IPA has done before in the FEL stages. When you have incremental development until the execution comes, defining the requirements up front. It’s nothing different from what we discussed in the APR model—awareness, preparedness, readiness—in a previous conversation.
It’s exactly the same thing. This is not reinventing the wheel, it’s just sticking to the processes, right? That has been for years. Something important to mention is that they need to be in full synchrony with the risk management process in the organization. That’s, I think, the most common failure points I see.
Paul Turner: Sticking to the process and having someone own the process can be challenging on today’s large projects, right? There are lots of groups involved, and it’s natural for groups to slip into their individual silos, but it’s imperative that someone develops that process and holds people accountable to that process. It’s the only way to get to the outcome because projects are getting more complex, and there’s a lot more uncertainty in projects.
So, how do you approach this complexity while keeping teams focused on delivering outcomes safely and on time?
David Tain: 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. So we call it the APR: awareness, preparedness, and readiness. The first stage, awareness, is no more than defining the readiness. What exactly is 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.
David Tain: It’s interesting, I want to make a little parenthesis on complexity, as a lot of people talk about navigating complexity. There’s not a single definition of complexity, but I’m going to propose the one I use for readiness, this operational readiness as a systems-based approach. Navigating complexity is about identifying information patterns. Combining past information to identify risks, anticipate futures, and make decisions. That’s it. Everything in complexity is just information patterns, past information, identifying risk, anticipating the future, and making decisions. That’s what operational readiness is about.
Navigating complexity. Having said that, as a leader, when you’re navigating this complexity, the key responsibility, because this complexity is embedded in a flow of information, is that you need to maximize the contribution of your team. You need to bring the best possible information you have to make decisions and, as a leader, keep the team focused. You need to ensure that you remove the roadblocks for the team. Make sure they have the best information, trying to maximize their contribution based on their expertise. The only way to do that is by fostering a culture of trust, right? I mean, we always come back to the socio-technical part and the human part of operational readiness.
Everybody needs to know their role in the big picture. It’s funny because it brings to mind an anecdote from a tremendous project I worked on a couple of years ago, an offshore project. One of the leaders I was in charge of, to be honest, one of the leaders I admire the most in my career, used to always be in touch with the team.
He would quote in all his meetings to make sure he made his point across an anecdote that a lot of people probably have heard. It was when President Kennedy went the first time to the NASA headquarters in the 1960s, during the race to reach the moon. The first time he visited the facilities, he saw a guy mopping the floor and approached him.
He said, “What are you doing here?” And the janitor looked at him and said, “I’m helping put a man on the moon.” That right there is the level of focus that project had, the one I’m referring to, and that level of focus and trust is the one that you need to achieve, the ultimate level of trust that you need to achieve in your teams.
Paul Turner: That’s very important, that level of trust and that level of focus that’s often required to elevate project teams to that level to build these complex projects. But often, on the flip side of that, we see that commissioning aspects or operational readiness aspects are treated more like just a checklist at the end rather than that upfront leadership effort at the beginning of the project. So, how would you define true operational readiness leadership, and why is it so vital to project success?
David Tain: It’s interesting because as soon as you start getting more and more involved in these operational efforts. Readiness is not just testing a lot of checklists, right? Yes, checklists are really necessary, Paul. There are operational processes that require checklists, right? Rigorous checklists, but operational readiness cannot be reduced to a simple checklist.
It has to be elevated to a process. The reason is that you need to navigate this complexity driven by all this information that is stemming from velocity interfaces that are emerging along the project life cycle. Interfaces are going to be dynamic. For example, you have a full engineering effort, and then all of a sudden you realize that the material you’re trying to get is not available anymore, or you have some constraints.
So, this interface is going to change, right? You’re now changing the entire system. The system is going to readapt. To a new form, a new path to success, right? You’re going to reach success, but now you need to readapt and re-accommodate the pieces of the system. Leadership is about navigating that interesting complexity of each project.
With a transition mindset, projects cannot be treated as cooking recipes. Because every project is different. If they were so easy, we wouldn’t be having this conversation right now, and there wouldn’t be so many overruns.
Paul Turner: That’s right. It’s more than just a checklist. You mentioned that human element, that leadership component, which is so key to bringing large groups of people together to accomplish these great things. You’ve mentioned mentoring and coaching in this conversation as well.
What advice do you most share with professionals trying to grow into these leadership positions to maybe elevate from the checklist completion more to the leadership role to lead teams for operational readiness and commissioning leadership?
David Tain: I’m going to respond with what actually helped me personally in my career. You need to make an effort in moving from a scope completion mindset to a systems-thinking approach. Especially paying special attention to the interfaces. That’s the only way that you’re going to be able to understand how everything is interconnected.
This famous saying that the devil is in the details, I always say the devil is in the interfaces, or even worse, yes, the devil is in the details, but it has a special room in the interfaces. Systems thinking is critical, and of course, with that in mind, in technical terms, it’s outcome assurance.
Paul Turner: Absolutely, yep. Do you have any examples from past projects you’ve worked on where operational readiness has really made the difference, where that’s been the delivery of success on a project?
David Tain: Oh yeah. I always rest at ease when I feel that I’m deploying, and I had sponsorship for deploying robust operational readiness processes because normally projects end in success. Regardless of the changes, one particular big project comes to mind where operational readiness played a key role, particularly because of software changes. That’s when you test the operational readiness process. That project had substantial delays, construction delays. These big mega projects, not only here but everywhere in the world. This project had major delays, and there was a lot of pressure. There was a partnership, and a lot of pressure to bring cash as soon as possible to the organization.
Of course, the decision was, instead of going to all the trains, we’re going to just bring one train up while we’re actually taking another one. You can imagine all the changes in a multi-billion-dollar project that you need to make to ensure that your RFO date, your ready-for-operations date, is brought back as soon as possible to mitigate the delays. Trying to bring cash.
That project defined what the isolation points were from the technical perspective, yellowing off P&IDs, ensuring that you have the minimal equipment necessary to start bringing product to life, and product to the stream, feedstock permits on the side, right? Simultaneous operations, right? I’m in an operating facility now, and I have construction workers who had no clue.
I have a fence with monitors, gas monitors, and on one side, I have people putting rebar into a concrete slab, right. That was one of the key things I remember most. When we were doing the robust part of the operational readiness, at the end, the PSSR, the pre-startup safety review, the rigor that these meetings had—these were hours and hours of review—but that tested the readiness process, and that project was successful.
One of the largest producing facilities in northern Alberta, almost 15 years ago. That’s one of the key things—no safety incidents, right? When you’re talking about readiness, the first thing you need to think about is safety, right? How do you ensure that, with simultaneous operations, the training of the team is in place.
That’s another thing. You’re asking me this question, and all these meetings are coming back to my head, and it was beautiful. The socio-technical aspect played a key role there, right? You have people with so much drive from the organization to bring cash, trying to make it a reality in the field with operations. That challenge and that transition were crucial to bringing it to life and avoiding, in the worst-case scenario, an accident or fatality.
Paul Turner: That’s where that systems-based thinking, that systems-based leadership, is so critical to navigate all that complexity at the end. How about on the other side of projects? Is there an example you can share where commissioning and operational readiness were undervalued, and the project paid the price? What should leaders take away from that situation?
David Tain: I think we all need a project like that in our careers to know when things go wrong. That particular project was, by far, the smallest yet the most complex project I’ve ever had in my life. It was kind of a Black Swan situation. Where the human factor failed, there were different intentions, and that translated into delays, insufficient information, and all that.
I cannot overemphasize that we are dealing with a socio-technical system, and anything you do at the human level is going to affect all the information. In that particular project, our advice was late, the process person was not in tune with the latest information. You’re trying to play catch-up with engineering. Every time you tried to do pre-commissioning or static commissioning, something was breaking, something was loose.
I had a situation where equipment needed to be returned because it was damaged due to a lack of procedures. You weren’t ready. You’re trying to play catch-up, but the dramatic part of that project, Paul, was that the accelerated, uncontrolled pace was because it was a brownfield project that needed to be connected to a live plant.
The end result was that all these things went wrong. The window of connection was lost. The project had to wait around six months until the next shutdown. Of course, you had to demobilize the entire team, and six months later, a new team was brought in with new learning curves, new stuff. They paid the price for sure. Quantification of losses, I cannot tell you because that’s confidential information from the organization. I was just in the commissioning and readiness portion of the project, not embedded in that organization, but I can assure you that it was a big loss of opportunity by losing that window.
Paul Turner: Some of those are expensive lessons to learn the hard way for sure. We’re definitely in this complex environment with energy transition, decarbonization, climate change, environmental initiatives, global expansion of data centers, digitalization. There seems to be an immense amount of projects on the horizon. This is definitely a complex environment to be working in and designing projects. So, how do you see the role of operational readiness evolving over the next decade?
David Tain: You know what, Paul, I’m really optimistic, as I mentioned at the beginning when you asked me about the passion, the career. I’m really optimistic about the future of operational readiness and how technology is going to contribute to that. The reason is because I see this and decided to take the approach of a systems-based perspective.
Operational readiness, in a nutshell, capitalizes on the complex and adaptive nature of systems, right? By operational readiness, you orchestrate and synchronize resource information, and as I mentioned before, information is produced at different levels, maturities, and availability. A lot of times, you have to make decisions with no information. That’s a fact. That’s part of the complexity. I personally see predictive models that are going to improve decision-making, safety, and efficiency, right? If I see projects and organizations as a socio-technical system, I can safely adopt a systems dynamics lens, right? I see artificial intelligence contributing with tools that use deep learning to calibrate information and harmonize information delays and oscillations. Creating feedback loops, balancing loops to help stabilize the system, orient decision-making into that management.
In practical terms, right now in commissioning, we use completion management systems of different sophistication, and I see that growing in sophistication. These completion management systems are advancing at a really fast pace. There’s going to be a point where we transition from these CMS, completion management systems, that are widely used in our industry, to what I call predictive readiness management systems, right? An area that is being used right now is material management, reliability, and asset management, where you can use machine learning to predict and determine the risk of material, perfect inventories, and that’s being used.
I think these predictive systems, using artificial intelligence, are going to use deep learning to help steer all this decision-making, right, in organizations. If you see that—and this is the part that I’m trying to conceptualize, and you can see I’m in early stages, sharing it with you—imagine this predictive analysis able to integrate all the areas in operational readiness. Not only using artificial intelligence to use existing information, internal and external, from the project and optimize it. Imagine now that you are able to use this predictive analysis to integrate all these areas and prioritize all these risks and residual information. More than prioritize it, discriminating between what is noise and what is truly risk.
That way, you are able to steer and help decision-making to senior leadership. That, to me, is the future, right? What I’m saying here is that artificial intelligence is not going to replace people. That’s something I have a big caveat about, right? It’s going to make teams smarter, safer, by providing tools for decision-making. More to come, the future will tell, but I really believe in the future of operational readiness and the integration with artificial intelligence and new technologies.
Paul Turner: That predictive readiness analysis is going to be key, isn’t it, to help teams get out of that reactive firefighting mode, to get proactive and get ahead of issues, and allow projects to complete with a smoother finish at the end. I agree completely with the evolution of technology and helping teams to predict issues rather than react to them. You’re joining ICxA at a very important time as we advance outcome assurance into policy frameworks with governance and financers. Why was joining this ICxA Movement and Outcome Assurance movement important to you?
David Tain: The first thing is because it aligns a lot with my own beliefs. Outcome assurance plays a vital role in readiness, right? I strongly believe in the application of systems thinking, the role systems thinking plays in execution. That’s one of the things that aligns with my personal beliefs. As soon as I switched my mind from scope completion to systems thinking, which was years ago, outcome assurance to me is a philosophy that brings the entire project and the entire organization into a common understanding of success. You determine the right requirements to do the right thing at the right time. We have an end in mind.David Tain: That’s what it all reduces to. You have a goal. How do you reach that goal, right? It’s only through outcome assurance, right? Outcome assurance is taking the right steps and adapting. It’s not linear. I cannot emphasize that enough. That’s something I say with the outcome assurance portion: projects are non-linear efforts.
They’re really complex, non-linear efforts, and outcome assurance is going to allow you to adapt as the project comes, and operational readiness plays a key role in that philosophy itself.
Paul Turner: Right. That philosophy of starting with the end in mind and taking the right steps right from the beginning to, like you said, adapt as things change because there will always be challenges on projects for sure, but at least navigating those challenges with a focus on the outcome at the end. So, how can outcome assurance, in your mind, reshape the way that executives and project owners define and measure their project success?
David Tain: Outcome assurance provides you with a clear roadmap to success. It gives you a clear mind on the end goals and allows you to safely define the requirements upfront. Not only that, going to the socio-technical portion, you define the technical requirements, but you also bring this culture of the teams: either we win together or lose together. There’s no midpoint. If one portion of the system, one component of the team, is not winning, the entire project is not winning, and you will always find your weakest link in that system that is going to bring the entire project down. Outcome assurance ensures that you have this clear roadmap and detect deficiencies on time. That’s the importance of embracing that mindset.
Paul Turner: Now, Canada, in essence, is starting to embrace this mindset with the start of the new major projects office that was announced a few months ago and embarking on some large infrastructure investments in projects here in Canada. If you were to sit across the table from one of these major projects that’s investing in, say, a $5 billion mega project for transport or oil and gas, what’s the single most important piece of advice that you’d give them about readiness and assurance as these projects are starting?
David Tain: The first idea that comes to my mind when talking at a director or project sponsor level. You were appointed there to finish a project safely, right? That’s the first thing, even before operational readiness. That’s why I want to make sure that at this point, it’s really important to me. You are appointed there to finish a project safely, and that’s going to be your main yardstick. Forget about the rest. Your function is to leave people better than when you found them. Foster a culture of trust to get the best possible information. On the other hand, when you move toward the actual readiness portion, you have a strategic, forward-looking function to create value for the organization.
What does that mean? It means that your ability as a leader to anticipate the future is critical to identify the risks and address them on time. I bring it back again to materials. That’s one of the things I found that brings more problems to the project. It’s one of the first critical areas to look at. Because that can put you in trouble, going back to the offshore hose blow-up in a previous question you asked me. You’ve got to be careful with that. Embrace your complexity as a normal attribute. Trust your team, and what I mean by trust your team is not just voicing them but seeing with them and ideating scenarios with them.
You, as a leader, are there to identify patterns that others cannot make sense of. That’s your role there. Your ability to forecast the future is critical, paramount. You need to make sense of these patterns for decision-making. You are there to make decisions, and the only way to feel confident—this is a big responsibility on your shoulders. My recommendation is, in order for you to ideate futures, to improve your ability to predict what’s going to happen, leverage and make sure that you deploy a really robust readiness program. In my opinion, it’s your key to navigate the complexity that these big assets bring.
Paul Turner: Certainly a lot of responsibility, and that predictive element of projects—it’s often very beneficial and key to have folks from commissioning, folks from operational readiness at your side at the beginning of projects there to inform you and predict the future and see what those risks are so that you can guide projects to an outcome. So, definitely good advice. We’ve got some questions in the chat. Do you have some time for a few questions, David?
David Tain: Yeah, of course. Absolutely.
Paul Turner: Awesome. I see Darren’s got some feedback here for you. He says, “Have to agree with David’s comments. I was involved with planning, commissioning an FPSO refit. And yes, the challenges related to working in this environment can be super tricky, especially the logistical aspect.” Anything to add on that, David?
David Tain: Happy to see Darren here, one of our board members as well. One of the intrinsic complexities is not only the difference in projects. That’s why I’m always predicating and overemphasizing the importance of bringing all this collective intelligence to the front end. Don’t treat projects as, you know, sure, you can have a very basic start of how projects are going to behave, but don’t make the mistake of thinking that everything is equal checklists and stuff like that. You can start with that, but embrace the complexity and take it seriously. Take it really seriously about how everything is interconnected, determine the interfaces, and embrace complexity as an intrinsic part of the project. That’s the only way to adapt as information is coming and hopefully handle a lot of changes. If you do well, that’s where the operational readiness process itself is going to help you navigate that.
Paul Turner: And if you’re watching live, if you have any questions, shoot them in the chat. We’ll get David to answer them here for you. I’ve got another question here on project management. Why do several companies want a PMO, project management office, as the core of project management? Is this necessary, maybe? How does that relate to commissioning, project management, outcome assurance?
David Tain: My opinion, yes, PMO offices emerge as a way to standardize project management practices, right? You can see here in the Project Management Institute, right? This is one of the key functions that have emerged progressively and have brought essentially important—I don’t disagree with—a central repository of knowledge. As a PMO that has the right level of governance in projects. However, as I mentioned at the beginning, right, the PMO is a starting point. These PMOs need to be agile and flexible enough nowadays to adapt to the different complexities of projects, right? You have a PMO that is going to give you the standards and the governance of a project, even tools on how to manage particular scopes to how you’re going to control your KPIs. Don’t fall into the trap of thinking that all projects can be managed as a cooking recipe. Yes, deploy your PMO, but always with outcome assurance in mind. Use your standards, standardize your processes for sure, but then never lose the outcome assurance and systems thinking based on that.
Paul Turner: That’s a good recommendation because often PMOs are strong in all those aspects that you mentioned there, but need some assistance or guidance on that systems-based thinking and those outcome assurance elements. Not that it’s not their fault, it’s just not how project managers are trained. There’s not necessarily that systems-based approach, but that’s how commissioning and operational readiness folks can help with that PMO function, to provide that guidance and support right at the beginning with a systems-based approach.
David Tain: Correct.
Paul Turner: If you can achieve a culture of trust, it can provide massive value across the entire project life cycle as teams are much more likely to work together. Great advice from Darren. Anything to add on top of that, David?
David Tain: Culture of trust—and I always go back to the most successful projects that I have been working on—they’re sponsoring greatness programs from the top, as I mentioned, but these greatness programs always rely on the human factor. We talked a lot about this in our previous presentation, and there are formal studies. Deloitte conducted a study in 2012, retaken in 2020 and 2022, which mentions the human component in readiness programs and how a project can lose value if that human component is not taken into consideration. The title, “Operations Go Live,” is the title of the study for anybody that’s curious about what it’s about, so they can just go on the internet and download it.
Paul Turner: Definitely check that out. Please share your experience on preparing and handling the data sets using different stages and how you utilized it for better decisions and for forecasting.
David Tain: It’s interesting if you use a staged approach. You’re going to see that you enter first into the awareness stage. You can’t speak about data sets if you don’t first speak about requirements. Requirements are going to drive what type of data you need and what metrics you’re going to use. You can have simple projects, right, that have two or three P&IDs and 20 isometrics and so on. Or you can have an FPSO, depending on the requirement, where the requirements are safety requirements, offshore and insurance requirements, you name it, right? That’s going to be there, as I said. Depending on the data set that you have, that’s going to be the tool that you’re going to use. For an FPSO project, you cannot manage it with Excel. You probably need that completion management system. If you have a $2 or $3 million project, a brownfield, low-technology project. I don’t like to use monetary value to define projects, I also use the caveat of technology.
A small project, whose data set can be well-managed by a simple tool. You don’t have to invest in that. That’s why you don’t rely on this expert thing that says, “On my next operational readiness, I have this software solution for you.” The management of data sets is going to be driven by the requirements that you have. That’s the importance of this awareness stage in operational readiness, particularly in the APR model that we propose—awareness, preparedness, readiness. This awareness stage is critical because that’s going to be the cornerstone of what you’re going to do.
Paul Turner: You touched on this next one earlier in the discussion, but maybe you have something more to add. What do you think for the next decade of energy projects, about ideally organization, also if AI is coming to energy projects?
David Tain: I trust that predictive models, I personally call them predictive readiness management systems, right? As I said, without being an academic, that’s the way I see it. The role of AI is going to be that all this information is going to be optimized. You’ve got to remember AI capitalizes on existing information. A key example: you go to ChatGPT, and ChatGPT is going to compile the best possible information they have from the network, right? From the internet. The same thing is going to happen with AI in projects. As projects advance, more and more information is going to be available, internal and external.
That’s going to allow you to steer, visualize information risks that are truly risks, or prioritize actually based on criticalities and based on how the project has evolved. This AI, these predictive analytics, are going to help you, especially when you have big data sets, large amounts of information, to simplify the decision-making process, right, without compromising interfaces. That’s the key thing with AI. Simplify—and that’s something I’m working on. How do you simplify decision-making without compromising interfaces by trusting AI? That, to me, is one of my personal research questions that I have, and hopefully, I find the answer, or somebody else does.
Paul Turner: Absolutely. That is the quest for sure. Romario is asking, from your past experience, what’s the most critical lesson learned from a past project that helped mitigate commissioning risk?
David Tain: Ownership, because who wants commissioning, who wants readiness, right? Who wants the transition? I like talking about commissioning, but when you talk about what is driven by a lot of organizations, commissioning is, “Now this is what you have to do,” and I prefer to talk about transition to operations. Commissioning is the key cornerstone, the key role in transitioning to operations. The key lesson I have is: who owns commissioning? How is this deployed? The importance. It’s commissioning-led. Normally, what happens in projects is that you advance in bulk construction, and eventually, you switch to system completion. That switch needs to happen from the beginning. You can’t engage system professionals at the very end. That comes with ownership at the front end. You need to start having professionals who are commissioning-led, systems-thinking-based, that are thinking about the outcome, and that’s going to assure your outcome. That’s exactly what we’re talking about, outcome assurance, right? The big lesson is: think in systems since day one. Complete your scope, yes, for sure. But manage systems, don’t manage scopes.
Paul Turner: You nailed that. That right there is one of the biggest things that’s missing on projects. If project leaders can start with that systems-based thinking right at the beginning, we’d have a lot better outcomes on our projects, wouldn’t we?
David Tain: Absolutely, absolutely, yes.
Paul Turner: How do you detail a project charter through the lens of operational readiness? This would be getting at that early aspect. If you’re setting things up right at the beginning, right from the project charter, how would you view that or take that approach with a lens of operational readiness?
David Tain: When you set up a project charter, that’s the thing. Project charters are really necessary to define the actual boundaries of the scope of the project. However, when you’re talking about an operational readiness lens, you’re talking about an overarching function. You need to define your project charter, but don’t get amalgamated. Operational readiness is an intrinsic transitional function that is overarching between projects and operations, right? When you talk about a project charter, you need to account for how this transition, how it’s going to be, that interface, that functional interface between project and operations. You need to specify that in the project charter. That’s my big recommendation. A project charter cannot be an isolated document floating out there. You really need to ensure that the particular transitional stage to operations is well-defined in the front end. As I mentioned, operational readiness is an overarching function, built from the bottom but deployed from the top.
Paul Turner: Build from the bottom to deploy from the top. I like that. Here’s a big question. If everybody knew the answer to this question, we’d all be having successful projects. So, how do you ensure system turnover and final acceptance to the end user for a smooth transition to deliver a project on time by the commissioning process?
David Tain: When you are in a turnover process and a turnover function, don’t see that only from the turnover process. See it from above. The overarching function that I mentioned before, the turnover is the end result. A lot of things need to happen before turnover, so you can’t wait. If you have a systems-thinking base and outcome assurance, you can’t wait for your final walk-down just to try to avoid a deficiency. You’re supposed to be working in integration with the operations team, and even then, in the most optimal cases, right, when you are pre-commissioning assets, you have your two or three operations people that are probably going to be the ones managing the assets embedded into your organization. When I hear questions about how to ensure the turnover process comes off, you’re pretty much telling me, “How do I ensure the very last minute that everything goes well?” Well, I need to start from the beginning. I can’t talk about the turnover process if I don’t talk about outcome assurance at the front.
My recommendation is to make sure that you’re engaged at the right moment. If not, you’re going to always be in rescue mode. You don’t want to be improvising or addressing final things, or even worse, passing to operations punch lists to do pre-commissioning activities because now your contract is gone. Systems-thinking instead of scope-based is more about engaging the right resources at the right time, and that’s pretty much what operational readiness is about.
Paul Turner: To avoid that reactive element and get to that more proactive ability to predict the outcome of projects for sure. From experience from a previous project, how do you manage exceptions? Maybe I’ll add on that: how do you manage exceptions and how do you manage expectations?
David Tain: Exceptions mean anything that the project couldn’t complete and get passed to operations. That’s what I’m interpreting from this question. The management of exceptions is going to be a direct result of the capabilities of the operations organization and the performance of the project team. The better-performing you are and the better plan you have on the project side, the fewer exceptions you’re going to have to operations. That’s the first thing/ That means, again, you go back to defining the requirements, making sure that you’re complying, engaging the right resources at the right time. If there’s an exception, like a minor exception—say, an insulation car seal—sure, I can give this to operations because I’m not going to keep a project team just to install a couple of blankets or connect a couple of junction boxes at the far end just to switch a flipper in my room.
When you talk about exceptions, if you have a large number of exceptions because you have deficiencies in your execution, that means, not necessarily talking about performance, there are a lot of reasons for deficiencies, right? The organization itself, constraints, you name it. I don’t want to judge how deficiencies can happen. Exceptions are derived from deficiencies. The more prepared you are, the more ready you are, the fewer exceptions you’re going to have. That’s the only way I can see that. Trying to put a silver bullet on how to manage that deficiency is really hard because the sky’s the limit. Anything can happen.
Paul Turner: Anything can happen, and to write all those down as specific rules is impossible, which is why you need those experienced experts with that systems-based thinking who can make these decisions in real-time to guide the project on what’s best to do. Like you said, does it make sense to hold up the project for a simple switch, or not? But if that simple switch is a critical safety device and it’s going to protect a startup of something, then it may. You need the people with the experience who have done this before, who can lead that systems-based approach to make those judgment calls and keep everybody safe and ensure the project ends successfully.
Paul Turner: This is excellent, David. The audience always appreciates your wisdom, insight, and expertise being shared. We’re super thrilled to have you as part of the Institute of Commissioning and Assurance. We’re really looking forward to your contributions as we continue to shape the future of outcome assurance. If people want to reach out to you and get in contact, where’s the best place for them to connect with you and follow up with your work?
David Tain: The best place is always LinkedIn. I’m more than happy. Drop me a note if you have any questions. You can see here, this is my career, this is my passion. Drop me a note. Feel free to connect. Feel free to drop me a note. Let’s have a conversation about operational readiness. I’m more than happy to continue this. Reach out to LinkedIn, and if not, through ICxA, you can reach me through the ICxA website as well. Feel free whenever you want, and let’s just have a conversation.
Paul Turner: Absolutely, yeah. It’s all about connecting and helping projects succeed. For anyone else that’s watching, if you’d like to learn more about ICxA, learn more about David, or how we’re working with leaders like David to transform project outcomes, visit icxa.net, and we’ll be sure to help you out. And of course, connect with David on LinkedIn as well. Thanks for watching, everyone, and have a great day.
David Tain: Thank you.
Paul Turner: Thanks for listening.
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