Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
How Do You Coordinate Multi-Discipline Design Teams? image

How Do You Coordinate Multi-Discipline Design Teams?

The Off Site Podcast
Avatar
0 Playsin 8 hours

Join Jason and Carlos in this episode of The Offsite Podcast as they tackle three fresh topics from the world of construction:

๐ŸŽฏ Design Management Best Practices: Explore the persistent challenges of scheduling and coordinating design in construction projects. Discover why design delays plague major projects and examine effective strategies for managing complex design workflows, resource constraints, and multi-disciplinary coordination.

โš–๏ธ Oracle Licensing Controversy: Dive into the contentious terms of service surrounding Oracle's Primavera P6 software. Uncover the implications of data ownership policies and licensing requirements that are sparking industry-wide debate about customer rights and software vendor practices.

๐Ÿค Who Should Own The Project's Tech: Analyse a LinkedIn discussion about who should drive technology decisions on construction projects. Examine the pros and cons of clients, contractors, or supply chain partners taking the lead on software selection and implementation.

Key Timestamps:

00:00 - Introduction & Autonomous Highway Construction

03:22 - Design Management Deep Dive

16:41 - Oracle Licensing Terms Analysis

29:36 - Who Should Own The Project's Tech

Check out the Off Site newsletter here

Follow Carlos on Linkedin | Follow Jason on Linkedin | Check out Aphex

Recommended
Transcript

Importance of Software Efficiency

00:00:00
Speaker
your customers more efficient. Like in the day, the promise of software is some level of efficiency or benefit for customers. And the moment you like jump over a fence to protect revenue, to make your customers less efficient or stop them becoming more efficient, you've, you've like really got your whole world upside down as like a technology vendor.
00:00:18
Speaker
Right. So like, got got look in the mirror that point yeah, totally. It's like, are we actually having this conversation? Yes.

Introduction to Episode 96

00:00:31
Speaker
Welcome back to the Offsite Podcast, episode 96. We're four away from the big 100. Get excited, set the date in your calendar. I don't know when it'll be, but at some point.
00:00:42
Speaker
If only we knew the date, yeah. Yeah, if only we knew the date. I'm Jason Lansini. I'm joined once again by cars Carlos Cavallo.

Scheduling in Construction Projects

00:00:49
Speaker
And today we are talking about ah best practice is for managing the scheduling and coordination of design in construction projects. A rabbit hole if I've ever seen one.
00:01:01
Speaker
Then we're going to ah be totally shocked and blown away at the license terms that Oracle seem to have been implementing where it's unclear about whether they own or you own your data as ah as a customer of something like P6, allegedly. And finally, we're going to dive into the bowels of LinkedIn I would say we're safe now. The allegedly is important.
00:01:27
Speaker
um Finally... finally We're going to dive into the bowels of LinkedIn and look at a post that raises the question about on a project, who should be the driver of technology? Should it be the contractor, the client, or say the supply chain or consultants?
00:01:42
Speaker
But before we do that, Carlos, how are you? I'm good. I'm good. I was enjoying um reading one of the docs that our producer shared. That's producer Which producer Ollie, our fabulous producer in China. I don't know that he would have gone with fabulous is the word. but That's sticky

Autonomous Vehicles in Construction QA

00:02:02
Speaker
now. 160 kilometer stretch of highway between Beijing, Hong Kong and Macau has been completely built using autonomous vehicles from beginning to end. It definitely wasn't.
00:02:15
Speaker
fake days Fake news, fake news, Favors, fake news. There's no way. They've definitely done the easy bits, Autobag. So there's, yeah, so there's like a, you can imagine like a a paver on cruise control um with kind of like lane guidance kind of thing.
00:02:32
Speaker
and I think there was a person somewhat involved in that thing. And then you can imagine following that, a fleet of six rollers, And the roller's kind of like covering the three and a half lanes or whatever it might be.
00:02:47
Speaker
um so they're kind of like in this staggered formation and they're appearing to drive themself. I'd love to see what the QA was on this thing. Cause I just can't imagine that they're also actually doing the QA. Like I could imagine they drive themselves. I could imagine that they like keep a formation and cover the whole road, but there's more that a roller driver does than just like press forward and go in a straight line.
00:03:11
Speaker
Yeah, Odu, if you could reach out get some QA documentation, that'd be awesome. Yeah, yeah, yeah. Cool. All right.

Delays in Design Phases

00:03:17
Speaker
That wasn't a side quest that we didn't mean to go down at all. Let's get into it. All right. so design in construction and um the management of design. I think if you were to if you were to survey 100 large design and construct projects and said what was causing your project to be delayed, the answer would be 12 out of 10 times design. And if you dive under the hood, ah what typically you would see on most projects is that all the design looks like it's on track until none of it's on track.
00:03:48
Speaker
And you get to like 80%, 90% complete and the date blows out. It's kind of like that saying where like the first 90% takes 90% the the last the other of the time. you You obviously, and we've obviously spent a lot of time working with and talking to projects that have this exact problem. We've seen lots of different ways that um design gets managed.
00:04:12
Speaker
You know, it's historically or typically the realm of package tracking spreadsheets, very, very long meetings where we're going package by package through and kind of guessing dates.
00:04:25
Speaker
Then a week later, finding out that something on some other package meant that all of our resources went to that other package and all of our other dates are wrong. And it's also the realm of ah if we are slipping, what we should do is break the design into more and more smaller packages. So it's kind of like keep breaking down the the things that need to be gated or design assured.
00:04:47
Speaker
So there's there's like some common patterns. And once it starts, At least in my experience, once you start breaking things into smaller and smaller packages, you are multiplying the amount of design assurance processes that you need to go through and complexity just starts to like explode.
00:05:04
Speaker
it's It's kind of like a trap. It you can feel like you make one part of the project go faster and in the end you're making the whole project go slower. The question ah to lead to is how do you stop that from happening? What are the like patterns or what are the cadences or what are the the responsibilities that ah projects that do a good job at trying to manage what is a very hard to manage part of a project?

Issues with High-Level Scheduling

00:05:30
Speaker
um What do they exhibit? I don't know if you wanted to to pick up from there Carlos, given you've you've got a lot of experience with working with with design teams. There's quite a consistent or I guess common sort of state of play that we experience when we meet design teams.
00:05:46
Speaker
And most of them have a ah situation that they're in that contract schedules from a design perspective are super high level. Like we think of construction as being quite high level, but we're talking like weeks and months long activities.
00:05:59
Speaker
Yeah. So we have this very, very high level schedule, which like you you can sort of empathize with because of the time of building that schedule. Like you don't know the raft of... ah their joys and everything that has to be done.
00:06:11
Speaker
So you've got this very high level schedule. And that high level schedule usually when it's developed is like every design development duration is the same duration. Every, you know, you kind of like- it's like template copy and paste. So that that's what we have in P6. And some projects, don't wrong, they they spend a lot of time to to break that down into more detail, but generally you're not seeing anything less than two weeks as a duration.
00:06:35
Speaker
And then you've got a design team. So the design manager, is probably working with the sort of the planner to keep that as updated as possible. You've got design teams that resort to Excel and build these trackers because they're trying give an idea of where they are.
00:06:50
Speaker
But the immediate problem there is there's no logic between yeah everyone's tasks across the full team. And these are normally sort of discipline leads or design coordinators trying to keep track of everything that they're doing. The only way we know that we've got this schedule blowout or sequence issue is when you update the contract schedule at the end of the month. And there's there's this mismatch of detail. There's no logic and it's very hard to stay on top of it.
00:07:12
Speaker
Historically, there's not really been a way to facilitate that in a meaningful way without asking design teams to use complicated planning tools. Yeah, if I could double click on that just very briefly, like the you talked about you had no logic.
00:07:24
Speaker
So if we think about the construction parallel, why do we even have logic in our plan? Usually there's like, okay, but something has to be done before something, you know, the slab has to be poured before you can put the walls on top of the slab sort of thing. So there's like what would be called hard logic. um Sometimes like sequencing of work as well might not be exactly hard logic, but it could be that resources are going to go through a certain path.
00:07:48
Speaker
it's my observation that design has ah almost no very little hard logic ah in it in terms of you could almost start all design immediately you know there's obviously like you might need to do a design report before you do detailed design there's like this mini sequence thing that happens but there's usually no like meta sequence that must happen Is it logic and those sequences that are the the cause those tracking sheets to to be to be inaccurate for them? Or is it some other bottleneck or constraint that, you know, next week when we turn up and look at the tracker and everything's delayed, there's something else going on? So yeah, is it ah is it a lack of like planning with logic or is there some other constraint that's kind of driving delay?

Design Sequence Challenges

00:08:41
Speaker
I think there's a lot of all of it. So you could just imagine like if I'm to oversimplify an issue, you could be working in part of the team that is trying to get a section of the design construction ready.
00:08:53
Speaker
And someone originally planned that to happen after the piece of work that I was working on. you get that construction ready and then I do something that you thought was already done, which changes the design that's in the construction ready part that you've done.
00:09:07
Speaker
And that's like screwing around with that the the the status of all of these drawings, which you need to for construction. So the construction team can use. So there's this yeah prioritization. Yeah, there's like this ricocheting of consequences. Yeah, and you can imagine all this back and forth yeah um between teams. so And then there's also the classic construction team saying, we need something done.
00:09:30
Speaker
And if you've got discipline needs working in si silos, they're obviously trying to blast through everything that they want to to deliver. But without logic and sequence, it's really hard to prioritize that in a meaningful way.
00:09:41
Speaker
not just to deliver it, but to communicate to the team when it's going to be done and everything that comes with it. yeah it's a Tweaking something can can could change a lot of things.
00:09:51
Speaker
um so yeah ah You can see why it becomes a real difficult situation to manage when you're prioritizing. It's like the solution to that means you you probably need actually when up my comment about like there isn't a lot of hard logic or or or fixed sequence it probably points the need for a like very well thought through sequence where you kind of need i need this thing to be kind of locked or semi-locked before i move to this thing Yeah, yeah, cool. Yeah, and like knowing what to accelerate if you need to accelerate something that's in a month.
00:10:24
Speaker
like ah yeah Okay, so so what's everything else that has to be done? Because we can't just start that now because there might be a sequence of events that needs to be hit. So the process that they're running is kind of similar to construction, but a a more simple level of detail. And what teams want is to have that a sequence of activities and that base plan from the contract schedule, but to to distribute that ownership out to these disciplines so they can manage their own time, but within the guardrails of the sequence that's been determined by the planning team, the design managers. Yeah. So um yeah, that's kind of the like problem space they get into.
00:11:02
Speaker
And then from running an actual sort of short-term planning process, and ah most design teams do have a short-term planning process. um It's something that they might review every two or four weeks. And yeah it's normally in Excel, and they're looking a few weeks ahead. But by getting this sort of constant feed of of more live information on at least a weekly basis, it allows them to be a bit more agile. It allows them to spot these issues before...
00:11:27
Speaker
you get to the end of the month and you've lost two months in one month, which is the common situation that we see teams in. And then, yeah, on top of that, actually understanding why we're delayed and understanding which parties are responsible. a lot of these design teams are not just joint ventures, but they use a lot of specialist design houses that are contributing to these schedules. So it's a big coordination piece in itself. It's not just five guys in an office updating drawings that some people might assume is the case.
00:11:52
Speaker
Yeah, that's really interesting because yeah, the thing that I've observed in managing DesignScope is like the the problem kind of stems from when you look at each package or each component in isolation and you think about the steps that need to get done for that to be finished.
00:12:05
Speaker
It's very easy to go, yes, that could be done in two weeks. How hard is it to finish off the design report and get some design drawings issued for the staircase? Well, it's not, it's probably not that, you know, someone sitting there looking at the tracker goes, it's not very hard.
00:12:18
Speaker
but the usually what drives the production of work and the performance is that at the end of the day, every one of those little assumptions of like this could take two weeks so this could take four weeks is resulting in some person sat there with the list of things that they've got to get done in the week and that person can only get so much of it done. So it's usually like a resource constraint on actual production of of work.
00:12:43
Speaker
And ah that's where usually that like tracking sheet where you're kind of just thinking about a package by package and someone who's attending this meeting while most of the designers are back in the office doing their job.
00:12:56
Speaker
Someone's attending this this meeting, thinking about all of the packages and getting pressure from a contractor or a client. When you know when can we have this package? And they're just doing the old thumb suck. Yeah, that's probably three weeks.
00:13:09
Speaker
But if you do like five of those, that will be three weeks or that will be five weeks. It's Bob in the 3D modeling team that's got now like 20 packages to to do in the week. Yeah, exactly. And they're doing, they are thinking about resource. So,
00:13:24
Speaker
um you might have like one structural engineer in the team for example and then if you're resource loading tasks and saying i need this person's time and they go right in four weeks time we need five bobs that's not going to happen yeah and then you go back to prioritization again and and which one should go first and yeah a big coordination piece Simple plans, like, yeah, if we if we if we take for a moment, you know, just thinking through the lens of Apex, for example, the typical pattern is something like a a top-down start from what the master schedule says in terms of breaking down our packages.
00:13:56
Speaker
Then we're trying to break down the work that we've got to do into actual steps so that we're not just thumb sucking. three weeks yeah to be done. The three weeks normally gets broken down to a bunch of deliverables and those deliverables would be things like and stages yeah yeah like drawing updates, model updates, assurance, third party checks, the steps that you need to do to to achieve.
00:14:19
Speaker
And by breaking it down, it's way easier to predict an end date on a bunch of steps than a four week long bar. If you're at day two, no one knows if you're going to finish on week 28.
00:14:30
Speaker
twenty eight Sorry, day 28. So yeah yeah, by breaking it down to that. Probably will be week 28. Yeah. yeah um So yeah, that that granularity is needed for not just clarity.
00:14:43
Speaker
The granularity probably also lets you then ah put the resource or the sub you know the specialist designer and you can see suddenly like we've got third party assurance from these people with 20 packages this week.
00:14:58
Speaker
That's not going to happen. um So you can start to see and spot the the resource bottlenecks. And then also tracking delays against information from the client. because does I get all the shit, but they're still waiting on information too. um So yeah. that's ah Yeah, that's really funny because yesterday I was in, i met with a mega project in North America and they're in design phase and they're asking about the design use case.
00:15:23
Speaker
And so I um i i quickly showed in in the software, this is the typical sequence that you might have. You might do design development and then it might go for client review and then you might update it and then it might get approved.
00:15:36
Speaker
And they said, well, actually it's probably going to go back and forth 15 times from there. Yeah. You know, but you have to. Delay, second review, delay, third review. Exactly. Yeah. Yeah.
00:15:47
Speaker
That's you have to track that as like a, as a, as a design management team and you have to hold everyone to account because they're going to be holding you to account on the dates. Yeah. And it depends why it fails the review, right?
00:15:58
Speaker
So suddenly you're in a world of is it your fault, their fault, someone else? Yeah. There's a whole other book on the on the the review process and the games that get played in there. But we won't we won't open that.
00:16:09
Speaker
Yeah. Yeah. Yeah. ah No, super interesting. I think design is for for project most projects that are Rightly or wrongly, most projects that are massively delayed in the design and construct world, a large amount of that delay is accrued from the design phase and and probably no fault of the actual design teams or design management teams. like the The challenge given, no one's estimated the durations properly because it's an ah and it's ah full of unknown unknowns.
00:16:38
Speaker
right, shall we move on?

Oracle's Licensing Controversy

00:16:41
Speaker
the the controversy of 2025. So for context here, Oracle, the owners of of Primavera P6 have a set of terms of service.
00:16:54
Speaker
And um we were we were hearing more and more ah complaints from people across the industry that Oracle was allegedly kind of sending this audit team, which they, i think they call, i can't remember the exact name of the team, but it's like the the license, the the license inspectorate or something like that. i don't want to.
00:17:18
Speaker
Sorry, it's not called that. um And they were going and checking their customers for ah users in excess of their licensed them amount.
00:17:30
Speaker
And what that uncovered is that ah within Oracle's terms of service, not only does a does a customer need to have the actual users of the software licensed, but within the terms, the the users or people that view the data, whether it be through third-party services or other other API connection, are also deemed as needing to be licensed users.
00:18:01
Speaker
So ah said another way in the example that ah I wrote about the other day, this is the exact example that we hear probably most commonly is someone is using P6 to manage their schedule. There's a couple of planners managing that schedule for a project, and then they are connecting that to a Power BI dashboard to build some sort of report that they can show to the project management team and and probably to the whole project. Some people are putting on a screen in the office. and ah they're getting a lot of pressure to say, well, everyone in the entire office is technically needing to be a licensed user.
00:18:35
Speaker
Let's just start with like, what the hell? And then we can go on to why the hell? Maybe we go there. I can just imagine a project when you have to like submit some data to the client and you're like, whoa, have you guys bought licenses? Cause you can't view this. So sorry, we can't submit the schedule. um ah it's like It feels like Adobe charging you to view a PDF and that they've created. and yeah like is It is your data. So they're then charging you to, like the whole thing is baffling.
00:19:08
Speaker
It's so like siloed in its approach. Like let's close this ecosystem of information that helps run a project um unless you pay for it. It's anti-competition. It's anti-customer, isn't it?
00:19:21
Speaker
Yeah, and and you wonder is, is it like has P6 hit this ceiling of how many licenses it has out there? And now it's, a fuck, how do we generate more revenue? Because if you're not growing, you're you're dying and in software world, so.
00:19:37
Speaker
yeah Are they trying to sort of pull every last pound out of a tool that they're not betting on the future of? We see it as a relationship business. And this is a relationship killer when you send audit teams to see if you're using the data that you own in ways that they're not happy with.
00:19:52
Speaker
It feels like a really odd move, especially as I know that the type of license that they're saying you need to view the data is way cheaper than a P6 license. So they they're probably in um a weird world thinking, well, we've made it a lot cheaper, so that seems fair. But it's the principle of...
00:20:09
Speaker
charging you to view a Power BI dashboard that contains a date from P6 is bizarre. Do you think that the motivation... Yeah, we'll switch to to why the hell. Do you think that it's driven by a... like i ah Is it like an offensive or a defensive move? So to to frame the possible options, at least, that I'm thinking about is there's the the offensive move, which is we you know we've we've saturated the market of potential users. We want to try and find ways to grow that And so, you know, we're trying and capture the use of the data somehow in this licensing world and create this more and more, this like walled garden thing that we we can pull people into. And the defensive move is like, well, we kind of tried that with some of our cloud tools to make this thing that more and more people could access. And that's really struggled.
00:21:01
Speaker
ah We can see that there is a world of... ah tools like on the reporting and AI analytics side, on the BI side, on the authoring and updating data side that threaten to basically leech users over time from us.
00:21:20
Speaker
How do we stop that if we can't make good software? We'll kind of just stick up this big wall around ourselves. Do you think it's like ah it's primarily an offense or a defensive move? like the the industry is moving towards this connected environment. Everything you see is around this idea that like tools will connect. You've got an ecosystem of platforms that are producing data and that's shareable and it's this big collaborative environment.
00:21:44
Speaker
If they're seeing the trend towards that and they back the fact that There still isn't and a suitable alternative to P6 in major projects. like It is still everywhere. We don't see anything but P6 on anything large scale.
00:21:57
Speaker
There could be this odd view that is like, well, why wouldn't we charge for this? Because we are the center of construction. Everything is built in this schedule. They probably think that P6 is the thing that governs everything that happens on site every day to an extent.
00:22:13
Speaker
So it's ah it's like, it feels offensive and defensive at the same time. It definitely feels offensive. um but Offensive. yeah um But yeah, I think like if you imagine, if you imagine you're an executive in the construction division at at Oracle, you know, and by the way, this is a company that literally just the other day signed a $30 billion dollars a year order from OpenAI.
00:22:38
Speaker
um So the construction division is probably like somewhere near the bottom bottom of importance to the business. um But if you're an executive in that division, you know, they've been making consistent investment in, you know, Primavera Clouds and these other tools and they've, you know, trying to grow. And on the flip side, you, if you're seeing any form of leaching or churning or seat ah seat shrinkage across a customer base, surest way to like probably lose your job is to have that. And then you you start going, how do I, know, we'll have to bleep that swear word out. yeah How do I...
00:23:16
Speaker
how do i How do I combat that? Nothing worse than like trying to grow the thing while it's ah degrading or churning underneath. You become desperate. It feels like it's a much more logical thing that it's defensive than it is offensive.
00:23:32
Speaker
And offensive is like double down on what people want to make the tool more useful. Yeah, offensive would be kind of like, let's say like an Apple ecosystem world. Like I plan to ship the world's best BI thing in this thing. And if I bake into my contract that it's like cheaper to use our tool, then I'm going to, I kind of build this like walled garden that I can keep building inside of. Yeah.
00:23:56
Speaker
like Keep the data open, but build ah ah reporting tool that's so good that people will buy it and then make your revenue. That's the yeah that's the well thought out way of improving. ah so For me, the only the way that makes the most logical sense is that they're trying to stem the tide of... of I don't think they have customers like broadly leaving them because like you said, there's no real alternative.
00:24:18
Speaker
But I believe fully the story that we've talked about before and and with with the guys at Knows and Links and stuff where... I could see how they would definitely see a project previously having five seats now has three seats or something like that, you know? Yeah, yeah. I can imagine this is this whole, I guess, this whole thing started from a worry that tools will be developed with a purpose to update the contract schedule.
00:24:46
Speaker
So on a 20 billion pound job, you just need one license and you can do everything outside of that. And then someone's just broadened that definition. And then maybe after that's been done, you've got sales teams going, oh, fuck. Even if that's the concern, like which is i think exact I think you're 100% on the money. I think they were worried that someone would build a a tool to update the master schedule, which people have. There's lots of them.
00:25:13
Speaker
out there where you can go and put in progress updates on things and it will go and update the schedule. Even if that was their concern, do you think that that's like right that they should even do that? if that If that is your worry, just don't allow it as a tool. Like just restrict the ability to update the tool if that is like your primary concern.
00:25:33
Speaker
I just can't think of of too many ah companies and pieces of software that are both very large, successful, and have any sort of net promoter score where people like the thing, where the way that they operate is ah actively avoiding or limiting end user success or benefit or efficiency in order to protect the fact that maybe someone else can build a better interface for updating the schedule than they can.
00:26:01
Speaker
yeah Take like a Salesforce who have recently been accused of ah similar terms in their contracts which stop their customers training AI models on their Salesforce data, which is is somewhat akin to this.
00:26:16
Speaker
Even Salesforce, you can there's a whole ecosystem of tools that are built on top of Salesforce APIs to allow people to go and update records and stuff. It seems crazy to block people's access to their own data.
00:26:30
Speaker
But if you, let's say we we go X, couple years forward and the size of us of the world have one P6 license, like that tool's over. they've They won't even own and maintain ah tool where there's that few licenses out there. So maybe they see it as like a protective measure to ensure the future of a tool that's making them like a lot of money by, and this is specifically the updating thing, not like the the dashboard or anything else.
00:26:57
Speaker
One, like build or buy ah tool that does the updating thing well and sell that, you know, like build it or buy one because there's like tons of them. They're probably not that expensive and sell that and keep the ecosystem open and keep a competitive thing so that you can make your you can make your customers more efficient. Like in the day, the promise of software is some level of efficiency or benefit for customers.
00:27:21
Speaker
And the moment you like jump over a fence to protect revenue to make your customers less efficient or stop them becoming more efficient, you've like really got your whole world upside down as like a technology vendor. Yeah.
00:27:33
Speaker
Right. So like. you Got to look in the mirror at that point. Yeah, totally. It's like, are we actually having this conversation? Yes. So yeah, I think they have to build or buy a tool to do that.
00:27:43
Speaker
um But also going back to data ownership. Or change their pricing model. Like if they're going to provide a database, you can price your database solution, not per license. Like they're selling effectively like a database.
00:27:55
Speaker
They've kind of got this SaaS software, not SaaS software. desktop software that is an interface on top of a database and they're pricing that database through the lens of the the seat or the user using the software yeah yeah so i think they might need to just also rethink that whole pricing model And ah yeah, then the the other side of this is if it is your data, even if it's been updated, the set of dates that you originally owned, use P6 to update, et cetera, and you pull that data out, it's surely it's still your data. it doesn't become theirs because they've manipulated that data.
00:28:31
Speaker
No, same with Salesforce. I go and put my my you know my contacts and stuff in into my CRM like Salesforce for them to go, well, no now you can't you know ah train an AI model to make yourself more efficient.
00:28:44
Speaker
Yeah, sure. Training that model or updating the data in P6 is going to result in calls to a database. So price it like a database. If there's two parts to this, which is like front end software and a database. The problem for Oracle is just like databases are super cheap. they They're not- Yeah, yeah you can't slap a big number because everyone knows.
00:29:04
Speaker
Well, yeah, I can go to, ah you know, you can spin up a you can spin up a database for for basically free. I think naturally, yeah, Oracle has a database and this UI and the UI is like really struggling. and But yeah, the way that I think the pricing model really needs to be detached.
00:29:19
Speaker
ah Yeah, repeating what I said before, the moment you're a technology vendor and you find yourself having having a conversation that's like, how can we how can we do anything that blocks the benefit of our customers? You know, them moving forward is just like a big, like, have a look in the mirror moment.
00:29:34
Speaker
Yeah, short-term thinking. Yep. I don't think they're going to change that. I think those terms have been around for, I think, five years, ah someone mentioned on LinkedIn.
00:29:46
Speaker
um So it's not like a thing that has changed recently. took them five years to pull together an audit team. That's right. that Honestly, that is actually true. ah That is 100% true. All right, let's briefly dive into the to

Who Decides on Project Technology?

00:30:02
Speaker
the world of LinkedIn. So a post the other day by ah by James Swanston asked the question about who should own the ah construction technology relationship on ah on a project. Said another way, it's like, who should who should decide what technology is used on a project? Should it be the the general contractor?
00:30:24
Speaker
Should it be ah the supply chain? Should it be the client? Should it be the consultant? And what are the pros and cons of of of each of those parties driving it? don't know if you immediately have thoughts off the back.
00:30:35
Speaker
think there is a bit of both. So it's there's the relationship that There's the purchasing relationship and then there's the ongoing support relationship and they they do slightly differ.
00:30:46
Speaker
If we think about decision purchasing and and running that process, there could be benefits from both client and contractor. I'm going to ignore supply chain for now because I've a different view on that.
00:30:57
Speaker
A client on a major scheme by purchasing software can obviously enforce consistency across contractors, has buying volume or buying gains and can run the process at the right time, like before people start because contractors bit more reactive to to buying software.
00:31:14
Speaker
So I can see the the benefits there, but then the there can become a friction because some contractors deliver a project in a certain way, they use certain tools, and if that differs from the ah client, how does that work unless they put it into the contract? So I can see benefits from the client running that on a a scheme like we spoke about in the previous episode of lots of...
00:31:35
Speaker
tier one contractors working on a ah super scheme. Whereas the contractor is closer to the problem, probably, depending on the type of software, is ultimately probably going to be the end user.
00:31:46
Speaker
So you want something that is most suitable for the team or group of individuals who will be regularly using the piece of or the the innovation or the tool. There's some benefits from being the most suitable tool could be the one that's selected by the contractor, but then you haven't got buying gains, you haven't got you might have different contractors within a client organization using different tools, which makes reporting and oversight difficult. So you could see that kind of decision point across the two being a conflict depending on the type of scheme.
00:32:16
Speaker
For me, it's like a frustratingly stupid question.

Systems of Record vs. Collaboration

00:32:21
Speaker
And what I mean by that is, I guess you kind of have, if you classify technology or so or software at least into like systems of record, so this is where we, you know, the ah RFI lives or where the the drawing lives or or whatever.
00:32:36
Speaker
And then you've got like systems of collaboration. So it's like how we work together on a design or so or something like that, where you have, you kind of have to work together in the software. This has a lot of overlap with the Oracle conversation where like systems of record, it should not be a discussion about which piece of software we're using because it shouldn't matter.
00:32:54
Speaker
Why the It shouldn't, but it could because some there might be a dis that there there could be a varied functionality which closes doors on certain aspects. Almost never though, like most of the main pieces, like in Autodesk raise an RFI in protocol, or you can raise an RFI. The post talked about like an Autodesk versus protocol, call for example, as an example of this selection.
00:33:17
Speaker
It should be that we can set an integration that maps the fields together very, very quickly and off we go. We can pass one from the other backwards and and forwards, except that it's not in the interest of the um vendors to have a direct integration, easy to use with a competitive set because it removes one of the levers to drive a standardization of their tool across a contractor.
00:33:44
Speaker
or ah an owner's organization. So I think it's it frustrating that you're having this conversation at like a system of record level, because I think the problem shouldn't, I think if you think about every other industry, every company uses their own piece of software that they choose that makes them most efficient to deliver whatever they're delivering, and that that information should get passed to the next person that needs it.
00:34:07
Speaker
it's I think it's just crazy that a system of record that a system america might require that every single person on a project is a user in their system. it just like it's ah It's a crazy model because you now in construction, every one of the people on the project, the general contractor, the supply chain, the owner, almost every single one of them will be delivering many projects at the same time.
00:34:29
Speaker
which means by definition, they're in this world of like getting, we're having this stupid conversation about, you know, on six of my projects, I use this tool, four, I use this tool, seven. And then I, by the way, I i use this, i but I use two tools, you know, because I'm having to do the one for them and the one for us.
00:34:45
Speaker
ah think systems of records protecting their own patch and ah intentionally not integrating with their competitors is like a crazy problem ah to still be having.
00:34:57
Speaker
i think systems of collaboration where you're more likely to have this, we both need to be in the same spot in order to do the work together. which to be clear some of pro core is that some of autodesk is is that is a different story and i you know it depends probably on what the work who the owner of that workflow is is probably the best driver of it yeah yeah yeah i i totally agree on the system of record any collaboration piece yeah ah it it needs to be the organization or the body of people that need to use it closest to the problem and and have that day-to-day use because then you get that disconnect of
00:35:34
Speaker
someone making a decision without that group of people in mind. Yeah. But most cases are going to be the contractor at that point, I believe. um There may be a few from a client organization like communication tools. There's collaborative tools in design.
00:35:50
Speaker
it's hard to think of uh instances where you want the supply chain to talk to define their own tools unless it's something that's specific to have for them to function and it isn't a requirement of others to be involved in that that tool itself so um that makes sense for them to choose themselves yeah um sorry to like blow up the conversation but yeah the it's It i feels like a frustrating conversation to be it to be having. I think we're out of time.
00:36:20
Speaker
We are indeed. Right. Thank you very much, everyone, for tuning into today's show. If you did enjoy the episode, please do think about liking this video or following us on your chosen podcast platform. We really appreciate your support and we'll see you all next week.
00:36:32
Speaker
Bye-bye.