We've seen how we can take into account uncertainty and variability that we expect in our project duration and our project cost. We've looked at a project plan and we've identified how variability in the individual task completion times might affect our overall project duration. But what if we don't have that information? What if we can't estimate the durations at all, let alone three estimates for the durations? And what if we can't even estimate which tasks to include in our project? What will it take to produce a product? What will the product look like? If we are in the sphere of highly ambiguous projects, an environment with many unknown unknowns to us, new technology, new customers, new market and new opportunities, we may not be able to come up with a plan, let alone conduct some sort of risk analysis that we've done so far. So what do we do? Well, luckily there are tools and there are con, concepts that we can introduce, and we will be discussing, that allow us to deal and to think about how to work in highly ambiguous project settings. Instead of limiting ourselves to a specific plan, and thinking about the steps in a very specific manner, we're going to open the door to conceptualizing a whole roadmap of opportunities, a whole slew of possible outcomes that we might find ourselves and our product might accomplish at the end of the day. And instead of limiting ourselves to very specific tasks and duration, we're going to allow our individual employees, the developers, the engineers to conduct the work themselves and to find out more information that will help us adjust our plans for the project. We will progress in short and smaller durations on a near term basis. We will make little commitment as to how the future might unfold and we will be comfortable with the idea that we might find ourselves in many different final scenarios down the road a year and a half out. In the meantime we will empower individual teams to do short iterations, trial and error, to make decisions for themselves and to come back to us and report successes and opportunities that failed, in order for us to shut some doors and open the new ones. This mindset moves, moves away from the rigid work with the critical path. However, the critical path is important, and higher level senior management might still like to look at it and plan accordingly a company vision and a company strategy. And so there needs to be a communication between the teams on the field that are doing short iterations and quick information gain on each sub-level task, to communicate back to the higher level management what they've learned and how this fits with the vision of the progress of the project for the whole organization. Working in highly ambiguous settings is important to recognize how much, how important it is to gain information, to have our developers and to have those engineers out there working and progressing and gaining knowledge all the time. As we bring the material to a close and we think about the last few sessions that we've had, we identified ways in which we planned for risks, on which we take into account risks in our project planning and how that might inform how we execute our projects as well. We identify as a firm, where we are, how can we characterize our project, and how can we characterize the firm and the industry that we operate in. We identify the degree of complexity and how ambiguous the setting is, and then we choose how to plan and how to execute our project. And in the course of planning our project and before we dive into the execution, we spend some time thinking about our risk, coming up with a management plan, conducting a simulation analysis, or allowing our teams to explore, and setting ourselves up to a situation where we are going to conduct multiple parallel trial and arrow, errors exploration opportunities. Putting these ideas together with a solid plan and a solid risk management approach, we're now set up to start executing projects.
