Our risk exposure starts at the beginning of the project. Even before the project is actually a project.  The simple act of scoping a project in the initiating phase already alludes to the risks to which we may be exposed. For example, the minute we decide that our project scope is going to include software, we now know that risk associated with software projects are part of our future risk activities.  For a successful outcome to our project, our strategy for the project will need to include aspects that will mitigate or reduce these risks.

Let us consider scope first.  In an attempt to achieve synergies, or save money we often see the loading up of a project scope and objectives.  Sometimes this is possible we can achieve multiple objectives with efficacy provided there is enough cohesion in the objectives that allow formulation of a strategy to accomplish.  Typically, this disparity of scope and objective actually reduce our probability of success. Consider the story where an organization has a project to update their product line to meet a hard and fast government mandate. Success for this project scope means delivering a product that meets the regulations at a fixed date.  It would be in our best interest not to attach any other project work that requires development to achieve the “synergies” we seek. Why, you may ask?  Development projects very often require learning and adaptation.  The end date for development projects needs to be flexible as we explore, learn and adjust our product or system until we are comfortable that the risks do not exceed the reward for delivering the project objective.  Unless we start the development project well in advance of the mandate, we run the risk of having our development work risk the introduction date as we are still learning at the time we are supposed to launch and meet the delivery date.  If we launch, it will be with a partially developed product with intrinsic feature and quality problems, or we miss the regulatory mandate.  Either way, we lose.  If we have a fixed date type of project, we need to map other project scope that works well with a fixed introduction date strategy.  Mixing these types of projects compromises or risks the other.

Even when we have selected the correct product scope, or mixture of projects to produce a viable program, we have risk aplenty in our selection of strategy and tactics for our project.  We should explore the variety of approaches available to use to ascertain the levels of risks associated with each proposal.  This is not as difficult as it may seem. We can use decision-making matrix populated with important metrics for our project.  This need not be as complicated as a Pugh matrix but can be a simple list of the attributes we deem important in the project comparing the different approaches to those success attributes.  We will discuss and demonstrate these techniques further in the upcoming Risk Management Event.