Managing Successful Delivery for Mission-Critical Projects

TADEH HAKOPIAN: Hello, and welcome to Managing Successful Delivery for Mission-Critical Projects. Let's get started. Our little agenda today is learn about the challenges of mission-critical data governance, learn about the best practices for data governance and delivery, see examples of effective delivery strategies, and understand how to use standards and communication tools along the way.

A little bit about me, your presenter, Tadeh Hakopian. I have been in the world of building and design for over 12 years, including virtual design construction, building information management. And I've seen a lot of projects, big and small, and delivery strategies over the years. So that's my background.

And I think the main question to ask is, what is mission-critical? So we can get that out of the way. And all mission-critical is something that needs to work all the time or your mission fails. This can include power plants, ports of entry, hospitals, dams and hydroelectric plants, data centers, laboratories, military facilities, and anything that just needs to always work. Otherwise, it just wouldn't be functional compared to your conventional office building or school, which can just not work for a while. It's not the end of the world. These facilities need to continuously keep running. Otherwise, they won't be able to fulfill their job.

So the problems we're facing is we need to deliver a big project soon. It's critical infrastructure, meaning it's mission-critical, so it's important and big and requires a digital delivery portion in its contract. But you don't know where to start since you being given limited information, and this is a problem a lot of us have faced where we have these substantial projects that have a lot of people on them, from the owners to consultants to contractors to everybody in between.

And they're interested in providing and getting digital content, 3D files, BIM files, CAD files, but they don't really spell it out for you. They don't really give you an example of what that should be since, depending on the owner and the project, they may be new to all this. So let's get started with the first part of this, defining the problem, understanding what people want.

So with that in mind, know what you're getting into. Do a little research yourself if you're trying to be the one providing some kind of delivery for a mission-critical project. Read contracts. Ask questions. Send emails. Get on calls.

Doing any amount of research and getting any progress whatsoever is better than doing none because these projects have a habit of having a lot of requirements but not spelling them out. So if you at all whatsoever suspect that there will be some digital deliverables that will be landing on your lap, get started with some early research, and the more you get knowledge, about the better.

From there, you want to learn what the owner/client wants. And the little hint we'll give you for this is they want high confidence in business continuity. It's mission-critical. The business has to continue. It has to have a high uptime. It should not fail.

So that's their mindset with these projects. It's not good enough to finish the building. It has to operate and not stop operating. So think reliability, resilience. How can the design team and general contractor collaborate better to deliver what they need, including getting the schedule done on time?

But most important, avoiding failure, failure to deliver, failure to operate, failure of information-- how can we reduce that failure as much as possible to the owner and to this project? If you can answer that question, you will have a lot more traction.

So if you're still in a vacuum, then make assumptions. Even if after all your research and asking around you don't know, then figure things out on your own. If you don't have guidance, make guidance for the project. That's a better start than waiting around until somebody gets to you.

I've been in those situations where we didn't have clear delivery expectations on the digital content for the project, and that ended up coming back to haunt us literally years later when the project was closed out. And they wanted a bunch of stuff at the very, very end, like, the last couple months, and it was a mad dash to get it all together. So rather than wait around and hope for the best, do something, and that something should be develop a SOP, which is a standard operating procedure.

And I'll give you an example of a standard operating procedure right now. This is going to help the owner with their desire to avoid failure but also provide a successful project delivery. This is the interest of the owner to reduce time to market with early-stage coordination of large equipment categories.

The owner is asking what we can do to achieve that. So you can provide a copy of clash detection in your models across all disciplines at anything level of development 350-plus out of a scale of 500 in all categories so that they can go through that before construction even starts in the digital environment.

And delivery is reduced in time for the RFIs-- that's request for information-- and higher QA/QC so that you can avoid field checks and field clashes and [INAUDIBLE] problems in the field, which would cascade to potential failure in the project itself or limited failure in the project itself.

This can check all the owner boxes for delivery. They want to make sure it's done right, done properly to avoid failure, and this reduces failure with some early efforts. VDC clash detection has been proven to make the project more feasible, and through that, you can provide guidance for coordination through the project team and the owner.

And all you have to make clear that you need is the support of the owner when it comes to getting the design consultants, the general contractor group, and the owner themselves involved in this process. And you just spell this out and say, here it is, here's what we can do, here's what it takes, here's your results, this is what I need.

Making it that simple, almost like a memo, will go a long way to get the owner's interest, whether that owner is the company or the facility that is directly contracting you or some consultant working on their behalf as owner's rep. Making it simple and easy to digest up front will go a long way to getting adoption later.

But don't stop there. Share your idea. Share to executives your work plan. How are you going to deliver on time? This could be within your own company. It could be with other companies. Of course, ideally, you can talk to the owner side, the executive group, and, just in plain language, explain you're trying to accomplish meeting their goals.

Show a work plan in stages, including dependencies and critical paths, and we'll go into all of that in a little more detail later. But make sure you get this to leadership because your own local team would probably agree with you in all the efforts you're trying to put into place, but these are big moves that would require the entire project to get involved. So make sure you get to the highest leadership and get their buy-in.

So what you're trying to do is get feedback about what they see in your plan, what they don't see in your plan, and, from that feedback, ask clarifying questions of what they need in order to proceed. And the important thing here is get something from them. Walk away with direction and guidance and action.

They might just-- they nod their heads and think, yeah, this sounds great, but what you're actually trying to do is get them to say, yes. Yes, let's do this. Yes, let's proceed. Let's go to the next step. So that feedback mechanism and all the work you've done up to this point actually takes you to the next step. So don't just wait for nodding heads. Make sure you get an actionable response. Record it. And follow up with we have to record-- who we have to coordinate with as a next step, and then you can make progress.

And that comes to the next part, which is getting things kicked off, so we're going to things out and get ready for an actual kickoff. And one thing you have to make sure you understand is who is in charge of where. Who is in control of decision-making, approvals in your team, in other teams, in your own team? Who is the executive of the project? Who's the person you go talk to, say, hey, I want to get some things organized, I want to do some meetings, some documentation? Make sure you have that person already identified at this point.

And who is assigned to create deliverables? It could be you. That happened to me. I worked on projects where I got pulled in because they didn't have somebody to create the digital deliverables. I was the only person who was available to do that, and I had about a week or two to figure out a way to do that. So even if you're not aware it might be you, it could be you. So keep that in mind that-- by default, assume, even if you don't think it's you, it's you. That way, you can at least figure out what you need to get the work done.

Next, look at the contract. Understand what is being asked in the contract. What are the details? Now, some of these contracts can be pretty big and thick, so make sure you have somebody who is pretty knowledgeable on the contract itself to help you out.

And a couple of key pieces of information you need is who's contract prime. If you're working on a mission-critical project, there's usually lots of people contracted, and there can be very big companies contracted. But only one of them is the prime who is going to execute the contract. That will help you understand who you have to coordinate with for these deliverables because that prime will be the one almost every time providing the collection of digital deliverables.

And try to through the contract and see if you can find guiding documents for digital delivery. Anything about digital content, BIM, CAD, whatever keywords you can find, look for them, and see what they can tell you. If you can't find this information easily or you're stuck, raise a flag.

Tell your team, hey, I've looked up and down, I cannot find a thing about deliverables of any kind or digital deliverables or who's responsible. Make it clear that that's something we need to discover. Otherwise, it's going to be hard to do any level of digital deliverable work for this project.

Next is roles. Understand who is in charge of the project and your counterparts. Like I mentioned, there could be multiple companies involved. One project I worked on had about-- and it was relatively small. It had about eight design consultants and 10 to 12 contractors, including a general contractor, who was the prime, and 11 other subcontractors.

So those ended up being all my counterparts since, effectively, each of them was also doing some level of providing content for digital deliverables, and in a nutshell, it was all Revit models, BIM, and some clash detection. So I had to coordinate on my end with 20 people. That might not be true for every project. You might funnel things to other people so you have fewer people to coordinate with. But it's entirely possible that you would have a dozen, two dozen people to coordinate with at different levels, at different stages and different intensities of engagement.

So learn who your counterparts are. Make a list, and reach out to them. And understand who does what. Do they give you a piece of the digital deliverable? Do they give you a lot of it? Scope that out so you know who you're working with and what they can provide.

And then map out the process. Figure out what it will take you to get from beginning to end. This could be just a flowchart like in this example. I developed this for facility management deliverable. It wasn't just digital deliverables. It was a facility management process they wanted to scope out with a digital deliverable model content along with a parallel project of a digital twin. So we started from the left to figure out how we get to the right.

So we have on the right here the end result, and to get there, we had to work backwards. But I'll start from left to right to make it simple. We had mapped out the process, so this is pretty easy for anybody to understand without any expertise in any digital deliverable design technology or BIM process whatsoever.

And like we said, we start with the intellectual design intent, data we want to capture in that design, like square footage and equipment and building and whatever you would need as data points, and geometry. What's our 3D content that's going to help us with the other aspects down the road, including how well developed our content is for something like clash detection so we can avoid problems in the field?

That all goes into BIM. So you can see BIM ends up being this path forward that we can put all of our information into, and we can specify the technology or software using BIM as a process. From there, we coordinate everything in BIM. We get the following results. We get preconstruction coordination. We get quantity and data information, design plans, LCA-- that's low carbon analysis data for sustainability goals-- and visualizations, just making images and walkthroughs of the model available to the project team.

And then it would go into different paths. The design plans, LCA data visualization, can go to project facility data for lifecycle maintenance. The preconstruction data and quantity data can go into virtual design and construction and, therefore, clash detection. This was how we can make sure the people who needed the lifecycle data for the project facility operation itself would have understanding of what they're getting, and the people building the project would understand what they're getting.

But it wouldn't stop there. We're going to continue the virtual design construction process to create a clash-free deliverable or a clash-free at, say, LOD 300 or 350 or whatever our target is, deliver that as a signed-off set to the owner saying, here's your project, here's the map of your entire project, where we clashed. And on the parallel front there, they're going to work on a digital twin project with a different set of consultants for facility management.

It wouldn't go to the prime. It would be something they're trying to feed information into. That would include real-time streaming data from their equipment and project controls data that they would use as like a dashboard. So that, with the project facility data, will be married to the project model deliverable, and that would be a facility maintenance process to the owner.

I'm oversimplifying a bit here at the very end, but the idea was if we can start with a consolidated approach early on, a lot of the other efforts downstream are easier. And that's why I use these arrow boxes. It's easy to follow to the eye. You don't have to be an expert. And I make sure the facility maintenance operations and everything else are trying to achieve in big strokes is listed here so they don't miss anything.

I recommend that if you're working on anything similar whatsoever where you have a similar path forward and you may have to work backwards, make a flowchart. Any flowchart is better than no flowchart because sometimes people have no idea how any of this works in BIM or digital deliverables, so just paint a picture for them. It's an easy thing to talk through and use as a visual aid.

So once we have all that worked out, let's have a little kickoff. So example of kickoff would be scheduling a call, usually early stages of project. The project's already underway, but you're not really doing too much work yet. You're still trying to get the actual design and coordination work started. And what you want to do with that kickoff is align all the parties. That's your counterparts, the owner reps, whoever else needs to be aligned.

Get them together in line, and make a project execution plan or a BIM execution plan available for them to review with you. And that would be all the requirements for digital delivery. What kind of software you're using-- spell it out. Who's in charge of delivering the models? Spell that out. Put names on there.

What's the process? What's the platforms? How are you going to get there? What are the stages? Put as much information into the execution plan and how are you going to actually achieve your goals as possible. Keep it within a reasonable limit of size. I usually keep my execution plans within 10 pages as a kickoff document, and then the extended document can be used as a reference. You don't have to go through the entire execution plan if it's many pages long. Just stick to essentials that everyone needs to be aware of.

Get a signoff from everybody involved. Make sure they are aware of what the requirements are to each party, and answer any questions. And then proceed to do more calls in the future, weekly, biweekly, monthly, whatever the cadence is. Again, walk away with some next steps for everybody so they don't just stop here. It's easy to lose track of these deliverables.

Next part, challenges-- we're going to talk about headwinds. So far, everything's gone according to plan because I wrote it out that way, but things do not go according to plan. Things can get complicated and challenging.

The owner might want paper delivery with the digital delivery. So they might be interested in what you have to deliver, but they want it in paper document format too. And you're wondering, that's easy for 2D plans, sure, but how do I make paper delivery with 3D? You may want to address that as a concern and maybe a exception you need to make.

They give you standards, and they provide teams with their expectations. But the language and the requirements are not useful for any BIM, VDC, design technology process whatsoever, and you have to find a way to bring standards compatible with digital delivery into the project. Otherwise, it just becomes a good idea, but it doesn't really get applied early.

See if you can include standards or writing documents for level development, for the execution plan, anything, so it's available to the rest of the project team. Sometimes the owner specifies inflexible formats for data, file formats that are really old or proprietary that made sense 20, 30 years ago but wouldn't be helpful now. They're not as robust, not as rich.

So see if you can address that and see, can we provide you those file formats if that's what you want, but can we just use others as well to move forward? Again, don't make assumptions that they'll just say, sure. Make sure you get that addressed.

Make sure you get that clearly stated and saying, yeah, if you want to use other file formats, go ahead. You don't want to make assumptions on these big, complex projects because that can leave you with a situation where people didn't agree to what you're doing, and you have to make up for it later. Ask me how I know.

And some clients are not knowledgeable on the delivery process, even if they agree. Yeah, you're right. We should do clash detection and reduce those RFIs, and we should have execution plan, and we should put the standards. They may not know what you're talking about because they have a hundred things to juggle. So tell them that this is a little more effort, if it's not spelled out, it could be a little more effort, and we need to address it. And you're there for them to get information and guidance.

So be aware that they might be very agreeable, but they might not be very knowledgeable, and make clear that you're there to close that gap of information so that it doesn't become a problem later on where you're hearing things that aren't aligned with what your expectations are.

And with that in mind, set a baseline for what you're going to deliver because if they're not knowledgeable, they have standards. They're not going to know what they want, so for delivery, make sure you have some kind of guidance on what to achieve. What are the key performance indicators, the KPIs? What are the reports that matter to them? Are they interested in progress reports? Are they interested in cost control?

Try to find that out through the existing documentation, and target that with your process. Try to follow that language and speak their language as much as possible. Talk to people who have been talking to the owner side and other counterparts in the organizations that you're working with on this deliverable, and figure out what is the language they use, what is the terminology they use. Speak the language. And make sure the standards are in place, and if you need standards, they will be in place. Otherwise, it'll be hard to actually target anything with those KPIs.

And make sure you set the standard for data file formats to proceed with. You can provide a range of acceptable file formats or limit the scope, but don't make assumptions that everybody is going to use the same software as you will. These are big projects for mission-critical delivery. They could be using many different kinds of software.

Some might be using some specific analytical software that would be great modeling software for what they're doing but wouldn't be useful for me or anybody else. That could be for structural engineering, computational fluid design analysis, could be a lot of software that's technically modeling but may not be useful for anybody besides one or two analysts doing that portion of the work. So make sure you have that set of file formats that are acceptable for anybody to provide.

And for guidance, you can also say, hey, how do we address that issue of a paper document delivery? That paper document delivery might be referring to surveys. Well, you can say, do we really need a paper document if you want the survey? That's understandable in the past. For some of these agencies and companies, they have really old requirements going back decades. You say, well, who's really going to read those surveys? Sure, it's fine to have a couple sheets for printing plans, but what if we had a laser scan for as-builts before we get the project started if it's a renovation?

So you could create an example for a standard operating procedure for laser scans. Paper docs would be incomplete for the as-built, which is the problem scenario, and you can instead use a laser scan point cloud model, like the example on the right, to create a high-quality and complete model that can be referenced by anybody on the project.

It is three-dimensional, can be used as a three-dimensional asset that's accurate to a high level of detail, and you can specify the detail to anybody doing the survey. And it's measurable. You can use that to get distance, size, area, whatever. So that would solve some problems in getting the visibility scope. It's not just limited paper. It's a 3D asset you could use for other 3D applications, like clash detection, and it can help support the project.

So all you need at that point is a simple budget if that's on your shoulders to deliver, timeframe to complete if it's going to be a record as-built before for any kind of renovation or completion, and what file format. Get buy-in, and move on. This is an example of solving a problem while still making the owner provide a record document that they're going to need for future projects, and it avoids trying to use something that's antiquated.

So next part-- how do we make progress now that we have all our plans in order? So in practice, you have to make sure you report progress to the decision-makers and executives. And this doesn't have to be every week, but you do have to provide some kind of update. I would say at least monthly for fast-moving projects would be appropriate, saying what you're doing on digital delivery front, so people are aware it's going on.

Again, they might nod their head and say, that's a great idea, let's do it, take care of it. But they may not understand you're working on it actively every month. So just let them know, hey, we did this month. It could be a simple update. We did the kickoff. We got a part of our project rolling. Anything is better than nothing.

Keep them in your mind. Excuse me. Have them in their mind. Have you in their mind. Excuse me. Have you in their mind, what their projects are working on. Set milestones to work towards so that, again, if it's a monthly cadence or quarterly cadence, at the end of that month or quarter, you have something to work towards. So that'd be like a schedule, and we'll talk about that in a moment.

But also, make sure you use shared platforms to communicate. Do not put your content in a platform or software that only you and a handful of other people ever access. And also, please try to avoid using email and Outlook for the platform. People lose track of emails all the time. Use something that's accessible to the entire team to do this tracking so that everybody can see it.

So we're talking about milestones. First of all, in order to have a milestone, have a destination. Have a plan, and keep it updated. And with that plan, focus on phases of completion. What are you trying to finish along the way, major milestones? For example, what it would take to get from kickoff to a schematic design deliverable or at least turn over from schematic design to design development?

From design development, how do you get to the different stages of construction documents? From construction documents, how do you get to field operations and construction? And field operations, how do you get to the beginning to the end, to project closeout? And in project closeout, what does it take to make sure it's closed out and you have a deliverable or a handoff to the next party in the process?

Describe what those are in meaningful phrases and changes per milestone. So instead of just saying, we're making progress, we're doing things, it's like, OK, we got to the SD level, we got to the construction level, so people understand what's going on. And you can phrase it, at stage X, you shall receive Y, then we move on to Z. That Mad Libs phrase there will help you structure what you're trying to deliver to the owner and everybody else on the project so they're aware you're moving things along and you're going to provide the next thing. That helps them understand what's happening.

And my suggestion here early on-- you don't have to make a full schedule in Excel or some software where you're explaining every single day. Just set an outline, big steps, and go from there. Provide the stages. Provide the updates you'll get at each stage, like I mentioned, and explain the future state.

And one way I like to do that is actually a roadmap. The graphic example gives you a sense of how that works. On the left side, you have all your bullet points for the different phases of the project. On the right side here, in the months February through May, it will show you which active project you're working on in that month.

What I like about these is they're very easy to follow. You can write these down into a single page. It doesn't have to be a multipage document or multi-scrolling document. It's extremely easy to digest, and here's an example of a project timeline, just a generic template, where you can map out the phases of the top there. At each phase, you can map out OKRs. OKRs are just deliverables.

And you have phase one i one color, phase two in another color, phase three, and a phase four, all the way to the deliverable. And it's just, left to right a timeline, top to bottom the efforts and the phases. It's that simple. It's an x and y Cartesian grid. Anybody can follow this.

And if you then put in what you're trying to accomplish with those phases and deliverables, how they're staggered over time to whatever the timeline is, whether it's a month or five years, you can say to people, this is what I expect to happen, here's how I feel that these phases will work in tandem and separately in different lanes over time.

And all you're trying to do is provide clarity on what's happening, and this is a good document to ask questions, saying, any questions about this? Do we see an issue with the way I arranged it? Is there something I should know?

You want that feedback. You're not just doing a show and tell. You want feedback and explain to people what you're doing so you get the critical information you need to make adjustments. And the beauty of this is if you put everything in one big roadmap, you can then screenshot it, save it as a file, put it into the body of the email, make it a document in the execution plan, and share it. It's one page.

And that does not stop you from making more roadmaps per effort. Each one of these items here could be its own roadmap if it needs to be that detailed. But having a master roadmap like this can be a quick way to figure out what it is you're trying to deliver and do it on time.

And a little bit of elaboration on shared platforms. Ideally, you have a single shared platform, or repo, to rule them all, something where everybody has access to, whether that's Autodesk Construction Cloud, BIM 360, Microsoft 365. Whatever else it is people might be using, if it's the big project platform for everybody to share things in, put your information there.

Whatever you agree to, whatever standards, whatever execution plans, whatever documentation you may have, including the deliverables themselves at any stage, including the final stage deliverable, make sure it's on the shared platform. Make a copy of whatever you're working on, put in there. If you don't have-- if the originals are somewhere else, make sure you put a copy there because that's what everyone's going to have access to.

And if you do see there's a divergence of platforms where different companies are using different things, address that, and say, what platform must we use for digital deliverables so that you're not just putting them on every single platform, you have the right platform? Address that if you don't know. Otherwise, you could do all that work, and nobody knows you did it. Or it's not available or whatever the gap is, so don't take that for granted.

And then finally, takeaways, lessons learned, so what we learned today-- ask questions and know what people expect. You can make a lot of assumptions, but you should also ask questions. Learn from the leadership, the executives, your counterparts, your coworkers, whomever. Make sure you know what people want and not make assumptions so that you understand what is being delivered and who is in charge to deliver it. Whether it's yourself or another party, at least you know who is targeted for delivery.

Identify challenge areas, and account for gaps, like we talked about. Maybe the requirements they have for deliverable is not what is ideal, and you can say, OK, if I'm accountable for this, how do I address it? And if we see gaps, like the platform is not there or we don't have file formats that work on this process, then make sure you address that as well, saying you know what, I see this needs to be scoped better, otherwise we can't move forward to the next step.

Create a schedule and provide delivery milestones. Your project managers and executives will love you for it because they can see what is owed to the client and that scope of work. There's many things owed to the client, the owner, and the project, and you're trying to find a way to get it to the end. Make sure you make that available. It can be a simple roadmap. If they want more detail, provide them more detail. Anything is better than nothing.

And of course, last but not least, communicate early, and communicate often. It's easy to make assumptions. It's easy to think, OK, well, I know what I'm doing, I've done this 100 times. But you never know, so always ask questions as early, as often. And if possible, provide updates as often as possible about what you're doing.

Communicate to others what you are doing and what you're trying to achieve. And if they're like, great, we get it, awesome. If not, if you see a gap in the process, address it because early on is where it makes a difference. You don't want to be addressing these challenges at the very end where it can get very complicated very quick for a lot of people.

Special thanks to Enoch Chow and Dawn Bridges. I had a pleasure to cooperate with them on a session related to this, so their information, experience, perspective, and feedback on mission-critical delivery was very helpful for this presentation as well. So shoutout to them.

And here are some references. I have here "Turning the Key," a talk I did a couple of years ago at Autodesk University about leveraging digital deliverables to an owner, related to this talk, and it gives you a little more insight on more specific aspects of digital deliverables, including facility management processes like I described earlier.

Here's the Design-Build Institute of America documentation on project delivery. This is very helpful for people in the world of construction and even design. And then last but not least, "Mission Critical Project Management by Vince Kellen," this is a great document for just broad overview and very good guidance on how to do project management for mission-critical facilities. It's a good read. These are all pretty easy to get into and read.

At this point, we can take some questions, but thank you so much for attending my talk at Autodesk University. And I'll see you in the hallway.