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.
Why should you carry out risk planning and put in place sound risk management practices? Because it:
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:
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.
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. |
|
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. |
|
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. |
|
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. |
|
Other Common Technical and Operational Risks:
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.
How can project risks impact projects? Answering this question is part of risk analysis, which helps examine how risks can have an effect on: