And Why You Should Care…

We are starting to hear a lot of talk about program management in the AEC industry and among project owners. But what is it? How can program management improve efficiency and productivity? Why should you care?

Program Management in Construction | ProjectReadyProgram Management Defined

The simple explanation is that program management is the management, coordination, and integration of multiple, concurrent projects, which is a regular need and challenge for many AECO organizations. Being able to quickly view and access projects, platforms, content, and data in a program is essential to ensure individual projects work in synergy, avoiding conflicts and optimizing resources for maximum efficiency. But, as with most concepts, the definition goes much deeper and applies to many other facets of project information management.

ProjectReady CEO Joe Giegerich, Head of Development, Shaili Modi-Oza, and industry thought leaders Salla Eckhardt and Jeff Walter discuss program management as it relates to collaboration on information and data and discuss how to bring order to the complex nature of managing large, complex projects.

 

Listeners will learn more about:

  • Data unification and management
  • Enhanced collaboration
  • Risk Management
  • Streamlined processes
  • The importance of remaining flexible

Sign Up For New Episodes

Listen on Apple Podcasts

Contact Us Today And Learn How You Can Introduce An Effective Program Management Solution With ProjectReady!

Read The Transcript

To view the full transcript of this episode of the ProjectReady podcast, extend the section below.

Transcript

Joe Giegerich: 

All right, everybody. I want to thank you for, once again, coming to listen to the ProjectReady Podcast. Today, we have on our guest panel, once again, Salla Eckhardt and Jeff Walter of AECOM, and Salla is from OAC. Always happy to have them on the panel. Always makes it much more interesting because these are folks who are out in the field doing this every day.  

And our topic today is what is program management, and what is the essential elements around program management, and what are the challenges?  

So, program management, multiple concurrent projects, the regular need to see what’s going on in those projects.  

I’ve also spoken to other clients, and they describe it as a master in subprojects. Number of ways to look at it, right? But it’s all basically the same thing that you have multiple projects underneath an umbrella of.  

So I want to pause there because I don’t do what Jeff and Salla do. Basically, what is program management? 

Salla Eckhardt: 

To me, it is about setting goals to the outcomes that we want to see. So it’s part of the long-term strategy and delivering to that. And then having those multiple projects to create the outputs that are required to achieve the short-term and the medium-term goals that then lead to the long-term strategy and the outcomes that we want to achieve. So that’s how I’m looking at program management.  

Over to you, Jeff. 

Jeff Walter: 

Thanks, Salla.  

Yeah, that’s a big question there, for sure. So yeah, obviously, program management is, I think, to some degree is kind of an emerging, and the AEC industry is emerging zone of management expertise coming into play. And yeah, I think, as Joe mentioned, it’s really adding a layer of management on top of a complex ecosystem of projects and stakeholders. And as Salla mentioned, different business and value requirements across those different stakeholders within a program. And really, that ecosystem’s not getting any less complex or any simpler.  

It’s even getting more complex as this whole program management industry kind of emerges. And so definitely, from a digital perspective, certainly, I think some of those elements can help support achieving some of those program goals. 

Joe: 

Well, let me ask you a question on a follow-up. And I was remiss, and not… Shaili Modi, who’s always on these calls, is on this call today as well. So one question that comes to mind, why is this emerging? I mean, has this not always been the case where you have an airport being built, and you have 10 GCs and three engineering groups, and we… Why is program management emerging to your point of view? 

Jeff: 

Yes. I mean, I can take a first crack at this.  

I think obviously portfolio management, program management, these have all been elements within any kind of organization, I guess, in a sense, tracking, project, the level activities, and their performance. But within the AEC industry in particular, I think there’s a number of factors why there is more focus on this role in the delivery of infrastructure and built environment these days. And I think, obviously, one is related to maybe a bit of labor and expertise shortage on the owner side of the world. And I think in the delivery of mass amounts of infrastructure under short and pressured schedule environments and where funding is, the ability to mobilize and programs quickly and get funding kicked off really requires quite expertise in a team and kind of a management framework approach to delivery that I think owners are struggling to kind of with internal capacity around that. 

Joe: 

So, you see program management as an owner thing, is that correct? Owners, their reps, construction managers, et cetera. 

Jeff: 

Yeah, I think that’s how I would equate it to. And there’s different teams that I think deliver program management and doesn’t necessarily fit all on the owner side, but it’s definitely driven from owner-level requirements and needs to manage complexity and delivering a number of projects at once. 

Joe: 

Salla? 

Salla: 

Yeah, I think Jeff’s perspective was interesting and great. My perspective comes from inside a real estate owner organization and being an architect by background. That the industry has changed that it used to be about building landmarks and individual buildings and taking the project-based approach rather than process-based approach. But now that the industry is looking into a manufacturing industry that is a mass production industry, it’s starting to realize that managing large portfolios, and expanding the portfolios, and managing the finance side of things, it requires program management rather than just ad hoc, a siloed project management. 

And the owners are starting to think about their portfolios as an investment rather than something that is a landmark or their legacy per se. And that’s where the shift is now happening in the industry that we are no longer focusing on individual buildings, even though we are talking about smart buildings and talking about individual buildings, digital twins, et cetera. But now the horizon needs to expand to managing larger portfolios and managing smart cities, and how things are actually connected, and how the long-term strategies of build environment are managed. And that’s where program management is the right route to take. 

Joe: 

So, is this more of a view to the full lifecycle of a building as opposed to just building it and we’ve got to hand it off, we’ve got to maintain it? That’s why you have Revit, that’s why you have families, all those other components? And it’s that long-term and then repeatability? Is that the other element that you’re basically referencing? 

Salla: 

Yes. And it is, like you said, that it’s about the lifecycle and managing the total cost of the lifecycle. And that’s why I developed a digital building lifecycle framework to help people understand that what does it actually mean to own a building or manage a portfolio for decades to come that is not only about the campus investment when you’re designing and building something and then having the keys over? You actually have to have a long-term strategy and plan for what you’re applying to do with it.  

And that’s where program management helps you achieve the different milestones, and you’re not left drifting with what you own. 

Joe: 

So, it’s a shift in the view of what a built asset is for one. And Jeff, you had mentioned that… You said that, if nothing else, it’s becoming even more complex to manage a program. And this is why programs are kind of new because this different look at the full lifecycle, and ownership, repeatability, modular construction probably feeds into this as well, but what’s driving the increased complexity to your eye? 

Jeff: 

Well, I think even building off what Salla was saying on the lifecycle approach, I mean, program management in some ways it maybe becomes synonymous with project management, but I think, yeah, as Salla described, program even has a different view even beyond what a project management or building would say.  

So even just that lifecycle approach, that asset approach is a complexity in itself because it certainly obviously opens the door to a number of different stakeholders along that journey as well. And as well, the number of different types of data sources and software pieces that, from a digital and systems perspective, need to help support program management. 

But also, just as… I mean, just again, coming from an infrastructure delivery perspective, as those types of projects are getting bigger and the consortiums are getting larger in terms of delivering projects and programs, new types of program managements, delivery partner kind of concepts where it’s this cross between program management and owner-level kind of advisory are studying to emerge.  

So even within the idea of program management, there’s new kind of different zones of expertise that are filling in the whole concept of program management as a whole. 

So I know that’s definitely a couple of different points there, but I think that’s where some of the complexities is. It’s really around stakeholders, and collaboration, and really making sure feedback loop and also the right information is available to driving good decision-making on these programs. 

Joe: 

The way I look at stakeholders, and I think, Shaili, you probably do as well, to me, stakeholders are just data sources. Their inputs and outputs of data is a stakeholder. I guess I’m looking for a confirmation that that complexity is also that opportunity. So as you have the ability to aggregate and bring together different stakeholders and the data that represents, that’s a bigger set of data to wrap your arms around, right? But it’s also an opportunity. And so I guess a pivot I would have, and maybe I’ll turn this over to Shaili. So in terms of pulling all that information together, because before I go any further, I mean, we all agree that that information and the ability to make sense of it across stakeholders and related systems that’s a big part of the challenge and opportunity. So far, so good.  

So Shaili, what are some of the challenges around just even pulling all of that together in a way that would facilitate program management? 

Shaili Modi-Oza: 

Yeah, I would say the biggest difficulty. Of course, we’ve been talking about all the different stakeholders, the data, and a lot of different platforms. People are using so many different workflows, different ways of storing the data, how it’s all organized. And at a program level, basically, there are multiple projects with different teams using their different platforms and different processes in place, but still, because they’re all kind of connected to each other, there needs to be a way that all of this data can be somehow united so that we can see, at the program level, of course, just all of the things going on across projects as well, but having some level of consistency to bring that data, basically creating a data warehouse, as we’ve been talking about previously, as well, but I think the biggest complexity is when there are so many different platforms and use.  

Design team is using one software. GCs are using another software. They’re all trying to bring all of those systems together. I think that’s a big complexity. 

Joe: 

And it’s multiplicative in a portfolio in a program, right? Each project has six different stakeholders and systems, and then there’s too … 

Shaili: 

Yeah. And they’ll use their own different systems and just trying to… There’s no way to, at the moment, see or have that high-level view across all of the different things going on. 

Joe: 

And that ties back to the podcast you guys were on, which was Garbage In/Garbage Out Podcast.  

We have coming up about what is a data warehouse. And I know sometimes these topics may sound a little bit cute. Oh, it’s a warehouse of data. Okay. In what terms, in what context, in what use is written? Everything does tie back to that.  

So question, I guess, for the larger group as well. So if the challenge is the opportunity of bringing all this data together, what are some paths forward? I mean, there’s having a data plan at the beginning, governance rules, agreement, but I want to turn that over to everybody else. How do you resolve and try to move forward to make program management more effective? 

Salla: 

We did with my past team is that we started developing the data master plan because there are so many different programs within the portfolio management overall that, if thinking about what Shaili mentioned about the interoperability, and data creation, and data transcript between different tools that people are using for individual points of view, data master plan creates the overall strategy for everyone to understand that what they are expected to deliver for the sake of others that others can then build on top of. 

And when thinking about large portfolios’ management, that people might have understanding of the other disciplines, but the deep comprehension of a subject matter comes from years of focusing on a program. And that’s where programs like usability or accessibility, sustainability, affordability, smart environments, and innovations, they become programs themselves.  

But then others cannot necessarily be pseudo-experts in those topics. And that’s where the data management comes to save the overall team and save the project teams, that if they have a data master plan, then you have a roadmap to deliver what is needed at different milestones, and the quality of data meets the expectations of those that are using the data. 

Joe: 

Yeah. There are two things I would add to that too, because what I’ve seen for one is there’s a lack of trust between the different stakeholders. I don’t want to give you this information. When are you going to be able to access it? So that, I think, is an issue somewhat out of the gate. 

And the other issue that I run in the field with clients and prospects is… So you have the data master plan, but in that master plan, I think you’re always going to find stuff that’s just not going to work terribly well as well. And I think that’s okay. Where am I going with this?  

So I’ll talk to clients, and they go, “Well, if you’re not doing 100% of this, you’re going to go back to spreadsheets and the file system. You’re going to go back to silos.”  

There’s a sort of all-or-nothing attitude that I frequently encounter. And so I guess to you, Salla, because based upon your topics, it’s that not also the case that when you’re doing the data master plan, you’re going to go, “All right, this 70% we can handle. This 30%, we might have to rekey, or do brute force, or maybe we don’t want this… That data isn’t as valuable because of the lack of fidelity.” 

I mean, how do you address the exceptions? 

Salla: 

What we did is that we kind of create the critical expectations, critical path that then gives the foundation for what must be but also allows people to have the flexibility for the customization or having kind of ad hoc or workaround processes. So what we aimed at was to create something that was the ultimate simplicity, what gets you where you want to be as the baseline, and then you can continue expanding and improving from there. And that way, we were not putting any handcuffs on people or dictating that they must do something that was against the grain, but just creating what is absolutely necessary for the sake of the success of the project and the project team. And that way, we didn’t create something that was only extensive and difficult to manage, and was not something that was an encyclopedia of things and something that we felt that would be super cool to deliver, but it was something that was very refined and simplified. And that want us- 

Joe: 

Right. Doable. 

Salla: 

… to give that flexibility. Yes, doable. 

Joe: 

Right. And that is that sort of purist element that I always just found kind of weird. I was like, all or nothing. All right.  

Jeff, anything you would add to that? 

Jeff: 

Yeah. I think another interesting area of program management and where do we start and where do we initiate. I definitely love those data, road mapping, and strategy, and architecture ideas. A lot of focus on what contracts from a program management perspective, how these types of requirements for data across projects and across stakeholders are identified in contracts. And this also comes down, as you guys know, the ISO 19650 requirements, the compliance capabilities for programs, and how all those pieces fit together with managing those processes is really important, kind of rolling out across as a program.  

So, I think certainly contractually, I’ve definitely been focused on a lot in terms of identifying those needs from those different stakeholders and rolling them up into contract requirements. 

But I know, Joe, you also touched on the change management piece a few minutes ago and really just the shift required. And I think whether it’s project management, program management, it’s just AEC as a whole trying to reach to new trust levels. And I think this is really important.  

Something I’ve seen across program management is more focused on change management, and data organization, culture building. It’s really important. Everyone understands responsibilities, governance across these types of environments as well. Making sure everyone’s on the page. Really wrapping identity around these outcomes as well. So I definitely just wanted to back that point up that that’s an important trend as program management evolves and takes its first steps. That’s something to consider, for sure. 

Joe: 

Right. And be it the data management plan or, in our case, with ProjectReady, which is this sort of scalable data warehouse out of the gate… I mean, one of the ways we present our product is… And this goes down to the contracts, the data, or master plan, and our ability to make you sort of ready at the get-go is doing this proactively, right? Because that’s the other thing that I’ve witnessed in the years I’ve been working, and servicing the industry is a lot of after the fact… Well, we had this project on for three years, and now we know. You always know you just waited three years. And so the need for proactivity, I think, be it our product, data master plan, contractual agreements as to ownership, and MVP, by the way- 

Jeff: 

Risk. Risk as well, for sure. Yeah. 

Joe: 

Right. It all ties to that risk because it… Something that I’ve said is that if you don’t do something in our case, subscribe to my software.  

The risk is known. The risk is known that data will be inaccurate. That you’re going to spend 20, 30, 40% of your day looking for data. You’re going to have half your information and not even know what it is until you get sued. And then you have to spend a lot of money figuring out what that is. And that all does come around risk.  

Because the risk is, to my eye, in my mind, not being proactive, not addressing this in contract, not having a data master plan, not having be it our platform or an approach where technology is integrally recognized as part of the project from the get-go. So if we’re all in a kumbaya moment here, one of the things I would like to ask Shaili is, so what’s the role of manufacturers in all of this? And so for me, a manufacturer is anybody who makes something, right? So Autodesk, Procore, they make software. 

Shaili: 

Yeah. I think in terms of the different softwares that we’ve been talking about with Autodesk, Procore, Microsoft, one key thing is that they’re now making data available. So again, it’s all different for different manufacturers, but that’s where, I think, just in general, everybody’s heading where, using APIs, we are able to access the data. But looking at end users and their day-to-day life, that doesn’t really make it that much easier because a lot of work is involved in then trying to make sense of the data in a way that would then be helpful. 

Even looking at a simple use case that a lot of our clients are now having where they have two different Procores or two different Autodesk systems all related to the same project and there’s a lot of rework that needs to be done where people need to manually move data from one system to another or create RFIs in two different systems, manage that. It’s a lot of rework and manual handling, for which, in some cases, APIs are available, but it’s not very easy to just set that up or basically have end users get that flexibility to make it easier for them. So I think while the industry is heading in that direction, it’s not very easy for end users right now to just have all of these communications in place easily. 

Joe: 

Right. Because part of my objection has always been is looking at data and somehow another divorce from human interaction with it. Collaboration through integration, one of our taglines because… I think this is where you’re going with Shaili, you can bring all this data together, but there’s limited sets. But if people can’t easily access it and make that information easily accessible in terms of the work stream of their day, I think it’s rather a moot point. 

Shaili: 

Yeah, exactly. 

Joe: 

One other thing I would throw out there too is not all APIs are not the same. It’s much like the pre-contractual agreements, Jeff, right? That when you’re looking at a program, you should also take a hard look at the software you’re using. If the software is… Because a lot of software out there is a thing from the ’90s. I loved the ’90s back in the day, but time has moved on, and in the industry, it’s called barrier to exit. So you’re going to silo people’s information. You’re going to grab their information. You’re going to make it difficult for them to get to it. 

So I think this is a real point of consideration. I see this in massively large companies that have been out there forever. I see this in small startups. One of the things I would recommend agnostic of my product, and again, we want you to buy the product, yay, but put my CIO hat, I would give a very hard look at the systems I’m going to use and the maturity of their ability to interact to feed a data warehouse so you can apply AI, so you can manage a program effectively and reduce risk. 

Jeff: 

Yeah. I would completely agree with that on so many different fronts, certainly in the evaluation at a program management level of tools and systems that roll out. And that’s certainly kind of on top of our evaluation matrix is looking behind the scenes, for sure. And I think it’s not only just… Yeah, it’s not only process and synchronizing information, automation across systems, but really, also, even goes back to that traceability, and auditability, and trust in data. And really, if that is kind of a core approach from a program perspective is to have the capability as an organization to, yeah, have a data warehouse and have an architecture and a roadmap where all those systems, I think that’s a benefit. There’s a maturity on that side of things. 

Joe: 

Yeah. There’s a lot of… Well, we’ve always used it as a great product. Everybody uses it. That’s not strategic, is it? Right? The point of technology is it changes constantly. 

Jeff: 

Yeah, yeah. So it’s the first filter, in a sense, from that perspective, right? So yeah, there’s different levels of API quality and accessibility, and those are obviously changing constantly in a sense, so you have to be aware of that. But fundamental approaches, if the idea is to trace information, and I don’t want to say own it per se, but having a source of truth that you can trust behind, you really do need that architecture to support that. 

Joe: 

Yeah. You have Garbage In/Garbage Out. You have to get something in, and you have to get something out. So be it garbage or something great, there’s still that requisite element to it. And again, I utterly don’t distinguish between technology, and stakeholders, and systems because it is really kind of the Borg. If you watch Star Trek. It really is more on akin to that these days. 

Salla, let me turn back to you. Any other comments you would have as a follow-up on that? 

Salla: 

I love what you and Jeff are talking about because it kind of paints a picture that we are now in the same situation as we were in the past with the industry that this is how we’ve always done it, but now it’s digitalized. And what it actually means is that a lot of times people are following what others do. And they want what the others have without thinking through what is the right fit for their core business and the choices that they want to make. And then they end up in a situation where they buy program management services from somewhere, but the program managers, they are producing what they already produced for some other client or multiple other clients. So it’s never the right fit because there’s not enough understanding of what are the outcomes that are meant to be achieved and what the client wants to achieve. 

And even the client doesn’t know what they want because they are just basically following what others have already been doing. So that brings us back to the 1990s all the time because, like what people now say is that, “Let’s just rinse and repeat.” It’s the modern way of saying that this is how we’ve always done it. So we need to somehow create disciple and get people to comprehend what they should be doing with their data so that they stop data hoarding and start leaning towards data management because then they get the value out from the data that they are collecting or creating. And then they start seeing the value in data platforms and start really thriving with their digital transformation. 

Joe: 

And being a New Yorker, I’m picking up on Jeff’s comment. I think it starts with a contract, right? Because that’s how you get paid. If the contract stipulates that you have to be able to get data in certain fashion and time, it has to be orchestrated in a way that AI, predictive analytics, all these things can be applied. That legal constraint that’s going to drive money makes the world go around, I think, goes a long way to then influencing, “Okay, we’re going to have to communicate this contractually that forces the hand of data mapping and then forces the hand of selection of systems that allows stakeholders to come together.” 

Jeff: 

Just to jump in here, but that’s the shift, I think, Salla maybe even describing there is in a sense going from an old, maybe traditional approach, where you come in with this is your solution or this is your approach and trying to fit it within the constraints of an existing environment versus a new methodology, a new approach where you’re definitely a listening or advisory kind of consulting approach, looking at a longer kind of journey, that kind of concept, and being able to facilitate that journey in different ways as well and different pathways. So I think that’s really a big shift, I would say, within program management that I would love to see more is certainly… And every program is definitely different, as even sound described, that there’s no way one approach could fit any or all program concept. So I think it’s just natural because of that complexity to be more listening, and consulting, and advising, especially as applies to digital and systems approach. 

Joe: 

The way to manage the program is one thing, the elements that you use to it is quite another. This is why I’m very big on this quote modular approach. On this particular client, on this particular program, it’s not, “This is what we always use,” it’s, “this is what will work best here.” And you have a fairly large and increasing pallet of solutions to bring together out there that you can then apply strategically because your obligation, my understanding, is to the owner, not to a particular software package or something to that effect that you foisted on people because that’s your comfort zone as a vendor, as a consultant. 

Salla: 

You’re touching my favorite topic, like processes, re-engineering, Joe, because that’s my core expertise. That applying digital tools on analog processes will not fix anything.  

The technology is only going to underline and highlight what’s wrong with the old process and what has over complicated over the years in the old process. So, like Jeff said that the consultants should be used as advisors rather than as someone that is just pushing a button on software. And that’s the mindset change that the industry struggles with, that people are not incentivized or motivated to simplify the processes and rethink the processes because the process is really engineering. It’s really difficult. It’s complicated. And it takes a lot of time. It’s like creating a new standard. So people shy away from something like that, and they just want to have the quick and easy push a button solution that leads into the situation where people have the best tools in the world, but nothing changes. The outcomes remain the same. 

Joe: 

And quick and easy, long-term is difficult and messy, right? It’s like jamming too much stuff in a drawer, and then you pull the drawer out, and you break your favorite knife that’s been stuck in there. I like knives. I like to cook, but just like… And the number of times we’ve had conversations with prospective clients that go, “Oh, we’ll get an admin to do that. That’s what we always do…” And that’s just jamming stuff into a drawer. That’s just jamming stuff into a closet and hoping that somehow another it orders itself when you close the door. 

Jeff: 

Just one other point on the flexibility modular kind of approach, and Salla, I know I’d love to hear your perspective on program management, which is really in essence a development, a lot of the potential infrastructure buildings, whatever kind of that program is, eventually potentially could fit into digital twin and downstream kind of lifecycle-oriented management abilities and capabilities as well. Maintaining modularity. We’re kind of looking beyond program management into, “Okay, what is the bigger kind of management landscape?” Digital twin or whatever those types of concepts are really, they need to almost fit together, right? And then, when you open a canvas to a digital twin concept, where you’re adding a whole other layer of potential modularity or different stakeholders from perspective, really, that doing a flexible design from a program early stage can have those downstream benefits throughout the whole lifecycle. 

Joe: 

Manage the entire project’s ecosystem to be able to bring it together effectively and be able to swap components in and out. 

Jeff: 

For sure. And right through into operations, I mean, the whole lifecycle of that asset that’s developed during that program. So maintaining modularity at a core really helps us kind of hand off into these different management areas. 

Joe: 

And I think a pushback you would get is, well, if there’re all these different modules and different systems, how do we make sense of it through a data management plan, through having a data warehouse that scales like ours? They’re having contracts that stipulate things because data is only as good as its relationship, right? And so you can have a modular approach if you go, “Well, it’s always these 20 fields, those 40 fields, these three values all ties back to one.” Then you can have that modular approach, a scalable data warehouse, and the ability to manage a full lifecycle of an asset. 

Salla: 

I have one perspective for our listeners that when they are thinking about their program management and the digital transformation and adoption to new tools as their pre-engineering their processes is that when thinking about the long-term strategies, there needs to be some kind of understanding of what the priorities are. And that ties back to what do they want to pay for.  

Not everything costs the same. Not everything will get the same allocation of funds, et cetera, but really kind of deep diving into what is the core business where they want to make money, or what do they want to support if it’s not finance-related, what they’re all about, but really crystallizing that, what do they want to achieve? And that’s the key for really understanding how they can start approaching the data management, that information management, within their programs and really start thriving towards the future that they want to achieve. 

Joe: 

Yeah. It’s how we would do any engagement, be it by old services organization what we do here. The thing I want to add to that is if you have a vision, it’s like building a building. If you know what the architecture is going to be, you can start building that foundation. 

So the other thing I would add to listeners out there is you have to have some sort of plan, but don’t let it overwhelm you either. I would argue, right? There are places you can start, which is where you’re going solid. You got to pick something. It may not be the most expensive, but you get the most ROI. But you have to start and have a plan to do this, I think, as opposed to wholesale incrementally, although I would like to hear what you guys think of that. 

Salla: 

That’s spot-on. The needs change as the end users or the clients change. So it’s like you’re spot on that you have a starting point, but it’s an evolution for decades to come, hopefully. And that way, whatever the priorities are, they depend on what people want and what the end users and the clients are going to pay for as well. So very elegantly said, Joe. 

Jeff: 

And I think I’ll add to… I mean, I just had a conversation with a client in program management space. And definitely on the ground, incremental approach, especially when you’re dealing with big-owner organizations and systems, is definitely on the top, but also connecting that incremental agile, I guess, a bit of approach to, “Okay, what are we going to be looking like in three years?” Because typically in programs, those, at least from an infrastructure perspective, can last five, 10 years. Everything that I’ve been involved with is at least a minimum. So you have that kind of view over the life cycle of a program to put milestones and lighthouses out there. So at three years, planting a vision, for example, that AI is enhancing program analysis experience and putting those out there, but then managing that through incremental agile change in a way. So we’re seeing maturity in the market in terms of where I’m seeing owners wanting to be from program management perspective. And yeah, really getting teams excited about the future of program management using the full depth of these types of technologies to help support. 

We’re definitely seeing, even from a Garbage In/Garbage Out perspective, even demonstrated use of AI, doing risk analysis, schedule analysis, those types of things within program management as we speak. So I think there’s some opportunities to plant those new visions within the structure of program, and then yeah, lighthouse and build that out that way is a good strategy. 

Joe: 

All right. So look, thank you, everybody, for listening. Thank you, Salla. Thank you, Jeff. Thank you, Shaili. And just for what it’s worth, another one we have upcoming is what is a data warehouse. It really does tie back to what we discussed today. And even if you look at previous podcasts like around how to optimize search, this again goes back to data. You’re searching for what information on a program. So, as I say, pretty much in every podcast, this all does tie together. And excited to pick up in the data warehouse conversation, which I think is really a sort of logical extension of today’s podcast. So again, thank you everybody, and we’ll talk to you next time. 

Jeff: 

All right. Thanks, Joe. 

Shaili: 

Thank you. 

Jeff: 

Thanks, Shaili. Thanks, Salla.