Understanding Risk Management

Overview on Project Risk

Consider a project case involving the acquisition and processing of digital imagery and LiDAR data for a large in the spring (leaf-off coverage). You are managing the project and have hired an aerial survey firm to conduct the work. The contract with this firm takes into account some weather problems (e.g., storm conditions and cloud cover) that require the contractor to do some schedule adjustment for the aerial mission. However, during the contracted period of acquisition, the weather conditions are very bad--extended storms and cloud cover conditions that create major schedule problems for the flights (potentially beyond contract terms for schedule adjustment) and present obstacles for acquiring cloud-free coverage in the entire area. In addition, there is some major flooding in some parts of the acquisition area covering some roads and properties. This situation could impact the project cost, schedule, and possibly the quality of the products. In this case, the weather is a risk event which, as the project manager, you must address. How do you handle this?

Risk is unavoidable in GIS and other IT projects. The central theme of this lesson is to take into account potential risk events, which may impact project schedule, cost, quality, etc. in project planning and execution. The purpose of risk management is to position you to better identify risk events early and take action that can eliminate or reduce negative effects of those risks on the project.

Since 1994, the Standish Group, a well-known research and consulting company, has conducted major studies of IT projects in a large number of organizations and examined the success of those projects in comparison to their planned objectives, timing, and budget. The products from these studies, known as CHAOS reports, have consistently shown that many IT projects (more than 50 percent) had substantial overruns in schedule and budget and that about 30 percent of them were failures and were canceled—and this is the case in the most recent version (Standish Group, 2020). The Standish Group also studied the reasons for IT project failures and concluded that the greatest causes had to do with inadequate planning (including the lack of a sound assessment of requirements) and poor project management during execution.

The good news from this study is that these problems can be overcome by proper project planning before the implementation begins and putting in place effective project monitoring, reporting, work delegation, and communications. Is it safe to take conclusions from the Standish CHAOS Reports and apply them to GIS projects? Yes, "mainstream IT" and GIS projects are generally complex and incorporate the most recent technology tools, methods, and the need to involve users and subject matter experts in design and development. Many other risks associated with design and analysis should be capable of being translated from the world of IT to GIS.

Risk Management Terminology

Risk Management is one of the "project knowledge areas" defined by the PMI in the Project Management Body of Knowledge (PMBOK). Let's review some key terms in risk management as described by the PMI:

Risk - an uncertainty that can have a negative or, less frequently, a positive impact on meeting project objectives.
Risk Event - a potential event or condition that cannot be fully predicted and which may have an impact on the schedule, cost, quality, or overall scope of a project.
Risk Management - a systematic process of identifying, analyzing, and describing potential risks and active monitoring and response during project execution.
Risk Category - Risks are normally classified into several categories, appropriate for the project, to help understanding and monitoring of risk events. The number of categories should be low (e.g., from 3 to 6).
Risk Identification Register - Identification of the full set of risk for a project, usually in table form, that includes, at a minimum, the name of the risk, a risk ID# (usually with a alpha code corresponding to a risk category), and a description of the risk. Sometimes, risk registors include other information to characterizing risks (triggers, probability of occurence, impact level, etc.). See Figure 8-1.
Risk Matrix - a 2-dimensional grid that organizes risks (from the Risk Register) into classes of probability (of the risk event occurring) and the level of impact on the project. See Figure 8-2.
Risk Analysis- the processing of identifying and describing potential risks, the probability of occurrence, and the potential project impacts. The results of the risk analysis are presented in a risk matrix.
Risk Response Strategy - a type of action that can be taken to respond to the risk and control the impacts from risk events--usually lowering negative impact on a project's scope, schedule, deliverable quality, or cost. The PMI categorizes risk response strategies--the main ones being: avoidance, mitigation, and transference.
Risk Management Plan - an assignment of responsibilities for risk monitoring and a description of actions to be taken in response to risk events.

Why should you carry out risk planning and put in place sound risk management practices? Because it:

raises the profile of a GIS project by conveying its importance to the organization and helping to sustain support and necessary resources from senior management;
puts the project in a much better position to deal with problems and changes early and to take action so that negative impacts are avoided or reduced;
gives the project team confidence that unforeseen events will be handled in an organized way.

Risk Identification and Preparation of a Risk Matrix

The level of detail, time, and rigor required for risk planning depends largely on the size, budget, and complexity of the project. For simple projects with a small project team and budget and short time frame, risk identification may be quick and risk monitoring can be handled much more informally than with larger projects. A suggested first step in risk identification is to describe categories for organizing risks. In GIS projects, risks and risk events can often be organized into the following categories:

Technical/Operational: Includes risks associated with the technological and operational aspects of the GIS program or project, including hardware and software, network configuration, database development, security breaches, and the procedural workflows associated with technology acquisition and implementation. These risks reflect potential technical obstacles in system development that could impact costs or the schedule.
Organizational/Staff Resource: Includes all aspects of organizational relationships, management, assignments, GIS governance structure, high-level legislative and executive support, legal and policy rulings, and all types of political and media influences on the organization and the GIS project and program. This category also includes staffing allocation and participation issues.
Funding/Finances: Includes risks associated with allocating and sustaining funding for GIS operations. This includes internal decisions inside the organization that impact funding streams for GIS, as well as external economic changes that impact resources available for GIS.

The risk categories for a specific project may vary but it is a good idea to limit the number of categories to no more than 5 or 6.

Consider a major project for field data collection and application development (like the Metropolis Geodatabase Project that we are using in course assignments). This type of project has risks associated with each of the three categories above. An example of risks/risk events that fall into "Technical/Operational" (TO) and Organizational/Staff Resource (OS) categories is shown in Table 8-1 below. In this table, the "Triggers/Indicators" column represent events or circumstances that can be monitored and may arise that allow a project manager to take action to address the risk.

**Table 8-1: Example of a Risk Matrix for GIS Project (Technical and Operational Risks)**
Risk/Risk Event Examples	Description	Triggers/Indicators
TO1: Field Conditions Inhibit Quick and Accurate Positioning with GNSS Collection Devices	The GNSS data collection devices being used encounter satellite reception problems in some areas of City resulting from weather problems or "urban canyon" (tall buildings) conditions. These problems cause problems with simultaneous signal acquisition of enough satellites to get a quick, accurate position at the location which can impact occupation time at that site, the need to revisit the location, or other technical work-arounds.	Weather condition forecasts for a specific work day Observed times for positioning that exceed planned acquisition times Identified urban building conditions Pre-project tests of selected urban areas with tall buildings
TO2: City Signs Blocked Or Obscured in Field	In some cases, City signs are difficult to find or access which complicates the process for position and data acquisition. This problem is aggravated by quality problems with the original City source data which is out of date and inaccurate. Some signs, because of their location (alleys, behind buildings), are difficult to find. In other cases, signs may be blocked by vehicles or other obstructions which may cause problems in getting accurate positions.	Observed problems in quality of City source data. Discrepancies in identified signs in City source material vs. signs collected in the field Observed conditions in the field--parking congestion
OS1: Contractor Team Member Leaving Leaves Participation in the Project	A member of the contractor's team leaves the team or employment with the company. This could result from: a) employee makes decision to leave employment with the contractor company, b) employee is moved moved to another project by the contractor because of company workload issues, c) employee behavior or performance problems result in removal from project or termination from company. This potential disrupts project work.	Notice by employee of plans to leave History of performance problems from routine work evaluation Workload issues based on project assignments by company
OS2: Inadequate Participation by City Team	A member or members of the City's project team are not meeting expectations in the level of participation or required timing in the project. This results in poor response for information needed by contractor (e.g., providing City source data, answering contractor questions), inadequate review comments during quality assurance work, or other project activities requiring City participation. This potentially impacts the project schedule or quality of deliverables.	Decisions by a Departmental manager to reduce staff participation Observed problems with quality and timing of team member participation

Other Common Technical and Operational Risks:

unanticipated installation or deployment problems with new software package
system crash or other unanticipated hardware problems result in delays, lost data, and unanticipated costs
users state requirements for additional data (not originally in scope)--"scope creep"
source materials being used for database development are missing or are of lower quality than anticipated
technical problems with access/integration with the external system
performance/response time problems with the software or custom GIS application

Like other aspects of project planning, a sound, comprehensive risk analysis takes time and some research--particularly for larger, more complex projects. Brainstorming with subject matter experts (e.g., IT system or database administration staff) and other experienced project managers, inside and outside of your organization will help in the risk analysis. A project manager also needs to decide how detailed or "granular" the identification of risks should. Just like breaking project tasks into subtasks, risks can be defined at different levels of detail. The general rule is to define risks at the lowest level of detail needed to support comprehensive risk management--and don't make it any more detailed than is necessary.

Types of Project Impacts from Risk Events

How can project risks impact projects? Answering this question is part of risk analysis, which helps examine how risks can have an effect on:

Budget: impacts on the anticipated (planned or budgeted) monetary cost, staff levels, or other tangible resources for the project or program;
Schedule/Timing: impacts on the planned schedule and timing for completion of deliverables or milestones;
Work scope and services: impacts on the nature, volume, contents, specifications, etc., of the products, services, and results planned for a project or defined for a GIS program;
Quality of work and deliverables: impacts on the quality of products and services, which may relate to accuracy, amount of error, reduced performance (e.g., GIS application), etc.

Understanding Risk Management