If you know me, you know that I have spent a great deal of my career building project risk analysis software - Pertmaster (PRA) and Acumen Risk. I am grateful these tools made a positive impact in helping most organizations and project teams improve their schedules and forecasting. When I invented Acumen Risk in 2012, the objective was to design a tool that would literally put me out of a job facilitating project risk workshops. I believed the complexities of traditional Monte Carlo and risk modeling should not be left solely to internal or external risk experts. Instead, the tool should act as a pseudo-facilitator that simplified the entire process and enabled the team to build their own risk models. Fast forward to today, while it’s fair to say that the likes of risk reporting have rapidly progressed through innovative tools, the task of capturing a team member’s expert opinion as an input into a risk model is still a treacherous process. Scheduling is a tricky thing, and the underlying concept of using a duration range as an input isn’t sufficient to truly capture the realism of a plan. Don’t get me wrong, risk software tools are good, in fact, they are really good, but it’s our underlying philosophy towards risk modeling that needs a nudge in the right direction. "The estimate is aggressive, but I will finish early." I recently facilitated a schedule risk workshop using the accepted approach of a 5-point scale for capturing uncertainty (from very conservative through realistic to very aggressive). When talking through the categorization for construction, a team member adamantly stated that the scope was aggressive (i.e., required more time) and so we made the necessary adjustments to the model showing that the duration would more often than not take longer than planned. WRONG. What the team member really believed was that he was actually going to finish his scope in less time but that it was going to be difficult/aggressive for him to do so. So, in fact, the risk model was backwards because we had forced him to think in terms of duration uncertainty whereas in reality, he thought in terms of ‘where am I really going to land?’ Dates or Duration? The Complexity of Knock-On Let me give you another example. For those of you that have facilitated risk workshops, you will know that schedule uncertainty ranges are duration-based and not date-based. How many times have you had to remind the team to think in terms of duration and not dates? Don’t flag construction as aggressive because the finish date is going to be later than the plan suggests. Construction may take less time than planned but may finish later than planned due to delayed preceding scope such as engineering (i.e., knock-on). In order to get your risk model right, you have to model in terms of duration. That’s all very well, but project team members inherently think in terms of dates, not duration. They plan by dates; their performance is tracked by dates; they live and die by dates, and yet we force them to convert dates to durations when capturing their opinion. Add to the mix the complexity of CPM knock-on-effect with logic paths, and the whole thing starts to get a bit silly. Oh, and by the way, when trying to think in terms of duration, make sure you convert working time to remaining Gregorian-based time...seriously? Risk Events versus Uncertainty We invented the concept of separately identifying uncertainty and risk events so that upon completion of analysis and reporting, we can understand whether it’s the plan itself that is unrealistic, or external risk events are impacting our ability to execute on time. Again, back to the risk workshop scenario, how many times have you been reminded to try and categorize the uncertainty of duration without taking into account the impact of risk events (as these will be accounted for in the risk register)? Sounds simple, but in reality, it’s really hard to do. Team-members think in terms of “I am more likely to be early/late (dates) because of poor estimates...or risk events...or knock-on from preceding work.” Trust me; you will get a few raised eyebrows if you really think you can look this team member in the eye and ask them to separate this out into an uncertainty range, and a risk event with a probability and impact value. Pre-mitigated versus Post-mitigated Risk Models (a.k.a. Keeping it real) A project executive once taught me a very valuable lesson about ‘keeping it real.’ I was trying to explain to him the difference between a pre-mitigated and post-mitigated risk scenario that I had built for him. Halfway through my delivery about cost-benefit of risk mitigation, he cut me off and said “Dan, I pay my team to mitigate. Why are you even presenting this scenario to me? My team members are experts in the field, and their job is to inherently mitigate.” I tried to explain that if the team does nothing about the risk, then their exposure would be greater. Putting my risk modeling pride aside, I knew he was right – I was trying to be too clever and arguably too academic with him, rather than giving him a model that reflected reality. Pre-mitigated risk models show extreme risk exposure ranges and aren’t helpful. When capturing uncertainty and risk event impacts from team members, we shouldn’t insult them by asking “What is the range without mitigation?”. We should simply ask, “Based on your expertize and plans in place, do you believe the planned work is achievable?” What are we really trying to establish in a Risk Workshop? I have come to the conclusion we should simply be trying to capture team members’ expert opinion on the realism and achievability of the plan. It boils down to buy-in versus push-back. Risk workshops aren’t risk workshops; they are realism or confidence workshops. End of story. It’s the subsequent analysis and reporting that gives us insight into risk exposure and drivers, etc. Risk workshops are all about establishing how much (or how little) team members buy-in to the plan. If we can somehow capture team member expertise and convert this into the inputs that a CPM and risk analysis tool require, then we get the best of both worlds: - We accurately capture team member opinion without forcing them through a complex process (and just let them think in terms of dates)!
- We still get the benefit from the tried and trusted analysis and powerful reporting that Monte Carlo tools such as PRA and AcumenRisk offer.
Make it Easy for Team Members (those that are experts in the work, but not CPM) So, let team members think how they naturally think. Let them buy-in or push back on dates and not duration. Let them flag concerns and then back this up with reasoning (schedule realism, risk event, or knock-on effect). Let’s also take into account consensus (or lack thereof)! Wouldn’t it be valuable to know the differences in opinion of team members? In fact, shouldn’t those differences in opinion drive the range of uncertainty that we then plug into our risk model This is why we created BASIS To help with this process, we have developed a tool called BASIS. BASIS is designed to both calibrate and validate project plans and risk models. Calibration through AI (Artificial Intelligence) BASIS uses captured planning knowledge (e.g., previous projects or standards) to calibrate your plan, establishing a realistic baseline that the team can then review during a risk workshop. Through some very clever Artificial Intelligence, BASIS literally benchmarks your plan in real-time so that you can be confident that the plan you are about to run a risk analysis on is as realistic as possible. Not only that, but it also tells you where you should focus your efforts on identifying risks. Using historical experiences, it makes suggestions as to common risks relative to the scope of work. Pretty clever stuff and very useful in terms of making sure you don’t miss anything in your risk workshop. Validation through HI (Human Intelligence) Once you’ve established that your plan is a realistic forecast, you then need your team to review it and either buy-in or push back. This then becomes the basis for your risk model. To make this process easy and meaningful, BASIS offers team members the ability to review and markup the schedule in their own personal markup layer. Not only that, they get to think in terms of dates, and not get caught up in the weeds of calendars, constraints, working time versus non-working time, etc. Tied to this, BASIS then conducts an automatic consensus analysis enabling the project planner or risk facilitator to pinpoint areas of disagreement versus those areas where the team carry a consensus. It’s okay to raise concerns about the schedule, but if the team members have wildly differing opinions, then you have a serious problem with buy-in. Conclusion As I stated in the introduction, today’s risk analysis tools are really good at what they do – analysis. The challenge lies in the fact that risk analysis is built on CPM, and that in turn requires inputs (durations, logic, ranges, calendars) that are very different to how team members think and operate on a daily basis. What is missing is the 'translator' that enables team members to articulate their confidence or buy-in (or lack thereof) into a project schedule and have that translated into the building blocks that CPM/risk analysis tools require. That missing link is exactly what we are building in BASIS. Let CPM tools do CPM; let risk analysis tools run Monte Carlo simulations, but most importantly, let those who understand the project most articulate to you (in their terms) their belief or buy-in to the schedule. Having such harmony between tools and team members will continue to improve the science of schedule forecasting. | 
