Name: Risk-Aware Forecasting: Where Threat Meets Opportunity
Uploaded: 2026-08-18T15:30:42.980Z
Duration: 59 min 39 s
Description: Risk-Aware Forecasting: Where Threat Meets Opportunity

Transcript for "Risk-Aware Forecasting: Where Threat Meets Opportunity": Hello, everyone. I'm Lisa Bergstrom, senior marketing manager for Deltek. Thank you for joining us for today's presentation. While you're joining, we have a few quick housekeeping notes. For the best webinar experience, please use Google Chrome. If you have a question, type it into the Q and A box anytime during the presentation. We We will address as many questions as we can at the conclusion of the webinar, and any questions left unanswered will be addressed individually offline following today's presentation. Resources, including the presentation slides, are available for you to download in the resources tab on your screen. You will also receive the on demand recording of today's webinar via email within twenty four hours after the webinar ends. So with that, let's go ahead and get started. Welcome to our future presentation, Risk Aware Forecasting, Where Threat Meets Opportunity. At this time, it is my pleasure to introduce today's speaker, Tom Polin, Advanced Solution Architect at Deltek. Tom brings deep experience in project controls, earned value management, and program execution across the defense and federal contracting community. He works closely with project control teams to help them adopt practices and technologies that improve costs and schedule outcomes on complex programs. Welcome, Tom. Hey. Thanks, Lisa. I'm excited to be here today talking about one of my favorite topics. It's in the first word of the title risk, and we're combining that with forecasting because why wouldn't we? They're really different forms of the same thing. And what I am going to talk about today is how you can do risk management with respect to your forecasting process. I've seen time and time again over the last too many years, thirty one years in this industry, where forecasting and risk management are treated as separate processes. One, that's not good practice. And two, that's not fun. That's not fun to do them separate. We wanna do them together because they're both real they both really have the same goal, which is predicting the outcome of your project so that your reporting is accurate, so that your stake hold holders are satisfied with the information that you're reporting. Nobody wants to hear one thing from a forecast and see project execution play out differently in real life. It's not good business, and it's just it's it's not fun. So let's get into it. And and before we even get into the agenda today, we have some statistics from the recent recently released 2026 Deltek Clarity Report, and I am keenly interested in some of the data. And this is all provided by you, our our listeners, our our the the people that we engage with on a daily, weekly, and and monthly basis. And perhaps you're you're even one of the individuals potentially listening today who helped populate some of this information, by participating in the Clarity, survey. If not, many of your peers have, and we were able to compile a tremendous amount of useful information. There's a full Clarity report that you could find on the Deltek website, but I have extracted several key statistics today, and it's not gonna surprise anyone that the statistics that I extracted are all related to risk and forecasting. So the first one, top risk domains as ranked by government contractors, here in The US. Project execution topping the charts at 38%. So 38% named project execution schedule, cost, and scope as their top risk concern. We can see supply chain on there. Cool. Cyber cybersecurity data protection, more important than ever. Talent resource, regulatory compliance may or may not, apply to some of you depending on what industries that you're in. Our webinar today will appeal to all industries. So if you hear something about compliance and you're like, hey. What's that? Well, some of your peers listening do need to care about that and and and others don't. So this is not a compliance heavy, presentation today, but we we do wanna pay homage to it. Client or stakeholder satisfaction, financial performance, cash flow, and environmental climate related risks. So it doesn't take a PhD in statistics to see that the most popular response was, project execution, schedule, cost, and scope, and that intersects very nicely with the forecasting topic that we're talking about today. So I want you to remember that because we're gonna put up some more statistics, but we're gonna bring it back around in a minute. And then I promise we're actually gonna get into the to today's agenda as well, but I like the hot start. Okay. The risk management gap. Where's risk management being performed? So let's first look at the chart on the left hand side. I love this. Pre RFP, 32%. I I can barely see the histogram through my sweet tears of joy that people are addressing risk before and during the proposal phase. 55% at the proposal phase. More than half. That is excellent, excellent best practice to be identifying, managing, and even potentially mitigating risk during the proposal phase. Is that client friendly or what? You're you're making yourself and potentially your client aware of your risks during the proposal before it's an execution problem. You're you're demonstrating your expertise and your awareness of what could interfere with your own ability to execute the project before the project has even been awarded. Round of applause for those 55%. Not too far behind project initiation, and then it's getting lower during execution. So that's it's not an uncomfortable side of the story, but I'd love to see those all those bars near 100% and staying level. But this hey. This is continuous improvement, and I love it, and I believe these numbers are higher than ever. So let's look at these panels over on the right. 75% of firms see project risks escalate to affect enterprise performance at least sometimes. So companies now more than ever are intersecting project risks and enterprise risks, and it works in both directions. If something is a risk at the enterprise level, it may very well become or already is a risk at the project level. And if a risk is identified in the project level and this project is in your business area, in your line of business, which it probably is or maybe you shouldn't be doing it, you're seeing you're potentially servicing that to the enterprise level as well. And, again, bravo to those 75%. 35 34% of projects operate with no risk management practice in place. Frown face. But it's only 34%. That means two thirds do have a risk management practice in one form or another. Phenomenal. 9% of firms manage risk continuously across the full project life cycle. I think everyone would want to. I think maybe it's just a matter of, well, how do we do that? What are the questions we should be asking our team, ourselves, our customer? What benchmarking should we do out in the industry? Should we use artificial intelligence to help this this process? And the answer to those rhetorical questions is is usually yes. Now let's go to the next slide here. I I'm reading some of these because this information is new to me as well. This information is hot off the press, just a few weeks old. Now wait a second. We said that, risk analysis is is front loaded. Project execution was identified as the, the the top area where, or the the most critical risk domain for companies. But then during execution, we can see it's actually not the top area. So that doesn't tell me anything bad or anything like that. It tells me that we're all working together to still figure out what excellent looks like across the entire project life cycle for risk management. Do I have all the answers? No. But what I am going to do in today's session, and we're gonna get to that agenda slide in just a second. I promise. What I am going to share today are, my very personal experiences and the experiences of my peers when it comes to identifying what successful enterprise and project, based risk management looks like. Oh, we've got more. We've got more statistics before we get to the agenda here. I was I was getting ahead of myself. That's how excited I am. The the system is strained. 27% of projects over around budget, 26 ran behind schedule in 2025. Our 2026 Clarity survey looks at 2025. 2026 will be discussed in 2027. So I think that's good. I think hey. I'd love to see, you know, 0% of projects, you know, ran over budget and cost, but I think we're doing pretty well from an execution standpoint. These are some very telling numbers about whether or not we're getting better at this, and I I believe we are. This next one, the tool fragmentation, if you've ever talked to me at a conference or some of my peers here at Deltek, this has been a frustration for people trying to put up a a risk aware forecasting and project control system together. Two to five disconnected tools is the 85% case, and only 5% of our survey respondents operate in a fully integrated system. Hey. We're a software company. We're working to help fix that for every man, woman, and child on the planet Earth. We talked about 38% being the top risk domain project execution that is squarely our scope today is to talk about that. We said, hey. The 9% only 9% managed continuously across the project life cycle. AI investment, I mentioned AI just a couple minutes ago. 32% rank, implementing AI to improve processes as their number one way to address project management challenges in 2026. We can't ignore the AI discussion. We need to lean into it and talk about where it intersects with successful project execution. I almost said risk management, but really, this is all about successful execution, and risk management is one of the ways that we get there. What if we can't do these things well? What if what if we need to be afraid for a second and say, well, what if we don't have a reliable forecast? What if we can't do this well? What if we're not aware today of what our forecast may look like thirty, sixty, ninety days from now. And what happens when our customer, whether it's a commercial industry or whether it's government contracting or maybe a little bit of both depending on what your firm gets into, what happens if people start taking a closer look and we're not risk aware when we develop our forecast and when we communicate to our customer what our cost target currently is and when we expect to finish the project? Well, when there's close scrutiny and and there's not do and we're not doing it well, forecast collapse. Our cost system might be telling one story. It might say we're on target, but our schedule tool and process might say that we're behind schedule. And if I'm your customer, I'm gonna say, wait a minute. You're telling me you're gonna finish and meet your cost objectives, but you're gonna be late. How's that gonna work? Usually, if you're running longer on your project, it means you're spending more. I've seen that happen almost every time. And interestingly, the schedule and cost, objectives being met were within not being met. We're within 1% of each other. One was 25%. One was 26%. There might be something to that. Here here we go. Delays trigger real financial, fallout. Slip a critical path, you're going to spend more. Cast, penalties, depending on what industry you're in. At a minimum, rework, strain budgets, and, schedule acceleration costs that start compounding right away. Meaning, when you're late, everything starts getting worse, not just the schedule itself. If you're in an auditable industry, formal or informal, government contracting is more formal, commercial might be less formal when it comes to audit. All of a sudden, there's shuffling of papers. There's well, wait a minute. We have to get our story together. I've heard that from program managers a number of times. Hey. We need to get our story together for the customer. We need to get our story together for the audit agency. Well, should we need to get our story together or should our story be accurate and healthy and hey. They can come in. They can look at everything we have. We can be fully transparent. We're very confident that our forecast is accurate. There's certainly risks along the way, but we've identified them and we're prepared to show what we're doing to mitigate those risks. Decision slow down when it matters most, manual reviews, spreadsheets, that shuffling of papers that that makes me cringe. You know? We shouldn't have to, we shouldn't have to do that. It shouldn't be an emergency. And finally, our own leadership and the leadership amongst our stakeholders, they if we have been unable to deliver on our commitments, the next time we make a commitment, their eyes are rolling. They're saying, wait. You don't have the credibility. We believe you're writing a check that you can't cash. Meaning, we think that you might be over overly optimistic about your forecast because you haven't been able to deliver on the things that you prayed it, that that you stated previously. Why would we believe you now? I've heard those words out loud, and that leads to cascading painful conversations. What we're gonna talk about in a minute is having the painful conversation internally so that you address and make things robust so that when you do need to report the numbers, although they're not always convenient, they're accurate, and they represent the state of the work and the business as you know it right now. That's a good place to be even if some things have gone wrong. Finally, we're we're we're on that agenda only 15 in. We're gonna talk about what a forecast is and isn't and and where I believe traditional forecasting has failed. And I don't take that word lightly. But we're gonna build team confidence. We're gonna talk about how to do that in steps that you can literally take this afternoon, tomorrow, or Monday, to talk to your team and engage the risk conversation without having to say that you're having the risk conversation. You're just gonna get right into it. We're gonna look at some charts today that help make the risk and forecast picture click for just about anyone. We're gonna talk about saloon door risk management. What's that? Why are we talking about saloons today? Well, if you've seen a presentation that I have called risk for the rest of us, we're gonna borrow from that. We're gonna talk about ways to do forecast and risk briefings without making them excessively complicated. In fact, we're gonna try to make them excessively simple. Oh, simple briefings with sophisticated support behind them just in case, but briefings that any human can understand and brief another human on when necessary. My theory of risk and forecast management is we have to look at things almost as bad as they can get because only when we stare deep into the abyss of future project failures can we truly understand the steps that will be required to prevent that scary future from becoming the reality for our project. It sounds like I'm around the campfire with a flashlight under my face. I'm scaring you. Well, I'm not trying to scare you. What I'm trying to do is say, if we don't look at how bad things may get real reasonably and realistically, we won't take the steps today to prevent surprises from happening later on. And in our clarity, survey, report this year, the question is asked, if something changes and I like this question. If something changes in your largest contract tomorrow, how long will it take that information to show impact to your project portfolio and enterprise forecast? How long will it take that problem to surface up to the executives so that they can make a decision as to how inconvenient that future needs to be or what resources we can marshal to mitigate and manage risk so that the forecast that we're reporting is certainly very reasonable. I like that, and that's a tough question to, to answer. Don't lose too much sleep over it. But if something, you know, borderline catastrophic is predicted for your project, what's the information delay in getting that information to the people who can make the decisions now, today, August 18, to prevent an emergency in September, October, November, and into next year? I like that. I stole it. Now I'm gonna this gets a little personal here, my tornado chart of existential fears, and we're gonna talk about tornado charts and their relevance to forecasting a little bit later on. But I thought we'd have some fun with one. And if you're thinking tornado chart, some of you might be going, yes. I use those as part of my risk management process. And others of you might be saying, why is this gentleman, Tom Poland, talking about weather? Well, it's not really about weather. It's called a tornado chart because the aesthetic of the chart. My first of three existential fears when it comes to project controls is the fact that labor may have been underestimated so that when we start executing the project, all of a sudden, we're overrunning our labor cost and and usage right out of the gate. Magnitude of fear along the x axis, so this bar has some length. That this will become more relevant as I go to the next one. Underestimating cost, that's further up. That has a higher ranking. I'm going from lowest to highest here. There's only gonna be three bars on the chart. So labor is my first fear. Underestimating cost is my next fear up because cost includes labor, but then it includes material, travel, other direct costs, things that aren't a human resource but have a cost impact to execution of the project. And let's go for the top one. Overrunning cost and schedule. In fact, I'm so fearful of it. It goes off the right side of the chart into the black space next to the chart. Overrunning cost and schedule. That's low and slow. That's you know, you can't borrow from one to help the other. You're you're you're you're out of bed on both. You're if you're overrunning cost, you can't use cost to make up schedule. And if you're overrunning schedule, you can't, you know, use schedule to help make up cost. So this is kind of a fun fun chart here to talk about, but it becomes very relevant. And the reason why I wanted to show it to you here is, one, I'm genuinely concerned about these things. But, two, as a teaser towards saloon door risk management later on, this is a really easy style of chart to explain to almost anyone. They're ranked and the longer bars are the largest magnitude. I could ask you later, what was my number three? You you might if you remember, you might say, underestimating labor. How many were above that? Two because it was number three because it was on the bottom of the list. We're gonna get back to this chart, but I sort of wanted to tease it a little a little bit because, you know, in a, you know, dozen slides or so, when I when I pull one up, you'll be like, I'm already an expert on this chart. Pulled in earlier talked about talked about it, and these are the things that I fear the most in project controls because they're really difficult to unwind. So if we get our forecast right, we we have to be less concerned about these things. Let's talk about today's flow. I'm going to give you very real calibration questions that have been very useful to me and my peers in understanding what our risk temperature, risk profile, risk tolerance is for the work at hand. These will be questions on the screen that you can ask your project team today, this afternoon. This is not a theoretical presentation. This is a very, very practical presentation leveraging the tools and resources that I've used for my entire career. We're gonna address uncertainty. We're gonna help prevent the team from overthinking and give you quick answers that are gonna help fuel the accuracy and reliability of your project forecast. We're gonna talk about everyone's favorite risk topic, the risk register, the list of things that can and maybe will go wrong during project execution. Now on that risk register might be mitigation plans as well to prevent that scary and inconvenient future from becoming the reality for your project. But if we don't address and discuss those risks early on, as early as the proposal or even pre RFP phase, we don't address them, they are certain to become problems that cause the project to derail. And my favorite part of today's show is that concise briefing, that saloon door risk management. I'll explain in a while why I call it saloon door risk management. I think some of you will get it. Maybe some of you have figured it out, but we're gonna we're gonna work our way there. And I am I fully believe that when we brief risk, we should do it in a very human way, not with computer screens, not with statistics and data that take would take reams of paper to print out or put up on a PowerPoint, but a very real human conversation that you might have with a friend or family member. But it's about risk and the risk to the, successfully executing to the project's baseline and the project's forecast. Now where here's where I said, hey. We we we may have been doing this wrong for the last hundred years or so. So let's talk about the past in traditional forecasting. Traditional forecasting is deterministic. The forecast is one number. I've worked on projects where the program manager wanted to hold the forecast to the baseline values deep into project execution. Well, the longer that goes and the longer that forecast gets held at the same values as the baseline, for for cost and schedule, I believe the less reliable it is. It's built up, bottoms up, which is great from each individual activity on the project, how much time and cost are remaining for this in in progress activity? And the most common question I've gotten from engineers, control account managers on this question is, well, how much time do I have left? Well, wait a minute. That's that's not what I asked. With what you know today, how much time is remaining? And we'll get to some of these questions in just a minute that I that I normally do ask, engineers and stakeholders. And then as part of that, past forecasting process and current, the remaining time and cost are entered into the tools, and the project forecast is automatically generated. It's literally arithmetic adding up the remaining cost and the remaining scheduled time for those different activities. Now here in 2026, and what we're seeing seeing evidence of in that clarity report is we're talking about risk both at the project and enterprise level. That's fantastic. Risk is not deterministic. You don't necessarily know today which risks will and won't be realized on your project. You've gotta do things like assign uncertainty and intersect your risk register to your project plan to see what's really going to happen. And it's a probabilistic, not a deterministic science because if the if we knew all the risks were going to happen, we would just bake them right into the plan. So new forecasting is taking the the the current progress, all the things we did in the past that are in those first three bullets on this slide, but then also incorporating risk considerations. That's what leads to a reliable forecast. The problem is this. I used two words on the slide, risk considerations. That's a big problem to solve, is knowing what uncertainty to bring into your forecast and what to keep on the side. A comprehensive bottoms up EAC estimate at completion. I believe this is an opinion in this last bullet. I believe it's not valid unless it considers risk. If one of my subcontractors presents me a forecast, I am literally going to ask, did you consider risk? What's your risk picture? Do you have risks to that forecast? If so, what are they? If if they say they don't, I'm highly concerned because then I'm not sure that they know their industry well enough to know what the risks are. Every industry has risk. Here's some of these questions that will help, that I believe will help a project team get comfortable with the discomfort of the inconvenient risk conversation. I might ask the program manager, what's uncertain about this project? And then the best thing that I can do when I ask that question is something I have difficulty doing, being quiet and letting them talk and talk and talk. And if they're silent for the first five seconds, I'll wait another five seconds. It might turn into a staring contest. Who knows? And then as a follow-up, if they give a vague answer, oh, you know, the technology is uncertain. Well, where specifically is the technology uncertain? And what are the technology items that we're highly certain about and we've worked with many times before? And how do you, program manager, technical manager, engineer, believe this uncertain deal affect our outcome? I might not even use the word forecast. I'm trying to assess the confidence that the team has in the plan that they or maybe a proposal team has put together. Again, if they say we don't have uncertainty about this, I'm highly skeptical about that because I've seen a lot of projects run into emergencies and problems that they didn't anticipate. Got enough at bats with this to know that when we plan the project, we don't necessarily know everything that can and will go wrong during execution. We must acknowledge that. We must not fear it. We must lean into it and say, okay. We do know that there are uncertain things. How can we build those things into our forecast? That's what gains confidence. Over to that risk register. I don't oh, it does. I was gonna say, I don't think it says risk register anywhere on this slide, but it actually does down in the lower portion. Are there I might ask the program manager, risk manager, engineering team, are there specific threats and opportunities which may affect our ability to deliver on time or potentially things consequences that could happen during execution that would prevent us from delivering at all or having a catastrophic failure. Nobody likes to talk about that. But if we don't talk about it now, will we take the steps to mitigate it and prevent it from happening later? Now the team may already maintain a risk register. I've seen hundreds of them, maybe thousands, called risks.xls, meaning they have a spreadsheet where they're maintaining their risk register. That's good. It's not great. We'll talk about that. But if they say we don't have any named threats, we don't have any opportunity on this project, again, that's where I would be more concerned about that than any threats that they actually bring up. If we bring up threats and opportunities, it shows that we're aware of what we're doing, and we're also aware of where can where things can go wrong. Next question. Project execution needs to proceed irrespective of risk. We wanna do the work that we said and signed up to do. How much delay should be can and should be expected? Have we done a job like this before? Was it delayed by three months? Was it delayed by twelve months? Was it canceled by the customer due to unforeseen risks? The response indicates whether or not they understand risk can and will drive the need for a certain level of contingency. And in some industries, this is called management reserve, contingency, schedule margin. You probably know you may know, what it's called in your industry. I've been told we have risk, but we can still finish on time and on budget. Fantastic. Can you tell me more about that? What's the plan if some of these risks do happen? That's that's the that's the key point. If they have an answer to that question, my trust with this project team is building. If they say we have risk, but we don't really have a plan, well, then we gotta roll up our sleeves and make sure that we do have a plan when some of these inconvenient things may happen. Notice I said may. Again, probabilistic. These are things that I've heard. Proceed carefully with your hazard lights on if you hear any of the following. I've experienced all of this. The work was estimated by someone else. They're over on the other side of the corporate campus in the proposal center. I'm responsible for managing execution. I didn't make those estimates. I don't know what went into them. Uh-oh. This is a reality. I have worked at a defense contractor that had an isolated proposal center, and the basis of the estimates that went into the baseline, which is then the initial forecast, was not communicated. It was estimated by people who are professional estimators who may or may not have executed programs in in their lifetime, which is fine. That's the way certain companies are organized. But if we don't know the basis of that estimate and whether risk was considered as part of those proposal estimates, we're in a very uncomfortable situation if another person then needs to manage execution of that work. What were the assumptions? The question might be as simple as that. Two, I addressed it earlier. We lock the forecast to the baseline. Cool. When do we unlock it? We know we I think we all know on this call that the baseline is not how things turn out in real life. Hey. I'll be there in five minutes. I might not be there for an hour. I may have just told someone I'll be there in five minutes even though I believed in my heart I would be there in five minutes. That's the type of estimating we do every day. Multiply that by a 10,000, 50,000, 100,000 line project schedule. All of a sudden, we've built in a lot of optimism bias. We don't have time for risk management on this project. It's not called for. This is an all hands on deck situation. Oh, that sounds like that's the ideal time for risk management if it's, you know, don't wait. Go. Go. Go. Ready, fire, aim, whatever you wanna call it. Oh, hey. Risk manager is not a, this is a cost reimbursable project. Risk management is not in the contract, so we don't need to do it. It might be more important than ever if if it's not in the contract because it's gonna be the expectation. Those who are responsible for executing the work are responsible for managing the risk that can drive the execution of that work. We have a risk register and a spreadsheet. Good. Silver star. We'll talk about what gold star looks like in a few minutes. We update the forecast quarterly, and then we review risk once a year or when there's new scope or when the customer comes in. Well, wait a minute. That's the old school forecast that we do irrespective of risk. How could risk intersect and interfere with our forecast? If we're talking about forecast and not talking about risk, we're not talking about forecast. We're not talking about a realistic forecast because we're not considering risk. Hey. The the project's risk manager handles all the risk. Well, that's cool, but we're all responsible for execution. Therefore, we're all responsible for being a participant and a collaborator in the risk conversation. These are things that I hold dear. I hope you do as well. Here's some more rhetorical questions. If you know me, you know that I love these because they, they can be uncomfortable questions. Who owns the project risks? Everyone. Who owns the forecast? Everyone. What will happen if responsibility is unclear? It means no one necessarily will accept responsibility for these for these items. And can the risk picture and forecast become complicated and difficult for the team to understand? Yes. While I can explain the cascade of charts that are on the left hand side of the screen, I think about risk and forecast management every minute of every day. I don't know if that's healthy or not, but here we are. What I'm not going to do today is train you on these charts. I think they're great backup material. They're statistics. I love statistics. I can think and talk about statistics all day. But the the the picture can be come so statistics ridden that there's more noise than signal in that communication process. My saloon door risk management approach, we're getting there, I promise, is all signal with as little noise as possible. And as much as I love these charts on the left hand side of the screen, I know they're small. I'm just putting them there notionally so you can see all the bars and gadgets and bells and whistles. I love them, but they can become noise for a decision maker very quickly. And that's why I overlapped them on this slide. I just wanted to make noise out of them. Now we gotta make a sharp u-turn, left turn, turn things upside down for a minute. Before we get into the risk register and addressing uncertainty, you have a different kind of risk lurking in your plan right now, whether you know it or not. In almost every plan that's out there in the world. And I've looked at a lot of them, and I've made some of them myself. If you're doing what's called the critical path method schedule, sequencing activities that go into executing your project. You know, at a high level, this would be, like, you know, requirements, definition, design, engineering, testing, you know, delivery. That's like a four line schedule. Your schedule is probably more like 400, 4,000, 400,000 lines depending on what you're building. I've seen every one of these problems in almost every project plan that's out there. Missing logic, activities that aren't sequenced along with the others. A high the the opposite problem, a high average number of links per activity. Meaning, we've linked everything together so tightly, we're not even sure how to get from project initiation to project delivery because there's just connections everywhere. The critical path, is it accurate and unbroken, or is it held together with hard constraints? Oh, that's the next one. Are there hard constraints? And if there are, what what are they attached to? Lengthy, unmanageable activities, hundred, two hundred. I've seen five hundred day activities. Leads and lags, that's more technical. Those who build schedules, who are around schedules, understand that terminology. If you don't, that's fine. This kinda gets into the nitty gritty of crit what's called critical path method scheduling. And then merge hot spots, activities that have so many things that need to happen before they happen that the activity can't happen. If if we waited for everybody, to attend this webinar today who signed up, that would be a merge hot spot. We'd still be waiting to start because someone would still be in their car get trying to get to their computer or wasn't able to make the event at all. That would be a merge hot spot if we were still sitting here playing, like, elevator music waiting for the, the webinar to get started. That can infect your project plan as well. So duration uncertainty. This is a probabilistic science that can contribute to a reliable forecast. In fact, this is the most common way to get started with what's called a schedule risk assessment. There's different methods of assigning uncertainty. One of the classic methods is assigning a three point estimates. Meaning, if an activity is supposed to take, let's just say, a hundred days for simplicity here. Well, what is a good execution look like? Can it ever take ninety days? Yes. Can it ever be quicker than that? No. Not usually. Ninety days would be the fastest. We could do this activity that we normally estimate at a hundred days. Cool. Well, what does uncertain look like in the other direction? A hundred and five days, hundred and ten days. Has everyone has this activity ever taken a hundred and fifty days? Yes. Okay. We're gonna set the maximum duration at a hundred and fifty days. So I was able to talk through one with myself there in about ten seconds. The problem is, what if I have a forty, fifty thousand line schedules or even a 200 line schedule? All of a sudden, I have to have that conversation over and over again. Well, hey. Deltek is primarily a software company, and we've come up with some clever ways in our risk assessment, risk management software to use red, yellow, green to assess the uncertainty of an activity or even a roll up, like a work breakdown structure roll up or a roll up based on location, contractor, any number of tangibles and intangibles, that you can assign uncertainty to. And then we say, okay. Well, does the uncertainty system, software smart, can then do the math behind the scenes so that we're not sitting here going, okay. Does that normally overrun by 10 or 15% sometimes? No. It's it's light red. Cool. And we move on to the next area of the plan. Quick. Quick. Quick. And it yeah. This is that mapping table here that I pulled up on the screen where green would be very conservative. And, yes, you can tweak these factors. I'm not saying you have to use our software. We love it when you do. But what I challenge people to do is come up with a method to make this three point estimate process easy for people rather than asking them the mathematical factors on every single activity. Well, why not? What if we had unlimited time? Well, it doesn't mean everyone is really excited about estimating the duration of an activity three additional times over the estimate that they've already made. There's a human brain drain factor there by the five hundredth activity. I'm just saying just do it like the last one. Do it like the last one. At that point, I'm not even doing a risk assessment. Parametric data, AI in your data lake. You know, any way that you can use parametric information, machine learning, and now in the last couple years, generative AI. To have this unbiased look, artificially intelligent look at your past performance and see if your latest job that you're planning and forecasting now is you writing a check that you've been unable to cash. Meaning you're making commitments on the current program that you haven't seemed to be able to live up to on past jobs. AI is a great objective way to call that out with an unbiased resource to tell you you've never been able to perform in the past on similar work in the way that you're saying that you're going to perform on this one. Now maybe you know something that the AI doesn't, but if you can't identify that thing, you should expect to perform to the level that you performed to in the past. Now the con for this is the AI is only as smart as the information that you're able to furnish it with. We all know that corporate memory can be very inconsistent, but it's to me, it's a whole lot better than starting naively with a blank sheet of paper, being overconfident about what you're able to deliver on when it's inconsistent with what you've been able to deliver on in the past. So AI is not taking over the planet yet, Maybe soon. Who knows? But in the meantime, let's leverage it in smart ways, human in the loop, all that good stuff so that we're using AI as a resource, but not using AI to generate our forecast. I would be very uncomfortable with that, at least at the in this day and age. That risk register. Everybody loves talking about the risk register. It's on your shared project drive called risks.xls as I alluded to before. I believe in many organizations, the risk conversations should start at the enterprise level discussing risks that are specific, not even necessarily to our company, but risks that are specific to our industry. That's a good health check to make sure that we understand what we're getting into. In your industry, there might be global supply chain risk that's very popular right now. Political environment, buying trends. There's no enterprise risk that can be discussed that's too big or too small. I want everyone to have a voice at the table. It doesn't mean we're gonna build everyone's risk into the forecast, but I'd much rather have them discussed and deferred than not discussed at all. In other words, on this last bullet here, we might not ultimately link all of those enterprise risks to individual projects. We might carry them as interesting thoughts, but we want to determine whether or not those individual risks would actually infect an individual project. If we don't do that, we don't have enterprise risk awareness, and we could be naively forecasting and naively executing our projects, which normally leads to those scheduling cost overruns. We need an enter enterprise workflow. We need those risks discussed at the enterprise level to work their way down to the project level. Again, all opinions considered, unfiltered. Nobody wants to inhibit that. I I made this point on the third bullet there. Tailor them to individual projects when applicable. A schedule risk doesn't need to be a cost risk. A cost risk doesn't need to be a schedule risk. A reputation, safety, and quality risk, those can be discussed separately. Not every not everything has to fit into this cost and schedule box, and that's okay. What we don't wanna do is carry any number of risks, hundreds of risks that are unlikely to affect any of the, projects that we're executing or planning to execute. At that point, we're probably misidentifying risks. Let me talk to you about some of the characteristics that I think are important for discrete threats and opportunities and distinguish this process from uncertainty, which we discussed earlier. Threats and opportunities on that risk register have a name that's separate from the names of the activities and the scope of the project. If something is just if a risk is just I'll be really simple here. If the if the risk is just engineering, that's uncertainty that we can apply to the engineering tasks in the schedule. A risk would be like, we're having difficult finding engineers with the skill set that we would need to engineer this project. That's a discrete named labor risk. If there's a a piece of equipment that's important to test our software, equipment or material, and that is prone to breaking down. That's not uncertainty on the activity itself. It could be, but I would rather see that as a risk of equipment failure due to some of the following popular reasons that this equipment breaks. So that when we have the mitigation conversation, we can try to prevent those instances or or reasons, those root causes for the equipment breaking down. Stare into that abyss. When identifying threats, the team should not begin mitigation during the identification process. And the reason I feel that's so important is if we start mitigating when we're identifying the threat, we're going to talk ourselves out of putting that risk on the risk register. We don't even know if it's significant enough to project execution to mitigate yet. Why would we spend time and energy mitigating it until we know if it's even going to lead us to the abyss, lead us to problems later on? Now if it's safety, quality, and reputation, it might be very important to mitigate right away even before it occurs. I totally get that. Discuss it, document it, assess the causes, probabilities, and impacts before having that mitigation conversation. That's staring into the abyss. How bad could it get? We want to assess that full strength and impact. And then for leadership, because they're gonna have to spend on mitigation, we're gonna wanna show them the consequences of unmitigated versus mitigated, put a price tag on it, and see if it's worth it. If it's quality and safety or reputation, it probably is. If it's a five day cost delay potentially due to the risk, we might be able to make that up in other ways. The risk exposure histogram. I am not gonna spend a lot of time on this today. I'm gonna I'm gonna hardly spend any time on this because this is part of that noise that I talked about earlier that can diminish the signal in equality risk briefing. Hey. This is the histogram of project outcomes, dates along the see, I'm already tired of it. It dates along the x axis, the number of hits in the Monte Carlo simulation on the on the y axis. The moment I even say those words, program managers on the line right now, they're like, wait. Stop, man. Like, what do I need to worry about? So, yeah, there's all kinds of different shapes. Call me up. I'll put my email address up on up on the screen at the end. We'll talk about these all afternoon if you want, but I'm not gonna talk about it right now because it's statistics and it's data that's important to developing the forecast, but it's not a briefing. It's not truth and consequences or cause and effect or anything like that. It's an intermediate chart that helps me prepared for a risk briefing, but it's not the risk briefing. I know some of you are using it in risk briefings. You're not doing anything wrong. I'm super glad that if if you're using it in risk briefings, I'm super glad that you're using it, but I'd also recommend with some of the things that I'll show you in a minute or two on how we can lean that out. I'm just gonna move forward here. Schedule margin, this is more technical. The difference between the deterministic date and the planning tool and where we think we're actually going to finish the project with, like, maybe an 80% level of confidence. And they will vary between the two. What you've committed to in your forecast and the 80% case may be different. And if they are, you need to look closely at that. Normally, the 80% confidence level date is later than the date in your planning tool. So you need to look at that gap, that contingency, and say, are there things that we can do today to prevent that seventy five day, fifty five day delta from the deterministic date to the p eighty date from becoming reality. We'd love to finish on the date that we say advertise that we're finishing. But if the 80% case or 90% case is further out in time than that, maybe that should be our forecast. I'm not saying make it your forecast, but see why that date's coming out different. And a great way to do that would be on the tornado chart. Remember, we talked about one of these earlier with my three fears. It was really easy. The lower threats are on the bottom. The higher threats are near the top. The level of magnitude is along the x axis. The name and ranking of the threat is the y axis. It's really easy, and I highly recommend that you do use this chart in a risk briefing. But I'm gonna skip ahead to the second variant here. This is my favorite. Now I know my risk names are really small on the left hand side. I am no PowerPoint genius. I think you've all figured that out by now. I have the named threats on the y axis. If the program manager says to me, Tom, you've talked a lot about risk today. I saw your webinar. I bought the video game, the whole thing. But what do I need to know right now about this tornado chart? My answer is very simple. Let's look at the threat that's named first at the top of the chart. Why? Because it has the highest magnitude. Remember, mine was magnitude of fear. This is magnitude of likely project delay. It can be expressed at days, sensitivity percentage. I like days, weeks, you know, units that make sense to real people. You know which threat to mitigate first. How? Because it's the one on the top of the list. This is the one chart that I recommend using in a risk briefing if you use a chart at all. And I say if you use a chart at all because if I come in to do a risk briefing, I expect to have this memorized. And why defer attention to a chart on the screen if I can say, hey, team. I looked at five items in-depth, but there's two. If you look at those top two, they have kind of a higher order of magnitude than anything else on the screen. I know the numbers are small. I'm just telling you to look at the bar sizes. Those are the two risks that hopefully I can memorize or maybe have a little note card like in school. Say, hey. There's two things that we need to worry about now and stare into the abyss on and see what we can do today. What levers can we move today to prevent those forecasted inconvenient delays on those risks from becoming reality? That can be a very simple conversation. That's the saloon door risk management. The old cowboy movies, I think we've all seen, you know, one, maybe more. They bust through those double doors in the saloon. Hey, everybody. Guess what? You have three seconds to get their attention when you say that. Hey, everybody. Guess what? There's two risks that we need to think about today, right now, and make some decisions on. Otherwise, we should expect some pretty high magnitude delays on this project. And you and I know that scheduled delays are gonna lead to cost delays. This can be brief for cost as well. There it is. This is Salundor risk management. I have this chart. Maybe I have it printed out. Maybe I'll put it up on the projector screen or share it on Teams. Maybe I won't. That's your own style, the urgency of the situation. Explain the chart to the team if necessary. If people aren't sure, hey, everybody. This is less complicated than you think. The top risks with the longer bars are the things that we need to think and talk about the most, or we should expect the highest delays from these items. No PhD in statistics required. It's super, super simple. Is there complicated underlying information that I'll be happy to talk with with you all about at another time? Absolutely. But I'm briefing people on risk that have a lot of things to think about. They don't need all my statistics. They need the bottom line. This chart helps communicate the bottom line. Risk mitigation. I'm I'm not gonna talk about the chart on the right. What I will talk about is when you identifying risks for that risk register, risk.xls or maybe something a little higher performing than that. Risk of major equipment failure. It's one of the examples I used earlier. But look what I did in the example here. Well, how could it fail? Well, you know, it's it's a unique piece of equipment that not a lot of people in the industry have training on. Oh, we have a risk of failure due to insufficient operator training. If we decide to mitigate this risk later on, we look back at the risk register. Well, the the risk on the top of our tornado chart is risk of major equipment failure. Oh, and then there's a note next to it that says due to insufficient operator training. I don't have to be a rocket scientist to say, well, it's our highest risk. Maybe we need to hold some training for that equipment. I didn't just split the atom. I read the risk name off the risk register. So I told you not to mitigate risks while identifying them, but I didn't say not to discuss a root cause of why that risk may be realized. I would love to see all of those root potential root causes on the risk register. Let's talk about that briefing. Remember those saloon doors? Hey, everybody. Guess what? This will vary significantly, depending on the forecast and the official forecast. Meaning, how long are those bars on that tornado chart? There we go. And that's the third bullet. How much you prepare? You can run those tornado charts for different areas of the project. If you're in the, government contracting business, that could be by control account. For commercial, that could be your WBS or other ways that you break out your, break out your work. And, again, that's the Lendoor risk management. Simple, brief, hard hitting remarks. Be prepared for objections. A lot of people don't understand risk and what you're delivering them. You don't change the confidence level dates by, like, going in and changing a date like you might in Excel or something like that. No. No. No. I said no three times. Don't let the risk assessment be treated as just additional program documentation. It's so vital to that forecast. It's not doing risk and then on to other program business. It is risk management is the business of program execution. And sometimes, when talking with project teams, I say this, only when we stare deep into the abyss of future project failures can we truly understand the steps that will be required to prevent a potentially scary future from becoming the reality for our project. So be safe, but be bold when it comes to discussing risk, and don't be afraid to bring up inconvenient things. I don't know if the program manager will thank you later on or not, but you will have a more reliable forecast as a result. Lisa has a couple, notes, for us all as we move towards wrap up today. Here she is. Hey, Lisa. Thanks, Tom. Before we hop into questions, we're gonna just conduct a very brief poll. So, our polling question for today is, would you like to be contacted by a sales representative to see how Deltek PPM can help you achieve improved levels of project success? And to answer your poll the polling question, you will need to go to the polling tab and just, go ahead and choose your answer. So I'll leave this polling question up on the screen for a bit while, Tom, you can probably go ahead and dive into the first question for us today. Sure. While I have you, Lisa, I think I know the answer to this, but I wanna get it straight from you. Will everyone receive a recording of the webinar today? That is one of the questions that came up. Yes. Great question. Yes. Everyone will receive the recording as well as a copy of the slides. Alright. Awesome. Okay. Just looking at the top of the list here from, from John. I know John, pretty well. Once a project goes into execution, what's the suggested frequency of reviewing and updating the risk register and running the risk analysis? So to the extent that it's practical, I would love I I believe I believe the ideal would be every time that we're updating the schedule. When we're updating the forecast, it we're updating the forecast when we update the schedule. My contention is how can I update the forecast without considering a fresh look at risk? Now I know what some people might be thinking. Wow. That sounds very burdensome. Well, with the right tools, it's not burdensome. If we get too far apart from our schedule and execution updates and our risk model, that's where I start getting really nervous really quickly. Next question from Mohammed. Is there a reason or advantage to doing the risk analysis and project execution? I believe that we should be doing it from pre RFP to proposal to project execution. Now if we're 95% done in execution, the the risk assessment might be the wave of a hand and say there are two weeks left in the project and some closeout activities. There's not very much risk. So the incremental workload as we approach project completion will will diminish and get less and less, but I believe there's an advantage for doing it, all throughout. We are one minute, of the, ahead of the top of the hour. So I am gonna call it right there, Lisa. I'm the I'm going to, I'm gonna call it, for the q and a, and we'll turn it back over to you. Okay. Great. Thank you so much, Tom. Really great presentation. So before we officially conclude, we wanna remind you that you'll receive an on demand recording of the of the webinar of today's presentation within twenty four hours. And if we are not able to get to your question, we'll be sure to follow-up with you directly offline. And with that, I'd like to thank you for joining us today. Please visit deltek.com for more upcoming Deltek events. Have a great rest of your day.