Introduction
In today's world, more and more reliance is placed upon the project manager and his or her team to complete a project successfully. Effective planning and execution of the plan are essential in supporting project success. Within the early stages of the project, the team participates in activities that explore risk factors, which may negatively impact the project. Of major importance to the project, is to identify the risks and determine how the team will address them. This is done via “risk identification, risk quantification, risk response development and risk response control” (PMI, 1996,111); the four components of “project risk management” (Duncan, 1996, p. 111). “Contingency planning involves defining action steps to be taken if an identified risk event should occur” (PMI, 1996, p. 120), and this paper views contingency planning as a necessity in today's project world.
Risk Assessment
Risk Identification
One of the first tasks the project manager and the project team participate in is the identification of the risks that may impact the project. The initial step is to identify events that pose a threat or risk to the project's success. Basically, there are two types of risks that need to be identified and evaluated: internal and external risks. Internal risks are those “things that the project team can control or influence,” (PMI, 1996, p. 111) while external risks are those “things that are beyond the control of the project team” (PMI, 1996, p. 111). Of the two types, the internal risks are often easier to identify because external risks are not as obvious.
One of the projects that this author has been involved with is the processing of a large (in excess of 250,000 transactions) volume of data within a given time frame through a data processing architecture. The architecture contained many application systems and spanned multiple processing platforms. The project team identified an internal risk, which was that there might not be enough disk space to accommodate the volume of updates scheduled for processing. If this risk should occur, processing will stop until a solution to the problem is determined. The amount of processing time lost impacts the project since it may mean that the process would need more time to be completed than the time frame allowed for processing. Thus, the project would be completed later than scheduled and advertised.
An external risk cited during the risk identification process was the possibility of a winter snow/ice storm during the weekend of the scheduled processing. Weekends are chosen for volume processing since client usage of the data systems is negligible. The project being used in this example is business critical, and the time frame is mandated by government regulation. Harsh financial penalties, in excess of $1,000,000, may be imposed if processing does not occur within the mandated time frame. In addition, processing occurs during the winter when snow/ice storms are possible.
In order to support the processing, application support personnel are required to monitor application processing progress for the duration of the process from an “on site” central work location control room. The project manager recognizes that certain application processes execute longer than others do and that fatigue is a factor for those team members monitoring long-running processes. To address the fatigue factor, processing is monitored in shifts, and each shift is no longer than 12 hours.
The external risk is that an occurrence of a snow/ice storm may prevent team members traveling from home to work to perform shift changes because of hazardous driving conditions. The “on duty” personnel would not be relieved, and poor or wrong decisions may result due to fatigue.
The execution of the risk assessment process is a team exercise with the project manager present as a guide/moderator. The submission of risks from the team needs to be in an open forum, and the team must be able to freely discuss the merits of the risk being identified. In addition, the team needs to be in agreement as to whether an identified risk is really a risk to the project or not. An illustration of this occurred when a team member identified an additional external risk that the data center may “crash,” becoming inoperable during processing preventing the project from completing. The team members bypassed steps in the process and began to discuss how they would handle this possibility. The discussion centered on how they would acquire access to an alternate data center; consequently, one team member stated that this is a “risk” all team members face in their daily work outside this particular project. The team then agreed that this was not a risk to the project and determined that it should not be included in the list of risks to be evaluated. This illustration not only lends itself to the strength of the team and the freedom they need to explore possibilities, but it also lends itself to the team taking responsibility for determining which risks are reasonable.
Risk Quantification
Once the team has identified the risks, the next step is to quantify them. The purpose of risk quantification is to determine which risks would be most detrimental to the project should they occur. The next step after quantification entails addressing these risks.
There are many procedures that enable a team to perform risk quantification. Regardless of the process, a basic concept involves both the project manager and the team as they determine the probability of the risk occurring. Some procedures attach a numerical probability (percentage) to each risk. Another procedure may rate each risk using a scale of high, medium or low as a form of evaluation. In some cases, subject matter experts may assist the team by helping to assess and determine the risk occurrence.
Another dimension that works in conjunction with risk probability is risk severity. Risk severity refers to the impact that the risk would have on the project if it were to occur. The severity/impact can be quantified by the words high, medium, or low. (The method of using risk severity is documented in Paul S. Royer's article of March 2000, entitled “Risk Management: The undiscovered dimension of project management.”)
In this case, a process that quantifies risk for both probability and severity/impact was exercised. The team evaluates each risk for risk probability as well as risk severity/impact. At this point, the team must be cautious while quantifying in order not to misevaluate a risk probability when reviewing severity/impact and vice versa.
All risks will be evaluated for risk response. However, those risks that earn “high-high, high-medium, high-low, medium-low, and low-low severity/impact-probability combinations will be evaluated for mitigation and contingency strategies" (Royer, 2000). Those risks that earn “medium-high, medium-medium, and low-medium, severity/impact-probability combinations will be evaluated for mitigation strategy" (Royer 2000). Finally, those risks that earn a low-high severity/impact-probability combination will be “treated as project assumption” (Royer, 2000).
During the project, the internal and external risks aforementioned were both rated as having a high severity/impact and a high probability factor. Using Royer's process, both risks warranted mitigation and contingency strategies.
Risk Response Development
There are many different strategies within response development. Of the strategies, available, Royer applies mitigation and contingency. While both strategies are planned, each strategy addresses risk during a different time in the project. Mitigation addresses risk before manifestation and attempts to reduce its impact before occurring. Contingency addresses the risk at the time the event occurs and attempts to reduce its negative effects.
The team mitigated the internal risk of not having enough disk space to accommodate the number of updates in the following way: The team planned to receive estimates of the number of update transactions that would be received for processing. They further planned to use the estimates to calculate how much additional disk space was needed to accommodate the processing. Knowing how much space was needed; members of the team planned to meet with the system Data Base Administrators (DBAs) and request them to validate that their databases would successfully process the number of updates. In addition, the team members were to request that the DBAs review all of the databases and take the necessary steps to ensure that they were in an operational state supporting efficient updating of the database. The purpose was to minimize processing time in order to complete processing on schedule.
Along with planning the mitigation strategy, the team also developed a contingency plan. The team requested that the DBAs engage the data center management team and ask them to reserve extra disk space and disk drives. The requested space and disk drives were to be used in support of the process in case it was necessary.
The team reviewed the external risk and developed a contingency plan. In this case, no mitigation strategy could be planned because the weather was clearly out of the team's control! The plan developed called for several actions to be taken. The project manager would review the weather reports starting 10 days prior to the beginning of process execution. If an ice/snow storm were predicted for the weekend, the team was prepared to spend those days and nights at the work-location site.
In accordance with the plan, the team members were to bring sleeping bags to work so that during their “off shift” hours, they would be able to sleep. An investigation would be necessary to identify available offices where the team members could sleep during that weekend. The project manager was responsible for coordinating the team's meals and snacks by working with the location's cafeteria manager.
The work location has showers that are used during the week by employees who exercise during their lunch breaks. Further arrangements were to be planned with the location's landlord for team access to those showers during the weekend. All of the plans made would not be put into effect unless the ice/snow storm was predicted. It was also planned that initial contact with the cafeteria supervisor and the location's landlord would take place prior to the monitoring of the weather report. The purpose was to inform the landlord and cafeteria manager of the upcoming processing and the actions necessary to be taken in case the storm came to fruition.
The contingency plan to stay at work over the weekend, in the event the storm occurred, may be viewed as a creative solution to the problem. While it was a team decision, acceptance and commitment to the plan by all members was necessary for a plan of this nature to be successfully executed.
Another important factor is that this project this project occurred at a time when telecommuting was not a viable option. If the same problem presented itself today, more than likely one of the contingency plans would be to work from home and report status of the project via e-mail.
Although risk assessment is executed in the primary stages of the project, further risk assessments can/should be done as the project progresses to ensure that all risks are addressed.
Risk Response Control
Risk response control “involves executing the risk management plan in order to respond to risk events over the course of the project.”
The mitigation strategy plan developed to address the possibility of not having enough disk space for all of the update transactions was implemented successfully. The result was that there was no need to employ the contingency plan as proposed. The estimates obtained were accurate, and the steps completed by the DBAs, to ensure efficient updating, supported timely processing completion.
The mitigation strategy to address the event of an ice/snow storm did not have to be executed since there was no storm. Fortunately, the weather during the weekend of processing was clear, and shift changes occurred without incident. The project completed on time and within the mandated government window.
Conclusion
One might conclude that since neither contingency plan presented was implemented, there may be no need to develop them; however, this is not true. A contingency plan is executed when the risk presents itself. The purpose of the plan is to lessen the damage of the risk when it occurs. Without the plan in place, the full impact of the risk could greatly affect the project. The contingency plan is the last line of defense against the risk. For a project manager, it is better to have the contingency ready for implementation than to have to develop one as the risk is taking its toll. The contingency is another instrument in the arsenal of tools that a project manager carries to support project success. Due to the timing when a contingency needs to be implemented, contingency planning is a necessity in today's project management world.
PMI Standards Committee. (1996). A guide to the project management book of knowledge. Upper Darby, PA: Project Management Institute.
Risk Management. (1993). Arlington, VA: Educational Services Institute.
Royer, Paul S. (2000). Risk management: The undiscovered dimension of project management. Project Management Journal (March), 6–13.
Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA
