Risk Project Plan
Barker, (2007), defines risk as an even that may likely occur and when it does, it will pose a threat to the successful delivery of a project. Another definition he cited in his publication in the year 2004 was that, risk is any uncertainty in a project plan that can be controlled or at least be monitored.
It is therefore apparent from the above definitions that, risk is an uncertainty. That is it is something that can probably occur, and if does, the successful delivery of a project will be in doubt. Though it cannot be prevented from occurring, but it can potentially be controlled or track.
Good decision making by analysing what can go wrong, as well as the probability and severity of the impact is at the root of risk management. Software development is often faced with numerous problems which cause projects to miss deadlines, exceed budgets, or deliver less than expectation. Though these problems cannot be eliminated totally, some of them can be controlled better by taking appropriate preventive measures. Risk management is an area of project management that deals with these problems or threats before they occur. As nothing can be predicted what will happen in future so management have to take the necessary steps in the present to take any uncertain situation in the future. Risk management is about dealing with a concern before it becomes a crisis. The objective of risk management is to avoid or minimize the adverse effects of unforeseen events by avoiding the risks or drawing up a contingency plan for dealing with them.
What is software Risk management?
Software risk management is usually defined as “a set of principles and practices aimed at identifying, analyzing and handling risk factors to improve the chances of achieving a successful project outcome and/or avoid project failure” (Boehm, 1989). According Pressman (2005), “Risk management is a series of steps that help a software team to understand and manage uncertainties”.
From these definitions, risk management can therefore be seen as an approach aimed at dealing with issues that can cause deviation from the project plan.
A successful risk management process is one in which risks are continuously identified and analyzed.
Importance of risk management
Managing risks in software projects is very important because it can help to: “avoid project failure; avoid rework; focus and balance effort; and stimulate win-win situations” (Boehm, 1989). Software risk management also “helps project managers to pin point weaknesses on their plans thereby giving a useful insight to the project's health”. Barker and Cole (2007).
According to Barrow (2007) there are four reasons why risk should be managed.
The first reason he mention is to minimize delays. Project delivery time is very important to the stakeholders of the project. If the potential risks are identified before the commencement of the project and appropriate measure are taken when they occur, then the project results in fewer delays.
Secondly, when a potential risk occurs then arranging resource to deal with the risk become very much time and cost consuming. And one of the most difficult aspects of project management its human resource. Therefore, when risk is effectively managed, the cost of dealing with it will be significantly reduced.
Let take for example, while a project team member is working on task A, a risk happen to occur. Due to poor contingency planning, the project manager calls in a team member Y to come and tackle the risk. But at the same time the team member Y is busy working on task B which depends on outcome of A. It can be understood from this point that the entire project is jeopardy. While team member Y is busy doing task B, in reality he is doing nothing. This whole scenario, if it occurs in a project, will incur cost to it.
Thirdly, when a project come in late or over budgeted or failed entirely, it's financial return can go down, and its reputation is also affected. Managing risk provides the means by which companies can ensure a return on investment. And when late delivery of a project is avoided, it means that projects start repaying their investment earlier. When cost overruns and de-scoping are avoided, profits margins are preserved and the overall benefits of the business are achieved. Allocated budgets for the risk which has not occurred can then be used elsewhere and this also helps in a way to increase profit margins.
Fourthly, the extent of how effectively a project is planned in terms of risk and change management, tells how much a project manager needs to work when the project is running. When all the risk are effectively identified and successfully mitigated, then as a project manager there is a lot of time left when the project is running. On that spare time the project manager can concentrate on other areas which can enhance the output of the project.
Barry Boehm designed a risk management model where he divided risk management into two categorises - risk analysis and risk management.
According to his diagram, recognising what can go wrong is the first step, called risk identification. Once the risks have been identified, they are then assessed for their impact on the project. Once this has been done, the next phase comes in which is the management side. Risk management involves planning, controlling, monitoring, directing and staffing. Planning involves setting up contingency plans for risk that are likely to occur. Planning, monitoring and control will later be discussed. Risk staffing and direction is basically concerned with putting in place people or staff who will be responsible for the daily management of risk. Risk analysis and management
A number of models for risks management are available, but most are similar, in that they identify two key components - risk identification and risk management. Risk identification is systematic approach used to specify threats to a project's plan.
Project managers have to identify the areas where the risk can be and how it can affect the outcome of the project. According to Bob Hughes and Mike Cotterell, factors which need to be considered when identifying risks in software projects include:
The type of application to be developed. Whether it is a simple data processing application (e.g. an airline booking system), a safety-critical system (e.g. a traffic control) or a large distributed system with real-time elements - is likely to be a critical factor. The size of the application is also important - the larger the system, the greater is the probability of errors.
The skills and experience of the staff involved in the project are also major factors - an experienced programmer is, one would expect, less likely to make mistakes or errors than one with little experience. Inexperienced staff can lead to project failures. For example if an experience developer builds a systems component and then leaves before it has been fully tested, the people or person taking over might find that their lack of familiarity with the system makes diagnosis and correction of faults difficult.
It is important that the project and its objectives are well defined and that they are absolutely clear to all members of development team and all the key stakeholders. The requirements of the customer need to be clearly understood before the initiation of the project.
The development methodology also needs to be well defined. Well specified and structured methods (such as PRINCE 2 and SSADM) for project management and system development will decrease the risk of delivering a system that is unsatisfactory or late.
Also when a project requires new hardware for development, then there is a probability of risks compared to one where the software can be developed on existing platform. Also when a system is developed on one type of software or hardware platform to be used on another there might be additional (and high) risks at installation.
Total changeover to a new system also poses particular risks. Gradual changeover minimizes the risks.
Tools and Techniques for Risk Identification:
Tools and techniques in identifying risk in software projects as mention by San Francisco website (http://www.scribd.com) article on Risk-management-for-ICT-project-management, includes:
Documentation review which basically involves going through the organisations' past data, assumptions, plans and outcome. After having a clear idea of these factors project managers will now try to figure out what might appear as a risk in the project.
Information gathering is another common risk identification technique which requires the project stakeholders to arrange a meeting and from the meeting people come up with the list of risk.
From the information gathered, Check lists technique can be used and they are developed based on the organisations' historical data of similar projects. If the same projects are undertaken, then the project managers come up with a list of risks. And when the list becomes comprehensive then the list is being changed into check list and the impact and monitoring techniques are then accordingly designed.
Assumption analysis technique can also be used and it involves the validation of assumptions that are made previously and then documenting them as the project progresses.
There are other two techniques in identifying risk and they are called the qualitative and quantitative methods.
The qualitative risk analysis is a method where the impact of the risk over the project is identified. It also states what the probability of that risk is to occur and then ranks the risks according to priority. It is the first step towards the quantitative analysis of the risk.
One of the tools used in the qualitative method is the Probability and impact assessment which helps to determine how much is the probability of the risk to occur and also how much the risk is going to cost in terms of time and money. Once the probability of the risk is identified and impact of the risk is being assessed, then the probability and risk matrix comes in. Once done, this matrix can make the project manager understand on which risk they should concentrate most. The risk exposure of a project is normally indicated by the position of the risk in a matrix.
The figure bellow is a sample probability and impact matrix.
Low Medium High
Figure 1.2 Sample probability and impact matrix
PMBOK (2000) The New PMBOK Risk Management Concept. http://facweb.cs.depaul.edu/yele/Course/IS372/IS372w3-2.ppt
Based on the risk probability and impact matrix, risks are organized in order of priority. By prioritising risk, project managers can understand which risk they need to look upon first.
The quantitative risk analysis process evaluates the impacts of the risks that have been prioritized during the qualitative process and it quantifies risk exposure to the project by assigning numeric probability for each risks and their impact on the project objective.
A technique used in the quantitative process called sensitivity analysis is used to analyze potential risk event on the project by determining which risk event has greatest potential to impact the outcome of the project.
Another technique used in the quantitative risk analysis process is the Expected Monitory Value Analysis, which is a statistical technique that calculates average and the anticipated impact of the decision. EMV is calculated by multiplying the probability of the risk times its impact and then adding them together.
A diagramming analysis technique called decision tree is also used to aid in selecting the best course of action in situations in which future outcomes are uncertain by determining an outcome in a logical way. The figure below shows a sample decision tree using EM vans one of its inputs.
Good outcome probability .6
Poor outcome probability .4
Good outcome probability .8
Poor outcome probability .2
Figure 1.3 Sample Decision Tree using EMV
Having identified the areas where a risk is likely to occur and the risks that might affect the project, there is a need of assessing their importance. Some risks will be relatively unimportant (for example, the risk that some of the documentation is delivered late), whereas some will be of major significance (such as the lack of skills)
“The probability of a hazard's occurring is known as the risk likelihood; the effect that the resulting problem will have on the project, if it occurs, is known as the risk impact and the importance of the risk is known as the risk value or risk exposure” (Software Project Management, Bob Hughes and Mike Cotterell).
After the risk is analyzed, the next step is to priorities the risk. At first focus has to be made on the most sever risk; and then the less sever ones. So most of the time project management team fails to identify the sever risk and work on the less sever risk. This often results in the form of a crisis.
The goal of risk analysis is to assist the project development team in developing a strategy for dealing with risks. According to Roger S. Pressman, an effective strategy must consider the following three features: risk avoidance, risk monitoring and contingency planning.
According to Pressman (2005) risk avoidance is best if a software team adopts a proactive approach to risk. Dealing with the risk is an art. Management should always try to identify the proper risk involved in a particular project. Therefore, an experienced manager will take the project after proper risk analysis and avoid any risk involved in the project.
Planning is a process which determines which actions to take while risk poses a threat to the project. There are a number of strategies which can be used in risk response planning. The strategies that can be used include, risk avoidance, transferring or outsourcing the risk to another person or organisation other than those involved in the project, trying to tackle the risks in hand, sharing the risk among different parts of the project, enhancing the impact of the opportunity, risk acceptance (i.e. accepting the impact of a risk if it occurs and drawing up a contingency plan.
A contingency plan is used by project managers to create some tasks which will be regarded as alternative of the actual plan. The contingency tasks are managed in a way that when the risk occurs, the contingency tasks starts automatically. And when it does all the procedures are properly documented.
Monitoring and control is a process where the project manager monitors factors that may likely provide an indication of whether a risk is becoming more or less likely to occur. According to Barker and Cole (2007), it is not something that is done only at the start of the project. It has to be continuously done throughout the existence of the project. It basically involves rechecking the risk log, and project charter and objectives and finding out if already defined risks are efficiently managed. And whether there is likelihood for a potential risk to come up.
Risk management is most effective when carried out in the early stages. A properly structured risk identification, analysis, and mitigation process can solve the risks associated with projects. Stakeholders in a project play important role in successful management of risk in an organization. A successful risk management process is one in which risks are continuously identified and analyzed for relative importance. Risks are dealt with, tracked and controlled to effectively use program resources. Risks are prevented before they occur and personnel should consciously focus on what could affect product quality and schedules.
Project managers should accept the fact that risk assessment and management is not a substitute for adequate pre-project planning, project controls, or other management and technical requirements.
Risk analysis and management can absorb a significant amount of project planning effort. Identification, evaluation, contingency planning, monitoring and control all take time, but the effort is worthwhile. References and Bibliography:
- Barker, Stephen and Cole, Rob (2007) Brilliant project management: What the best project managers know, say and do. Pearson Prentice Hall.
- Barkley, Bruce T. (2004) Project Risk Management. McGraw-Hill.
- Lock, Dennins (2003) Project Management. Gower 8th Edition.
- Bob Hughes and Mike Cotterell (Second Edition) Software Project Management
- Bob Hughes and Mike Cotterell (Fourth Edition) Software Project Management
- Wiegers, Karl E. (2007) Practical Project Initiation: A Handbook with Tools. Microsoft Press.
- Roger S. Pressman (Sixth Edition) Software Engineering, A Practitioner's Approach. Risk Management-Chapter 25 (pp 727)
- Roger L. Van Scoy Software Development Risk: Opportunity, Not Problem, www.sei.cmu.edu/pub/ducuments/92.reports/pdf/tr30.92.pdf (Accessed 23/06/08 Time 22.45)
- Barrow, Bryan (2007) Four Reasons to Use Project Risk Management. http://www.bcs.org/server.php?show=ConWebDoc.16427 (Accessed 04/04/08 Time 09.34)
- Elyse (2007) Qualitative Risk Analysis. http://www.anticlue.net/archives/000817.htm (accessed 28-06-08 Time 18.32)
- AIRMIC, IRM and ALARM, (2002) Risk Management Standard. www.theirm.org/publications/documents/Risk_Management_Standard_030820.pdf (accessed 25/06/08 Time 19.54)
- Risk-management-for-ICT-project-management http://www.scribd.com/doc/2658578/ (accessed 29/06/08 Time 22.17)
Need an essay? You can buy essay help from us today!