EXPERIENCE HAS SHOWN THAT risk management must be of critical concern to project managers, as unmanaged or unmitigated risks are one of the primary causes of project failure. What we know, we plan for, and we are more often successful than not. However, without mitigation, risks will introduce chaos and failure into an otherwise well-planned and managed project. This article addresses the identification, mitigation strategy and contingency planning, and ongoing management of project risks, and is designed to provide additional techniques for practicing project managers and provide risk management awareness for their client sponsors.
Numerous texts address risk management and statistical methods to calculate a range of “estimates” to account for the duration risk of activities in a project task network. Project management software and other tools help deal with the operational problems of resource overallocation. However, some of the techniques assume that risks are identified and can be uniformly addressed by increasing project time frame or resources. These assumptions don't always hold true.
Managing a successful project is like walking the high wire, a complex balancing act fraught with competing distractions. The successful tightrope walker has years of practice and starts training on a “low” wire. Much attention is paid to the setting of the guy wires and support poles to provide a predictable tension to the high wire. Moreover, intense focus is required for the task at hand and to ignore the noisy crowds. A prospective tightrope walker who has not gained competence through experience and who has not properly set up the tightrope environment is sure to fall.
Likewise, rare is the project manager who can deal with the inherent risks, distractions, and complexities of project management without detailed plans and processes. Unfortunately, risk management is not always approached with the rigor of other project management processes—scope/change management, issue management, conflict resolution, deliverable-based work breakdown development and scheduling.
Paul Royer is a managing consultant with CIBER in Bellevue, Wash., USA. He has over 30 years of experience in the information technology field, including extensive practical and methodological experience in project management.
Over time, many project managers learn to manage risk by denial, sidestepping, and attempting to shield themselves. They develop various patterns of behavior to fend off the impact of risk-based failure, such as:
Adding nonjustified contingency time, money, or resources to the project plan; that is, “padding” the estimate
Pointing fingers and placing blame
Begging forgiveness and renegotiating scope when the “unknowable” occurs
Taking shortcuts in quality assurance activities in an attempt to avoid risk impact or missing milestones
Eliminating infrastructure deliverables, such as training or metadata documentation
Reacting with “it's just one of those things” behavior and expecting the client to accept it.
The trouble with these behaviors is that there is no learning and, therefore, they tend to be repeated.
All of the above behavior patterns are reactive, lead to project failures, and serve to weaken the credibility and confidence of the project manager. I don't suggest that there are not unforeseen circumstances that can seriously impact a project. However, there are steps that a project manager can and should take to mitigate and minimize the impact of “foreseeable” risk-based failure.
Before exploring the steps to successful project risk management, it's useful to examine the characteristics of some project environments. The project manager is selected from the ranks of successful “doers.” Correspondingly, membership on a project team comes as a positive recognition of past work and success. It naturally follows that project team planning and environment perceptions-are positively focused (that is, the project manager and team members are optimistic, positive individuals who believe they can do anything, without regard to time or resources). This does not imply failure, as many projects are successfully completed by superhuman efforts of a few individuals. However, overoptimism represents a “Pollyanna” management approach and can lead to disaster.
During the project proposal and planning phases, the project manager draws on past personal experience, the project team, and the client community to develop a project plan. Generally, a series of brainstorming sessions is held to define goals and objectives, fix boundaries of the project (scope), quantify deliverables, develop a project life-cycle approach, and set the timetable, milestones, budget, and resources. This is the point in the project life cycle where risks should be identified and mitigation strategies developed; however, this often doesn't occur. Many reasons exist for not spending the time and energy to carefully examine risks:
Quantifying risks could lead to non-funding of the project
Client doesn't want to spend the time and energy
Client doesn't believe the risks are real
Client wants a simple plan.
I believe there is another underlying force at work, too. The sociological trends of our society and current philosophy of team building emphasize the need to be positive—problems are opportunities; risks are challenges to be overcome; negative thoughts are socially suppressed. In this environment, to emphasize risks is to be labeled as a negative thinker and noncontributor—almost a pariah. It's as if we've forgotten a basic survival instinct: risk aversion. Our evolution from the African savanna was a systematic process of learning to avoid risks. Risk-adverse behavior is a survival trait and should be included as a balancing factor, even in today's sophisticated civilization.
There are positive, proactive steps to manage risk. When practiced consistently within an organization, these proactive steps can form the basis of a formal project risk management methodology.
In my experience, risks can be divided into two classes: recognizable risks and unmanaged assumptions.
Recognizable Risk Classification and Mitigation
Recognizable risks are those that can be identified during planning and engagement contracting activities. For the most part, they are highly visible and immediately apparent to everyone (or at least someone) involved with the project. Typical examples include new technology, financial resource constraints, staff resource limitations, changes to business processes. Historically, mitigation strategies have often been put in place for these kinds of risks.
Unfortunately, mitigation strategies can introduce risks of their own. For example, if the project calls for the introduction of new technology, training could be included in the project plan as a risk mitigation strategy. However, while training is necessary to acquire new skills, it is usually not sufficient. Coaching, mentoring, or at least the ready availability of an experienced practitioner is often required to ensure skill transfer and proficiency in a short period. Therefore, it would be advisable to include a contingency plan for an onsite expert or consultant, should the need arise.
It follows that as risks are identified, a risk mitigation plan should be developed and implemented. Further, a contingency plan should be included for high risks, with a triggering circumstance or measure defined to invoke it. It may not be necessary to plan the contingency action in detail at this time; however, it is important to know what should be planned based on an appropriate trigger (that is, a set of warning signs). Continuing the new technology risk example, if anticipated productivity measures are not met, the expert is called upon.
Risk mitigation strategies and contingency plans cost time, money, and resources to develop and implement. Rare is the project where every risk is manifested and every contingency plan triggered. In addition, project sponsors often don't want to spend the time (money) for detailed risk mitigation planning. Consequently, it may be more appropriate to set an overall risk mitigation budget as a percentage of the overall projected costs, rather than detail costing each identified risk's mitigation strategy and contingency plan. Industry experience suggests a 5 percent contingency budget for identifying and tracking risks. In addition, I suggest at least a 5 percent risk mitigation contingency budget for those risks not preplanned and budgeted in detail.
Risk Identification Techniques. To properly manage risks, they must first be “discovered.” Two common techniques to accomplish this are experience-based and brainstorming-based risk assessment.
Experienced-based Risk Assessment. The mark of a successful project manager—a survivor both organizationally and personally—is the ability to learn from experience. The impact of unmitigated risks encountered in past projects is imprinted indelibly in the psyche of the project manager and will be remembered in future projects. Why isn't this knowledge resource more readily available to the new project manager?
As a manager and internal consultant for a large health care organization for many years, I experienced firsthand the continued relearning required of newly christened project managers. Upon examination, I realized that a major contributor to failure for uninitiated project managers was their naiveté about risk management. They were inevitably high producers, motivated to succeed, knowledgeable in the business, and well thought of throughout the organization. Why didn't they all succeed? I submit that many project management neophytes failed or decided not to follow a project management career because either the organization became impatient with the learning curve required to adequately mitigate risk or the stress of reacting to risks brought about premature burnout. If the project risk management experience of seasoned, successful project managers was readily available to the new one, then burnout and failure could be minimized. How can this be accomplished?
Project management texts, seminars, and consultancy-based methodologies stress the importance of project closure reviews as opportunities to increase an organization's knowledge base. Unfortunately, closure activities, while frequently outlined in the project plan, are often only cursorily executed. There is always too much to be done, a new project to start, or a new priority to address. Nevertheless, even if organizational culture minimizes the importance of project closure reviews, project managers should take it upon themselves to document their risk management experiences during the projects and proactively share them with other project managers. This experience can form the beginning of a project risk checklist to aid in examining potential project risks and prior mitigation and contingency plans.
Further, consulting organizations, ISO requirements, and the Software Engineering Institute Capability Maturity Model methods stress the importance of process definition, consistent implementation, and continuous improvement to increase organizational effectiveness. This should be applied to project risk management as well. If an organization will take the time to document risks and their mitigation strategies, review them at project closure (successful or not), and share them via a readily available knowledge repository, new project managers and the organization itself will be more successful.
Brainstorming-based Risk Assessment. Facilitated brainstorming sessions with client stakeholders, project team members, and infrastructure support staff are the primary technique used to define risks and their mitigation strategies and contingency plans. The process defines risks in one column, mitigating strategy(s) in a second column, and potential contingency plans in a third column. Multiple mitigation strategies or contingency plans can be identified for risks. Using this technique, one can readily determine where the organization is exposed to an unmitigated risk. This form of facilitated session is also known as “force field analysis.”
Risk Classification. In the real world, there is neither money nor time nor resources to deal with all risks; therefore, management must choose which risks will have mitigation and contingency strategy plans developed and implemented for them. To enable this, it is important to develop an objective approach for classifying risks and establishing priorities. One approach is to examine each risk and classify it by the following three factors: category of risk, severity or impact on the successful completion of a project milestone, and probability or likelihood.
Predefining risk categories provides a way to classify risks for inclusion in the organizational knowledge base. While every organization should establish its own risk categories based on its special needs, seven risk categories that I've found useful are scope/change management risk, operational risk, financial risk, project management risk, strategic risk, technology risk, and failed assumption.
Exhibit 1. Building an intersecting matrix of high-, medium-, and low-risk severity and probability provides a simple, straightforward way to numerically quantify risk. More sophisticated numerical analysis techniques are not required to establish where resources should be applied to build appropriate risk mitigation strategies and contingency plans.
Within any organization, certain risk categories may represent higher risks for project failure. For example, some organizations may have much experience introducing new technology and therefore understand how to deal with technology risks. On the other hand, another organization that has not introduced new technology for some time may need to be especially careful when doing so. It follows then that the risk categories themselves may have weighting factors assigned to modify the severity/probability risk-factor ratings. Such weighting factors may aid in quantifying overall project risk, but they are no substitute for proper risk mitigation strategy and contingency planning.
Risk severity relates to the impact on the project and business if the risk manifests itself, and should be rated for objective evaluation. While more complex numerical severity rating schemes can be defined, I've found it sufficient to use a simple high-medium-low scale defined as follows:
High. Without mitigation, project objectives are in jeopardy.
Medium. Without mitigation, a deliverable/milestone is at risk.
Low. No deliverable/milestone is currently at risk, but an issue bears watching and is a candidate for active mitigation.
Risk probability is often indicated by a faulty assumption of resource and skill availability or by a timing and synchronization issue. As with risk severity, a simple highmedium-low rating scale is usually sufficient for objective evaluation:
High. Without mitigation and monitoring, the project deliverable/milestone completion will interrupt the project's critical path.
Medium. Without mitigation and monitoring, project deliverable/milestone completion will enter the project critical path.
Low. No project deliverable/milestone is at risk unless delays become excessive; therefore, it should be documented and monitored.
Combining these elements leads to the matrix of risk severity vs. probability shown in Exhibit 1.
More detailed and sophisticated matrices are in use by many companies and contained in many project management software support tools. However, I suggest that significant results could be achieved with this minimal level of complexity.
As well as quantifying risk severity and risk probability, other objective measures of risk should be considered; that is, where possible, the degree of impact on cost, schedule, and deliverable quality should be examined and quantified.
Risk Mitigation Strategy and Contingency Plan Evaluation and Planning. Exhibit 1 provides an objective starting point for choice. First, all risks with either a high severity or probability (severity/probability factor rating [SPR] of 3 or 2) should be examined in detail. They should have a mitigation strategy developed and included in the project plan and budget. If both the severity and probability factors are high (SPR of 3), then a detailed contingency plan with budget should be considered. If only one factor is high (SPR of 2), then it is probably appropriate to outline a contingency strategy with a trigger and leave the planning details until the contingency is triggered.
For the areas with at least a medium severity or probability (SPR of 1), mitigation strategies should be developed. Then if monitoring shows an increase in risk during the project, a contingency plan should be considered.
Those risks with both a low severity and probability (i.e., SPR of 0) should have a metric established to allow monitoring. That is, the risk should be treated as a project assumption and dealt with in the same manner.
After developing mitigation and contingency strategies for the risks, it becomes the responsibility of the project manager and the assigned accountable person to provide continuous monitoring and risk status evaluation. For effective monitoring, a success measurement for the mitigation strategy and a “triggering” event that identifies when the contingency plan must be invoked needs to be identified. It is the mitigation success metric and triggering event that are tracked. In addition, the project manager, team members, and stakeholders should be alert for new risks throughout the project life cycle.
Unmanaged Assumptions
In contrast to identifiable risks, unmanaged assumptions are neither visible nor apparent as risks and so can be the most dangerous. I believe that they are introduced by organizational culture and that when unknowingly present in the project environment bring about incorrect perceptions and unrealistic optimism.
Assumptions are a fact. Every project management class and methodology tells us to document our assumptions and have them verified by the client or other sources. However, do we manage our assumptions? I submit that we don't. Typically, when an assumption proves incorrect or a change in environment negates it, we “cry wolf” and fall back on the reactionary behavior.
Is this the best we can do? No! Assumptions should be managed in much the same way as risks, because they are a new source of risk. To avoid surprise, assumptions about the project should also be documented and monitored to ensure that changing circumstances don't negate assumptions and transform them into risks. For every assumption we define and document, a metric can be defined to test its continued accuracy. By establishing measures for our assumptions and monitoring them, we can proactively develop contingency plans to be triggered when change happens.
A colleague recently gave me a typical example of failing to manage assumptions: A state agency was acquiring a document-imaging system to help modernize and automate its accounts payable process. The basic assumption was that the integration vendor could easily provide the agency with an application design and implementation to optimize the business process. Unfortunately, this was not the case, and the project time frame began to lengthen as the vendor was forced to provide several iterative designs. This unmanaged assumption was recognized in time, so the project succeeded; however, there was much wasted time and sponsor anxiety generated before corrective action was taken.
What could have been done to avoid this situation? During the corrective action, it was recognized that an objective measure of the integration vendor's progress would have surfaced the problem much earlier. For instance, if a time or iteration limit had been contractually specified, then corrective action would have been triggered earlier. The project team discussed possible corrective actions:
Identify and contract with an experienced accounts-payable document-imaging consultant
Allow for more design iterations in the project plan, as this was a pilot project
Differentiate between minimal system and process requirements and nice-to-have features.
By examining the underlying assumption, defining an appropriate metric, and outlining corrective actions, the project could have proceeded without the stress generated by not recognizing that assumptions are risks that must be managed.
Assumption Identification Techniques. Project assumptions derive from three sources: experienced-based assumptions from prior project management exposure, those identified by brainstorming, and identified risks that have both a low severity and low probability.
Experience-based Assumptions. Not only does prior project experience give the project manager a source for risk identification and planning, it also provides knowledge about assumptions that hold true within an organization and types of projects. For example, experience may show that any new technology implementation effort should have a cost contingency factor of 25 percent or that sponsor availability can rapidly change during the course of a project. Appropriately documented, these are reasonable assumptions. However, they must be monitored and tracked for continued justification.
Brainstorming-based Assumption Identi fication. Using the same brainstorming technique outlined for risk identification, assumptions can be identified, a metric to monitor continued applicability defined, and potential mitigation strategies examined.
Converting Low Risks Into Assumptions. The risk mitigation strategy and contingency plan evaluation and planning activity emphasizes that low-probability and low-severity risks should have a monitoring metric established for them. Once this is done, the risks can be reclassified as assumptions and tracked accordingly.
Assumption Evaluation. Having documented assumptions and identified a monitoring metric and potential mitigation strategy, it falls to the project manager and accountable person to periodically test the monitoring metric and ensure that no environmental change has occurred. If circumstances change an assumption to a risk, the established risk management process should be invoked.
Enterprise/Program Risk Management
In addition to establishing project risk management, an enterprisewide or program-level risk management process should be considered. It is common for several major development projects to be occurring simultaneously across an organization. Moreover, similar risks may be encountered in these projects. If project risks are evaluated, then it becomes a simple, mechanical process to summarize them and examine the organizational implications of risk over all projects.
In my experience, if multiple projects have identified similar high risks (SPR of 2 or 3), then the potential impact on the organization as a whole is very high, even if interproject dependencies are low. Correspondingly, multiple medium project risks (SPR of 1), while not necessarily of the highest concern to an individual project, represent a greater aggregate risk to the organization.
For example, if multiple projects are simultaneously introducing similar new technologies to the organization (such as, client/server), then each project may rate the risk as either high or medium, depending on the project team skill set and risk-aversion mindset. Clients may only see or believe medium to low risk, if any, as the vendor marketplace has successfully exaggerated the “simplicity” of the technology. It is easy to envision (and demonstrate by past experience) that many or most of these new technology efforts will encounter difficulty and organizations will be forced to execute risk mitigation strategies and contingency plans.
If the individual project risks with their mitigation strategies were examined from an enterprisewide perspective, they would certainly be given greater weight. In addition, the organization can then act as a whole. For instance, a pilot project, which evaluates the new technology to establish its limits and usefulness, might be advisable and executed prior to each project proceeding. This would provide lessons learned and avoid the costly impact of individual project risk mitigation and potential failure.
SUCCESSFUL PROJECT RISK MANAGEMENT will greatly add to the probability of project success. Identifying project risks and assumptions, documenting them, and including them in the overall project plan and processes is a justifiable activity. I submit that it is a necessary one. At project closure, the project risk and assumption experience should be integrated into the organization's project management knowledge repository. This knowledge base can serve in future projects as the starting point for risk identification and analysis. New as well as experienced project managers can use these past real-world experiences to reduce worry and burden and increase the likelihood of success. ■