EPISODE 007

007 – Front-End Planning: How to Set Billion-Dollar Projects Up for Success with Roger Farish

Description

In this episode of The Major Project Podcast, Orion sits down with Roger Farish, a front-end planning specialist with 25+ years of experience at Bechtel, Fluor, Linde Engineering, and Kiewit, delivering major capital projects in LNG, refining, petrochemicals, renewables, power, and mining. riverside_the_major project pod…

Roger walks through his path from mechanical engineer and field engineer to portfolio leader and, now, consultant—highlighting how each role reinforced one core lesson: the front end is where projects are won or lost.

He breaks down what Front-End Planning (FEP) actually is—FEL stages, stage-gate processes, “concept / select / define / feed / pre-feed”—and how best-practice frameworks from CII and AACE help owners make disciplined, data-informed investment decisions instead of “gut-feel” commitments. riverside_the_major project pod…

Roger explains tools like the Project Definition Rating Index (PDRI), how it measures scope maturity, and why facilitation matters when project managers are (understandably) biased to push scores down so their projects clear the next gate. He shares stories of uncovering gaps where deliverables were claimed “complete” but hadn’t even started, and how structured reviews surface misalignment before billions are committed. riverside_the_major project pod…

From there, they dive into:

  • “Too big to start” mega-projects that are so large almost no EPC is willing to take on the risk—and how Roger helped one client shrink a project so at least two competitive bids were realistically possible.
  • Using historical data to separate systemic risk from project-specific risk, even when owner data is messy or inconsistent—and why there’s always something to learn if you dig deep enough.
  • The reality of execution bias, where projects gather political and emotional momentum that makes it hard to pause, re-scope, or walk away—even when the signals are flashing red. riverside_the_major project pod…

Roger also shares his views on AI in major projects: why a lot of “AI” tools today are really rules engines with new branding, why execution-phase use cases will likely mature faster than front-end ones, and how he’s already using AI as a teaching and mentoring assistant for younger engineers.

Finally, he offers career advice for students and mid-career professionals who want to move into front-end planning—covering the value of cross-discipline experience (field, startup, process, economics), and why a mix of engineering, finance, statistics, and project controls is such a powerful foundation. He closes by describing how his firm now supports owners, EPCs, and OEMs on estimating, scope definition, risk, governance, and FEL management across the front end of their capital portfolios. riverside_the_major project pod…


🎧 You’ll Learn

  • What Front-End Planning (FEP) actually is—and how FEL stages and stage gates fit together
  • Why early decisions shape cost, schedule, and risk outcomes far more than tweaks during execution
  • How tools like PDRI measure scope maturity and correlate with better cost and schedule performance
  • How to recognize and counter execution bias and “too big to start” mega-projects
  • Ways to use historical data to separate systemic risk from project-specific risk
  • Where AI is (and isn’t yet) useful in front-end planning and mentoring
  • How organizational culture and change management affect governance adoption
  • Practical career paths into FEP—from field roles to process engineering to project controls
  • Key best-practice resources: CII, AACE, and IPA’s Capital Projects

Transcript

Host: [00:00:00] Welcome to the Major Project podcast, your inside. Look at the high stakes world of billion dollar projects.

Orion Matthews: Welcome to the Major Project podcast. I’m your host Orion Matthews, and today we’re diving into one of the most critical and often misunderstood phases of billion dollar projects, front end planning. Joining me is Roger Ferish, an industry veteran who has spent decades shaping major capital projects from concept to execution.

Roger has 25 years of experience with Quit Lin Flo Bechtel. He’s delivered projects across natural gas, LNG, refining, petrochemicals, renewable fuels power and mining. So today we’re going to leverage this background to learn the insights and pitfalls that undermine project outcomes, and hopefully find some proven practices that can help avoid them.

So Roger, welcome to the podcast. 

Roger Farish: Thanks Orion, [00:01:00] and, and thanks for that very kind, uh, introduction. Happy to 

Orion Matthews: be here. Awesome. Well, we’re really happy to have you. And before we get started, maybe you can share a little bit about your background, sort of how you got into the major project space. 

Roger Farish: Yeah, sure.

So like you mentioned, uh, roughly 25 years of experience. I have to go back to my college days. When I was trying to figure out what I wanted to do when I grew up and I, I was a mechanical and I am a mechanical engineer by trade. So I went to Tulane, got my bachelor’s and master’s, uh, and mechanical engineering from there.

And when I was looking to go and go out and do workforce, I knew I wanted to do projects. Just the, the question was gonna be, uh, did I wanna work more on the owner side or did I wanna work. On the contractor side. But I knew I wanted to work on big projects and, uh, that’s where I got drawn more to the contractor side because I think they did a better [00:02:00] job at selling these mega projects.

And the truth is that owners do a lot of mega projects, but I think their ongoing stuff is a lot more on the smaller side. And contractors, especially the big contractors, the one that I, the ones that I was drawn to really make a lot of their profit on a yearly basis on the very, very large projects.

So I was, I was really drawn to the contractor side and I ended up, uh, like you mentioned, hired on, uh, with Bechtel and I went to work at one of their DOE sites. Which was actually recommended to me, but one of my, one of my my, uh, my advisor, my thesis advisor said, Hey, I know of the site. In South Carolina, uh, where one of my colleagues works at, and they are kind of self-contained and they do everything there.

They do self-perform construction. They do in the engineering, they do their procurement, they do everything. They have greenfield projects, they have brownfield projects, small [00:03:00] projects, mega projects. Like that would be a really good opportunity, you know, to, uh, for you to go out there. So let me connect you with, with some folks over there.

And so we got connected and that helped a lot, of course, in the process. And I went there and I got, I had a chance to do, uh, all of that. Started off as a design engineer supporting a lot of projects. I was in a kind of specialized group. And then very quickly, uh, Bechtel moved me out to a job site.

And, um, that was, that was great. You know, once I, once I went out there and I was working construction, running work packages, leading work packages and, and leading actual multiple work packages at one point it was just so rewarding. And, uh, ultimately that led me to make a move to Flor. I went to work with Flor in Greenville, South Carolina.

I, uh, had a chance to be exposed now to different industries while I was there. Worked on some power, some chemicals, some uh, biotech some [00:04:00] mining. Had a functional assignment in project management overseeing. Their project management processes. We were looking at their highest profile projects, uh, which was great.

We did a lot of, a lot of lessons learned to incorporate back into the processes. So that was an amazing experience. They moved me from Greenville to Houston and there had the chance to take on more and more responsibility, ultimately becoming a project manager, and then had an opportunity come up with Lindy Engineering.

And I, uh, moved to Tulsa with, uh, with Lindy, and I was overseeing all of their EPC projects in North America. That was about a $1 billion portfolio. Again, an amazing experience. Had a bunch of people reporting up through me, all project managers project engineers for Lin Engineering.

Had a bunch of projects going on. We had four [00:05:00] offices in the US where I had functional responsibility over project management. We also had the headquarters for Lindy Engineering in Germany. We had a very challenging project that was happening in Canada, so it was, it required a lot, a lot out of me. Uh, but it was an amazing learning experience.

A little bit unsustainable, as you can imagine, having all that responsibility, uh, multiple time zones, offices, folks, and ultimately landed at Kiewit where they were building up their engineering capabilities and oil and gas. And they involved me doing a lot of lump sum bids for EPC projects. As you can see, I’m now doing a lot more work on the front end of projects, which I had done also at floor.

And, uh, did that for several years. Co-led a big, uh, joint venture pursuit. With a large, more engineering focused EPC contractor. Then did [00:06:00] some more, uh, lump sum estimating, and then I was more in the feed phase actually leading, um, the, uh, feed efforts, uh, for some of these, some of these projects.

And, uh, my last couple of assignments were on the very, very front end projects, FFL one, FFL two for large mega projects. And, uh, also led the implementation of a, an estimating software at, uh, a keyword to help them just perform better estimates and support of these early phases of the, of projects.

Uh, and then about a year ago. Uh, I made the move to, um, to consulting. I, I thought that it would be a great opportunity to be able to bring all that skillset and help clients directly and helping them reduce costs, uncertainty on the front end of projects so they could ultimately make better investment decisions.

So that’s what I’ve been doing for the last year or so, [00:07:00] focused on three, uh, main elements. We do a lot of estimating. We do a lot of scope definition and scope reviews, and we also do risk assessments, risk workshops, uh, risk management and then we also sometimes manage the entire front end phase on behalf of the owner.

So as an owner’s engineer. And, uh, we also do some, uh, governance evaluations and support in terms of processes, so PMO processes, governance, pro processes. So a little bit long-winded but, uh, that’s the, uh, the breadth of my experience up to now. 

Orion Matthews: Well thank you for that summary. It me, it’s great to hear about your career.

And one thing that kinda strikes me is starting as a mechanical engineer coming up through the ranks on the sort of contractor side going out into the field, you’ve sort of done it all. You know, you’ve been in the project management space, you’ve led teams. Why when, when you, you know, and you got to the end of this amazing career and you said, Hey, I’m gonna make a jump into [00:08:00] consulting, the very common path, when you’re at that point, you can kind of choose where do you wanna work within this massive spectrum of things.

And maybe this leads into our topic of front end planning, but why choose front end planning Out of everything that you can focus on you, you sort of narrowed down and said, this is the area for me, this is what I wanna make a difference in. And I’m kind of curious to kind of hear what your thinking was on that and what inspires you about front end planning?

Um. 

Roger Farish: No, no, that’s, that’s, that’s, that’s a great question actually. And I had that decision to make, you’re exactly right. When I was kind of trying to figure out what was gonna be the next step in my career, and you look back and you look at all the projects that you’ve done, and you see where you’ve had that ability to influence the project the most.

And it’s always at the front end of the project. The decisions that projects made during that development phase [00:09:00] really shaped the project and can sometimes make or break a project. I like to take tell folks that if you do everything right in the front end of a project, it is not, it’s not a guarantee that your project is gonna be successful ’cause you still have to execute, but it just gives you that much higher likelihood that you’re gonna be successful, like exponentially higher.

And conversely. If you skip some steps in the front end or you go through it too hurriedly or, uh, you take some shortcuts or you don’t know what you’re doing, you know, you’re doing what you’ve always done, and then the likelihood of you being successful is quite low, significantly low, exponentially lower.

So that’s just that, that perspective said, okay, well where can I add the most value to projects then it’s definitely at the front end. So that’s where it led me to, to really being focused on that side of projects. 

Orion Matthews: Well, [00:10:00] I’m, I’m excited to learn from you about this, so maybe we can get into the front end planning a bit and before we do that.

I think a lot of people in our industry have zero experience with front end planning. They, they arrive after the decision’s made and maybe they’re in execute. So perhaps for our listeners and for my benefit as well, you can kind of give us a little 1 0 1, like what is front end planning at its 

Roger Farish: core?

Yeah. I mean, front end planning is all about a lot of what a lot of the front end planning processes that are in place are based on a stage gate approach, which you may have heard of before, which is kind of a waterfall project approach. And we hear terms like FEL zero, fel one, FE two, FEL three, and there’s also other terminology.

Terminology like. Initiate or assess. Uh, you have also terminology [00:11:00] like concept feasibility select define. Those are all kind of, you know, I, I kind of talked about in, you know, in order sometimes you hear feed and you hear pre-feed or I pre-feed usually before feed. Mm-hmm. Um, so, so all of those are, are front end names for the different for the different stages in the, in the process.

And usually you have a stage, like I mentioned, the FE one stage, FEL two, stage a field three, uh, stage. Then at the end of a stage you have a gate, you, so you have a gate review. And typically you review everything that’s been done up to that point. You review, you usually have a, uh, an economic analysis that’s associated with that.

You have kind of a checklist of all the things that are required to perform that gate review. And, uh, there’s usually a request of funds to continue with the project and usually a recommendation, right? Should the, the project continue? Should it go on hold, uh, should it go or recycle? So there are [00:12:00] options, right?

There are exit ramps for different projects. Uh, and if everything still makes sense, then the project moves on to the next stage. And then, uh, so on and so forth. So that’s kind of the essence of the front end planning process. Uh, but the whole idea is that organizations are taking a disciplined and structured approach to making those decisions so that they’re making the best possible decision and how to invest their capital.

Orion Matthews: So then just kind of repeating a little bit here, FFEL 0 1 2, maybe three, and concept select pre-feed. Uh, define. These are all before that sort of common term of execute, and maybe different organizations have different ways of framing it, but essentially it’s a number of steps intersected by a, a stage gate review where you have an event, either a, put it on hold, move it forward, but essentially these terms are somewhat interchangeable, is what I’m [00:13:00] hearing from you.

Maybe not completely interchangeable, but custom or different for each organization. 

Roger Farish: Yes, every, every organization has, I wouldn’t say every organization has different names for them, uh, but a lot of them have different names for them. But effectively they all, uh, mean they have very similar meaning. Uh, and there’s, there’s some industry, uh, best practices out there that kind of outline what that should be.

So the one that I rely on a lot are the definitions by the Construction Industry Institute, CII. So I participate a lot on, uh, on, you know, I participate with CI activities. And follow what they have published because again, it’s sort of industry standard and they just don’t, they’re not, they’re not, uh, they don’t only focus on one particular industry.

They have breadth in industry. So they focus on infrastructure projects, on industrial projects. Uh, the industrial [00:14:00] project category is very broad. It effectively impacts most of the process intensive types of projects. So that includes upstream oil and gas, uh, midstream, uh, downstream chemicals, some of your, maybe some of your, uh, renewable projects that are process intensive, uh, that you have out there, like, green hydrogen or renewable natural gas.

And then you have also, um, that have infrastructure and pipeline infrastructure projects that would impact things that are more linear. Like roads, uh, bridges, even pipelines. They also have a category for manufacturing and life sciences projects. Uh, and then also they have a category for um, a missing apps.

Well they have mining, mining projects. Yes. Yes. Category for mining projects. Yes. Uh, and they have also, uh, from, they have also, uh, when you, where we were looking at into more [00:15:00] detail and some of the additional tools, they have some segregation on big projects and small projects. So again, yes, I, I kind of prescribe to the CI methodology.

This is a great guide. And they’re also a not-for-profit organization, uh, which is great, you know, that keeps things objective. 

Orion Matthews: Well, so let’s say that I, you know, it’s just scenario plan this a little bit. I am an executive at a large owner. Organization. Um, let’s say that I just got done looking at a project and learning the Roger lesson that, uh, hindsight is 2020.

We just finished this project. It’s way over budget. If only we had done a good job in the planning phase. You hear this all the time, and I, as an executive are like, that’s it. We’re gonna get the best front end planning process ever. What does that look like? How do I as a project leader get the best front end planning for [00:16:00] my organization?

Like what does, what do you see as things that maybe organizations should be thinking about or I should be thinking about now that I’ve learned the lessons, I’m ready to take that step. What do I do? 

Roger Farish: Yeah, I mean, there are so many variables, right? I think you always have to, the, the first question would be, are you more.

Focus on singular projects. So if, if you’re a smaller organization, are you doing mostly let’s say that you’re just developing projects and you’re doing a one-off project and you, your organization’s fully focused on just that one-off projects. They’re gonna complete that project and then they’re gonna find another project and they’re just gonna go one by one.

Then the objectives are very different than if you have a portfolio of projects, right? Because then you are trying to find something that can permeate to all those projects and influence all those projects. And then you’re, you’re, your governance structure is gonna be [00:17:00] very different. So it really is owner dependent.

And even beyond that, there are some owners that have different objectives, right? Some of them are, they need to, in, in projects have different objectives, right? So some projects are very much schedule driven because there is a competitive advantage associated with speed to market. Others are more sustainable, sustained type of projects, right?

Or, or more of a measure growth type of project. Uh, and some of them have different profiles in terms of size, in terms of risk. So to me, the best type of governance set of processes are the ones that are best fit to the particular organization. So it’s, again, you have so many different variables, but the ones that not only are best fit for your organization, but the ones that are gonna actually be used by your organization.

And then you get into cultural types of issues, right? [00:18:00] So in looking to implement a new set of processes, you really gotta look at, uh, your change management side, right? So your organizational change management side which is more of an organizational behavior type of issue. Uh, but you need to be aware of that.

Like you need to have buy-in from executives, you need to have from different layers of management. You can’t really make usually that big of a change. If a culture of, because of the company culture and things have always been done a particular way, you can’t just go from, for from one side of the coin to the other one, right?

So you have to evaluate all those things so it’s not just the one that’s, that’s best fit for the organization. So one that’s best fit for the organization at that particular time. And sometimes there’s, there’s a kind of an evolution that, that organizations go through as they continue to mature and become more mature in how they govern, uh, their capital projects.

Orion Matthews: So sometimes they say that projects are too big to fail, [00:19:00] and then sometimes projects might be too big to start. Maybe could you take us through kind of maybe what those terms mean too big to fail, and then maybe from the front end planning side, too big to start. What does that look like? 

Roger Farish: I’m not sure about the too big to fail one.

I’m you, you know, uh, as projects get bigger. The risks become exponential, uh, because you just have an increasing number of interfaces. So the more interfaces you have on a project, then every one of those interfaces has not only additional cost, but additional risk. So, these like monsters of projects that have all these interfaces really are the riskiest of projects.

And I know Bechtel, a few years ago, published that [00:20:00] 98% of mega projects, so a billion dollars and above. Fail to meet at least one of their objectives, whether it’s cost, schedule, or another, uh, very important project objective. So it’s, and so I think it’s representative that actually the bigger the project, the riskier the project and the more likelihood and almost certainty that there’s gonna there’s gonna be, the expectations are just not gonna be met.

Uh, on the other side though, what you talked about, uh, so how do, how do some clients manage this? Is they try to scale back projects? Uh, so they find ways to de-risk projects. And actually I was lucky enough to help a client with that. Uh, a couple years ago they were trying to build a mega, mega project and it was so big that they would likely not be able to find an EPC contractor that would take on the majority of the risk.[00:21:00] 

The execution risk. So we helped that that client scale down the project to what we thought was gonna be kind of a maximum size that they would be able to contract and have at least two bids come in, uh, that they could evaluate side by side. So an interesting exercise in trying to de-risk a project just by looking at things like the, the overall size of the project uh, and what’s available on the market to execute the project.

Orion Matthews: So maybe take us through that a little bit. From one perspective I really wanted to talk about, which is bias it in my and limited experience. There’s sometimes a bias to execute when you’re in this pre-planning stage. ’cause big projects are exciting and they’re big economic events. So I think in general there might be a little bit of a bias towards.

Trying to execute a project. How do you inter, how do you intersect that as an [00:22:00] expert in front end planning and sort of work through that bias or, uh, coach people on it? What would be your advice for organizations on, on, uh, sort of execution bias, so to speak? 

Roger Farish: Yeah, I, I hear you a hundred percent. I, there’s a very ref, like very good reference project that happened some years back you know, more than 10 years ago.

But in the Midwest, a big downstream project. And it was originally thought to be, I think, around the value of X and it’s a mega project. And then billions, 

Orion Matthews: basically. Yeah. Billions. Tens of billions, yeah. 

Roger Farish: Yeah. Yeah. And the, the, um, the finished the cost, the actual cost was, I don’t know the exact figures.

I’ve heard different people say different things, but between two to four x of the sanctioned amount, and we’re talking [00:23:00] billions, right? Mm-hmm. Uh, so significant overrun and significant, uh, schedule delay. Um, and it’s one of those projects where once it gets so much momentum sometimes is just difficult to step away from it, you know, to take a step back and say, okay let’s, uh, let’s take another look.

Let’s take a second look. Uh, let’s bring in a, an expert that can tell us what is the likelihood that we’ll actually be successful. So yeah, it’s, some of these projects gain momentum. And, uh, what we do is again, try to bring that objective, at least from, from my side, is bring that objective point of view.

And tell ’em, look, have you thought about this? Have you thought about that? And these are the potential risks. And these are the downsides associated with that risks, with that risk. Let’s look at some of your historical data, right? How as an organization have you been performing?

How [00:24:00] has systemic risk been impacting your projects? How has project-driven risk been impacting your projects? There’s different ways that you can manage each one and that you can have at least a point of reference on what to expect going forward. So there’s so many things that you can do in terms of, of risk management risk mitigation, so you get a better understanding of what you’re getting yourself into in some of these mega projects.

Orion Matthews: This is a good segue into data. It sounds like a lot of your analysis might be data driven with historical data sets, benchmarks, KPIs. Maybe can you talk through that a little bit and maybe some of the challenges you face, I know working inside large organizations, sometimes data scarce or mixed up, like how do you sort through all these prior projects and in to help inform a decision on a potential new project?

Roger Farish: Yeah, it takes a lot of work, right? I wanna say it [00:25:00] takes a lot of work. You have to dive deep into the data, and the data usually doesn’t tell the entire picture. Like if you want to correlate your data and try to separate, we try to separate systemic risk. With more event driven project risk so that we can get an idea of, again how systemic risks are impacting a client’s projects and how those projects, more projects, focus risks are impacting them.

How are they managing those things? So we have to dive deep and do a lot of conversations and interviews with project managers that were involved. And sometimes you get the right story, sometimes you don’t, you know, so there’s that. You don’t want just one data point in terms of talking to folks that were involved in the project.

So it, it takes a lot of work in trying to analyze that data, both quantitatively as well as qualitative qualitatively. Different clients [00:26:00] track, uh, data differently. Some clients have a lot of data, others don’t have as much data. The ones that have, uh, a lot of data, though sometimes that data is very messy.

And so they’ll capture it one way in one project, another way in another project. So again, there’s a lot of effort that goes into that, but typically regardless of all of these challenges we’re able to gain insights from that data. That’s an important part, right? No, no existing owner data that we have reviewed to, not to date, has.

Told us there’s nothing to learn here. No, there’s always lots to learn. Uh, and then we can use that data to help these organizations make better decisions going forward. And that, and that thing in the end, that’s the golden nugget, right? That, that we get Sometimes the, the nugget is, is larger for, for some organizations that others but we, we always find something that owners can leverage.

Orion Matthews: So maybe you can take us through a story [00:27:00] here. Let’s pretend, I suppose this happened to you before. You’ve got your data, you have a notebook, and you’re walking into a boardroom or C-suite at the end, at this stage gate moment, and you’re gonna present to leadership. Can you talk about what that process is?

You go in with your sort of Roger. Cliff notes, like how do you go through that process of sharing your findings and moving and having that critical conversation, that stage gate moment? What does that look like for organizations? Maybe you can give us some stories. 

Roger Farish: So actually I, I have not yet participated in the reviews.

We support the reviews. The reviews are typically done by owners. I know that there’s some consultancies that do, uh, assurance and reviews of stage gate, uh, packages. We have not done that yet. So, specifically as it relates to stage review, haven’t been in those shoes, but definitely, you know, have had the chance to have those conversations at the end of a [00:28:00] particular assurance review.

Uh, whether it’s for risk or for scope or for cost on the estimating side. So to me, the, when we get to the end, uh, it’s just a presentation of the results and, uh, but, but to me, a lot of the conversations happen through the process, right? For example, when we’re doing A-P-D-R-R review and we’re looking at scope maturity and, uh, we start having these conversations about, uh, trying to grade the maturity of a project.

Uh, this happens a lot where a project manager wants to have a very low score. And in P DRIs, the lower the score the better. Uh, and just 

Orion Matthews: for our audience, what’s a PDR In? PDRI? 

Roger Farish: Oh, PDRI, it’s a project definition rating index. It’s a tool from CII that helps you score the maturity of a project. So the more mature project is.

Then the better defined uh, the project [00:29:00] is. And then, uh, CII has actually conducted research to demonstrate that lower score ultimately yields better project performance, both in terms of cost and schedule, which makes sense, right? The, the more develop your scope as and the less risk you have. And then the better definition, if you think of the estimating side, the, the better the, the quality of that estimate the, the less likelihood that you’re gonna have surprises.

That also helps you fine tune your schedule. That’s what PDR reviews. And we do lots of PDRR reviews. I have done them also in the past, and we do ’em as part of our practice. And, uh, as we, uh, facilitate these sessions, uh, we see project managers who want the project to keep moving forward. I try to push the score lower so it scores better.

So again, when you get to that gate review, the score meets the threshold. Uh, but then that’s part of the [00:30:00] facilitation process is you wanna facilitate ultimately getting at the right score. Uh, and that’s not necessarily the score that the project manager wants. So we have, we have, we ask a lot of questions.

We have, we ask these probing questions and we try to make sure that everybody has a voice. And again, that’s part of being a experienced facilitator to get to the bottom of, is that really the score or not? And I’ve seen it many, many times, a project manager is pushing for a lower score.

But then we ask questions, especially as it relates to a particular deliverable that should have been issued. The PDRI methodology has different scores for different levels of developments for particular deliverables. And, uh, you have no many, you have no idea how many times the project manager claims that the deliverable is complete, issued, like final, but sometimes the deliverable has not even been [00:31:00] started.

It’s, again, it’s just this bias like you talked about from, from particular individuals, uh, because they have motivation, right? Like in this case, the project manager loves his project, of course, and wants the project to keep going forward, and he’ll do anything and everything to keep, keep moving that project forward.

He might even know that there’s some gaps. He might not, right? In this case. In some of these cases, they were just unaware. They thought that these deliverables have been issued, and sometimes there was a confusion, misunderstanding of whether the deliverable was right. But they just want to keep moving that project forward.

And sometimes they’ll find these sort of sneaky ways to do that. And that’s, that’s one particular case. Uh, an example of that.

Orion Matthews: That’s, I think that bias is really fascinating and combined with the outsize impact that you have in the front end planning process. It must be a real skill to facilitate people.

And what I kind of heard from you is that [00:32:00] as you go into those stage gate conversations, a lot of the groundwork has already been done. Those aren’t really surprise conversations at that point. You’ve already kind of talked with key stakeholders, maybe big advocates, probably given them some. News that maybe that, that they don’t wanna hear or, you know, just sort of talked through all the pieces with different people before you even enter into a stage gate moment.

Does that sound about right or is it more of a bit of a surprise and you go through a lot of the interviews and then there’s sort of a reveal? Like how does that, how does that work? 

Roger Farish: Yeah. So there’s two facilitations that we do. We do risk workshops. So when we do risk workshops, we’ll typically have private interviews with, uh, some of the major stakeholders in a project.

And in that case we, you know, you have an open one-to-one conversation, so that makes it a lot, is confidential conversation. So we use that [00:33:00] information to help arrive at, you know, our final risk analysis. Uh, when we do A-P-D-R-I facilitation, it’s different, but by the way, when we do a risk analysis, we also do a risk workshop.

And that’s, we have, so we have a group, a group dynamic. So we have a, a risk workshop with the entire team, but then we’ll have individual interviews that are separate. So then you get, you’re able to get that individual perspective. When we do PDRI, we don’t have that one-on-one, uh, private conversation.

So then that’s when it’s that much more critical to be a good facilitator. And as a, as an experienced facilitator you kind of, you should know who should be answering the different questions. And if the, again, if the project manager is answering on behalf of them, then you need to, you need to know to, you know, go straight to them and say, you know, thank you Mr.

Project manager, but I wanna also hear from so-and-so. Right. And, I wanna say that for, it depends on the type of project. Typically, if you have more of a task [00:34:00] force, uh, type of project, the project team is a lot closer and they all kind of know what they’re doing. And in those cases, I really like to understand who’s part of the task force and who’s not part of the task force.

Because the folks who are not part of the task force are usually the ones that will give me the answers that are somewhat different from what the project team knows because they’re just not in touch with they’re not touching base with each other as, as often, right. So I find usually a lot of gaps there.

And then you, if you have more of a, of, um, of not, not a task force type of project a non-task force type of project, then that usually just requires that, usually I allow more time for those sessions because I know that there will be even more gaps. In those discussions. And then it’s more of a, uh, kind of a, I, I try to find the individual that is, that is, because sometimes it’s a major discipline, [00:35:00] a major part of the project, and that person sometimes is just not that engaged in the project.

And to me is trying to go through that facilitation session to figure out who that person or persons are through asking all these questions. And sometimes, yes, there are some surprises. You would think that there would be more alignment, and sometimes there’s not. So it’s a little bit of, of a fun like fact finding, um, facilitation process to figure out who’s that person, who’s just not that engaged and, uh, where, where we have a gap, uh, in the scope.

So it’s, it’s fun. It’s fun and, uh, again, it makes it engaging. And again, you’re, you’re, you’re bringing, highlighting those gaps that are so important back to the project team. That serves as alignment and to understand, okay, well this person for whatever reason right is not, uh, we have, we have a gap there.

So, so then it gives the project manager that action to go and get alignment with that individual, with that function. 

Orion Matthews: So I’m [00:36:00] curious ’cause you’re really experienced facilitator and a lot of mega projects that we work on might be in other countries worldwide initiatives. And I find one of the really fun things about our industry is to be exposed to a lot of different cultures, ways of thinking vary by country.

And so I’m curious that to hear if there’s approaches to understand, because when you talk about something like risk or identifying the gaps, there’s different cultural norms about how to express those things. Maybe you can talk a little bit about approaches that you might use in facilitation too.

Understand the cultural context and sort of appropriately navigate those pieces to, to come, to, come to your finish line. 

Roger Farish: Yeah. No, I hear you. I unfortunately do not have that much, uh, international experience as it relates to [00:37:00] facilitating workshops, but I definitely have project experience as it relates to working with international companies.

And I, I understand a hundred percent, uh, what you’re talking about. There’s a very big difference in working with south American cultures, uh, versus working with Asian cultures. And even within Asia, there’s different places that have very different cultures, right? Um, there’s very cultural big cultural differences difference between how Japan does work versus how the Philippines does work.

Uh, where the Philippines are very, very much aligned with how the US works. Uh, so. And then again how work is done in some of the European countries and even within European countries, depending on, on, even within a particular country, there’s differences, right? Uh, I had the experience, uh, with that working with Lindy, where they have an office in Munich and they have an office in Dresden.

And you know, the Eastern, uh, European culture in Dresden [00:38:00] is different from more of the southern, uh, Germany culture in Munich. So even within a particular country, you have different cultural communication aspects that you need to take into account when you’re working in project teams. So, look, I’ve been, I’ve been lucky to be able to do that, but you definitely a hundred percent need to take all those things into account, especially if you’re acting as a project leader or a project facilitator.

Orion Matthews: Yeah, I had, I worked one time in, in Asia, and I was working with a customer and so I was like, oh, this will be a different cultural experience. So I read up on it on the internet and it was like, oh, this is a very formal culture. You’ll, you know, everybody wears ties, blah, blah, blah. And so I got on the Zoom call and I had this like, outfit on and I was like, I’m gonna be appropriate with culture.

And they were just like, what, what are you doing here? And it was like this moment where I realized that culture also changes super fast. And so sometimes even what you read about in, uh, a book or something about how a culture is, could actually be very [00:39:00] different than either the organizational culture or like a micro culture.

So it’s, it’s very hard to stereotype, you know, people are all individual. But but it’s also good to understand those like levers of maybe where culture came from too. And I think that makes things really fun, uh, when you’re working on these big projects with lots of international teams. 

Roger Farish: Yes.

Yeah. And, and a lot of times what you mentioned is you have project team members who have had also, conversely, they have had that interaction with with other cultures, right? So they work on maybe in a lot of international projects. So they have also adjusted their approach. Uh, which is great, you know, it’s very refreshing.

So yeah, it works. It works both ways and you just, like you mentioned, you just have to be, you have to be aware. You have to be, uh, understand what it could be. But you, you also need to understand that a lot of them have grown [00:40:00] accustomed to those elements as well. So, which is, which is really helpful.

Orion Matthews: Well, let me shift it up a little bit. I wanted to just dive back into the question about data, because it sounds like there’s a lot of data processing in your space. One of the big changes over the last few years has been the introduction to ai, and I would love to kind of hear, you know, we, we talked about benchmarking data.

There’s a ton of unstructured benchmarking data, and then I believe like IPA organization has a lot of owner data and I would love for you to just sort of talk about, maybe, maybe the data landscape just a little bit more, but also take us through how you see AI impacting this space over the next few years.

Roger Farish: Yeah. So yeah, we work with, we work with a lot of data and we, uh, reference a lot of data sources. So we’re in the cost uncertainty space, so we need to have lots of different [00:41:00] references to ensure that we are using the right, uh, data and that the data lines up. Yeah, we subscribe to, um, to different data sources to support our work.

Uh, and some of them are, some of the data sets are better than others. Uh, we have really, for example, really, really good cost data for work in the US and as we start getting internationally than the quality of the data is not as robust. That’s just unfortunately, uh, the nature of, of the beast.

The, uh, a lot of the, uh, international projects and, um. The databases for other countries, other regions are just not as developed. And it also correlates with the fact that in some other regions, for example, some factors in developing cost and risk are not as, don’t drive as much as the cost, right?

So for example, in some of the Asia Pacific and Middle [00:42:00] East projects, labor is not as big of a risk as it is in North America, right? Uh, and so that kind of correlates with the quality of the data. So it, it sort of makes, makes sense. It aligns with, with each other. But, folks like me who are consultants, we don’t have access to the IPA data.

Owners have access to that, but unfortunately we don’t. So that’s, that’s, uh, but that’s, again, that’s something that an owner might elect to do. Depending on whether there’s a potential potentially good fit for them to do that. There’s obviously they would need to also contribute the data.

And when you contribute data, you need to contribute all the data. Well, that’s, that’s what you should do, right? Because if you, if you, if you think about it, if you’re not contributing all the data, then that means that some of the other, other organizations are not contributing all the data. And then what does that mean?

That the data is not a good dataset? So there’s also some risks there in understanding, okay, well, what are owners actually submitting in terms of the dataset. So there’s a [00:43:00] little bit of, I wanna say it’s, um, lack of transparency when you work with an organization with IPA, but again, it’s another resource that, uh, owners can use.

Uh, but also touching on the point of, of ai, um, so far our experience with AI has been mixed. Um, we’re trying to integrate some AI in performing our analysis. Uh, but to date, we just haven’t found good enough platforms to support that, but we continue to assess them. But in terms of, uh, writing reports we, we definitely leverage ai.

Uh, we leverage, I’ve leveraged AI in getting some of my less experienced engineers and cost estimators up to speed. So that’s been very helpful. Teaching them a workflow for when they have questions, how to use AI to understand some elements that, uh, that might be more obscure or maybe is not their particular [00:44:00] forte to learn.

Right? So they use ai as it relates to a particular project, and so far we’ve been leveraging it and, uh. We found it a great resource. Like it, it a learning, a teaching resource for our engineers that are less experienced. So that’s been, that’s been great. You know, it keeps a lot of my time because I spend a lot of time mentoring and tutoring our younger estimators and engineers and that just takes a lot of time off of, off of me.

So that’s been very helpful. And we usually then have just a summary discussion to ensure that they understand the concept well. And then, you know, if they pass the test, then we can move. 

Orion Matthews: So I know you’ve been going to a lot of conferences just to push on AI slightly more, and maybe this broaden it up beyond just front end planning.

Is there anything you’ve been seeing, because I, I mean every other conference seems to highlight AI today. What kind of things are you seeing that have gotten you really excited for the major project space in ai? Are you seeing. Areas that you recall from those conferences that [00:45:00] are particular that we should watch out for?

Roger Farish: I hear a lot of talk, but to me the proof is in the pudding. So I am a little bit more on a weight and c mode. I’ll give you an example. There’s a particular, uh, let’s call it a software early design software bolt on that we’re currently evaluating and it’s AI driven, but we’re, we’re finding as more rules driven than AI driven.

I mean, in the end, I mean, AI is sort of, rule space anyway, it can be, right? But. You know, I think that some people are calling a lot of rules-based processes, ai, and I think it’s a stretch. Again, we’re, we’re just trying to evaluate things that are out there and to see if there’s true ai that’s being implemented into processes that, that we could use and, and what we do, uh, in the front end.

I think that there’s, there’s a potential for more. Our, the work that we do is very [00:46:00] bespoke. It’s very much one off. It’s not that repeatable. Some elements are repeatable, but not that many. I think when you get more on the execution side of projects, there’s a greater opportunity. And I think that what we learn from the execution side will ultimate, ultimately permeate into the front end.

But I think yeah, there’s a much greater opportunity for implementation of AI in the execution side. 

Orion Matthews: Well, and I, I guess I’ll, I’ll share my thoughts a little bit here on the term, AI has become a marketing term. And so I, I remember being in the data computer space we, you know, there was a time when everything was client server, it lived in your closet and then everything moved to the cloud.

And I had conversations with engineers that said, well, I’m a, I’m an exchange server admin. That’s what I do. And the cloud is not what I do. I’m not a cloud engineer. And I had to tell them, I’m like, look you are a cloud engineer now. You’re cloud, everything is the cloud. And they’re like, well, technically it’s not actually, this is not really [00:47:00] technically the cloud.

And it’s like, no, this is the cloud unfortunately for you. And so I think trying to tease out what is actually AI versus what is just a new rebrand, I think within like a couple months of AI becoming hot. Salesforce changed their title on their homepage to be like the AI enabled platform for the future.

I don’t think they just built it from the ground up with AI in mind, of course. But like that sort of shift happens and it does dilute the ability to kind of tease out what is actually AI here and what is just maybe a really complicated decision making tool that’s using really, uh, standard sort of computational models.

And so, yeah, I’d say it’s good to watch out for that and and keep an eye on it, but that’s great advice that AI is probably making the most gains right now and the execute side of things, abilities to like, have it identify cost overruns before they happen, or potentially [00:48:00] integrate site photos into schedule and, and do visual analysis of things and stuff like that.

But when it comes to sort of bespoke stuff, maybe it’s not as helpful. Because you’re taking so many different learnings and thinkings and approaches that AI right now might just not be adapted to that space yet. 

Roger Farish: Yeah, no I agree a hundred percent. 

Orion Matthews: Yeah. So if we could just switch a little bit and talk about people in the space, maybe students, maybe you know, mid-level engineers that are hearing this podcast and thinking, front end planning is where I could make the biggest impact on mega projects.

I want to be in this space. What advice would you give someone if they want to pursue a career or make a career shift into this space, and really how would they educate themselves? How do they find jobs? Like what, what would be your advice to the, to the newcomers of this audience? 

Roger Farish: No, that’s a great question.

I think I think I’m [00:49:00] thinking from a couple sides, right? From the owner side, one area. To me that’s, to me very important and I actually have seen some younger engineers be involved in, is on process improvement, right? So you have all these processes for stage gate and like I mentioned, they need to be fit for purpose.

So I’ve seen some younger engineers, uh, on the owner side be involved in that because they can do improvement projects, uh, they can do a lot of testing, uh, and a new, and I don’t know that that can be very rewarding and it doesn’t require you to understand all the ins and outs of a project. You just need to understand, uh, the basics of the process.

And, you know, you can do some, some different types of implementation to help improve those processes. So that’s one area. I think if you are more of a especially in the industries that I support, typically it’s a process engineers. That are involved early [00:50:00] on in developing the process because that’s, that’s so important.

That understanding also having un a good understanding of economics of the economics of projects. So what I mean there is, the cost side, the schedule side. So if, if you were able to bring in a few of those things together then you might be able to be involved on the front end of projects.

And likewise, if maybe you are, have a good understanding of more of the economic side of things the sc the cost, the schedule risk, then you will need to develop that better understanding of the process part, you know, the process side of things, right? So if you can somehow. Be involved in, in pro.

Sometimes you can, for example, if, uh, I’ve seen it some engineers or young engineers that are maybe not a process engineer by trade or maybe a mechanical engineer, then they go to the field and they’ll learn about startup. And when you’re doing startup, you end up having to learn a lot about process because it’s [00:51:00] all very much related to the process.

So if you can somehow pull all those experiences together, then you might be able to contribute on the front end of projects. I think being a generalist in the front end of projects, uh, it’s very important. And also having had that lifecycle experience is very important. So I would say if you wanna, work in the beginning of a project, try to.

Maybe find those maybe not so desirable assignments. Uh, you know, push your manager to give you things that are outside of your comfort zone with the right opportunity, the right support so that if you have a goal of ultimately working on that side of, of projects, the early phase of projects where you can make that, that biggest impact then you can, you can draw on those experiences and ultimately be able to, uh, get involved in the front end.

Orion Matthews: Well, it’s interesting you talk about the economics of a project, meaning sort of the cost and impact, things like that. Do you think if I was in school, maybe I’m like a mechanical [00:52:00] engineer, maybe throw in a minor in business or something like that, do you think that would help? Or what kind of skills there at the colleges are offering, would you say lines up with front end planning type of work?

Roger Farish: Yeah, I mean, in the end it’s, it’s finance, right? So it’s, uh, when you talk about MPV and IRR, those are those are finance terms. A good understanding of economics is also good because a lot of these analyses are driven by market conditions, right? So usually they’re, they’re making estimates of in ranges.

They have ranges of, let’s say you have a, you have a feed stock, right? So that feed stock’s gonna have a cost. So you need to have a range of what that feed stock’s gonna cost you. And then you’re producing something typically. And that thing that you produce is also gonna have a range in price.

So you need to understand those kind of market elements that ultimately [00:53:00] feed an economic model for a project. Uh, so it’s, again, understanding all those things, how time impacts that, how the discount rate impacts that. It’s good to understand that side of things. So I would say, yeah, something maybe related to finance, economics or uh, or business would be very helpful.

Orion Matthews: I think that’s a powerful combo. I know a lot of people can go through mechanical engineering and maybe have like a physics minor or something like that, and then you can kind of exit college without ever even hearing about the time value of money or, kind of how inflation works in the calculations to come up with models for finance.

So yeah, throwing those in probably make it super powerful. ’cause learning those concepts on the go is completely possible. But I found it really helpful to be in school and actually have someone sit me down and take me through the finance models, uh, because it’s a, it’s a very different way of thinking, I think, than the way that engineers learn.

You know, it still uses the same mathematical concepts and things, but, uh, business folks do look at stuff from a very different perspectives. 

Roger Farish: [00:54:00] Yeah, I, I would say another one is statistics, right? Yeah. About risk. And even when you’re doing, uh, economic models, just an understanding of statistics is important.

So I would, I would add one, add that one to the list as well. 

Orion Matthews: Yeah, that’s a really great point. Awesome. Well, so what other tips or tricks kind of taken it up a level books, conferences, organizations? Like what can people do to get better at front end planning? What are your go-to resources when, when you’re entering into this space?

Roger Farish: Yeah. So I mentioned already, uh, a couple times, CII like I mentioned, um, they have, they, they’re a non-for-profit organization, so they provide that objective point of view and all of their recommended, or their best practices are research based. So they assemble research teams to look at a topic.

They ultimately have coming out of that, that research team, they typically have a best practice that is either updated [00:55:00] or a new best practice that deployed. Sometimes there’s a tool associated with that. And again, this is all not-for-profit. And if you’re a member, for example, if you work for a company that is a member company, then you have access to all those documents.

So I would say, Hey, go to them, to your manager and ask them to give you access so that you can go in and review some of those documents and you can learn more about front end planning, for example. That’s one of their one of their, their best practices. You can look, you can learn more about, uh, front end planning.

If the other organization that I am very involved with is A A CE, and that’s more on the project control side. Again the recommended practices from there are very important as it relates to front end planning mostly on the estimating side and on the risk management side. So I use [00:56:00] the the rps, the recommended practices from a a c on, more or less on a daily basis.

Because to frame a lot of the analyses that I do whether it’s the cost estimate classification or the different, uh, methodologies for risk analysis or the methodologies for developing contingency, all of these, uh, things are very, very important. The, the, um, um, the, uh, RPS for basis of estimate, that’s a very important rp.

The RP for, um, for estimate reviews and, uh, estimate validation. We do that as well. So those are, again, those are like rps that we use almost, basically on a daily basis they’re a little bit of our back. The backbone of what we do is based on those recommended practices. Um, I was, so that’s another great organization to be a part of.

Uh, and I would say, uh, in terms of books [00:57:00] you, we mentioned IPA once already but, uh, so I will give them a, a shout out. It’s, uh, I have it right here. It’s Capital Projects by Paul Barhop. That’s that book even though it’s called Capital Projects, is all about, uh, the front end planning of projects.

It’s not very technical in nature. It is very much, it talks about the support mechanism that is required to be successful in the front end phases of a project. So it’s a little bit more organizational in nature. It, it does paint a very clear picture as it relates to the things that are important.

As one develops a project, it’s more, uh, geared towards executives, but I think it’s still very accessible to anybody that has had or is interested in capital projects, especially the front end of of projects. So I, I definitely highly recommend 

Orion Matthews: it. We will include those links below too, so [00:58:00] you’ll be able to click those in the description and then.

One other thing I’d love to cover. Let’s say someone’s listening to this podcast and they’re like, you know what? We’re at a stage where maybe it’s time to pick up the phone and call Roger and get involved with him. How does your consulting business work? How do people, how do you best work with folks?

When’s the right time for them to call you? Maybe take us a little bit through your ideal customer and engagement where you add the most value for people. 

Roger Farish: I wanna say the earlier we get in touch, usually the better, uh, my experience is. I help, I’ve helped clients more on I’ve helped clients sometimes more on, on small capital improvement projects or sustaining capital types of projects.

And then they ask me, well, can you I’m looking to now do this other project and we’re on the front end phase. Can you help me with that? And then [00:59:00] all of a sudden we’re doing PDRR reviews, we’re doing, uh, risk reviews, we’re doing, then we’re very involved in the FFEL one phase. Then we’re sometimes managing the FFEL one contractor on their behalf because they don’t have enough, uh, staff to, to do that.

And, uh, now they’re growing and, uh, they need us to help them establish or, um, refocus their governance processes. You know, you, you know, it’s. Anywhere in between any of those, we can support projects, but usually as we get involved, we typically get more and more involved, which is, you know, it’s very satisfying to be able to do that as we find, uh, ways to help, uh, owners, clients support their development of projects.

Uh, also been involved with some EPCs, EPCs that don’t have those capabilities. I’ve been able to support them as well in different phases of, of projects and even OEMs [01:00:00] that are, that sometimes get approached by, for example, developers. And they own most of the scope. Uh, those OEMs sometimes need help to help the developers, uh, frame out the project so able to support those, uh, those OEMs as well.

So, there’s a lot of areas we can, where we can support projects, especially on the front end of projects. 

Orion Matthews: Well, and as I mentioned, people will probably see you at a conference or two if they wanna get in touch. Otherwise, is your LinkedIn and website up or how do they connect with you?

Roger Farish: Yeah, either one of those ways is a great way to find me. So on LinkedIn, I’m very active on, on LinkedIn. So definitely feel free to connect, uh, with me, uh, through LinkedIn and also we have our website up and run up and running. So it’s uh, roman cg.com and uh, you know, we have a contact form there that people get in touch with us.

Orion Matthews: Nice. Roger, I learned a lot about front end planning today. I think one of the [01:01:00] most insightful things you said is that there’s sort of this curve of influence that you might have over a project, and I think people might think this influence curve probably starts during execute, and that’s where the majority of your ability to affect the outcome comes from, because that’s where most of the money is spent.

But it almost seems like it’s inverted from where the money is spent. By the time you’re spending a lot of money, your influence ability is probably like connecting to that line of spend. And so it’s like the less you’re spending the earlier in the project, the higher outcome of success.

Kind of like dialing in a you know, a cannon ball before you shoot it. You wanna make sure the aim is correct before you apply all the force energy, money, things like that. And so that was a really insightful tip, Roger. I appreciate that and so much more. So thank you so much for coming on the podcast today.

Really appreciate your insights and hope to have you back sometime. 

Roger Farish: [01:02:00] Yeah, that’d be great. It’s, uh, it was great or Ryan, really appreciate you uh, inviting me and hopefully, uh, some folks, uh, get something out of it. And uh, yeah, be happy to, uh, continue the conversation whenever the time’s. Right.

Host: Awesome. Thanks for listening to the Major Project podcast. Be sure to follow us wherever you get your podcasts and learn more at the major project podcast.com. Until next time, keep building big.

ABOUT THE PODCAST

The Major Project Podcast

Every day, somewhere in the world, a billion-dollar project is underway, reshaping skylines, powering nations, and pushing the limits of what’s possible. But behind every megaproject are the people who plan, measure, and keep it all on track.



Hosted by Orion Matthews, founder of Queryon, The Major Project Podcast dives into the world of Project Controls — the art and science of delivering the biggest projects on earth. From energy and infrastructure to tech and space, we talk to the leaders managing billions in scope, risk, and ambition.



Join us as we uncover the lessons, failures, and innovations that define how major projects actually get built — and how data, risk, and human judgment come together when the stakes couldn’t be higher. 

See more episodes

Ready for a call?

Fill out the form below and an expert will reach out shortly.

"*" indicates required fields

This field is for validation purposes and should be left unchanged.
Name*