project management case study

A project is a finite endeavor (having specific start and completion dates) that requires the organization and coordination of a group of two or more people, to create a unique product or service which brings about beneficial change or added value. This finite characteristic of projects stands in sharp contrast to processes, or operations, which are permanent or semi-permanent functional work to repetitively produce the same product or service. In practice, the management of these two systems is often found to be quite different, and as such requires the development of distinct technical skills and the adoption of separate management Project management is the discipline of planning, organizing and managing resources to bring about the successful completion of specific project goals and objectives. Project management PM is a business process of the project-oriented company. The PM process starts with the project assignment and ends with the project approval. It consists of the sub-processes project start, project co-ordination, project controlling, project discontinuity management and project close-down. The primary challenge of project management is to achieve all of the project goals and objectives while honoring the project constraints. Typical constraints are scope, time and budget. The secondary—and more ambitious—challenge is to optimize the allocation and integration of inputs necessary to meet pre-defined objectives. Project development stages

The project development stages. Traditionally, project development includes a number of elements: four to five stages, and a control system. Regardless of the methodology used, the project development process will have the same major stages: • • • • •

initiation, planning or development, production or execution, monitoring and controlling, and closing.

Initiation

Initiating Process Group Processes. The initiation stage determines the nature and scope of the development. If this stage is not performed well, it is unlikely that the project will be successful in meeting the business’s needs. The key project controls needed here are an understanding of the business environment and making sure that all necessary controls are incorporated into the project. Any deficiencies should be reported and a recommendation should be made to fix them. The initiation stage should include a cohesive plan that encompasses the following areas: • • • • • • •

Study analyzing the business needs in measurable goals. Review of the current operations. Conceptual design of the operation of the final product. Equipment and contracting requirements including an assessment of 'long-lead' items. Financial analysis of the costs and benefits including a budget. Stakeholder analysis, including users, and support personnel for the project. Project charter including costs, tasks, deliverables, and schedule.

Planning and design

Planning Process Group Activities. After the initiation stage, the system is designed. Occasionally, a small prototype of the final product is built and tested. Testing is generally performed by a combination of testers and end users, and can occur after the prototype is built or concurrently. Controls should be in place that ensure that the final product will meet the specifications of the project charter. The results of the design stage should include a product design that: • • • •

Satisfies the project sponsor, end user, and business requirements. Functions as it was intended. Can be produced within quality standards. Can be produced within time and budget constraints.

Executing

Executing Process Group Processes. Executing consists of the processes used to complete the work defined in the project management plan to accomplish the project's requirements. Execution process involves coordinating people and resources, as well as integrating and performing the activities of the project in accordance with the project management plan. The deliverables are produced as outputs from the processes performed as defined in the project management plan. Monitoring and Controlling Monitoring and Controlling consists of those processes performed to observe project execution so that potential problems can be identified in a timely manner and corrective action can be taken, when necessary, to control the execution of the project. The key benefit is that project performance is observed and measured regularly to identify variances from the project management plan.

Monitoring and Controlling Process Group Processes.

Monitoring and Controlling includes: • •

Measuring the ongoing project activities (where we are); Monitoring the project variables (cost, effort, ...) against the project management plan and the project performance baseline (where we should be);

• •

Identify corrective actions to properly address issues and risks (How can we get on track again); Influencing the factors that could circumvent integrated change control so only approved changes are implemented

In multi-phase projects, the Monitoring and Controlling process also provides feedback between project phases, in order to implement corrective or preventive actions to bring the project into compliance with the project management plan. Project Maintenance is an ongoing process, and it includes: • • •

Continuing support of end users Correction of errors Updates of the software over time

Monitoring and Controlling cycle In this stage, auditors should pay attention to how effectively and quickly user problems are resolved. Over the course of any construction project, the work scope changes. Change is a normal and expected part of the construction process. Changes can be the result of necessary design modifications, differing site conditions, material availability, contractor-requested changes, value engineering and impacts from third parties, to name a few. Beyond executing the change in the field, the change normally needs to be documented to show what was actually constructed. This is referred to as Change Management. Hence, the owner usually requires a final record to show all changes or, more specifically, any change that modifies the tangible portions of the finished work. The record is made on the contract documents – usually, but not necessarily limited to, the design drawings. The end product of this effort is what the industry terms as-built drawings, or more simply, “asbuilts.” The requirement for providing them is a norm in construction contracts. When changes are introduced to the project the viability of the project has to be assessed again. It is important not to lose sight of the initial goals and targets of the projects. When the changes accumulate, the forecasted end result may not justify the proposed investment. Closing

Closing Process Group Processes. Closing includes the formal acceptance of the project and the ending thereof. Administrative activities include the archiving of the files and documenting lessons learned. Closing phase consist of two parts: • •

Close project: to finalize all activities across all of the process groups to formally close the project or a project phase Contract closure: necessary for completing and settling each contract, including the resolution of any open items, and closing each contract applicable to the project or a project phase.

Understanding Risk and Uncertainty Uncertainty Uncertainty is defined as an absence of information,knowledge, or understanding regarding the outcome of an action, decision, or event. Project managers constantly suffer from an absence of information, knowledge, or understanding. Risk Risk is actually a measure of the amount of uncertainty that exists. It’s directly tied to information. This is not exactly the way most of us think about risk in everyday situations. However, in the world of project management, risk relates primarily to the extent of your ability to predict a particular outcome with certainty. This interpretation is Amount of Risk

derived from the study of decision and risk analysis, the statistical sibling to project risk management

Threat :-The effects of risk can be positive or negative. Positive effects of risk are often referred to as opportunities. Threats are the negative—or “downside”—effects of risk. Threats are specific events that drive your project in the direction of outcomes viewed as unfavorable (e.g., schedule delays, cost overruns, and inferior product performance).

Graphical representation of threat ratings

Responding to High-Threat Problems There are a number of ways to address the high-threat problems you identify. Let’s examine all of the options for dealing with risk and potential problems: Avoidance. In avoidance, you choose a course of action that eliminates your exposure to the threat. This often means that you’re now pursuing a completely different course from what you’d originally planned. The space shuttle program provides an excellent study in avoidance. Many flights are carefully planned and then, because of marginal weather conditions, scrubbed. Delaying the takeoff of a space shuttle mission because of a weather threat is a perfect example of risk avoidance. Transfer. The most widely quoted example of risk transfer is something we’re all very familiar with—insurance. Risk transfer does not “treat” the risk; it simply makes another party responsible for the consequences of the risk.

Assumption. This means that you are aware of the risk, but choose to take no action on it. You’re agreeing to accept its consequences or to simply deal with them if it happens. That’s essentially how you’re treating threats that fall below the threat rating described above. Assumption is also a valid strategy in situations where the consequences of the risk are less costly and/or less traumatic than the effort required to prevent it. Prevention. Prevention refers to action taken to reduce the probability of occurrence of a potential problem. Ordinarily, it will be your first course of action in dealing with highthreat problems. Prevention begins with identifying the root causes of potential problems. Determining root cause may allow you to identify preventive measures that could reduce the probability that a given problem will occur. Be sure to revise the project plan to incorporate any preventive actions that you intend to take, so that they’re not overlooked or forgotten. Mitigation of Impact. This strategy aims at reducing the negative effects of a problem. You’re taking measures to lessen the impact. For example, installing air bags in automobiles does nothing to reduce the probability of accidents, but it may significantly reduce the effects. It’s important to note that mitigation tactics may be viewed as a waste of time, money, and effort, if the potential problem does not occur. Contingency Planning. Contingency plans are specific actions that are to be taken when a potential problem occurs. Although they’re intended to deal with problems only after they’ve occurred, contingency plans should be developed in advance. This helps ensure a coordinated, effective, and timely response. Also, some plans may require backup resources that need to be arranged for in advance. Contingency planning should be done only for the high-threat problems that remain after you’ve taken preventive measures.

Risk assessment The combination of risk identification and risk quantification. The primary output of a risk assessment is a list of specific potential problems or threats.

Common risks encountered on projects

Risk management Definitions of project risk The degree of likelihood that a project will not be completed on schedule and within budget or that a loan will not be repaid. Definitions of project risk management Project risk management is a structured process that allows individual risk events and overall project risk to be understood and managed Managing Risk: An Overview Many approaches can be used to address risk and the threats it produces. However, most processes for managing risk tend to follow some variation of this basic four-step approach: Step 1. Identification (determining what threats exist). Identify all significant uncertainties (sources of risk), including specific threats (also called potential problems or risk events) that could occur throughout the life of the project. Step 2. Quantification (determining how big the threats are). Obtain information on the range of possible outcomes for all uncertainties and their distribution and/or probabilities of occurrence, to better understand the nature of the threats and their potential effects on the project. Step 3. Analysis (determining which threats are of greatest concern). Use the knowledge gained through risk assessment to determine which potential problems represent the greatest danger to achieving a successful and predictable project outcome, ordinarily by considering the probability that a specific problem will occur and its anticipated impact on the project. Step 4. Response (dealing with the threats). Determine the best approaches for addressing each high-threat potential problem, which may include evaluating and choosing among a number of alternatives, and create specific action plans. Nature or Extent of the Effect. Let’s say that the same strike could cause “a schedule delay.” How much of a delay? A week? Two weeks? A month? Will the project necessarily be delayed by that same amount? When gathering insight on the nature and extent of problems and their effects, you’ll have to rely on several sources, including the following: • Survey data (preference, opinion, etc.) • Historical data • Product specification sheets • Mockup, simulation, or testing • Subject matter expert (SME) judgment

Areas of risk management As applied to corporate finance, risk management is the technique for measuring, monitoring and controlling the financial or operational risk on a firm's balance sheet. See value at risk. The Basel II framework breaks risks into market risk (price risk), credit risk and operational risk and also specifies methods for calculating capital requirements for each of these components. Risk-management activities as applied to project management In project management, risk management includes the following activities: • •

•

• •

•

Planning how risk will be managed in the particular project. Plan should include risk management tasks, responsibilities, activities and budget. Assigning a risk officer - a team member other than a project manager who is responsible for foreseeing potential project problems. Typical characteristic of risk officer is a healthy skepticism. Maintaining live project risk database. Each risk should have the following attributes: opening date, title, short description, probability and importance. Optionally a risk may have an assigned person responsible for its resolution and a date by which the risk must be resolved. Creating anonymous risk reporting channel. Each team member should have possibility to report risk that he foresees in the project. Preparing mitigation plans for risks that are chosen to be mitigated. The purpose of the mitigation plan is to describe how this particular risk will be handled – what, when, by who and how will it be done to avoid it or minimize consequences if it becomes a liability. Summarizing planned and faced risks, effectiveness of mitigation activities, and effort spent for the risk management.

Risk management and business continuity Risk management is simply a practice of systematically selecting cost effective approaches for minimising the effect of threat realization to the organization. All risks can never be fully avoided or mitigated simply because of financial and practical limitations. Therefore all organizations have to accept some level of residual risks. Whereas risk management tends to be preemptive, business continuity planning (BCP) was invented to deal with the consequences of realised residual risks. The necessity to have BCP in place arises because even very unlikely events will occur if given enough time. Risk management and BCP are often mistakenly seen as rivals or overlapping practices. In fact these processes are so tightly tied together that such separation seems artificial. For example, the risk management process creates important inputs for the BCP (assets, impact assessments, cost estimates etc). Risk management also proposes applicable controls for the observed risks. Therefore, risk management covers several areas that are vital for the BCP process. However, the BCP process goes beyond risk

management's preemptive approach and moves on from the assumption that the disaster will realize at some point. Risk management is activity directed towards the assessing, mitigating (to an acceptable level) and monitoring of risks. In some cases the acceptable risk may be near zero. Risks can come from accidents, natural causes and disasters as well as deliberate attacks from an adversary. The main ISO standards on risk management include. In businesses, risk management entails organized activity to manage uncertainty and threats and involves people following procedures and using tools in order to ensure conformance with risk-management policies. The strategies include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk

Principles of risk management The International Organization for Standardization identifies the following principles of risk management: • • • • • • • • • • •

Risk management should create value. Risk management should be an integral part of organizational processes. Risk management should be part of decision making. Risk management should explicitly address uncertainty. Risk management should be systematic and structured. Risk management should be based on the best available information. Risk management should be tailored. Risk management should take into account human factors. Risk management should be transparent and inclusive. Risk management should be dynamic, iterative and responsive to change. Risk management should be capable of continual improvement and enhancement.

Process According to the standard ISO/DIS 31000 "Risk management -- Principles and guidelines on implementation", the process of risk management consists of several steps as follows: Establishing the context Establishing the context involves 1. Identification of risk in a selected domain of interest 2. Planning the remainder of the process. 3. Mapping out the following: o the social scope of risk management o the identity and objectives of stakeholders o the basis upon which risks will be evaluated, constraints. 4. Defining a framework for the activity and an agenda for identification. 5. Developing an analysis of risks involved in the process. 6. Mitigation of risks using available technological, human and organizational resources. Identification After establishing the context, the next step in the process of managing risk is to identify potential risks. Risks are about events that, when triggered, cause problems. Hence, risk identification can start with the source of problems, or with the problem itself.

•

•

Source analysis Risk sources may be internal or external to the system that is the target of risk management. Examples of risk sources are: stakeholders of a project, employees of a company or the weather over an airport. Problem analysis Risks are related to identified threats. For example: the threat of losing money, the threat of abuse of privacy information or the threat of accidents and casualties. The threats may exist with various entities, most important with shareholders, customers and legislative bodies such as the government.

When either source or problem is known, the events that a source may trigger or the events that can lead to a problem can be investigated. For example: stakeholders withdrawing during a project may endanger funding of the project; privacy information may be stolen by employees even within a closed network; lightning striking a Boeing 747 during takeoff may make all people onboard immediate casualties. The chosen method of identifying risks may depend on culture, industry practice and compliance. The identification methods are formed by templates or the development of templates for identifying source, problem or event. Common risk identification methods are: •

•

•

•

Objectives-based risk identification Organizations and project teams have objectives. Any event that may endanger achieving an objective partly or completely is identified as risk. Scenario-based risk identification In scenario analysis different scenarios are created. The scenarios may be the alternative ways to achieve an objective, or an analysis of the interaction of forces in, for example, a market or battle. Any event that triggers an undesired scenario alternative is identified as risk Taxonomy-based risk identification The taxonomy in taxonomy-based risk identification is a breakdown of possible risk sources. Based on the taxonomy and knowledge of best practices, a questionnaire is compiled. The answers to the questions reveal risks.. Common-risk checking In several industries lists with known risks are available. Each risk in the list can be checked for application to a particular situation. An example of known risks in the software industry is the Common Vulnerability and Risk charting (risk mapping) This method combines the above approaches by listing Resources at risk, Threats to those resources Modifying Factors which may increase or decrease the risk and Consequences it is wished to avoid. Creating a matrix under these headings enables a variety of approaches. One can begin with resources and consider the threats they are exposed to and the consequences of each. Alternatively one can start with the threats and examine which resources they would affect, or one can begin with the consequences and determine which combination of threats and resources would be involved to bring them about.

Assessment Once risks have been identified, they must then be assessed as to their potential severity of loss and to the probability of occurrence. These quantities can be either simple to measure, in the case of the value of a lost building, or impossible to know for sure in the case of the probability of an unlikely event occurring. Therefore, in the assessment

process it is critical to make the best educated guesses possible in order to properly prioritize the implementation of the risk management plan. The fundamental difficulty in risk assessment is determining the rate of occurrence since statistical information is not available on all kinds of past incidents. Furthermore, evaluating the severity of the consequences (impact) is often quite difficult for immaterial assets. Asset valuation is another question that needs to be addressed. Thus, best educated opinions and available statistics are the primary sources of information. Nevertheless, risk assessment should produce such information for the management of the organization that the primary risks are easy to understand and that the risk management decisions may be prioritized. Thus, there have been several theories and attempts to quantify risks. Numerous different risk formulae exist, but perhaps the most widely accepted formula for risk quantification is: Rate of occurrence multiplied by the impact of the event equals risk Later research has shown that the financial benefits of risk management are less dependent on the formula used but are more dependent on the frequency and how risk assessment is performed. Potential risk treatments Once risks have been identified and assessed, all techniques to manage the risk fall into one or more of these four major categories: • • • •

Avoidance (eliminate) Reduction (mitigate) Transfer (outsource or insure) Retention (accept and budget)

Ideal use of these strategies may not be possible. Some of them may involve trade-offs that are not acceptable to the organization or person making the risk management decisions. Risk avoidance Includes not performing an activity that could carry risk. An example would be not buying a property or business in order to not take on the liability that comes with it. Another would be not flying in order to not take the risk that the airplanes were to be hijacked. Avoidance may seem the answer to all risks, but avoiding risks also means losing out on the potential gain that accepting (retaining) the risk may have allowed. Not entering a business to avoid the risk of loss also avoids the possibility of earning profits. Risk reduction Involves methods that reduce the severity of the loss or the likelihood of the loss from occurring. For example, sprinklers are designed to put out a fire to reduce the risk of loss by fire. This method may cause a greater loss by water damage and therefore may not be

suitable. Halon fire suppression systems may mitigate that risk, but the cost may be prohibitive as a strategy. Modern software development methodologies reduce risk by developing and delivering software incrementally. Early methodologies suffered from the fact that they only delivered software in the final phase of development; any problems encountered in earlier phases meant costly rework and often jeopardized the whole project. By developing in iterations, software projects can limit effort wasted to a single iteration. Outsourcing could be an example of risk reduction if the outsourcer can demonstrate higher capability at managing or reducing risks. In this case companies outsource only some of their departmental needs. Risk retention Involves accepting the loss when it occurs. True self insurance falls in this category. Risk retention is a viable strategy for small risks where the cost of insuring against the risk would be greater over time than the total losses sustained. All risks that are not avoided or transferred are retained by default. This includes risks that are so large or catastrophic that they either cannot be insured against or the premiums would be infeasible. War is an example since most property and risks are not insured against war, so the loss attributed by war is retained by the insured. Also any amounts of potential loss (risk) over the amount insured is retained risk. This may also be acceptable if the chance of a very large loss is small or if the cost to insure for greater coverage amounts is so great it would hinder the goals of the organization too much. Risk transfer In the terminology of practitioners and scholars alike, the purchase of an insurance contract is often described as a "transfer of risk." However, technically speaking, the buyer of the contract generally retains legal responsibility for the losses "transferred", meaning that insurance may be described more accurately as a post-event compensatory mechanism. For example, a personal injuries insurance policy does not transfer the risk of a car accident to the insurance company. The risk still lies with the policy holder namely the person who has been in the accident. The insurance policy simply provides that if an accident (the event) occurs involving the policy holder then some compensation may be payable to the policy holder that is commensurate to the suffering/damage. Some ways of managing risk fall into multiple categories. Risk retention pools are technically retaining the risk for the group, but spreading it over the whole group involves transfer among individual members of the group. This is different from traditional insurance, in that no premium is exchanged between members of the group up front, but instead losses are assessed to all members of the group. Create a risk-management plan Select appropriate controls or countermeasures to measure each risk. Risk mitigation needs to be approved by the appropriate level of management. For example, a risk

concerning the image of the organization should have top management decision behind it whereas IT management would have the authority to decide on computer virus risks. The risk management plan should propose applicable and effective security controls for managing the risks. For example, an observed high risk of computer viruses could be mitigated by acquiring and implementing antivirus software. A good risk management plan should contain a schedule for control implementation and responsible persons for those actions. Implementation Follow all of the planned methods for mitigating the effect of the risks. Purchase insurance policies for the risks that have been decided to be transferred to an insurer, avoid all risks that can be avoided without sacrificing the entity's goals, reduce others, and retain the rest. Review and evaluation of the plan Initial risk management plans will never be perfect. Practice, experience, and actual loss results will necessitate changes in the plan and contribute information to allow possible different decisions to be made in dealing with the risks being faced.

10 Golden Rules of Project Risk Management

The benefits of risk management in projects are huge. You can gain a lot of money if you deal with uncertain project events in a proactive manner. The result will be that you minimise the impact of project threats and seize the opportunities that occur. This allows you to deliver your project on time, on budget and with the quality results your project sponsor demands. Also your team members will be much happier if they do not enter a "fire fighting" mode needed to repair the failures that could have been prevented. The 10 golden rules to apply risk management successfully in your project. They are based on personal experiences of the author who has been involved in projects for over 15 years. Rule 1: Make Risk Management Part of Your Project The first rule is essential to the success of project risk management. If you don't truly embed risk management in your project, you can not reap the full benefits of this approach. You can encounter a number of faulty approaches in companies. Some projects use no approach whatsoever to risk management. They are either ignorant, running their first project or they are somehow confident that no risks will occur in their project (which of course will happen). Some people blindly trust the project manager, especially if he (usually it is a man) looks like a battered army veteran who has been in the trenches for the last two decades. Professional companies make risk management part of their day to day operations and include it in project meetings and the training of staff. Rule 2: Identify Risks Early in Your Project The first step in project risk management is to identify the risks that are present in your project. This requires an open mind set that focuses on future scenarios that may occur. Two main sources exist to identify risks, people and paper. People are your team members that each bring along their personal experiences and expertise. Other people to talk to are experts outside your project that have a track record with the type of project or work you are facing. They can reveal some booby traps you will encounter or some golden opportunities that may not have crossed your mind. Interviews and team sessions (risk brainstorming) are the common methods to discover the risks people know. Paper is a different story. Projects tend to generate a significant number of (electronic) documents that contain project risks. They may not always have that name, but someone who reads carefully (between the lines) will find them. The project plan, business case and resource planning are good starters. Another categories are old project plans, your company Intranet and specialised websites.

Are you able to identify all project risks before they occur? Probably not. However if you combine a number of different identification methods, you are likely to find the large majority. If you deal with them properly, you have enough time left for the unexpected risks that take place. Rule 3: Communicate About Risks Failed projects show that project managers in such projects were frequently unaware of the big hammer that was about to hit them. The frightening finding was that frequently someone of the project organisation actually did see that hammer, but didn't inform the project manager of its existence. If you don't want this to happen in your project, you better pay attention to risk communication. A good approach is to consistently include risk communication in the tasks you carry out. If you have a team meeting, make project risks part of the default agenda (and not the final item on the list!). This shows risks are important to the project manager and gives team members a "natural moment" to discuss them and report new ones. Another important line of communication is that of the project manager and project sponsor or principal. Focus your communication efforts on the big risks here and make sure you don't surprise the boss or the customer! Also take care that the sponsor makes decisions on the top risks, because usually some of them exceed the mandate of the project manager. Rule 4: Consider Both Threats and Opportunities Project risks have a negative connotation: they are the "bad guys" that can harm your project. However modern risk approaches also focus on positive risks, the project opportunities. These are the uncertain events that beneficial to your project and organisation. These "good guys" make your project faster, better and more profitable. Unfortunately, lots of project teams struggle to cross the finish line, being overloaded with work that needs to be done quickly. This creates project dynamics where only negative risks matter (if the team considers any risks at all). Make sure you create some time to deal with the opportunities in your project, even if it is only half an hour. Chances are that you see a couple of opportunities with a high pay-off that don't require a big investment in time or resources. Rule 5: Clarify Ownership Issues Some project managers think they are done once they have created a list with risks. However this is only a starting point. The next step is to make clear who is responsible for what risk! Someone has to feel the heat if a risk is not taken care of properly. The trick is simple: assign a risk owner for each risk that you have found. The risk owner is the person in your team that has the responsibility to optimise this risk for the project. The effects are really positive. At first people usually feel uncomfortable that they are actually responsible for certain risks, but as time passes they will act and carry out tasks to decrease threats and enhance opportunities.

Ownership also exists on another level. If a project threat occurs, someone has to pay the bill. This sounds logical, but it is an issue you have to address before a risk occurs. Especially if different business units, departments and suppliers are involved in your project, it becomes important who bears the consequences and has to empty his wallet. An important side effect of clarifying the ownership of risk effects, is that line managers start to pay attention to a project, especially when a lot of money is at stake. The ownership issue is equally important with project opportunities. Fights over (unexpected) revenues can become a long-term pastime of management. Rule 6: Prioritise Risks A project manager once told me "I treat all risks equally." This makes project life really simple. However, it doesn't deliver the best results possible. Some risks have a higher impact than others. Therefore, you better spend your time on the risks that can cause the biggest losses and gains. Check if you have any showstoppers in your project that could derail your project. If so, these are your number 1 priority. The other risks can be prioritised on gut feeling or, more objectively, on a set of criteria. The criteria most project teams use is to consider the effects of a risk and the likelihood that it will occur. Whatever prioritisation measure you use, use it consistently and focus on the big risks. Rule 7: Analyse Risks Understanding the nature of a risk is a precondition for a good response. Therefore take some time to have a closer look at individual risks and don't jump to conclusions without knowing what a risk is about. Risk analysis occurs at different levels. If you want to understand a risk at an individual level it is most fruitful to think about the effects that it has and the causes that can make it happen. Looking at the effects, you can describe what effects take place immediately after a risk occurs and what effects happen as a result of the primary effects or because time elapses. A more detailed analysis may show the order of magnitude effect in a certain effect category like costs, lead time or product quality. Another angle to look at risks, is to focus on the events that precede a risk occurrence, the risk causes. List the different causes and the circumstances that decrease or increase the likelihood. Another level of risk analysis is investigate the entire project. Each project manager needs to answer the usual questions about the total budget needed or the date the project will finish. If you take risks into account, you can do a simulation to show your project sponsor how likely it is that you finish on a given date or within a certain time frame. A similar exercise can be done for project costs. The information you gather in a risk analysis will provide valuable insights in your project and the necessary input to find effective responses to optimise the risks. Rule 8: Plan and Implement Risk Responses Implementing a risk response is the activity that actually adds value to your project. You prevent a threat occurring or minimise negative effects. Execution is key here. The other

rules have helped you to map, prioritise and understand risks. This will help you to make a sound risk response plan that focuses on the big wins. If you deal with threats you basically have three options, risk avoidance, risk minimisation and risk acceptance. Avoiding risks means you organise your project in such a way that you don't encounter a risk anymore. This could mean changing supplier or adopting a different technology or, if you deal with a fatal risk, terminating a project. Spending more money on a doomed project is a bad investment. The biggest category of responses are the ones to minimise risks. You can try to prevent a risk occurring by influencing the causes or decreasing the negative effects that could result. If you have carried out rule 7 properly (risk analysis) you will have plenty of opportunities to influence it. A final response is to accept a risk. This is a good choice if the effects on the project are minimal or the possibilities to influence it prove to be very difficult, time consuming or relatively expensive. Just make sure that it is a conscious choice to accept a certain risk. Responses for risk opportunities are the reverse of the ones for threats. They will focus on seeking risks, maximising them or ignoring them (if opportunities prove to be too small). Rule 9: Register Project Risks This rule is about bookkeeping (however don't stop reading). Maintaining a risk log enables you to view progress and make sure that you won't forget a risk or two. It is also a perfect communication tool that informs your team members and stakeholders what is going on (rule 3). A good risk log contains risks descriptions, clarifies ownership issues (rule 5) and enables you to carry our some basic analyses with regard to causes and effects (rule 7). Most project managers aren't really fond of administrative tasks, but doing your bookkeeping with regards to risks pays off, especially if the number of risks is large. Some project managers don't want to record risks, because they feel this makes it easier to blame them in case things go wrong. However the reverse is true. If you record project risks and the effective responses you have implemented, you create a track record that no one can deny. Even if a risk happens that derails the project. Doing projects is taking risks. Rule 10: Track Risks and Associated Tasks The risk register you have created as a result of rule 9, will help you to track risks and their associated tasks. Tracking tasks is a day-to-day job for each project manager. Integrating risk tasks into that daily routine is the easiest solution. Risk tasks may be carried out to identify or analyse risks or to generate, select and implement responses. Tracking risks differs from tracking tasks. It focuses on the current situation of risks. Which risks are more likely to happen? Has the relative importance of risks changed? Answering this questions will help to pay attention to the risks that matter most for your project value.

The 10 golden risk rules above give you guidelines on how to implement risk management successfully in your project. However, keep in mind that you can always improve. Therefore rule number 11 would be to use the Japanese Kaizen approach: measure the effects of your risk management efforts and continuously implement improvements to make it even better.

Four steps for reducing project risk Whether it's small or large, complex or simple, every project has risk. It's our job as managers to do our best to not only minimize the risk in our projects but to minimize it as soon as we can. In this article, you'll learn a simple four-step approach for doing just that. Inventory The first step to managing the risk of a project is to inventory the situation. That is, identify all of the risks that you think are possible in the project. The inventory should include all internal factors for the project such as resource changes, assumption failures, and sponsor availability. It should also include all external factors such as a change in company direction or a change of technology direction. Most of all, however, it should include the things that are new in the project. If the project is working with a new technology, is using a new development methodology, or even if there are new, relatively unknown team members, these need to be listed as potential risks to the project. The purpose of the inventory phase isn't to classify the risk or identify its importance. That step happens later. The goal is to collect all the risks. If you mix in the process of evaluating the risk you’ll find that you won’t get a complete inventory of the potential risks for the project. Staying focused on capturing risks is essential to the process. Evaluate Once you have a complete list of potential risks, it’s time to evaluate them. Each risk should be evaluated based both on its probability and on the impact that it would cause if it happens. The loss of a key team member may have a low probability; however, the impact to the project can be great. Some people struggle with the evaluation step because both of the numbers, percentage and impact, are guesses. They recognize that even subtle changes in the values for these numbers can have a huge impact on the total risk of the project. However, in general, the objective here isn’t to come up with a single number that represents each risk. The objective is to develop a framework for evaluating the various risks against one another. Although precision in the estimating process is useful it's not essential. The other factor to evaluate when looking at a risk is its duration--how long that it can have a potential impact on the project. For instance, the loss of a subject matter expert early in the project is a risk because their input is still needed. However, later in the

project they may not have much input and therefore aren't a risk if they leave.The risk of a functional analyst leaving is greatest in the initial phases of the project when they are intensively interacting with the customer. Later on in the project, the loss of the functional analyst has a smaller potential impact for the project. In order to get a consistent number for all of the risks, multiply the probability which should be per interval of duration by the impact and finally multiply that by the duration. The resulting number is a single number, a risk quotient, which can be used to prioritize risks within the project. For instance, if the probability of the risk happening in a given week is 10%, the number of weeks the risk may happen is 10 weeks, and the impact is $1000, the overall risk is $1000. (.10*10*1000 = 1000) Prioritize Now that you have a single risk quotient for the various risks, it's possible to prioritize the risks for the project. It can give you a clear vision of what the risks are and which ones you'll ultimately need to be concerned about. This is also a part of the process that typically helps validate the estimates made above. For instance, if your greatest risk is personnel turnover (as it usually is) you may want to more objectively evaluate the probability. If the average person stays at your organization for three years you can assume a probability of them leaving in a given week is 1/156 (3x52 weeks/year) which is a 0.00641 percent chance. Control and mitigate Once the risks are prioritized you can go through the list and identify which risks are controllable, which risks are things that can be mitigated, and which risks must be accepted. For instance, the risk of loosing key personnel can be mitigated by providing completion bonuses or even just monitoring their happiness more closely. Technical risks can be controlled by moving them forward in the project so that they are proven out nearly immediately. In general, the fastest way to reduce the overall risk quotient for a project is to tackle the controllable risks early in the project. The more quickly that you are able to validate the risk associated with an item the more quickly the risk is no longer a risk (so its probability can be zeroed out.) Focusing on controllable risks won't completely eliminate risk but it will quickly cut it down. The next step is to develop mitigation strategies for those risks that can’t be controlled. Completion bonuses are a routine way that organizations which are closing down operations mitigate the risk that the people participating will leave before the project is ready to let them go. Not every mitigation strategy needs to involve money. Simply getting a verbal, personal commitment to finish the project is often enough to further reduce the probability that a person will leave during the project. Most people value their own sense of self worth and they believe that their ability to meet their personal commitments is a part of the admirable part of their self.

No project is without some risk. The best way to identify risks is through a combination of checklists and brainstorming. Checklists allow you to catch the typical risks that might be inherent in projects like yours. A team brainstorming session allows you to find risks that are specific to your particular project. You might end up identifying dozens of risks through a combination of checklists and brainstorming. After you identify all the risks, you must figure out which ones are important enough for you to address (risk analysis). You want to classify each risk it in terms of high risk, medium risk, or low risk. You do that by looking at the likelihood that the risk will occur and the impact of the risk on the project if it does occur. For example, a risk that is highly likely to occur and has a high impact to the project would definitively be a high category risk. On the other hand, a risk that is not likely to occur and has a small impact to the project if it does occur would definitively be a low-level risk. All other combinations fall somewhere in the middle of this continuum. The following list gives you the various combinations based on the impact to the project (high, medium, low) and the likelihood of the risk occurring (high, medium, low) Likelihood High High High Medium Medium Medium Low Low Low

Impact High Medium Low High Medium Low High Medium Low

Overall risk level High Medium Low High Medium Medium/Low Medium/Low Low Low

This is one example of how you can categorize risks as being high, medium or low, based on the likelihood of occurrence and the impact. There are many other techniques as well. These high-level risks should be managed. The low level risks can be ignored. The medium-level risks should be evaluated individually. You might need to respond to some while others can be ignored for Analyzing each risk allows you to determine which ones are important enough to manage. This analysis save you the wasted time associated with managing risks that are better documented, but ignored.

Risk analysis Risk analysis results and management plans should be updated periodically. Risk analysis allows you to examine the risks that you or your organization face. It is based on a structured approach to thinking through threats, followed by an evaluation of the probability and cost of events occurring. . Risk management involves adapting the use of existing resources, contingency planning and good use of new resources. Risk analysis forms the basis for risk management and crisis prevention. There are two primary reasons for this: 1. to evaluate whether the previously selected security controls are still applicable and effective, and 2. to evaluate the possible risk level changes in the business environment. For example, information risks are a good example of rapidly changing business environment. Managing risks in project is imperative for its success. We need to have a process (or processes) in place for risk management to be effective. Here are the seven steps project manager can use for risk management:

1. Identify Threats: The first stage of a risk analysis is to identify threats facing you. Threats may be: • • • • • • • • • •

Human - from individuals or organizations, illness, death, etc. Operational - from disruption to supplies and operations, loss of access to essential assets, failures in distribution, etc. Reputational - from loss of business partner or employee confidence, or damage to reputation in the market. Procedural - from failures of accountability, internal systems and controls, organization, fraud, etc. Project - risks of cost over-runs, jobs taking too long, of insufficient product or service quality, etc. Financial - from business failure, stock market, interest rates, unemployment, etc. Technical - from advances in technology, technical failure, etc. Natural - threats from weather, natural disaster, accident, disease, etc. Political - from changes in tax regimes, public opinion, government policy, foreign influence, etc. Others - Porter's Five Forces analysis may help you identify other risks.

This analysis of threat is important because it is so easy to overlook important threats. One way of trying to capture them all is to use a number of different approaches: • •

Firstly, run through a list such as the one above, to see if any apply Secondly, think through the systems, organizations or structures you operate, and analyze risks to any part of those

• •

See if you can see any vulnerabilities within these systems or structures Ask other people, who might have different perspectives.

2. Estimate Risk: Once you have identified the threats you face, the next step is to work out the likelihood of the threat being realized and to assess its impact. One approach to this is to make your best estimate of the probability of the event occurring, and to multiply this by the amount it will cost you to set things right if it happens. This gives you a value for the risk. 3. Managing Risk: Once you have worked out the value of risks you face, you can start to look at ways of managing them. When you are doing this, it is important to choose cost effective approaches - in most cases, there is no point in spending more to eliminating a risk than the cost of the event if it occurs. Often, it may be better to accept the risk than to use excessive resources to eliminate it. Risk may be managed in a number of ways: •

•

•

By using existing assets: Here existing resources can be used to counter risk. This may involve improvements to existing methods and systems, changes in responsibilities, improvements to accountability and internal controls, etc. By contingency planning: You may decide to accept a risk, but choose to develop a plan to minimize its effects if it happens. A good contingency plan will allow you to take action immediately, with the minimum of project control if you find yourself in a crisis management situation. Contingency plans also form a key part of Business Continuity Planning (BCP) or Business Continuity management (BCM). By investing in new resources: Your risk analysis should give you the basis for deciding whether to bring in additional resources to counter the risk. This can also include insuring the risk: Here you pay someone else to carry part of the risk - this is particularly important where the risk is so great as to threaten your or your organization's solvency.

4. Reviews: Once you have carried out a risk analysis and management exercise, it may be worth carrying out regular reviews. These might involve formal reviews of the risk analysis, or may involve testing systems and plans appropriately. 5. Plan Actions - Explore all the possible ways to reduce the impact of threats (or exploit opportunities). Plan actions to eliminate the risks (or enhance the opportunities). Action plans should be appropriate, cost effective and realistic.

6. Monitor & Implement the Action - Track the risks throughout the project. If risks occur then implement the risk strategy based on action plan. Ex. If mitigation strategy is selected, execute the contingency plan based on risk triggers. In case contingency plan fails, execute fallback plan. 7. Measure the effectiveness & Control the risk impact - Measure the effectiveness of the planned action and controlling the risk impact by understanding risk triggers & timely implementation of planned actions. Risk management processes are cyclic which starts from identification of a risk and it may result in identification of another new risk. There are plenty of ways to fail when managing a project. When a project does fail, the project manager and executives pay dearly for these mistakes since the staff and product costs are usually high, and a failed project like a CRM implementation will effect the business for years. After years of project successes, some failures, and roundtable discussions Avoiding these 12 common mistakes will keep your projects on track and successful. 1. Project is Not Part of The Strategic Plan 2. No Executive Sponsorship 3. Poor Technology Evaluation 4. No Customer Involvement 5. Scope Creep 6. Invalid Pilots 7. Inadequate Testing 8. Poor Planning 9. Rolling Out At The Wrong Time 10. Limited Training 11. Under Estimating Change To The Business 12. Avoiding Risk Analysis 1. Project Is Not Part Of The Strategic Plan A strategic plan identifies your company’s business goals and the solutions needed to support those business goals. If a project does not line up with one of the items on the strategic plan, you should not do the project.

Many organizations are in a “re-active” mode. Their focus is on the hottest fire of the day. These organizations usually look at a strategic plan once a year or sometimes never create one. Within these organizations project failure is more prominent than project success. What is the key? Projects aligned with business goals on the strategic plan will “add value” to the business and your customers. A large manufacturing organization implemented an expensive application monitoring solution that was implemented on-time and 13% over budget. The justification for the project: Help Desk staff would better understand the user application needs and problems when they called in with an issue. The project team considered this a success, plus they had some cool technology to play with. Unfortunately for the project team, the CFO attended the project de-briefing. The CFO’s only question to the team was: “How does this product help us produce more widgets, reduce inventory, or improve customer service?” After a minute of silence and blank faces, the CFO then stated that this project was a failure and just cost us $300,000 +, returning no value to the business. This project team learned a lesson the hard way.

Roadblocks Encountered Non-strategic projects are first to be cancelled Team members and other resources are pulled for higher priority “strategic” projects Executive and business unit time commitments are limited Project budget is reduced Executives and business units are slow to respond to critical issues, risks, or project activities

Action Items Identify which item on the strategic plan your project supports Understand the priority of this strategic plan item Understand the “value” your project brings to the business Decide whether the risks are to high too continue

2. No Executive Sponsorship Executive sponsorship of your project is vital for project success. Active sponsor participation has historically ensured a project will be on-time, within budget, and meet the business goals. Take a look at the projects you have been involved in over the past year. When there is an executive sponsor sitting in status meetings, reviewing plans, meeting with team members, etc. the project team stays focused on the project objectives, roadblocks are removed immediately, and morale is up. Project teams seem to feed off the executives leadership and focus. Projects that are delegated down to line level managers seem to float along, stop when issues arise, and go in fragmented directions. These projects have a higher risk of failure. There are three areas of sponsorship your project should have before moving forward. At smaller companies, there may be one executive who will sponsor all three areas and in larger organizations this will be three different executives. Technical Sponsorship: The executive responsible for the technology strategy, issues and decisions. Business Sponsorship: The executive responsible for the implemented features, functions and business processes. Financial Sponsorship: The executive responsible for the project costs, total cost of ownership, and return on investment. Roadblocks Encountered Project does not get the right level of support when needed Project goes in fragmented directions Issue resolutions are slow to arrive, sometimes causing a stoppage of the project Project lacks focus No leadership Action Items Identify the technical, business, and financial sponsor Determine the sponsors participation in the project Elicit sponsorship from C-Level executives who will receive the greatest value from the project

3. Poor Technology Evaluation Many project failures start at the beginning. The evaluation team is knowledgeable on some aspects of the technology but they do not spend enough time researching solutions and they believe all the hype from vendors and industry media. We have found successful project teams perform an intensive due diligence upfront by using tools like RFI’s, RFP’s, client visits, demo’s using live customer data, etc. Asking the tough detail questions in the beginning can save your return on investment at the end. Roadblocks Encountered Products selected do not work Products selected have never been implemented before The correct components were not budgeted or purchased until later in the project Vendor goes out of business before project completion Action Items Perform an intensive due diligence upfront Verify reality vs. vaporware See it, touch it, and use it in a comparable environment

4. No Customer Involvement Successful projects need input from the people who will be affected most by the project. The customers should be consulted on the value they will receive from a product. When implementing an inventory control system, your best feedback will come from the inventory control clerks and supervisors. They better understand the business processes and how to improve efficiencies than anyone else on a project team. These customers can best help with process improvements, features, and functions. Another key factor on customer involvement is who will be included on the team. Successful projects have the best and brightest customers on the team. These individuals make the best decisions in a more timely manner. Also, their time is committed to the project to avoid the day to day business priorities that would normally take them away from the project. Roadblocks Encountered Products developed do not meet customer needs New business process reduces productivity Product design takes longer than expected Product is not accepted by the customers Products developed do not provide a return on investment or add value to the business Action Items Assign the best and brightest customers to the project Commit customer time to the project to avoid day to day priorities

5. Scope Creep Adding additional scope without testing it against the business case and evaluating the impact on the cost, schedule, and risks is the easiest way to sink a project. Modifying products is risky and the most common form of scope creep. The project best practice is to implement quickly, get the benefit quickly, and modify later. As an example, waiting on software features is better than getting off the vendor upgrade path. A large retailer implementing a retail management system decided their operations were so unique that they changed 90% of the programs during a two year, $11 million implementation. During the development phase of this project, the vendor released a new and improved version of the software. Once the modified package was implemented, the retailer looked at upgrading to the new release. First, they found that they were not eligible for software upgrades since they modified the code. Second, analysis determined that they would need one full year of programming effort to input the same modifications into the new release. End result, they will be customizing and running this system until it breaks or they can cost justify the purchase of a new system. The least predictable “scope creep” issues are changing business needs, business models, mergers, and acquisitions. These add complexity but have less impact to the project when implemented in smaller milestones and phases. Roadblocks Encountered Development never ends, product changes frequently Modifications to product during initial development drastically increases your risk of failure Getting off the vendor upgrade path Unexpected increase in cost, effort, and duration Action Items Only modify products if business critical Test the change in scope against the business case Evaluate impact on cost, schedule, and risks Implement scope changes in the next release Set up a Change Management committee

6. Invalid Pilots Pilot phases of a project can be very enlightening. What a great tool, test the product in a smaller real life environment. Failure occurs when the pilot does not simulate reality. A mid west distribution company built a brand new lab environment for the new Back Office System project. The pilot was a complete success. Problems started occurring during the rollout of the software to remote locations. Unknowingly, a project lead asked “What is the hardware configuration of the pilot test lab?”. What did they find? The lab was built with the latest and greatest server and desktop hardware. The remote facilities were running hardware from five years ago and did not support the new software. When performing a pilot, have an accurate inventory of all hardware, software, tools, etc. Validate them all during a pilot. Roadblocks Encountered Pilot lab equipment does not mimic reality Works in the lab, not on the production floor Product can be a complete failure on the first day it is released Action Items Before starting, document an accurate inventory of all hardware, software, and other production environment information Validate the pilot tests for all environment configurations

7. Inadequate Testing Question: What is the second item cut when a project is low on funding or over budget? Answer: Testing of course. Limiting your testing of a solution will increase the chance of system failure or unknown bugs that can cripple your business. Do not skimp on testing to save time or money. Eliminate features first. To limit project failure, the testing phase should consist of system test, customer acceptance testing, volume testing, and stress testing to test scalability. Roadblocks Encountered Dramatic increase in product bugs Dramatic increase in quality issues Increased risk of product failure Increased costs during deployment and support Low customer satisfaction Action Items Eliminate features before cutting back on testing Testing should include system test, customer acceptance test, volume test, and stress testing

8. Poor Planning Rolling out a product to one location is fairly simple. Now, take the same product and try deploying it to hundreds of locations across the country simultaneously. Multiple location deployments are more of a challenge to do quickly and cost effectively. Larger deployments require more planning due to greater chances of conflicts and timing issues. Proper planning of equipment and resources will make or break the project. Roadblocks Encountered Number of outside locations to deploy products increases project complexity and risk exponentially Unknown conflicts and timing issues delay project Unexpected staffing needs Unexpected equipment and supply needs, increasing cost of project Action Items Perform a detail plan before the start of the project Review and adjust plan on a daily basis

9. Rolling Out At The Wrong Time Proper timing of a project “Go Live” is an important success factor that is often challenged by missed milestone dates. Business sponsors want solutions implemented before peak times where it will provide the greatest benefit. However, pilots and testing cannot be sacrificed. Pressing your luck on the timing of a rollout can be disastrous. A small specialty retailer was behind schedule on a warehouse system implementation. The original planned completion date of the project was one month prior to the Christmas rush where the facility pushed through 1/3 of the yearly volume. Scope creep added an additional 2 months to the project, but the new date was not acceptable. Limiting the software testing reduced this overage by 1 month. Therefore, the team was behind schedule by 1 month but could be implemented days before the Christmas rush. This new software was so important to the business that they made a decision to “Go Live” the weekend before the heaviest volume would arrive. Due to poor testing, the system could not handle the warehouse volume which slowed productivity and delayed shipments to the stores. A project post mortem review estimated a $13 million loss of sales caused by the poorly timed system roll out. Roadblocks Encountered Missed milestones and a “Go Live” date that cannot move will sacrifice other key project needs (i.e. Testing, pilot, etc.) Peak volume season sounds good to the business but adds unnecessary stress and risk Conflicts with other projects and initiatives targeted for the same period of time Action Items Once a “Go Live” date is available, evaluate the business cycle, other project dependencies, alternative dates, etc. Understand why the business needs a solution by a certain date Allocate enough time between “Go Live” and Peak Season to work out any last minute kinks

10. Limited Training Training is the first thing cut from a project when funding is low or over budget. You get the product released and the sponsors will not spend additional money on training. Without proper training, the new system will not provide the expected return on investment. Additionally, poor or no training will lead to low customer acceptance resulting in a failed project. To receive value, the customer must know how to use the new product. Roadblocks Encountered Low customer acceptance Increased costs during deployment and support Low morale and decreased productivity Lost revenue Action Items Prepare a low cost training alternative Involve customers more during the product testing Eliminate features before cutting back on training Delay the project if possible \

11. Underestimating Change To The Business Change management involves the business process changes necessary to succeed. When implementing software, failure occurs most of the time when the project sponsors do not understand that they must change the business to work with the software or change the software to work like the business. Managing change is more difficult in organizations with high turnover, lack of education, or high stress environments. To successfully manage change, a project should have 25 to 35% of the budget allocated to change management. This allocation will lower the project risk and provide a cushion toward project success. Take, for example, the shoe company that implemented a warehouse management system to increase inventory accuracy and throughput. The project was, from the beginning, focused on software features and functions. Little attention was given to current and future operating practices on the warehouse floor, how they could improve and must change. In the end, the implementation resulted in a 1.2 millionsquare-foot facility that was very adept at quickly losing product. If process improvements are identified early, as part of the business case effort, they are much more likely to be carried through to implementation. Roadblocks Encountered Project and business processes are not aligned Business process changes are not considered until the end of the project Drastic process or project changes required at the last minute causing overages and delays Results in reduced or negative ROI Action Items Understand the business process impact of the solution at the beginning of the project Allocate a 25 to 35% change management budget (time and cost) Set up a Change Management committee with the business

12. Avoiding Risk Analysis No one likes discussing project risks. It is human nature to think positive, nothing will go wrong. Sometimes success or failure is determined by how well prepared a project team is when disaster occurs. If the project team or organization is not prepared, the project may stop unexpectedly until a new plan can be executed. During a project milestone review session at one financial services company, the project manager was asked “risk type” questions like, “What are the chances that vacations will slow down the project?” and “What affects will a union strike have on the project?”. The project manager answered with one statement, “We don’t worry about those things, we are here to code, test and install this application.” As you guessed, no one analyzed the risks so no mitigation plan was in place. In the end, consultants were hired to make up for low staff counts, the project was over budget by 43% and implemented 4 months late. An insurance company that ran a skeleton staff always ran projects by the seat of their pants. Plans were sketched out on scrap pieces of paper and planning for the unexpected was considered a waste of time. During a hardware and software upgrade that was to be implemented before year end processing, there was no contingency plan if the hardware was late. Due to production problems, the new hardware was delayed for 2 months. Two weeks before the “Go Live”, they were scrambling around looking to rent hardware. Unfortunately, the project was not implemented before year end. Successful projects start a risk management log on the first day. Risks are identified throughout the project, a mitigation or contingency plan is defined for each risk, priorities, probabilities and ownership is assigned. Staying on top of project risks will keep your project on track. Roadblocks Encountered Nobody likes discussing “risks” Project teams are not prepared for disaster Unrealistic view of the project status A .01% risk probability can stop a $100 million project dead Unexpected project delays and cost overruns Action Items Day 1, start a risk management log Identify risks throughout the project Continually revise risk mitigation and contingency plans

Avoiding These Common Mistakes Will … Reduce project overruns and missed schedules Improve project ROI and business value Improve customer satisfaction