Project Plan Software
Barker (2007) defines risk as an event that may likely occur during the development or process or a project 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 tracked.
It is therefore apparent from the above definitions that, risk is an uncertainty. That is it is something that can probably occur, and if it 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 problem areas in a software project, in addition to the probability and seriousness of the effect is at the root of risk management. Software projects are normally faced with numerous challenges which make projects to complete late, to go beyond the estimated cost, or perform under expectation. Although these challenges cannot be one hundred percent avoided, but some can be managed by putting in place the necessary remedial actions. Risk management is that aspect of project management that takes care of these problems before they come up. As future happenings cannot be predicted and known exactly, therefore, management should always try to take the appropriate measures in the present to deal with any threat that might come up. Managing risk is about dealing with uncertainties before they become threats. And 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 to Roger S. Pressman (2005), Risk management is a series of steps that help a software team to understand and manage uncertainties.
From these definitions, we can conclude that risk management can therefore be seen as an approach aimed at dealing with issues that can cause deviation from the project plan.
Importance of risk management
Managing risks in software projects is very significant in the sense that it can help 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 becomes very much time and cost consuming. And one of the most difficult aspects of project management is its human resource. Let's 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 the outcome of A. It can be understood from this point that the entire project is in 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. But, when risk is effectively managed, the cost of dealing with it will be significantly reduced
Thirdly, when a project come in late or over budgeted or failed entirely, its 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 the potential areas where risk can occur is the first step, called risk identification. After those areas are know, 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, staffing and directing. 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 for the daily management of risk. Boehm's diagram is shown below.
Figure 1.1 Boehm's software risk management model
From:
Boehm
Tutorial on software
risk management
IEEE computer society
1989
Risk analysis and management
A number of techniques for risks management are available, but most are similar, in that they focus on two key areas - risk identification and risk management. Risk identification is a systematic approach used to specify threats to a project's plan.
Software Project managers should always try know the potential areas where risks can occur and what impact they can have on 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 - can 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 lower 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.
Techniques and tools for Risk Identification
Techniques and tools in identifying risk in software projects as mentioned 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 technique is 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.
A tool 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.
|
High Risk 6 |
Risk 9 |
Risk 1 Risk 4 |
|
Probability medium Low Risk 3 Risk 7 |
Risk 2 Risk 5 Risk 11 |
|
|
Risk 8 Risk 10 |
Risk 12 |
Low Medium High
Impact
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 technique evaluates the impacts of the risks which have already been prioritized during the qualitative process and it evaluates risk exposure to the project by giving numeric probability for all the risks and their effect on the project's 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 method is the Expected Monitory Value Analysis, which is a statistical technique that calculates average and the anticipated impact of the decision.
A diagramming analysis technique called decision tree is also used to aid in selecting the best approach in dealing with situations in where future happenings 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
4200
Choice X
EMV=7000
Poor outcome probability .4
2000
Decision start
Good outcome probability .8
4000
Choice y
EMV=6000
Poor outcome probability .2
1000
Figure 1.3 Sample Decision Tree using EMV
Source:http://www.scribd.com/doc/2658578/Risk-management-for-ICT-project-management
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 potential of a risk to happen is called the risk likelihood; the impact or consequences it does to the outcome of the project, if it happens, is called risk impact and the severity of the risk called risk value or risk exposure.
Source: (Software Project Management, Bob Hughes and Mike Cotterell).
Having analyzed the risk, then prioritising the risk will follow. Firstly, more concentration has to be made on the most sever risk; and then the less sever ones.
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. Management should always try to identify the exact risk involved in a particular project. Therefore, a wise project manager will undertake a project after proper risk analysis, thus avoiding 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.
Conclusion
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. Risks are prevented before they occur and project managers should critically focus on what could affect product quality and schedules. They 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)
We provide a professional essay writing service that thousands of our customers use as an effective way of improving their grades, improving their research and saving them lots of time.
