Risk Management And Project Risk Management
Risk Management - Any large scale projects involve certain risks and that is true of software projects. Risk management is an emerging area that aims to address the problem of identifying and managing the risks associated with the software projects.
The basic motivation of having risk management is to avoid disasters of heavy losses. The current interest in risk management is due to the fact that the history of software development projects is full of major and minor failures. A large percentage of projects have run considerably over budget and behind schedule, and many of them have been abandoned midway. It is now argued that many of these failures were due to the fact that the risks were not identified and managed properly.
Risk management is an important area, particularly for large projects. Like any management activity, proper planning of that activity is central to success.
Risk Management Overview
Risk is defined as an exposure to the chance of injury or loss. That is, risk implies that there is a possibility that something negative may happen. In the context of software projects, negative implies that there is an adverse effect on cost, quality, or schedule. Risk management is the area that tries to ensure that the impact of risks on cost, quality, and schedule is minimal.
Like configuration management which minimizes the impact of change, risk management minimizes the impact of risks.
Risk management can be considered as dealing with the possibility and actual occurrence of those events that are not "regular" or commonly expected. The commonly expected events, such as people going on leave, resource unavailability or some requirement changing are handled by normal project management. So, in a sense, risk management begins where normal project management ends.
Most projects have risk. The idea of risk management is to minimize the possibility of risks materializing, if possible, or to minimize the effect of risk actually materializing.
It should be clear that risk management has to deal with identifying the undesirable events that can occur, the probability of their occurring, and the loss if an undesirable event does occur. Once this is known, strategies can be formulated for either reducing the probability of risk materializing or reducing the effect of risk materializing (risk mitigation). So the risk management revolves around risk assessment and risk control.
Risk Assessment
Risk assessment is an activity that must be undertaken during project planning. This involves identifying the risks, analyzing them, and prioritizing them on the basis of the analysis. The major planning activity in risk management is assessment and consequent planning for risk control. Due to the nature of a software project, uncertainties are most near the beginning of the project. As the project nears its end, risks can be assessed more precisely. Due to this, although risk assessment should be done throughout the project, it is most needed in the starting phases of the project. In addition, early identifying risk provides the management with a lot of time to effectively handle the risks.
At a very high level, the software risks can be broadly divided into three categories:
Cost risk
Performance risk
Schedule risk
Cost risk is the degree of uncertainty associated with budgets and outlays for the project and its impact on the project. Performance risk is the possibility that the system will be unable to deliver all or some of the anticipated benefits or will not perform according to the requirements. Here performance includes quality. Schedule risk is the degree of uncertainty associated with the project schedule or the ability of the project to achieve the specified milestones.
The goal of risk assessment is to prioritize the risks so that risk management can focus attention and resources on the more risky items. Risk identification is the first step in risk assessment, which identified all the different risks for a particular project. These risks are project-dependent, and their identification is clearly necessary before any risk management can be done for the project.
Some list of risks specific to the projects and solutions:
Personnel Shortfall: Staffing with top talent, Job matching, Teambuilding, Key-Personnel agreement, Training, Rescheduling Key People.
Unrealistic Schedules and Budgets: Detailed multisource cost and schedule estimation, Design to cost, Incremental development, Software reuse, Requirements scrubbing.
Developing the wrong software functions: Organization Analysis, Mission Analysis, User Surveys, Prototyping, early user manuals.
Developing the wrong user interface: Prototyping, Scenarios, Task Analysis, and User characterization.
Gold Plating: Requirements scrubbing, Prototyping, Cost-Benefit analysis, Design to cost.
Continuing Stream of requirements changes: High change threshold, Information hiding, Incremental development
Shortfalls in externally furnished components: Benchmarking, Inspections, Reference checking, Compatibility Analysis.
Shortfalls in externally performed tasks: Reference checking, Pre-award audits, Award-fee contracts, Competitive design or Prototyping, Teambuilding.
Real-Time performance shortfalls: Simulation, Benchmarking, Modeling, Prototyping, Instrumentation, Tuning.
Straining Computer Science Capabilities: Technical Analysis, Cost-Benefit Analysis, Prototyping, Reference checking.
The top-ranked risk item is personnel shortfalls. This involves just having fewer people than necessary or not having people with specific skills that a project might require. Some of the ways to manage this risk is to get the top talent possible and to match the needs of the project with the skills of the available personnel. Adequate trainings along with having some key personnel for critical areas of the project will also reduce this risk.
The next item, unrealistic schedules and budgets, happens very frequently due to business and other reasons. It is very common that high-level management imposes a schedule for a software project that is not based on the characteristics of the project and is unrealistic. This risk applies to all projects. Project-specific risks in cost and schedule occur due to underestimating the value of some of the cost drivers. Recall the cost models like COCOMO, Function Point estimates. Even the size estimate is correct, by incorrectly estimating the value of the cost drivers; the project runs the risk of going over budget and falling behind schedule. The cost and schedule risks can be approximated by estimating the maximum value of different cost drivers along with the probability of occurrence and then estimating the possible cost and schedule overruns.
The next few items are related to requirements. Projects run the risk of developing the wrong software if the requirement analysis is not done properly and if development begins too early. Similarly, often improper user interface may be developed. This requires extensive rework of the user interface later or the software benefits are not obtained because users are reluctant to use it. Gold plating refers to adding features in the software that are only marginally useful. This adds unnecessary risk to the project because gold plating consumes resources and time with little return. Some requirement changes are to be expected in any project, but some time frequent changes are requested, which is often a reflection of the fact that the client has not yet understood or settled on its own requirements. The effect of requirement changes is substantial in terms of cost, especially if the changes occur when the project has progressed to later phases. Performance shortfalls are critical in real-time systems and poor performance can mean the failure of the project.
If a project depends on externally available components – either to be provided by the client or to be procured as an off-the shelf component or dependency with other services – the project runs some risks. The project might be delayed if the external component is not available on time. The project would also suffer if the quality of the external component is poor or if the component turns out to be incompatible with the other project components or with the environment in which the software is developed or is to operate. If a project relies on technology that is not well developed, it may fail. This is a risk due to straining the computer science capabilities.
Using the checklist of the top-10 risk items is one way to identify risks. This approach is likely to suffice in many projects. The other methods are decision driver analysis, assumption analysis and decomposition. Decision driver analysis involves questioning and analyzing all the major decisions taken for the project. If a decision has been driven by factors other than technical and management reasons, it is likely to be a source of risk in the project. Such decisions may driven by politics, marketing, or the desire for short-term gain. Optimistic assumptions made about the project also are a source of risk. Some such optimistic assumptions are that nothing will go wrong in the project, no personnel will quit during the project, people will put in extra hours if required, and all external components (hardware and software) will be delivered on time. Identifying such assumptions will point out the source of risks. An effective method for identifying these hidden assumptions is comparing them with past experience. Decomposition implies breaking a large project into clearly defined parts and then analyzing them. Many software systems have the phenomenon that 20% of the modules cause 80% of the project problems. Decomposition will help identify these modules.
Risk Control
Whereas risk assessment is a passive activity identifying the risks and their impacts, risk control comprises active measures that are taken by project management to minimize the impact of risks. Though risk assessment is primarily done during project planning as risk assessment in early stages is most important, like cost and schedule estimation, the assessment should be evaluated and changed, if needed, throughout the project.
Like any active task (e.g., configuration management, development), risk control starts with risk management planning. Plans are developed for each identified risk that needs to be controlled. Many risks might be combined together for the purposes of planning, if they require similar treatment. This activity, like other planning activities, is done during the project initiation phase. The risk management plan has five components.
These are
i) Why the risk is important and why it should be managed
ii) What should be delivered regarding risk management and when
iii) Who is responsible for performing the different risk management activities,
iv) How will the risk be abated or the approach be taken, and
v) How many resources are needed?
The main focus of risk management planning is to enumerate the risks to be controlled (based on the risk assessment) and specify how to deal with a risk. One obvious strategy is risk avoidance, which entails taking actions that will avoid the risk altogether.
Another obvious strategy is risk reduction; if the risk cannot be avoided, perhaps the probability of the risk materializing can be reduced or the loss due to the risk materializing can be reduced.
The actual elimination or reduction is done in the risk resolution step. Risk resolution is essentially implementation of the risk management plan. For example, if the risk avoidance is to be user, the activities that will avoid the risk have to be implemented. Similarly, in the plan it might have been decided that the risk can be reduced by prototyping. Then prototyping is done in the risk resolution step and necessary information obtained to reduce the risk. Incidentally, prototyping is very important technique for reducing risks associated with requirements or reducing risks of the type "perhaps this cannot be done?"
Risk monitoring is the activity of monitoring the status of various risks and their control activities. Like project monitoring, it is performed through the entire duration of the project. Like many monitoring activities, a checklist is useful for monitoring. While monitoring risks, like with monitoring costs and schedules, reassessments might need to be performed, if the real situation differs substantially from the situation predicted earlier based on assessment and planning.
All projects are essential and every project has its own risk elements. Commencing from initiation to post completion of the project, the degree of risk grows within, as does the haze of uncertainty, thus proper project risk management can make a difference.
Risk inevitably comes with any project. It resides in the project as a contrary and hinders as an adversary. Enclosed within, the compound constraint of time, budget, workforce and multiple quantifiable and non-quantifiable determinants; a project marches towards its success and the risk factors follow until project execution.
To be precise, "risk" in a project management is the threat or possibility that an action or occurrence will unfavorably affect a project's potentiality to achieve its objectives. Any counter event and adverse causes that can become an obstacle are risk factors.
However, inside the project management line of attack is the term "risk" this term is considered as a negative component resembling an occurrence that will adversely affect the goal of the project. Nevertheless, in the optimistic and neo project management approach, "risk" can be considered as a prospective occurrence or a productive event; if handled and executed properly it may lead to achieve enhanced objectives, improved and advanced.
Project risk management is the procedure of determining or evaluating risk and developing strategies to manage it, and is concerned with identifying risk and putting in place policies to eliminate or reduce these perils.
Project risk analysis is the detection and quantification of these probabilities and collisions of events that may harm the project. The risk analysis process identifies risk in advance, and the risk management process established methods of avoiding these risks thus reducing the impacts that may occur.
Risk Detection
Risk detection is an initial step in the risk management course. As these potential hazards occur causing problems in its kinetics there needs to be a plan for identification. To identify these concealed threats at their origin before their occurrences whether they are quantifiable or non-quantifiable is the foremost groundwork; this groundwork is the risk identification course of action.
Risk detection starts with tracing risk sources as a root cause, and its source branches including internal to external and primary to secondary.
Some of the most common risk detection methods in project risk management are as follows;
1. Objective Oriented Risk Detection
2. Scenario Oriented Risk Detection
3. Taxonomy Oriented Risk Detection
4. Regular Risk Inspection
Risk Evaluation in Project Risk Management
Once the risk detection process is concluded, then they must be evaluated for their latent severity for loss, and its likelihood for hazards. In project risk management, each risk should be exploited independently as they vary from simple to complex results.
Generally, plain risk can easily be quantified, while those risks of probabilities are unfeasible to enumerate; thus in the evaluation process it is significant to take a finer presumption to accurately accentuate the implementation of the risk management remedy. Moreover, the primary problem in risk evaluation is lack of statistical information and scientific evidences for determining the pace of risk events that may occur.
Conversely, gauging risk is often quite a complicated process, although numerous formulae are being followed; a popular yet simple formula is;
Project Risk = Accident X (Probability X Impact)
Or
Project Risk = Accident Probability X Accident Impact
Here, risk is directly equivalent to "probability of accident" multiplied by the "impact of accident". In opposition, project risk management is less reliant only on the type of formula pursued, but more reliant on the risk occurrence and on how risk management is employed.
However, in general a systematic tactical plan that should be prearranged for risk management is as follows:
Risk: Description of the Actual Risk
Impact: Impact on the Project if the Risk Occurs
Possibility: Possibility of Loss if Risk Occurs
Action: Action Remedy to Reduce the Impact
Cost: Cost if the Risk Occurs
Once risk is identified and evaluated, there are four major practices that need to be followed to prevent a failed remedy, they are:
1. Risk Evasion: Avoidance of the Risk Altogether
2. Risk Diminution: Reducing the Degree of Risk through Precaution Measures
3. Risk Retention: Accepting the Degree of Risk with Loss
4. Risk Relocating: Transferring the Risk to Another Party
Hence, in the combat of project risk management etiquette, a precedence procedure should be tracked, whereby risks with the maximum loss and the maximum probability of evils should be handled first; vice versa to those with minimum risk.
Project risk management is the tactic of methodically applying lucrative action for diminishing the effect of hazard to the project. Risks are never fully avoidable due to exterior elements and limitation of financial and practical margins. However, with the acceptance of a certain degree of risk and the arrangements of its counter to tackle it, the risk at hand can be recompensed.
All risks can never be fully avoided or mitigated, therefore all projects have to accept some level of residual risks, but if the risk is handled with mythological and proficient approach referring to statistically and scientific information then risk rewards.
Project risk management is one single process to manipulate, exploit, and extinct risk.
References
Continuous Risk Management Guidebook, Pittsburgh, PA:Software Engineering Institute
Barry W. Boehm. Tutorial: Software Risk Management, IEEE Computer Society Press
Thank you for read this Pesonal Financial Artiles - Risk Management And Control, Next Articles What is Identity Theft
Author : Vamsi Mohan Vandrangi : Bharat Bista - edited by - Bruce Cullen
