Thanks for coming, we've got a full house. Brilliant. My name is Jareth Reeves and I'm really pleased to welcome my friends from England here from nPlan. nPlan has been involved with AACE for many years. We've submitted quite a few technical papers. This one's going to be quite an interesting one, just like the previous ones on the graph neural networks and AI schedule risk analysis. Really interesting stuff. So without any further ado, I'll hand over to you guys. Cool. Thank you. We're going to be talking about how AI can be used to generate and iterate on a schedule. If that's not the talk you want to listen to, you can leave now. We'll start with some brief introductions. Rhys, do you want to introduce yourself first? Sure thing. You're a bit of an act to follow, so I'll go up front. I'm Rhys. My background is in civil engineering, tier one UK contractors. About three years ago, I tried to... I decided to try my hand at software and technology. So I've been working at nPlan, deploying nPlan's product suite across the UK, North America. They keep you busy, what can I say? Helping bring the world nPlan. And Dev? And I am Dev Amrathia. I serve as the chief executive to nPlan. I'm one of two founders of the business as well and come from a background in delivering large energy projects with Shell, where I was a project manager. I did that for about nine years on four different continents, managing large projects. Yes, there are seats here, here, here, and there. If you want to take a seat, it's 55 minutes more to stand. So there's some seats here. Did that for about nine years. For all my sins, then, I became a special advisor to the previous to previous to previous British prime minister. We tend to change them around quite often in the UK. And I served Theresa May when she was prime minister. I worked as her advisor on emerging technology, which was a rare and junior role for that prime minister. I wrote the UK's strategy on artificial intelligence after leaving Shell. And nPlan is a bit of a genesis of these two things. I saw how hard it was to get large projects done when I was at Shell. It took a little bet that I wasn't the only person in the world who struggled to deliver my projects. And then I saw how powerful AI could be back in 2016 and 2017. It was far less popular back then. And set off to go build nPlan from there. Like I said, top act of fault. We're going to go through these kind of four main parts to this. We'll leave about 15 minutes towards the end for you to ask us any question that you'd like. But we'll start with a little bit of background and scene setting. Why we thought we had a privileged position to be able to build a system to generate schedules. We'll show you how it works. We'll show you the challenges of doing this kind of work. We'll tell you about the limitations of the systems as well. We've not built God. It has flaws. Don't worry. And we will try, and please don't decimate us for this, do a live demonstration. So we will create a schedule here today in front of you. No magic tricks. We'll hopefully, fingers crossed, it'll work. Tiny chance it doesn't. Cool. Let me give you some background on how this all came about. Because I think this is important context to help you realize where this is going as well. So we started the journey of nPlan eight and a half years ago now. And we started on this basis that it is incredibly difficult for professionals in the world to understand how long a project is probably going to take, what could go wrong with it, and what they can do about it. This is typically reliant on the experience of a project team that you bring together. We are constantly affected by the biases that we live in. And we believe that there is a better way to do things. So what we set off to go do at nPlan nine years ago now was let's try train a machine learning algorithm to go learn how previous projects perform. And then if it can learn this experience in the same way that we, the professionals sitting in this room, learned about how projects performed, then it might be able to help us answer some of these really spiky questions about project performance. How long do we think this project will take? What could go wrong with the project that is in question? And what could we do to improve it? The simplest way of thinking about this is the way we learn. And this is the way I learned when I was at Shell was we made assumptions, plans. We then went and built those plans, which is you're now performing on your construction project or engineering project. And then you have built it. And the difference between what you plan to do and what you actually do is what you're learning. Right? I thought it would take us 15 days to do this. And we took us 25 days to get the permit. It took us 25 days to get the permit. Now I have learned something, right? And hopefully I'm going to be a bit wiser on the next project I get to work on when someone says, oh, of course we'll get a permit done in two weeks. I can say, no, I've seen this happen before. Right? You can see this pattern. The more experience you have, the better you get at recognizing these things on projects. So what nPlan has now done is we've amalgamated just over 750,000 project schedules. They come from all over the built environment. It covers just over $2.5 trillion of capital that has already been deployed in the world where we've seen what was planned to happen and what actually happened. There are hundreds of millions of activities in there where we can see what was planned and what actually happened. Right? That's the basis of that learning. We basically know a lot about how projects were planned and how they actually turn out. I'm not going to go into much detail of that. But you might wonder where the 750,000 projects come from. These are the few organizations we are allowed to name, but these types of people. In summary, they're people that build a lot of big things all the time. It does come from mostly energy, infrastructure, mass transit, utilities, power gen. That's the kind of game space we usually play in. And that gives us this incredible privilege to understand more about the world and how we can see what we can see. And how it gets built. So let's dive a little bit deeper into the life of a scheduler. This is clearly something that we have spent a long time studying and working with. We work with schedulers and planners all around the world today. And there were two kind of frustrations that came out, right? The first is how long does it take you to handle the schedule? So the word handle is used to describe how long does it take you to connect activities together? How long does it take you to type the activity name? How long does it take you to drag and drop? And of course, each of those things in individuality is quite small, right? But now you have a 5,000 activity schedule. And you know, those numbers can go up and up and up and up. We've seen schedules that people are very proud to say, this is a 75,000 activity schedule. And I can't even believe that a poor soul built something like that. There's pain involved in this process, right? I hope you're laughing or smiling because you felt some of this pain or have seen someone go through this pain. There's nothing heroic about this work. Nothing. The most valuable thing a scheduler or a planner does is to think critically about how to execute the project and then communicate that in an effective way. I promise you, I promise you, I promise you, I promise you, the act of drawing a relationship or extending a bar in the Gantt chart format is not the most valuable time that a scheduler should spend. So if you're spending most of your time doing this thing, call it the handling part, wrestling inside your scheduling software, are you spending enough time communicating, thinking about your options, thinking about scenarios, and being strategic about what would happen if something happened on our project, right? The what ifs. This is a constant battle that I used to go through when I was a project manager at Shell, where the schedule is a singular depiction of the future, a singular, one version of the future. But of course, if you've heard the saying, the schedule is only ever as good as the first day we reach the field, one of the reasons people are saying that is because, well, the schedule only told us about one thing. We didn't consider hundreds of options in front of us. Like what would happen if this happened or this happened or this happened, right? It just becomes too overwhelming and too complicated. But these are important discussions to have as a team. So we wanted to try and see, like, how do we unshackle these poor souls from doing this work that frankly isn't very value added? So there's three things coming together here, right? Endplan has this incredible experience on a vast volume of schedules. AI has rapidly made its way onto the front page. Technology has developed at a rate that no one had anticipated, not even Endplan, not anyone in the AI sector either. And the third is that we've never seen such a dramatic shortage of skilled schedulers as we have right now. There are more scheduling jobs available in the market over the last year than they have ever been in the history of mankind. So take that in for a second, right? We're trying to build more things and we don't have more skilled people to build them. I mean, that's why, you know, conferences like this are so important. We're trying to transfer this knowledge and raise the game in how much we all know. But the fact is still the same, right? We just don't have enough people. And the confluence of these three things leads us towards building Schedule Studio, which will tell you a little bit about the underpinning technology now. Thank you so much, Dev. Yeah, and thank you all for coming. We appreciate it's the last day of the conference. It's after lunch. You could all be on Venice Beach, like my colleague will be, fairly soon. But you're here hearing about schedule generation technology. And when we look back over the last kind of two and a half years of fundamental research and kind of product research as well within MPLAN, we notice kind of really seven key technologies that can be split into two groups. There's a group of technologies that help us to gather and synthesize information. It's like optical character recognition, retrieval augmented generation. And then there's some technology, mainly large language models, which we're hopefully all familiar with now from applications like ChatGPT. And five real trends within the language model space that allow us to gather information and then use it to be able to gather information. And then we're going to actually build schedules. We're going to dive into these a little bit before we have a look at Schedule Studio. First up, gathering information. Hands up in the room. Who has read an RFP in the last year? A kind of scope document. Yeah, there we are. We're in the right room. Great stuff. Yeah, we spend so much of our lives reading documents, making notes, making sticky notes, making notes digitally somewhere. And obviously one of the first challenges when we were building Schedule Studio was, OK, how do we give computers the ability to digest and synthesize and synthesize and understand all of this data? And two, technologies come in very, very handy. Optical character recognition is essentially used to extract information from documents, like scans, handwritten notes, pictures, whiteboards, etc. We do so much of our work analog these days. I'm personally a bit of a Luddite when it comes to things like note taking. So being able to snap a picture and ask the AI to say, right, please summarize all this information and store it somewhere for me digitally, super useful. Retrieval augmented generation is maybe something fewer people in the room are familiar with. Who has heard of RAG? Possibly in the wrong room then. No, a couple of hands going up. Excellent. Retrieval augmented generation allows large language models to use specific pieces of information from specific documents within the schedule generation process in this example, but more generally in their outputs. So lots of people have talked to this conference about how ChatGPT is unreliable. That's because when you ask it a question, it knows everything from the answer to your question to the latest Lakers scores. By using RAG, you can say, hey, use that knowledge base and that reasoning capability, but look at these documents to answer my question. And obviously, when we are building schedules, we've got lots of documents as inputs. We want to use them. And this is an example of retrieval augmented generation. This is a real RFP that we downloaded a couple of days back. It's about 195 pages. It gives you everything from the project outline, the scope, the sequencing, the contract model. And if I was building a schedule, the old-fashioned way, as I used to do, I would have to read through every single line, making notes as I go. We've got some nods in the background there going, yep, I've felt this pain before. And I'd have to digest and synthesize all that information, hold it in my mind and in my team's mind as we went to then build the schedule. The RAG pipeline, MPLAN, has built as part of the schedule studio platform, is able to do exactly that. So this 195-page document, it reviewed it, created a taxonomy of facts, fact types, things like external dependencies, the scope and objectives, financial considerations, timelines, constraints, etc. All the things we think of. But it did it in 10 minutes. 10 minutes, the process of 200-page documents. When we tested externally and internally with construction professionals like yourselves, the retrieval accuracy and the taxonomy accuracy, i.e. the classification of the facts, was on a par with human beings. And it cost less than a dollar to do. This is a key piece of technology in generating schedules and lots of other applications as well. And you can do this, you know, this is just one document. You can do it for as many documents as you like. More on that later. And then we get to building schedules. We've got all of our information in a big data lake, in a big bucket. And, well, hands up in the room. Who has tried to generate a schedule using ChatGPT or Gemini? I've had a couple of conversations. Yeah, thank you. Thank you, sir. There's a couple of people in the room. And I'm guessing it wasn't perfect. Yeah. Yeah. Yeah. So that's where we were two years ago. How the hell is this going to work? And thankfully, it now works. That's why we're here. And there's really five things that have made it work in the language model space. The first one is parameters. These are basically the concepts we understand. They are the core of knowledge. You can think of parameters as like a space an entity can fill with facts that help us navigate the world. The more parameters you have, the greater the intellectual area you can cover, the greater the nuance and detail you can understand. Parameters are a really abstract concept, to most, myself included, but they're indicative of the potential of a language model. About eight years ago, models had about 350 million parameters, as they could hold 150 million concepts, if you like. Today, we're at two trillion. So that order of magnitude change is indicative of how two years ago, even 18 months ago, a year ago, this simply was not feasible. It is now. Of course, when we think about project scheduling, you know, understanding nuance and detail and interconnections between different facts is super, super important. It's the difference between having a, probably what you've got, a completely linear schedule with 10 lines, and, you know, a 300 line, highly parallelized schedule that's reflective. So parameters are almost like our container. Obviously, it's data that we fill that container with. Parameters might be potential, have the space for these concepts, but it's the data that fills in these parameters with useful knowledge. And like the explosion in parameter capability, data capability has exploded over the last two years. Language models are essentially trained by being repeatedly presented with vast amounts of diverse text obtained from various sources, and being exposed to various sources, and being exposed to various sources. And being exposed to it repeatedly, so they remember it. A little bit like we, if like me, you've ordered the wrong amount of concrete on site five times, you definitely don't make that mistake again. But you have to learn over time. Again, seven, eight years ago, we were at about 3.3 billion tokens, and ease of understanding, you can think of it as like a token as one word that it knows. We're now at around 13 trillion tokens for the largest model. 13 trillion tokens for the references. The entire internet, plus proprietary sources, plus synthetic data, etc. It is every word, number, story, thought, lessons learned documents the human race has ever digitally recorded, encoded in one model. And obviously, if it's in the data, it can use it, and no. It's pretty powerful. Models have just increased to this point where, compressed within them, the knowledge of humanity is there, latently available. The knowledge and the kind of misconception, shall we say, of reality. This combination of parameter space, plus ever larger amounts of data, means that language models just routinely equal or surpass human level performance at complex tasks. We work in the software space. There are language models that are equal to human software engineers. There are language models that can routinely create elegant mathematical proofs that have been hidden to humanity hitherto. They're not things it's retrieved from Wikipedia somewhere. They are net new novel So the first one, maybe a little bit more familiar to some, is the idea of context windows. So at this point where, great, language models know all of this stuff, and they can answer questions about all of this stuff. But I don't want my language models to be telling me about the Lakers results when I'm trying to generate a schedule for a waste of energy plants. I want to ground it in a knowledge rack that we talked about earlier. This is where context windows are super, super important. It's great that LLMs have read the entire internet, but I wanted to look at this specific document. It's not on the internet. A context window is basically the amount of information that you can give a language model and say, hey, please use this. A little bit like kind of parameters and data. There's been an explosion in context window capacity about two years ago. So we're talking very, very, very recent. You could probably give a language model about 5,000 tokens, about 5,000 words worth of information to use in outputs. Any guesses to where we are now in terms of context window tokens? Take a guess. Over a million. Over a million. Over a million is 60,000 pages. Now, I've seen some hefty RFPs in my time. None of us passed 60,000 pages. We're at the point where we can put entire libraries into a language model and say, hey, use this to answer our questions. So we think about all these documents we get when we're trying to build schedules, RFPs, RFIs, sign drawings, etc. All of that can be used as context generating schedules in the future. And this allows LLMs to form a more holistic understanding of the project's requirements, constraints, objectives, and grounds it in reality and truth, and avoids things like hallucinations, which I'm sure we've all experienced. Now, the getting structure is another fundamental improvement to language models. As we increase parameter size, diversity of training data, and the size of context windows, LLMs have an enhanced ability to interpret, navigate, and reason about structured data. Even 18 months ago, if you gave a language model an Excel sheet with 100 rows and 100 columns and said, tell me about this data, it would likely fall over. And that's a very, very simple structure. That is no longer the case. If we keep in mind that construction schedules can be conceptualized as large, interconnected network graphs, i.e. structures of tasks, milestones, links, and also WBS, RBS, CBS, VBS, etc. These are all structures that language models can now navigate and understand, and therefore reproduce. Possibly the most important, though, is sequential reasoning. The ability to break tasks down step by step. These first four things are great, but they don't get you to the ability to generate complex networks, like construction schedules. Early LLMs were constrained to generating immediate answers, so people who've used ChatGPT will know that, you know, you ask a question and it rushes to give you an answer. That was a very conscious decision from part of the people making these models, because they perceived that time to value was important. Now, it is for some use cases, but for things that are much more complex, you want people to think about it. If I gave you a button and said, you can press this button and get a schedule in one second, you're not going to trust that schedule. If however it takes an hour, and you know that the machine has been thinking about it, you implicitly have higher trust, and you definitely get better results. In terms of applicability to kind of automated schedule generation, when you're creating a schedule for a multi-phase project, like a commercial building, these models can determine the logic, the sequencing, the interdependencies, the fact that concrete has to be poured before it can be cured. All of this is implicit in the model's understanding. of reality. That's a lot of technical information, certainly for a Tuesday afternoon. But this is kind of how it all fits together end to end. So you can drop your documents into a system like this, and the system will create a high level project description. It'll tell you what it understands about documents you've shared. You can then validate the assumptions that AI has kind of made about the project, and add your own information if necessary. From that, you can generate a project sequence, WBS, and again, philosophically at Endplan, everything we do has human beings in the loop. It's not press button, get schedule, it's press button, human in the loop, and validate, get schedule. Once you've reviewed and edited your WBS, you then generate a schedule based on that phase, that sequence, and that work breakdown structure. Importantly, obviously, you can then edit it, you can interrogate it, and you can export it over to P6, because P6 hands up with a the room who uses P6. Pretty much everyone. These have been some slides, but God willing, I'm now going to show you Schedule Studio, and hope that it works. So... Very simply, I'm going to start by pressing Start Creating. Now, Dev did say we were going to do this completely live. Given the time we've got left, I'm just going to show you the step-by-step. It would take the rest of the session for us to generate a schedule end-to-end live. I do want to leave time for some questions. So, once I've pressed Start Creating, I'm going to get to this page here. Very, very simply, there's three things. Textbox at the top allows you to basically put any text you like about your project in there. You can direct the system to try a multi-span rather than a single-span approach to the bridge that we're building. Anything at all. Here, I've just posted in a project overview of the i35 NEX project over in Texas. I've done that because I've also included the RFP. It's about a 200-page PDF. It was actually the one that we looked at earlier in the RAG example. So I'm giving this system the kind of the most basic information that I'd expect to use myself as a scheduler to build out a plan. There's also a simple project overview in there that is literally just lifted from the Texas DOT website. All publicly available information. And down in the bottom right-hand side, where I can move it over here, we've got our phases. This is just, again, default based on the information I've put in. But, as you'll notice from the text and the add new phase, you can add or remove phases as you like. Let's say commissioning is not within your scope. You can tell the system, hey, just don't look at commissioning. Let's say you are in control of what's being generated. Now, if we have more time, I'd click Create Schedule Overview, but that might take about five minutes or so. I don't want to be standing up here for five minutes in silence. So I'll hop over to here. This is an overview of your schedule. Now, this is all automatically created using all the technology that we just talked about. We've got the location, we've got the start and the end date. Again, this is from the RFP. We've got the duration. We've got what the project actually is. And down below, what the system is doing here is telling you what it's assuming. I'm sure we've all had bad experiences with generative products where you go, why on earth have you assumed that's what I wanted? This is transparent. So this is the summary. And each of the phases has a phase breakdown summary as well. And you'll notice all of these are editable. So if it's misinterpreted something, if it's made an assumption that you don't like, or if you just want to give it more information and clarify something, you can put it all in there. And this is the same for every single phase. Now, likewise, what I'd now do is generate a WPS. And I'm sure half of you in the room are thinking, my organization has a standard work breakdown structure that we use. If that's the case, you can throw that in as a document. And as we talked about earlier, retrieval augmented generation will mean that this system will go, ah, that's a work breakdown structure. I'll put that over. That's not to say it's a simple copy and paste. If it perceives that there is no commissioning work in your scope, your RFP, it probably won't include a commissioning section in the work breakdown structure. However, if we hop over to here, we've got our automatically generated work breakdown structure. And if I don't like some of these things, I can simply remove them. If I want to add something, I can simply press add. Again, the human is in the loop. You are all in control. And finally, what I do is press generate schedule. This is the bit that will take between 20 and 60 minutes, which is a current limitation of the platform. What you guess out of the end, and pray for me here because perils of a live demo. Jinxed it. Jinxed it. It would be the final tab as well, wouldn't it? It would be the final tab. Marriott Wi-Fi, honestly. So you're what? This is dead, by the way. Sorry. Yeah, he's on Twitter, honestly. Yeah, this is... All these all do talk amongst yourselves. That is very poor. Yeah, I've missed my own name. That's a real strong move. There we go. And again, pray for me because I have not put my password in for quite some time. Ta-da! Fantastic. Pretend that didn't happen. We will cut that from the recording. Thank you very much. Where were we? We've started from some documentation, RFP, project overview, very, very standard stuff. We've extracted a summary of the project and the phases, and we've seen how we, as the human beings, in the loop, can influence what the model then uses. We've used that phase breakdown to create a work breakdown structure, and we've hit go. This is the schedule that we get. This is a fully logically linked schedule using the WBS. All of this is obviously, you know, interoperable as it would be in P6. Each of these activities has start dates, end dates, and are reflected of project. Hopefully, hopefully, hopefully, hopefully, hopefully, hopefully, the last interruption. All the way down to... ... to... ... to... ... honestly. ... it's connected to the... ... the wrong Wi-Fi. ... it's really... ... ... honestly, I'm never presenting again. It's quality review time coming up. I'm gonna get cooked. I'm gonna pretend you're laughing with me rather than at me. I was gonna say, logically linked schedule, activities reflective of the scope and the sequence and the phases that we've inputted. Project end milestone right at the end. And there's kind of two interesting things here. Nobody in their right mind is ever gonna go and build a job based on the schedule that AI has created, even if you're not going to be able to do it. Even if they've had, you know, human input. You simply won't do it. You, as the scheduling community, have to stand behind the plans that you create. So we've given you three options here. One is very simply, you can just edit this manually as you would in P6. The second is that you can export it to P6 and go and make more, you know, nuanced detailed edits over there. And the third is that you can ask the schedule, you can ask the system even, to edit the schedule using plain text. So over here, I've said add a control room for the toll road of this site. Start the control room. I've said construction in parallel with the site preparation works. And it's gone okay. I'll add the construction detail for a control room in parallel with the preparation works. All I need to do is confirm that edit. And those activities are now in there. There's a full edit log and you can add or remove, revert or change anything that you've done. And exporting to XCR is as simple as export. Thank you very much. That was the end to end process. I'll now hand back over to Dave. Dave. Talk a little bit more. Thank you. I have a very small detail to continue on with that. When I was at Shell, we were working on a large polyethylene plant in Pennsylvania. And I was part of the team that took the project up to sanction FID. And it was about a $14 billion facility. And we, the owner team had, you know, a contractor EPC working on the feed package. We took that to the board. Please give us $14 billion. We promise we'll get you this polyethylene plant on time and on budget. They of course didn't believe us. And they said, cut a billion dollars out and you've got the green light. So we started value engineering, which is fun. Everyone had lots of ideas. It took us a week, no more than a week, to come up with all our ideas. There was everything from let's make the tarmac five millimeters thinner to let's build the facility modular instead of stick build, right? So some being more strategic than others in the changes we're about to make. So it was about a week of coming up with ideas. And then it was seven months of redoing engineering to get us to the new package. And of course, one of those changes, like, let's do it modular now, which you can imagine if you've got, you've finished feed for a $14 billion facility, you have quite a lot of stuff you need to go through again to figure out how to modularize such a facility. Seven months later, we took the new package back to the board. And it didn't make much economic sense because the price of polyethylene had shifted in the market. You can imagine how we as a project team felt when that happened. Eventually, the project got financed and it's now actually an operating facility. But the pain we went through in not being agile at responding to these changes we had to make in the early stages of the project were just catastrophic. Right? They really hurt the economics of the project in the end. One of the things that I did, as soon as I had access to this was I recreated the schedule for that facility again. And then I played the scenario out, right? Right, you've given me the schedule. Now I want it modular. And it the interpretation of the system to take that instruction of go from stick build into modular, and recreate the schedule with that fairly simple instruction or an idea, into this new version was done in 60 minutes, right? Something that we as a project team would have never been able to reach in that kind of speed. So the kind of three things that we've heard over and over and over is, you know, there's a lot of data, it takes a long time for us to ingest everything and understand it as a project team. And then we have to make this into a reality and reflect that into a schedule, right? We've shown through retrieval augmented generation and large language models that generation and large language models this becomes really fast. These things read massive documents and interpret them incredibly accurately and quickly. The second one is a really interesting concept that dealing with an uncertain future is almost impossible. What that means is, today, in present moment, if you are scheduling a project that is six years long, you don't really know what's going to be the what the world will look like in six years time. But you are required, to give certainty to give certainty to the world around you, to your stakeholders about what's going to happen in six years. Do you really know how you're going to commission the thing in six years time? Question mark, right? Do you have all of the information present right now to tell you how something is going to work many years into the future? Most often not. So this is a fact of life. There's no AI system going to change this, by the way. The further out in time you go, the more uncertain your future will become. It's just life. Given that life is not going to be any different for us, no matter how much AI changes it. How do you handle that? How do you process this fact of life? One of them, one of the really interesting features that we think this unveils is you're just a lot more agile about handling new information, right? A new long lead supplier is just sent in their documentation, ingest it, read it through a large language model, ask a large language model, ask a large language model, to update the schedule with new information that's just arrived. That kind of agility to be able to handle new information quickly and in an agile way is your secret weapon. And testing scenarios, this is really powerful. And I wish when I was building that polyethylene plant, we had tested our scenarios well before we reached the final investment decision. We went to the committee with one version of the truth, and it was like, here it is, this is the best thing we could possibly build. And they said, well, no, it's not. Build it for a billion dollars less, and then it's the best thing you could build, right? We should have, that kind of analysis of like, there are a hundred different ways we could execute this, and thinking across hundreds and, dare I say, infinite number of scenarios about all the possible combinations and permutations we could use and think about to execute our project, is a more powerful lever to pull on to get to a better project outcome. The biggest thing that stops us is that it just takes too long to think about many scenarios. So we kind of take a little shortcut and say, let's just think about these few scenarios instead, right? This is, of course, only applicable to the very early stages of projects when you're in option selection and concept design, right? Of course, you're narrowing down, and then you choose your one option. But if you never thought about enough options to start with, you will inevitably hit these scenarios that, you know, you'll see these scenarios that, you know, I painfully went through and perhaps some of you have also experienced. Now, let me tell you about what this thing is limited on, other than internet connections. It is limited to the size of the project being, the project schedule being created right now. It is limited to about a 350 activity project schedule, which everyone is, easily can tell you, is a fairly high level project schedule being generated, right? This is not production level schedules. You cannot go hand this over to a foreman and say, here you go. Here's your instructions to go execute site-based work. I wouldn't do that, at least. By the way, when I'm saying limitations, I'm talking about limitations right now. I do not think these limitations will live on for more than a few months. The second, and I think this is an important one, none of the systems, none of the technology today is capable of reliably interpreting drawings. And what that means is that these systems have no spatial awareness. They don't know that the distance between the pipe rack one and pipe rack two is intertwined by something else and that you're going to have to do some gymnastics to be able to connect the two pipes together, right? That's an advanced level of thinking. That requires spatial awareness. That requires spatial awareness, requires drawing interpretation that generally would occur when you're ready to make production schedules. But in the higher level schedules, this capability does not yet exist. Again, I'm stressing it's a matter of time. So given that these limitations do exist right now, the right time to be using this is bidding and option selection. I talked about the value of being able to get through many, many scenarios quickly, but bidding is a really interesting one, right? We've heard from many GCs and EPCs that we get so many opportunities through the door. How do we drive down the cost of responding to the opportunities that are coming our way? Of course, the schedule is just one component of the total bid that you have to put together, but hopefully you're now putting the schedule together much, much, much, much, much faster than you would have ever done before. The important thing about the systems when you think about their use and their interpretation of their use is that you are not just trying to find a shortcut to producing a schedule faster. I mean, that's nice, but that's not, call it really an aspiration we should have as a community. The aspiration is that you're able to think faster and more critically about these questions. As Reese was whizzing through that demo, you saw those boxes filled with text, which was the AI system throwing assumptions at you. As a planner, as a scheduler, your job is reviewing these things. And as you're doing that, you're just way more critical than if you didn't have any of that information to criticize. The fact that something gave you something to criticize will allow you to become more critical. Sounds a bit circular, but trust me on this one. When you're in the edit mode, when you're in the edit mode or I am in review mode as a scheduler, you are doing more valuable work. I was leeching into this slide. But the bits that we're all excited about is how fast things become, how we drop some of that schedule grunt work out of the system, and how we really get to play with scenarios, how we get to think in options, and how we get to handle these changes in a much, much, much more agile way than ever before. Just that edit feature, the ability to just give a strategic edit to the schedule. I'm not talking about, I think the permit should be instead of 14 days, 21 days. That's not a strategic edit. But saying, hey, let's not do it modular, or let's do it modular instead of stick build. That's a strategic edit to your project, right? Being able to handle these things in a fast, agile way allows you to be able to respond to the most strategic questions your leaders will ask you. What happens if, you know, dot, dot, dot, and many people, many schedulers all around the world hear this all the time, but just can't give someone an answer? Imagine you could just write that stuff down in your notepad, and by lunchtime, you've got 25 different answers to some of the most strategic questions being asked by that project team. And that's it, folks. We've got some presents for you today. The presents come in the form of QR codes, but on that side, it's free. So everything you just saw today, you can use for free for 30 days. It's not free forever. I wish we had that kind of money in the back, but we don't. But play around with it. If you really like it, you know, and we're all friends, we can let you use it for free for a little bit longer as well. So that QR code takes you to this page where you can just sign up to it yourself. Just a disclaimer, if you upload documents, we will not use anything. We are not looking at the documents upload. If you want to upload, I don't know, create a schedule for a missile system, I don't know, that's on you. Like, we're not doing anything with that data. So yeah, the T's and C's are written there if you want to read it. We're not using your data is a simple way of saying that. And then down in that corner is a bit cheeky, but we're also running an event. It's not as big as the AAC. We call it AI Day. And one of the really painful things about doing this conference here today was that as a company, we release our products twice a year, just like Google and Apple. We kind of want to be like them, I guess. But so twice a year, we release do our big releases. And I couldn't show you some of the things that we've been working on because they get released next week. So if you want to watch what those are, that's there. We'll do half of it is the releases. But the other half is a really interesting expose by Chevron, where Chevron will talk about how they see their future in delivering their projects with AI. AI. They're a very progressive thinker in the space. They've spent a long time thinking deeply about what is the role of AI in the project delivery environment. And some of their leaders will be with us to talk about their views. That's it from us. Really happy to take your questions today. Thank you for listening. Thank you. So, Jonathan, we've got first questions out here. Okay. How's that? Thank you, Dev. Great presentation. It's more of a not really a question, but I guess a little hype up. I've been privileged to be able to know Dev for a while already. And I had the privilege to already use it. A few things that I as an EPC contractor that I noticed using this is the ease of use. Like I could make a schedule. I tried making a level one estimation schedule. Feed schedule. Feed schedule. Pre-feed schedule. And feasibility study schedule. Took, give or take, 30 minutes each time. And I only uploaded things like the kickoff meeting material, overview, ITB, you know, those kind of things. So it was really quick in that sense. And I only had to change, you know, a few logics here and there. But, you know, the quickness of how the schedule pops up, it was really impressive. So definitely everyone, if you have a chance, try it. You might take a little tinkering in the first, you know, schedule you make. But once you get used to it, it's really has very high potential. So, and we're going to definitely from my company, we're going to keep in touch with you guys. So really appreciate your, you know, continuous work. Because I know, like, it took you a while to get to this stage. Yeah. Thank you, Anton. Thank you very much. Probably worth saying just before we get to the next question. Empire is not just Dev and I. We probably should give a shout out to our entire research team. Five or six people whose entire job is to basically make stuff like this work. They don't focus on the day-to-day nitty-gritty, the kind of the fires we're fighting or creating. We'll leave that for later. But we are privileged to have five or six people working full-time on solving these problems. We have a question just there. Hi, thank you. One of the other sessions was titled, like, Top 10 Mistakes of Developing Schedules. And I think three, maybe even four of the top mistakes was, like, essentially a lack of collaboration with project team members and stakeholders and experts. Do you guys have any plans to integrate any sort of collaboration tools into the workflow of, like, your generation wizard? Like, being able to just, I've put my input in and now I'm going to send it to my concrete superintendent who can put his opinion on, I can, you know, build 100 feet of wall at a time or, you know, I've got enough form work for X, you know, square feet or something. Is that anything that you've got in mind? For sure, right? Like, P6 is the least collaborative thing you could think of. Sorry, I mean, I have nothing for or against P6. But so our view is that collaboration occurs through the process. So by the time you get to Gantt view, you know, I don't think you reach it. That's where collaboration begins. Collaboration begins, you know, we went through a couple of steps. So at the moment, we didn't show a collaborative system. And I hear you, you know, we went through a collaborative system, right? Like, I went to that point about schedulers need to do much more about communication. That's the bring your teams together point. I think the collaboration part will occur through the generation system, right? Where it's so much easier to have people review the assumptions that are going to go into the system. Like, do we all agree that this is what our pre-con scope is going to look like? Before you go and create your WBS and then you create your detail schedule, right? And get people coalesced around these things. And then once you've got some view of a Gantt being produced, then yes, I agree. Have a second round of collaboration from there. Anybody else? Thank you. Thank you, guys. Great presentation. Is there any type of step by step of protocol to do the import export to P6? That's question one. And what about commodities and resources? Is something that you can do in your application or has to be in P6? First of all, super easy. Press export. That's it. It takes longer to load into P6 than it takes to download. download from Schedule Studio. Or use P6. That's one of their specialties. In terms of resources, I don't think I quite caught the question. Yeah, commodities, I'd say. Commodities, resources. Yeah. So, obviously, under the hood, it's doing a resource-based calculation. Yeah. That's essentially how you get the durations. It is not a current piece of functionality. It's probably one of the other limitations that you can't say, here are my set of resources and treat this as a resource constraint. It's actually a problem. Again, that is very much a today problem and it's a kind of direction of travel. that we're taking. That, probably right now, today, is the kind of thing you'd hop into P6 and go, okay, well, at least the resource side here, here, and here. We think this is part of the scope for us to go from level two to level three scheduling. Okay. It may be controversial, but we don't think you should be resource loading at this level. Yeah, but sometimes you want to see an initial profile, how it looks. It is making a resourcing assumption during the generation process, to which you can criticize and say, actually, actually, we don't have that many people available to do that part. Okay. And then it will adjust. You can do that in the edit feature. Okay. Thank you. Thank you. Great presentation. My question, one of the contracting methods du jour right now is progressive design build across the industry, which lends itself to multiple work and packages by possibly the same or multiple contractors. But part of that delivery method, one of the big challenges and risks is interface management between, you know, handoffs, coordination from beginning to end. Is that part of your guys' roadmap to continue to develop this in terms of not just generating your bidding option, but then also part of this would be able to take these schedules and then coalesce them together. to start identifying for teams proposing on these, what their interface management plan might need to be based off of their contracting approach, because each one of those might be handled in separate project work packages or schedules. You know, that's an awesome idea. And the truth is, no, we had never thought of it. So. So I give credit. Yeah. I mean, yeah, let's talk about it because you're right. It sounds like a spicy, you know, complex part that will end up being in no man's land. And yeah, just saying, honest to God, it wasn't even wasn't even on our radar. Thank you. That's why we like coming to these conferences. Any other questions? Still got several minutes left. If not, I've got one on the back of the question about resources. And a level two schedule typically use for risk analysis. And as that's part of your portfolio, can you run schedule risk analysis on schedule studio? Yes. Yeah. I mean, because it's, you know, it's a schedule that exists in schedule studio, but is under the hood, a kind of a P6 data structure. You can, if you'd like to, and actually, everyone have done this, take it straight out of schedule studio, throw it straight into Mplan's other predictive analytical products. And without teasing too much, probably more on that at AI day next week. Right. Well, I was going to touch on that point because that's the question that I had throughout the talk was if you could give us any insights to where you, you really keeping it, keeping it under wraps. After my debacle with the Wi-Fi, I'm not sending it out loud again. Okay. If there's no more questions, then we'll call it. Thank you. I'd just like to thank everybody. Thank you for coming.