Could your projects use additional risk management? Experts agree that it is one of the most underutilized areas of project management. As engineers, when we’re managing a project in our area of expertise we like to think we know the primary risks and we have them under control. But a small amount of risk management planning at the outset of every project will reap disproportionate dividends for most people.
Risk is a function of two components:
- The Probability of occurrence
- The Consequences (what’s at stake)
The engineering risk management process involves five components. In a project management plan, each of these could have their own heading. The components are:
- Planning for risk
- Identifying risks
- Analyzing risks
- Developing risk response strategies
- Monitoring and controlling risks
Good risk management is proactive, not reactive, and seeks to reduce the probability of an adverse event occurring as well as the magnitude of its impact.
Planning for Risk
The project manager or engineer should develop a written risk management strategy which includes the methods used to execute a project’s risk management plan. This should be included as part of a larger project management plan. Adequate resources need to be available to manage risk. The key to writing a good Engineering Risk Management Plan is to provide the necessary information so the project team knows the objectives, goals, tools and techniques, reporting, documentation, and communication roles and responsibilities.
Project risks should be examined to a level of detail that permits an evaluator to understand the significance of the risk and its causes and to potentially examine the root causes. Surveys of customers, end users, and other stakeholders could be beneficial. Some typical engineering risk categories are:
- Cost – the cost of the project is higher than forecast, or increases during the project (scope creep)
- Schedule – customers or end users are not given the final product within the agreed upon time frame
- Technical – performance objectives are not met
- Feasibility – the product is does not turn out to meet financial and/or business objectives.
- Logistics – components do not arrive in time
- Human Resources – project staff are not available, or lose availability
- Production – concerns over packaging, manufacturing
- Support – maintainability, operability, and trainability
- Engineering – technical requirements for the product are too onerous, or not physically possible
- Business – the financial metrics of the project change (demand slows, market prices change, etc.)
- Contract – third party consultants/contractors/suppliers are do not perform, or did not interpret the contract the same
- Funding – the project cannot be funded to completion, or funding is removed part-way
- Management – meddling in the project causes complications
- Political – regulations change, or were not fully considered
- Threat – Security, survivability, and vulnerability
- Test – product tests are not set up correctly
Cost and Schedule risk are often considered as separate categories because they are generally the most likely to happen and require the most management resources.
Risk analysis is the systematic process to estimate the level of risk for identified and approved risks. Normally, this involves the creation of a risk matrix which quantifies the probability and consequence of the defined risks and a conversion to an overall risk level.
A commonly used qualitative risk analysis method involves risk scales for estimating probability of occurrence and a risk mapping matrix. For each identified risk a probability and a consequence is assigned in the form of letters A to E. Each letter should be defined by a verbal description. Then a risk mapping matrix is drawn up to categorize each risk.
Two primary methods exist in order to perform a quantitative risk analysis:
- Decision Tree Analysis
- Monte Carlo Analysis
The Monte Carlo process is an attempt to create probability distributions for potential risks and randomly sample them to quantify the risk. The process starts with a random number. Spreadsheets are your friend for this. You must isolate the variable which contains the risk and calculate the other variables from it. For example, if you are performing a Monte Carlo analysis on the schedule risk, you would define the critical path and create a spreadsheet column for each of the critical path tasks. The first (leftmost) column is a random number, whose range you must predefine and which represents the actual duration of the activity. All of the other tasks get calculated, and you can take a look at how often your completion date changes.
Developing Risk Response Strategies
In the Risk Management Plan (within the Project Management Plan) strategies to deal with each risk should be placed into four basic categories:
- Acceptance: Also known as retention, the project manager or organization is willing live with the risk without further mitigation.
- Avoidance: The project can avoid the risk by removing whatever requirement caused it to appear. The risk is sidestepped.
- Control: Also called mitigation, this involves recognizing the risk is there and performing actions to minimize it, developing contingency plans in case the risk comes to pass, or developing fall-back provisions.
- Transfer: Sharing of the risk with another party, or outright transfer (wouldn’t that be nice!)
Monitoring and Controlling Risks
Within the Risk Management Plan, provisions should be in place to systematically track and evaluate the effectiveness of the risk response actions against established metrics. Some techniques that can be used for monitoring and controlling risk:
- Earned Value: This method compares the value of work completed to date (earned) with the value of work supposed to be performed at that point in the schedule.
- Program Metrics: Formal, periodic performance assessments evaluating whether the risk management plan is achieving its objectives.
- Technical Performance Measurement (TPM): A way to measure the technical performance of a project and compare with the specifications required for project success.
Engineering projects contain their share of risks. Hopefully this has given you a good overview of the engineering risk management process. Good luck in your projects!