So we've planned our project. We've come up with the correct scope. We've come up with the dependencies among the tasks. We've calculated the completion time of our project. So let's start implementing. Let's execute our project. Well, I think we all know that there's something that will prevent us from just digging in. There is a big uncertainty or unknown, associated with how the project will actually take place. And so part of our planning is going to pause after the initial first steps. And think about what risks do we foresee in the execution of our project. And can we plan and amend our plans accordingly in order to better face those risks as they manifest themselves? Well, before we start thinking about the tools that we're going to use in order to incorporate risks and uncertainty into a project plan. Let's try and identify what is the source of the uncertainty and where the risk's coming from as we think about projects and the execution of projects. Using some terminology defined by Christoph Loch and his colleagues when they were working together at INSEAD, we're going to be thinking about uncertainly on several dimensions. First, we're going to think about foreseeable uncertainty. What are the risks that we anticipate our project will face that we can plan for and conceptualize, and we know they are going to occur? Natural variation in the task durations, conditions associated with the weather that might change and might impact the duration and the execution of our project. We may want to think about alternative paths that we may want to take as we conceptualize and think about the future of our project. These are foreseeable uncertainties. Some can be positive uncertainties, and some can be negative. But we can think about them. We can can articulate them. And we can conceptualize how we will deal with them. Another source of uncertainty comes with the complexity of a project. When we have multiple tasks that interact with each other and sometimes in not obvious ways. Or we have stakeholders that might interact with each other and might lead to unknown outcomes, we may have a level of uncertainty that we cannot necessarily plan for. We know it exists. We know it's out there, but we don't exactly know what the setup outcomes might look like, and how likely they are to occur. And so we can't plan a mitigation plan, for instance, if we don't know exactly how an outcome will turn out. But we know that the project is complex, and so we can think about it in that context. And finally, on the most extreme level, we have unforeseeable uncertainties. We have unknowns that are far beyond what we can conceptualize at the start of the project, or the initiation and the planning phase. We're dealing with a very novel technology or a brand new market that we have never experience before. And therefore, we can't even conceptualize the range of outcomes or where they're likely to occur. And therefore, we call these unknown unknowns. Sometimes we can use the following terms to define these degrees of uncertainty. We can think about uncertainty, risks, and ambiguity at the extreme. Ambiguity characterizes those unknown unknowns. What's important for me to highlight is that risks, while they exist in projects, and typically we think about them quite negatively. Risks and uncertainties, or many uncertainties, can offer big promise. If tasks are variable and the outcomes are variable, they can end up in a very positive place, not only on a negative and on the downside. Most of our planning, however, will focus on how we deal with the downside. In order to think about where your firm is, and your specific project on the spectrum of foreseeable uncertainties versus unforeseeable uncertainties, and how complex your project is, you may want to think about a mapping such as this. Consider for instance where you fall in terms of technology uncertainty and demand uncertainty. Technology, identifying the technology of your actual project and what it entails to execute. And demand identifies your clients, your revenue stream, and the typical firm turnover in your space. And so companies that operate in this base of pharma, computer, software industries. These projects are typically considered high uncertainty or high degree of unforeseeable uncertainty, both in terms of technology and in terms of demand. On the other side, on the flip side, projects that have to do with wholesale, utility, banking or construction might sometimes be considered lower risk. We can plan better, we can anticipate what's ahead of us. There is a low level of uncertainty associated with both the demand side and with the technology itself. And so using such a mapping will help us identify where we are in terms of the spectrum of risks that our project is likely to face. The reason it is so important is that the degree of uncertainty that you face in your project will also indicate how useful some of the planning tools are for you. And so if you think about your project, you think about your industry, and you think about the activities that you're about to engage in. Mapping them on the two axis of ambiguity and complexity will allow you to identify the best way forward. And so if your project has few interactions, it is not highly complex. Tasks are either very sequential, or not many stakeholders involved at the same time with your project. Then perhaps you can use a more straightforward planning tools that we've introduced so far. And so when there is low variation in your project, low uncertainty, and few interactions, just straightforward planning will suffice. As we introduce more interactions, more complexity, and there is a high degree of risk introduced from the complexity that our project entails, then we would like to add additional avenues to planning and executing our project. We would like to encourage fast responses, and allow our decision-makers and those who execute in the field to take more authority and react quicker to changes in their working environment. If our ambiguity goes up, and we are dealing with still foreseeable events, and we have few interactions, we can come up with a risk management plan that allows us to plan mitigation, contingencies, and reactions to uncertainties as they unfold during the life cycle of the project. The more we move into the domain of highly complex and highly ambiguous projects with unknown unknowns, or void a novelty that we cannot articulate and plan for and scope out upfront. Then we must include an opportunity for trial and error, for parallel exploration, in order to be able to learn and to gain information about the area of our expertise. And so the traditional project planning tools that we've been focused on so far are going to be less useful in those environment. And scoping will require a different mindset. And the execution that will follow will allow for parallel experimentation. And for mistakes to be made. And for information to be gained. As we move forward, and look, and conceptualize how to plan our risk or how to plan for the risk and uncertainties in our project, remember this mapping. And remember to identify where your project falls in order to come up with the best mitigation plan and the best set of execution rules for your project.
