Outcome-Based Design: The Shift of Design Technology and Tools

HARRISON DAIGLE: Hi, everyone. We want to start off today with talking about, interestingly enough, what I started to learn at AU last year. So I heard this term passed around a couple times, outcome-based design, and this idea of strategic foresight of where the tools that we're using in the industry are heading. And so from a couple of those lessons, I started to do some research over the past year and really wanted to dive into what outcome-based design could be, maybe is. And so today is talking through what I discovered.

So a little bit about myself as to why I'm giving this presentation. So I've been in the industry about 12 years at this point. And I've been fortunate enough to where I've spanned a number of different offices of different size.

So I started off as an architect at a firm of 10 people, and I grew into roles at a firm of 300 people and then scaled up as a BIM coordinator at a firm of 30,000 people. So I've seen a lot of different projects of different scales, different complications, technicalities. So I'm really interested and curious as an individual of how these technologies are used across those scales.

A little bit about where I work. I work at Hart Howerton as a design technology manager. Ultimately, I'm really fortunate that I get to work with a multidisciplinary firm of planners, architects, landscape architects, and interior designers, where we focus on the design of complete environments and enhance value for clients and steward their natural resources.

So what we're going to be breaking down today. As we're looking towards the tools of the future, I thought it was really important to talk about where we've been in the past. So the breakdown of today is going to be talking about where those tools came from, what those tools look like in the hands of people, what people create with those tools. And then as we start to head towards outcome-based design, how do we start to unpack and learn from what we can find in our archives.

So this is going to be a high-level overview, really abridged. But before we get there, I think it's also important to explain a little bit about my background and why I'm interested in data as an architect. I'm fortunate enough to live in Northern California, where there's some really incredible trails, where I go running almost every weekend during the fall.

And so one of those things that I carry around with me is a GPS watch. And while I'm tracking while I run, I find it really interesting of, OK, maybe I'm going a little slower this lap. Maybe I'm picking up the pace. But it's really after I'm done with a run where I kind of see those metrics and understand, oh, that's really why I was going slow. This hill was a much, much tougher than I thought it was. So I take that curiosity with me from outdoors and from GPS tracking into everyday workplace and in the AEC industry.

So one of the things that I really feel compelled and stumble upon are these really complicated graphs. So there's a bit of a theme of twos throughout the whole presentation. So I'm going to highlight two graphs and then start to share how those impacted me and how I start to frame the tech stack that I use.

So the first of those two graphs is this history of BIM diagram or mind map. When I stumbled across this, I'm already walking into it, just open to understanding data. But it was the first time that I had seen not just the tools themselves, but the history of those tools and the people and the external factors that start to impact the ecosystem of the tools that we use.

Now, this is really interesting from a highlighted level. And, of course, it's a Miro board, so we can zoom in and out of it, but where to really start? So this was one of those things that I indexed, really cool. I revisit it from time to time. But still framing of how do I dive into specific tools?

So then along with that, a couple years ago, I stumbled across an article that was talking about Revit and how architects are using and trying to understand how the improvements to Revit can be integrated into their modern practice. And so the article itself was really compelling. But, really, this diagram at the very end of it was what I lingered on the most. It was the first time that I had seen Revit positioned, and it's kind of explaining, OK, here's the center of our spoke and understanding here's the capabilities that we can use within Revit.

But, also, here are some external tools that maybe are Autodesk provided, maybe they're not. But what are the capabilities of Revit? And so I started to think about not just Revit, but all of the tools.

When I started in practice as a designer, I had a general sense that, OK, for documentation, for model creation, I would be using Autodesk tools. For presentation, I would be using the Adobe suite. For early concept modeling, I might be using [INAUDIBLE] or at the time Google SketchUp.

But now seeing how these tools are progressing, I started to take these primary categories and develop a little bit of my own map to understand, OK, not specific to Revit anymore, but what is important in modern day practice of these different categories and how we break them down and how they start to fill into our workflow? So we'll revisit this as we go on throughout the presentation.

But these are those primary categories of thinking, where do we start when we model? What are we offering in? How are we optimizing that workflow? Are there ways for us to share that information with colleagues? How are we collaborating externally as well as internally?

How are we taking that authoring information and presenting it to a client or to internal stakeholders? How are we taking that presentation that may just be a drawing and actually adding that next level of character to it? And then as we move forward in sustainability, in practice, how do we critique and analyze the performance of those buildings? And so, of course, documentation being the underpinning, so really lingering on documentation as we head into what I want to start to outline as really this continuum of design technology history.

So it's interesting to point-- and I really want to start at basics, not digital technologies, but haptic physical technologies. As an industry, we started on paper. And so I'm not stating that we started using paper in the 1930s.

But there's a much richer history to this, much more than I could fit onto this diagram. But generally speaking, these paper practices were labor intensive and took a lot of physical storage and management of documents. So time consumption, limited ability to share and collaborate those documents.

Now, I do want to linger on this last bullet on this slide in saying that a lot of the mechanisms that we use in practice from a legal standpoint were established in this era and are still used as a dominant reference point. But as we started to understand, OK, how can we drive efficiencies, we moved to this next era of CAD. And interestingly, as we start to look at this and build out this diagram, some of you might start to think, why is Harrison listing this in the '50s? I didn't start using the tool until much later.

So the first instance, we see the remaining of these tools is going to be when we start to see academic settings. And those terms show up in academic papers and research. But CAD starts to represent, of course, that task translation from paper into a digital medium. We can increase precision. Now we can store those documents digitally, which means revisions become easier, and we can share those files more readily.

So that reference point back to when we first start to see AutoCAD hit the Market-- it launched in 1982, so really calling attention to the fact that there is this time gap before when we first see the term and when it becomes a tool that is ready for the marketplace and for our industry and AECO to use. So, of course, with that required significant training. And from a firm standpoint, there was an investment. How do you train people? How do you understand the hardware and the software that needs to be leveraged in practice?

So continuing to build on this timeline, in the '70s, we start to see the term BPD pop up. And so no longer were we just thinking about the digital translation of the task. But what if we were to design the system inside of a digital framework that we're not just thinking about points and lines on a paper, but what if we think about these objects as a database, something that we can start to run analysis on, something that we can start to query against where we're not just thinking about lines, but we're thinking about walls? OK? Then we can think about what objects get hosted into walls.

So a lot of you will recognize this framing is exactly what we talk about when we use Revit. But again, we see-- in the '70s, the terminology comes out. But it's not until 2000 that tool hits the marketplace in a way that we can consume it and use it for everyday practice. And again, the same thing, same translation. Except to a greater extent, there's a steep learning curve, specifically with BIM tools.

And it completely changes. No longer-- so it's an inversion of our production where it's not just a task translation. We're forced to think about our process differently. What becomes important? So those same software and hardware implications exist to a greater extent now. And we haven't gotten rid of CAD. We're using it in tandem alongside BIM.

So now, we get to today. And again, we're building down as we go. But now academically, we're a little bit into the past. So there's been a period of times of understanding. OK, the terminology comes out, we see it progressed in certain extents. And then we see, specifically with AI-- machine learning and AI-- stops and starts. AI winters, where the technology receives a lot of investment and just doesn't necessarily get to where we expected it to be or hope that it would.

But now we see something like Forma launch. After Autodesk acquisition of Spacemaker and then translation into Forma, we can start to see where these tools will start to land in practice. And we're just starting to hit that era-- so starting to hear the terminology that did last year at AU-- where we heard outcome based design or outcome based BIM. It's interesting. OK, what does that start to mean to practice? What can we learn from the translation from paper to CAD and CAD to BIM that starts to give us a little bit of a glimpse to what we can expect from tools like Forma?

And so like I mentioned, I want to start to build out this specific diagram. So these are just content headings that I was trying to tease out in modern day practice of understanding what we can do. Now, if we apply that to the paper era where we had these physical translations, maybe this is what each of these tools would be.

So maybe we had one tool that was used to optimize. Maybe we had a Mayline. In institutional knowledge management, maybe we had a guidebook-- standards document in the office that everyone would reference. And so as we build this out, these do represent specific tools to my firm, Hart Howerton. So keep that in mind, that these are specific reference points that I can explain. So very small set of tools here in the paper era.

Now we move to the CAD shift where there are still a lot of tools or we're adding tools on, but it's not insurmountable. It's reasonably expected that one person or a handful of people in the firm are going to have a great depth of knowledge of each of these tools. So we've added hardware. We've added software. We've added technical ads and pickups from a digital standpoint for improvements, but still relatively manageable.

Now we get to the BIM paradigm. Like I said, this is Hart Howerton's active tool stack. So when I think about each of these tools-- there's a specific tool that we use for authoring. And it understands, OK, are we thinking about-- are we starting a model in Revit? Are we starting it using SketchUp? Are we starting it using Rhino? Each of those would fall into our authoring bucket where as we move around, is it reasonable for any one person within the firm to be able to leverage that knowledge that becomes that knowledge component?

And while I'm here, I think it's interesting to point out that we are a heavily Revit and Autodesk dependent firm at Hart Howerton. But it's interesting that there are lots of functionalities that can be added by reaching out and finding developers that are adjacent to the industry-- or adjacent to Autodesk, that is. And of course, we also use tools that are not Autodesk provided. As I mentioned, Adobe products. So it's interesting to see how that tech stack plays out, and how we can start to leverage it as we move forward.

And now, along with that terminology that I was starting to hear last year at AU, I attended a very impactful session for me that was given by the strategic foresight team at Autodesk. And it presented this diagram on the cone of plausibility, and I want to present it here today as we talk about the context of past tools and where we're headed.

And so we think about the continuum moving forward, and we start to think about where these tools are headed and how we might leverage them. Some are going to be more probable than not. Of course, we as practitioners and design technologists, we have to attempt to find the area that's going to be best suited for our firms. But I find this to be a really compelling diagram that just helps to explain potential futures.

Now the history of the tools. They're just tools, in a general sense, right? They're hoping to find the right audience for a use case of pickup, and to start to implement into practice. But ultimately, where we see those tools is in the hands of people. So it's important to talk about what digital maturity looks like at a firm and for individuals.

So to talk a little bit through technology acceptance and through how to frame this diagram, think about the stack on the right as the barriers to entry for technology acceptance. And on the top of this graph, we have not addressed. And on the bottom, we have resolved. So the further, we get to not addressed, maybe it's something that we as individuals in the industry, or me as a design technologists at Hart Howerton-- I need to clear those barriers for my team.

So if we think-- let's look at the middle of these three diagrams, as it were. Maybe a firm goes out and strategically hires the design technologists so they have that in-house expertise component covered. Along with that, maybe they're positioning them as a trainer of staff, so that staff training is covered. But there's still the component of cost software, so we're kind of sitting in the middle of the diagram with cost software.

And maybe at this point, we're anticipating some client demand. But it's not quite sitting there yet in terms of utilization of new tools. And then we're working-- of course, it's a new tool to us, so we don't have any established or recognized use cases, and we're starting to build out those standardized protocols. So start to think about the tools within your company. And whenever they're brought in, how do they start to disseminate and how are they accepted?

So with each individual that you confront, there's this technology acceptance model. And what it states is that there's two general gates for an individual. We'll keep it with individuals at now. But there's two gates that have to be passed. Does the individual perceive it to be useful, and is it easy to use? So those are the two components that are really important.

And as I start to head into this next-- like I said, diagrams of twos. So we have the technology acceptance model, and now we're moving into diffusion of innovation. So the second of these two diagrams, as we start to think about-- OK, we're perceiving it to be easy to use and we're perceiving it to be useful-- think about these as the individuals that you confront and that you work with in your own firms.

So the innovators are always going to find the silver lining and a use case for those tools, and want to get their hands on it. And then as we move along, as we're building out this bell curve, we have early adopters-- typically in leadership roles-- expecting change. They want to find things that are easy to use to implement into practice.

Then behind those, we have our early majority. And continuing to move forward, we have the late majority where typically, it's a little bit tougher. Right? We're on the other side of our bell curve where we have to provide statistics or information to win these people over. So the perception of ease of use or the ease of use of a tool is not as palpable to this group of individuals.

And then at the very end, just to round this out, is to talk about laggards where it's typically fear that's driving them or the fear of being left behind, in a general sense. So is the technology-- it's no longer beyond just being useful. We have all of our adopters before that. But we need to get this last group.

So if we take this diffusion of innovation and apply it back to our timeline, I found it interesting to think about what if I were to take this graph and kind of extrude it and twist it, and think about what does this look like on the timeline? So if we look at CAD first, we start to build out our tool adoption and think about-- OK. When was the first time-- or when did we move out of innovation and early adopters and into the early majority?

So the purple bar that I have positioned in the middle part of this graph is really starting to allude to, OK, we've probably hit early adoption. So if we take that and we extrapolate it, and place it on both CAD and BIM, it starts to show this compelling overlap between CAD and in BIM where we had the late majority joining CAD at the same time that we were seeing the early adopters really get into BIM.

So interestingly for me, having worked at a number of firms where CAD and BIM were heavily utilized in both settings-- or in all settings-- it's compelling and helps me understand, oh, that's why there was friction. These people maybe were already or still struggling to understand what the use cases for CADs were, and we're getting to BIM already. I'm not ready for this.

And obviously, I haven't built out the AI side of this graph because Forma is relatively new to us as of 2023. So time will tell when we'll start to see the early adoption really hit for this, especially at the rate of technology is moving. But it's compelling to start to think about what are the overlaps that we're going to see in individuals, and what is the friction that we're going to start to feel? How do we provide those use cases, and provide the insight to those potential late adopters or to those laggards in a way that compels them to be part of the conversation so that we can knowledge share and gain from their experience?

So with that individual level, want to take it back to new hires in a general sense. So every individual is a product of their education and of their past experiences. And so when they join the workforce, they're typically what we've seen in my experience-- and leveraging knowledge resources out there as well-- that they're not necessarily versed in the tools themselves. The knowledge that they gain in education is on their content specific.

So as an architect, I didn't learn how to use Revit or how to use AutoCAD, necessarily. They were tools that I practiced, certainly. But the primary emphasis of the curriculum was on form, and on standard of care, and on professional practice. And so when we think about these tools as they implement, I wanted to start to extract that knowledge base.

So honing in on Hart Howerton-- my company-- specifically, we can start to think about the core disciplines-- that multidisciplinary firm of planning, landscape, architecture, and interiors. Now it's reasonable for the people that I work with that there's going to be some overlap where, OK, maybe planning and landscape architects and architects are sharing knowledge and thinking through a puzzle at the service of a client. So I want to move quickly past that line and actually into titles.

So in every firm, generally speaking, has this kind of career matrix. So it's just starting to extrapolate and think through these pieces that we have at our disposal. So if we think about designers, associates, directors, and principals-- fantastic. Those are external titles. Let's go one level deeper. Let's think about the roles themselves, because ultimately, it's the role that predicates how the tool or what tool is being chosen for a given assignment for a given project.

So from those roles, I started to group these two together and understand-- OK, as we think about growth through a career, who is the ultimate party that is going to be driving or creating digital content, and who is going to be guiding that process? So we have our BIM authors as one party that's creating that content, and we have the process leader.

Maybe they don't have the depth of knowledge in a specific tool, but they understand the standard of care and the legal mechanisms, and are teaching and are mentoring that younger generation utilizing the tools, or helping red line culture of, OK, this needs to be changed. So they might not know the specific mouse movements or the commands to use, but again, it's the importance of that process.

So let's go back to that tech stack diagram. Let's think about the process leader leveraging and understanding the tech stack. And the BIM author understanding and saying, OK, this is going to be the right tool. This is our scope of work. This is our client. How do we start to leverage these to become better at them?

And of course, with any company, we're going to be in this situation to where we have those process leaders and BIM authors who are accepting that technology. And they're going to be a product of the diffusion of innovation within that company. So have we cleared those barriers to entry? Are we standardized? Do we have protocols? Do we have in-house expertise? Or is that going to free up bandwidth or the clarity so that we're in the early majority and feel confident moving forward?

So as these process leaders and BIM authors head into a project environment, this is what we start to see. And so these are diagrams, of course, that are fascinating, and happy to answer any questions on them. But of course, they start to represent what we might see and what I've seen in practice, where maybe we have one design BIM author who's really hyper focused on a project. And the process leader is balancing multiple contracts, multiple clients. And so they are dedicated to the project, but they're also focused on other work. So it's really the BIM author who's helping to shepherd the initiative forward.

And at the same time, we're going to have our engineering team, and our construction team, and our client owners and operators who are all part of this conversation within this Prozac bubble. So is it reasonable that we're going to have six power users or early adopters or, if we're lucky, innovators who understand the technology at a granular level, and are able to push it forward not just at an efficiency standpoint, but in a data integrity standpoint? They understand it for what it's doing. So each of these bubbles and each of these modules start to represent how we might start to see practicality.

So honing into one of those specifically that I interface with a lot is a landscape team. So let's say the landscape team is making a distinction depending on where their site is in the world. And they need to understand based on who the BIM author is and their technical capabilities, and who the process leader is, and their confidence either to use a new tool or to use something that already has major adoption.

So this is what, as I mentioned, each of those bubbles within that tech stack diagram starts to represent specific tools. So maybe for a lot of the work that I do-- or not maybe-- for a lot of the work that I do, we use Esri JS as a resource because we're comfortable and confident starting off with that. We can get our State Plane Coordinate System and understand the impacts very closely.

But we need to move that into a modeling software. Well, depending on the process leader in their confidence and ability, are we moving that into SketchUp? Are we taking that into an Autodesk product like Civil 3D or maybe AutoCAD? Or are we moving towards Rhino and Grasshopper? It's going to be determined by those individuals. And so as we think about projects and we think about individuals, it doesn't just become this tool is the tool. It's what's going to be best suited for this project and this client.

So with that concept of thinking about multiple tools as we spread out across different projects, I want to start to dive into what project archives actually look like. Now, before we get to that, I want to distinguish between process management and task management.

The more and more I started to think about and look into outcome based design, I started to understand that there is this distinction between process and task. And so are we really expecting support from algorithms on a process standpoint, or is it best suited from a task standpoint? So we'll continue to revisit this, but are we thinking about the sum of all these parts or are we thinking about a very specific task that we take on with this short term objective?

So if we hone in on those processes, I'm going to use the AIA Basic-- Architect's Basic Services as a grounding mechanism for us as we move through this. But if we think about those core services-- schematic design, design development, construction documents, bidding and negotiation, and contract or construction administration. If we think about them, just as five equal bubbles, it's not really what they are.

What do they represent to you and to your company as it relates to revenue? And these are going to be different for each. I'm just using these to ground and think through this. So from a revenue standpoint, maybe the diagram looks like that. How much time are you spending on that? Maybe you have a general understanding of your revenue and your time expenditures for those five services. But have you ever thought about the digital assets you create during those processes? Regardless of the tool, just what are you creating and how much overlap there is.

So if we take those processes and start to think about the individual tasks, maybe we start to find areas where we can infuse algorithmic thinking and start to expedite processes. Do we need support in refining the 3D model? Or are we really trying to go from text to 3D massing as quickly as possible rather than just saying, OK, we're going to do all of schematic using an algorithm or outcome based focused?

So I was fortunate enough, being in the Bay Area, to attend a seminar or symposium for Autodesk Platform Services. And at that seminar, Jim Quanci stood up and gave this compelling argument that was talking about Autodesk. Now, the Platform Services event was specific to software developers, but I found this analogy really compelling.

As he was referencing Autodesk as this elephant moving forward-- this powerhouse of technology creation for the industry-- and to the individual software developers in the room, they could start to leverage Platform Services, but they had to be very wary and skeptical of which path they chose. Were they going to do something that was directly in the path of the elephant in this scenario? Or were they going to do something off to the side that supplements the industry?

And so back to that tech stack diagram that we saw that referenced those kind of supplemental tools that we use at Hart Howerton, we really like to work with a lot of those-- maybe not direct path developers, but off to the side because they're really helpful and supportive of those efficiencies.

So not just from a developer standpoint though, but I have this expectation now seeing Forma come out and saying, OK, we're starting to use terms like outcome based BIM and outcome based design. Autodesk is thinking about these things. They're forging a path ahead. So what becomes important to me as an individual design technologist supporting a firm? How do I stay out of their direct path and help my company prepare information and data that we can learn from our archives to prepare to use those tools?

So the first step that I took on was just trying to think about our digital asset creation process. So what I did, what you're looking at here are these asset ribbon diagrams. And so these represent four distinct projects where I went in and looked at project archives and said, OK, I just want to know the magnitude of all of the files that we have within a given folder on our server.

And so if we look at project A, I started to find these things pretty interesting the more and more of them I put together. But if we look at project A, we see that first real peak. So it's this kind of light gray, but that first peak represents JPEGs. And I started to see that appear on multiples of these diagrams.

So if we look at the same peak in project C and in project B, to me, that started to echo-- OK, we are in concept design. We're going on site. We're taking a site visit. We're understanding. We're creating site analysis. And as we move through each of these diagrams, they start to be a little different. We're catering to the client's needs. And this is not something that we're asking the teams to actively manage. This is passive data where we're just peering in after the fact and creating that timeline.

So we see this mass-- looking now at project C, I started to see these spikes of data and information that I could start to really unpack and peer into deeper. Where the largest masses that we see on any of these diagrams, with the exception of JPEGs-- that light gray, those first spikes-- it's really starting to become PDFs and email messages-- correspondence as we're just tracking for record keeping purposes.

But I started to linger more and more onto those PDFs. Is that really the data richness? Now, this is a magnitude. This is a count. So maybe I'm thinking about the wrong metric here. It's not just about how much, but what is quality data? What does quality data start to look like?

So as we extrapolate that project workflow, going to grossly simplify here. So in a general sense, we're awarded a project. We do the work. Does it fulfill the contract? Doesn't? We're going to continue to do the work. Once it fulfills their contract, we give it to the client.

Now reaching from my own experience across different firms, how often does this process happen where you're seeing it? And don't necessarily mean QA/QC from do we meet the standard of care, and do the documents correlate and correspond appropriately? I mean, the QA/QC that is looking at the digital documents and the digital files that are creating these data sources that we're going to start to try to tap into when we get to outcome based design.

So this last question here-- how much do we deviate from our standards and templates? How often do we think about that? How often do we track it? So just pulling some real quotes from some colleagues that I've worked with. QA/QC really being focused on that document process. And of course, there are clients pushing BIM initiatives.

But looking at critical mass of the industry, how are we preparing to think about digital QA/QC where it's not client driven? And even if we have a client driven process, is it something that is-- how are we translating that internally so that all of our information internally aligns?

So some of my favorite here-- or one of my favorite is to point out is we only use Revit for the drawings. We don't need the data to be accurate. We don't need the model to be accurate. OK. That's an index for me as a technologist. I can have confidence in the drawings. And of course, we can debate that. But when I hear that statement, it's an indicator that I need to be skeptical of that model. And here's a couple of use cases that-- some are admittedly fabricated for this presentation, but I've seen all of these in practice.

So things like geometry warnings. OK. If I want to start to harvest information or look for data within models, can I pull geometry from this model? I have to be skeptical. And then some of the ones that are a little bit more egregious-- thinking about revisions.

So the revisions aren't actually native to the model. So maybe we're trying to create these closeout documents, but someone has created a clever workaround that works for the documents, works for the contract, what we're responsible to the client. But it's not actually tracked back to the model. So again, this is pushing me more and more towards PDFs.

And then maybe this is one that I shouldn't be sharing as a presentation. But knowing that there is the possibility to override a dimension in Revit, how confidently can I use details if I scale them? If I am able to communicate to a machine, OK, here's what the graphics scale is. Well, how do you read the dimension versus the graphics scale? What's the conflict inherent when you find a difference?

So one of the things that we started to do at Hart Howerton in my team was lean into and try to peer what can we leverage. We know, again, Autodesk is forging ahead. And we're going to start to see more and more tools come that we can tap into, but how do we prepare our information and our data to be able to engage in that conversation when it comes?

So we honed in on these three areas of our work breakdown structure, project directories, and our digital and physical archives. Now, these are simple. We're going to start to unpack these even more, but it's just thinking about where our primary data source is.

So as we really start to break down our work breakdown structure, it gets even more confusing than that. As a company, we have a solid foundation. We understand what each of these means for project, step, and task. But how we converse and how we communicate with our partners either as tool providers of tool for sustainability analysis, or when we're contributing that data to the [INAUDIBLE] DDx, the way that we're using words is different.

So if we're trying to do an analysis just using something like a word count-- well, if we're using that against my company information or Cove.tool or the DDx, project is going to mean something different, or it does mean something different. So creating these relationship diagrams has become kind of a hobby of mine of just understanding what do all of these different terms mean. And even though we're using the same word, they mean different things.

OK. So we're starting to explain and really dive into the history of the tools for tools sakes, what those tools look like in the hands of people, and what people create with those tools. And so if we start to then peer to the next step of this argument where what is the information that we can take from the content people create? So the whole goal of this exercise is to think about what is the intent of the data.

So when it's created, what can we start to leverage? We're at the end of the process. We're peering back in general 2020 vision of saying, how can we harvest the information? We did a lot of good effort. How do we take those lessons learned and feed them back to the beginning of the loop in a way that either teams are confronted with or we're building these intelligent systems that can support us along the way?

So me and a colleague have really started to think through this idea of business intelligence is out there as a practice. We see it in Power BI. If you're in data visualization, analytics, it's a common term. But internally we've started to use this term-- design intelligence. So not just thinking about the infrastructure or the business operations, but how do we focus the design data back to what's important for our standard of care, and for the images and depictions and creativity that we can give back to the client?

So it's thinking about these internal versus external factors, business intelligence on the right being, infrastructural and internal. And of course, there's overlap within project support because we're in the business of design. But if we think about those primary objects-- if we think about those documents, those models that are intended to be represented externally-- that's where we start to create this framework for design intelligence.

So how do we source it? Design intelligence is the goal. What is the process to compile relevant data, and what are the tasks we can use to augment through the machine learning and AI? So our first approach at Hart Howerton was to think about our data sources.

So if we think about these different data sources as buckets of what information or what data points we might find, we'll see things like our business data, our technology data, information that's coming from those tools that we've been talking about. Or the results of those tools where we have the project drives, where all of these things get saved, where I had those ribbon diagrams that starts to talk about things.

And oh, by the way, we have to recognize pieces that maybe we want to try to avoid. But how many people are saving standard templates to their C drive? How many people have created a deviation? Is that deviation something we should actually be training on? How do we find that?

So these aren't there to say this is everything we're tapping into today. It's how do we start to think about those locations and data sources. So when we think about what those data models look like today, if we try to create relationship diagrams, it's very much point to point. We can tap in. We can use APIs to say, OK, I want to take this Revit information and I want to point it over to another location. So we can use things like ACC, and we can use the data model explorer to understand how do I extract in the data model exchange?

But in a general sense, I'm thinking about outcomes. If I have to think about two tools at the same time, that's a great starting point. But I'm going to be a little bit more selfish than that. I have a conception of-- there's a lot of data out there. How do I start to bucket these things together?

So we're borrowing from tech and understanding, OK, business, intelligence, business data-- we have this concept of creating data lakes-- data warehouses. Why can't we do that for design? How do we create a data lake for our design intelligence data and start to path it into an analytical process where we can peer in, we can query, and we can define outcomes that we want to take into task optimization?

So at Hart Howerton, we started with a simple use case, or seemingly simple use case. So focusing on contract documents-- so we want to start at the end of the process. What did we create? What did we deliver to the client? So the reason these numbers are out of sequence is to talk through those intricacies. But contract documents is the end of the process. That's what we're focused on today.

We know eventually that we want to use our contracts and proposals as either validation or a back check to understand, OK, there's going to be deviations as it relates to either scope creep or time increase or external factors that we didn't account for in the contract phase. And ideally, we've received more work from the client, so new work authorizations.

But we're going to start with contracts and then eventually we'll go from contracts-- sorry. Contract documents-- the end of the process to contracts. And then eventually-- again, understanding that Autodesk and other developers are working towards these authoring models, how can we start to see glimpses of these things?

So contract documents. While we started to look into these things, the more and more we appeared, it wasn't-- we didn't just pick contract documents because that's what we wanted. I would love to take all of my Revit models and all of my CAD models or CAD files, smash them together, and take the data, flip it upside down, and see what I can take out of it.

But as we were leveraging some of these modern AI, generative AI tools, generative algorithms, we were noticing that the tools we can leverage were mostly based on text extraction or text search. So where do we have lots of text? Contract documents. How can we start to leverage that? It's also this interesting interplay between we can start to try to push vision models towards it, but ultimately, we do have a lot of text embedded in it.

So the first simple process here is this is our, quote unquote, "latest and greatest diagram". So if we really extract this process and think about what we can find and what we can start to learn from, we have our latest and greatest documents of-- OK, we've made it to the end of the process. We have an as built file. If there is not an as built file in one of these folders, then we're going to search for revision.