Risk management in project development

Risk management in project development Risk Management In Software development Abstract: Risks are always associated with any kind of project development. It is important to identify and control the risks associated with any project as important it is to develop a project. Especially with software projects there are many unexpected problems which may hinder the software development process. It is crucial to control these risks from the technical development of components for a project to be successful. Hence the software industry is seeing software development risk management as an important practice to minimize the occurrence of risks associated with the project. This research papers gives an insight into various risks associated with software development and the methods to reduce these risks. Introduction: Risk management is a very interesting topic in todays world. Now as days we see that software is an essential part of any application and is used in every company for various purposes. Software has become an important part of life and is practically used in everyday life for various purposes. Now days, due to increase in software companies and usage of internet, a lot of complex and large software projects are developed. These projects have constraints of resources, cost and schedule. So it becomes necessary to build these projects risk free as there are many factors and constraints associated with it. In the present competitive world, there are a lot of companies making various softwares which are large scale and small scale. With this huge scope developing software, comes the risks of managing and developing successful software. Technology is advanced tremendously but still the problems and risks related to software development exist. Research has shown that 85% of all projects being developed fail due to various risks associated with project development. Out of these 40% completely fail due to incomplete requirements and 46% due to cost and schedule over runs and improper functionality. So, effective risk management is important for successful project development. Risk: A Risk is the occurrence of an event which can adversely affect or hinder the development process. A risk is any event which is likely to happen or not but if it does happen will have a negative effect on the project. Risk cannot be classified into various categories but it is the types of risks that need to be identified which are associated with a project. The risks may vary from managing team members, resources and changing environment or technology. Technical risks lie at the heart of most of the causes of software project failures. Technical risks can be defined as the possibility that the application of software engineering theory, principles, and techniques will fail to yield the right software product. Technical risk is comprised of the underlying technological factors that may cause the final product to be: overly expensive, delivered late, or unacceptable to the customer. (Dhlamini, J. 2009) Risk Management and Factors Responsible for Risks: Risk Management can be defined as An application of appropriate tools and procedures to contain risk within acceptable limits by identifying, addressing, and eliminating potential problems before they damage a project.(Dhlamini, J. 2009). It contains processes, methods and tools for managing risks associated with a software project. The basic aim of risk management is to early analyze and identify the risks associated with the project development and take the necessary steps change the course of action to minimize the risks. Risk Management is basically a continuous and formalized process of assessment which requires a team-oriented and needs open communication between all the members. The various factors responsible for risks in development of software projects are scope, resources, cost, communication, integration, time scale, quality and contracts. Every factor has its own risk and affects the project development in a way if not managed properly. Like if the project is outsourced there are times when the communication is not clear between the offshore and onshore team. Most of the times to cut the costs the management, might not use the right sources required for the project resulting in a failure. Sometimes the requirements are not defined properly with may result into a product which is not per the expectations thus affecting the quality of the product. At times, while the project is half way through and there is a change in the technology and company policy which may affect the project. Many times, stakeholder conflicts may also affect the project cost and deadline. Integration is also an issue if many teams are participating in project development. Risk Management Models: There have been various approaches and models proposed for software risk management based on the research on the risks associated with projects and the experiences of the project managers and professionals. There are a few basic approaches for risk management. They are traditional and risk-oriented method. The traditional approach is very generic to all the projects deals with the risks associated with all the projects in general and specific to a particular project. The second approach is risk-oriented which deals with identifying the risks associated with a specific project and aims to deal with those risks before they harm the project. Goal Driven Software Development Risk Management model is a risk-oriented approach to deal with the risks associated with the software project development. There are many such models that were proposed like the first one proposed by Barry Boehm in 1988. His proposed a framework by collecting all the requirements and measures together. SEI (Software Engineering Institute-1997) also proposed a risk management framework. The goal of this framework was to help the manager, developers and other decision makers to identify the risks at an early stage of development, so that appropriate measures can be taken at the right time to minimize the risk. Karolak in 1996 also proposed a model for risk management to handle high level risks. This model proposed a model to handle the risks which affect the cost and time of project development. The various methodologies for risk management are given below: a) Goal Driven Software Development Risk Management Model (GSRM): The GSRM is risk management approach which consists of a model of four layers to manage risks in software development. The advantage of using a layered approach is that any technique can be applied to any layer at any time without affecting the other layers. The diagram for the GSRM is shown below, Goal Layer: This is the first layer in GSRM where identifying, elaborating and modeling of goals are done based on the components to be developed for project to be successful. Success of a project can be defined as anything like meeting the deadlines, within estimated cost, fully functional project, meeting the user requirements, etc. So, success means identifying all the technical component development to be done as early as possible. In GSRM, the goals can be identified as project scope, business needs, user requirement, cost estimation, schedule, etc. So these goals in the development process must be ensured to be within project scope, maintained under decided budget and to realistic time scale, achieve all the business needs and reduce risks based on the nature of project, for a successful project development. Many times these goals may be too high so they are divided into small goals which can be achieved at different levels of abstraction. So it is important to attain these small goals to attain the final goal. Due to this, it is easy to model the development components where satisfying the goal makes it easy to final project fulfillment. (Islam, S. 2009) Risk-Obstacle Layer: This is the second layer in the GSRM model, which identifies the risks associated with the project development. These risks can be considered as potential obstacles which are identified from the early developed components and can affect the project goal. Many times there are processes that depend on each other and if there is an obstacle in one of the process it may cause obstruction in other processes also. Obstacles can be due to human error, wrong information, vague/incomplete requirements, miscommunication, wrong technology implementation, etc which may obstruct the achievement of goals resulting in affecting the time scale and cost of development. So risk obstacle identification is done through questionnaire, cross checking the requirements and brainstorming with the stakeholders. A set of brainstorming session and questionnaire is followed after the initial set of components developed to identify the risks before they worsen. These risks are then assessed by the assessment laye r. (Islam, S. 2009) Assessment Layer: This is the third layer in GSRM, where the risk is properly analyzed and explained the event that caused the risk to occur. The risk event that has caused the risk has two properties: likelihood and severity. Severity increases the negative impact of the risk event and likelihood is the possibility of a risk occurring due to the event. There are some risk factors that can give rise to one risk event which may cause many obstacles leading to disturbing the final goal. So this allows in analyzing the various risk factors and the impact that these risks will have on the set of goals to be achieved. So this layer considers risks metrics to identify the likelihood of occurrence of the risk event due to the risk factors. These risk metrics considers the risk factors, risk occurrence likelihood and risk severity for analyzing and measuring the risks which makes the process very easy and simple to identify the risks at early stage of development. For the assessment this model uses Bayesians subjective probability for analyzing the risks events that occurred due to risk factors. In this model, on those risk events that have a negative effect on the goals to achieve are considered. So, this layer basically gives the risks in the order of likelihood and severity that may affect the satisfaction of the final goal to be achieved through obstruction link. (Islam, S. 2009) Treatment Layer: This is the last layer in the model and this layer is to identify the set of actions that can be taken to reduce the risks and also selects the most appropriate action required for the particular risk so as to minimize the effect of the risk in achieving the final goal. Basically, this layer comes into action when the goals, risk factors and risk events have been identified and analyzed by the previous layers and a cost effective measure is required to be implemented to achieve the goal. For this, there can be various agents within the development environment like humans or some tools are used to satisfy the goals. So it is very important to consider the cost benefit of using a particular agent. Hence it becomes very much necessary to model, reason and trace a situation in the software development atmosphere to control and minimize the risks to attain the final goal. (Islam, S. 2009) Boehms Model: Boehm proposed a model in 1988 for risk management in software development. This model was based on spiral model and proposed a framework for minimizing the impact on risk by integrating risk management methods into software development model. The main idea behind this approach is to remove the anticipated risks at an early stage to avoid their occurrence and effect on the later stages of development. (Dhlamini, J. 2009) Boehms model stated that risk management can be divided into two subcategories i.e. Risk control and Risk Assessment. Risk Assessment can again be sub-divided into risk identification, risk analysis and risk prioritization. Risk Control can be sub-divided into risk management planning, risk resolution and risk monitoring. In risk assessment, the risks are basically identified, their impacts are analyzed and a priority is set based on the impact of analyzed risks. Then in Risk Identification all the possible risks that can arise during the project development phase. So this consists on maintaining checklists, suggestions, documentation, assumption analysis and decomposition. The risk analysis stage where the potential of the risk is identified and the probability of its occurrence. It includes the analysis of performance and network. Now once the risk is identified and analyzed comes the risk prioritization stage. In this stage the risk is prioritized based on the value of the impact of that risk. This basically helps in exposing the risk so that it can be taken care of before it aggravates. (Dhlamini, J. 2009) An example for the above can be given as below where the risk factors affecting Satellite Experiments software are given in the table below. The table below shows various factors affecting the project development. The column of Unsatisfactory Outcome shows the various reasons affecting the project. The second column shows the probability of that occurrence on the scale of 1-10. The third column shows the loss occurrence and the last column shows risk exposure. Software Engineering Institute (SEI): The framework provided by the SEI for software risk management is to enable three groups, namely the Software Risk Evolution (SRE), Continuous Risk Management (CRM) and Team Risk Management (TRM). The main motive behind developing this framework is to enable the decision makers like the stakeholders, customers, managers and engineers to identify the risks associated with the software development cycle like analysis, requirement gathering, developing, integrating and testing, so that appropriate minimizing strategies can be applied at the right time. These methodologies have relatively three fundamentally different objects i.e. risk prevention, risk mitigation and correction and ensuring safe system failure. To achieve these three objectives there are seven principles for risk management. (Dhlamini, J. 2009) They are, Shared Product Vision: It focuses on results. It is based on sharing product vision related to a common purpose and shared ownership. Teamwork: It defines working together as a team for achieving a common goal by pooling skills, talents and knowledge. Global Perspective: The system design and development is viewed from a global perspective of building a larger system. Identifying the potential of the final product from a global perspective and also the impact of adverse effects like cost and time overrun or not meeting the requirements. Open Communication: Making sure that communication is open between all the members involved in the project at all levels. By supporting formal and informal communication where required. Supports a consensus-based process where individual is allowed to give an opinion regarding the risk associated with the project. Forward-Looking View: It thinks about tomorrow, identifies the associated uncertainties and possible outcomes along with managing project resources and activities. Integrated Management: Making risk management an integral part of project development process. Adopting risk management tools and methodologies to project development process. Identification is the first step in SEI model. In this step the issues which will affect the project goal are identified. In the next step of analysis, these risks are analyzed by the decision makers to work on these risks. In the planning stage these risks are prioritized in the order of value which might affect the final goal. Then each risk in the order of priority is taken into consideration and a study is done on that risk is done during planning so that an appropriate action can be taken against them to avoid the risk and minimizing their impact. Then proper measures are taken so as to make sure that are risks are handled as they are planned. Thus tracking of all the measures taken is done to see if things are going as planned and all the necessary control measures are executed. Communication present at the center of the model facilitates connection between all the steps in the model. (Dhlamini, J. 2009) While implementing the SEI model all the activities follow a sequence of steps. The risk and mitigation database lies at the center of the model and is responsible for all the communication between various activities. It is responsible for identifying all the risks and making an entry for all the new risks that have been identified. Risks like cost overrun, increase in time scale, resources problem, vague requirements, improper functionality, improper testing, inefficient testing tools and no time for testing. Many times the risks are identified before they arise actually. Like increase in the cost of development, lack of proper resources or incomplete requirements. At times when huge projects are to be handled, they are generally broken into smaller sub-parts. (Dhlamini, J. 2009) In each sub-part different methods and criteria of handling risks. In this case, there is less time and cost required to handle these risks and is efficiently handled. These risks are prioritized based on their impact value, dependency, cost and resources required to minimize them. Risk mitigation plan is then made based on the priority of the risk, so as to give preference to high probability risk. This plan is documented so as to keep a track all the risks in the order of priority and a record of all the risks that are handled and ones remaining. This plan is then updated on regular basis as and when a risk is taken care of and they no longer exist. (Dhlamini, J. 2009) Riskit Method: Riskit Method was proposed by Jyrki Kontio in 1996 which mainly focused on goals and stakeholders. This model is very much based on theoretical concepts based on the experience. This model was proposed based on the previous developers experience. The main characteristics of this model are fully operational definition of process, risk management, scope, focus, authority, processes and steps for identifying and defining goals of the project. Riskit method has five elements of risk. Risk Elements in Riskit Method: Risk Factor: It is an attribute which may affect the likelihood of occurrence of a risk. Risk Event: It is an event of occurrence of a negative incident. Risk Outcome: It is a situation that occurs between the risk occurrence and before corrective measures implemented. Risk reaction: It is an action taken in response to the occurrence of the risk and the effect of the risk occurrence. Risk Effect Set: It is the effect of the risk event occurrence and the set of characteristics which are affected by the risk event. The seven steps in Riskit process are: Risk Management Mandate Definition: In this step the scope and frequency of risk management are defined with all the stakeholders being recognized. The output of this step is to mandate risk management like how, why, when, where, what, whom, etc. Goal Review: In this step all the predefined goals of the project are reviewed and refined and the new refined goals are clearly defined. Then the stakeholders associations analyze the redefined goal. Risk Identification: In this step, various potential risks associated with the project are identified and listed down. Risk Analysis: In the analysis phase, all the identified risks are classified in the order of priority. These risks effects are then estimated for all the possible scenarios. Then the probability of utility losses due to these risks is estimated. Finally, a graph is prepared based on the estimated risks and their scenarios. Risk Control Planning: Now, once the risks have been graphed based on their value of impact, the most important risk is taken for risk control planning. Then all the members decide and propose control actions to be taken for a particular risk. Then a controlling action is decided and finalized. Finally, the decided action is taken to control the risk. Risk Control: In this phase, the action for risk control decided in the previous stage is executed, resulting in reduced risks. Risk Monitoring: After the risk control stage, the risks are monitored to check their situation resulting risk status. (Dhlamini, J. 2009) FMEA Technique: FMEA technique is a risk management technique which stands for Failure Mode Effect Analysis. These days due to heavy competition companies realize the need for innovation but fear failure or sometimes ignore the risks associated with it, resulting in failure. Due to bad design, implementation and testing it may result in heavy loss, incomplete functionality or even decline in market share. To overcome this fear of failure and we need a process that will identify the failure modes that will damage customer satisfaction, recognize the reason for failure and see the causes of failure. This will help to identify the critical failure areas and take the necessary action to avoid the situation. So FMEA technique is used which provides a tool for recognizing the risk areas from design to production which may lead to failure. (Stunell, P. 2003) The FMEA process consists of a certain steps. The first step is identification of the risks that can occur during the project development process from design to development. In this step, first raw information is gathered from the stakeholders, managers and team members and previous projects in a structured format so that a knowledge base is create to identify all the potential risks that can arise leading to project failure. The next step is to assign a value to that risk based on its probability of occurrence, the impact of risk and detection based on the analysis of team members, stakeholders and other professionals. Then a Risk Priority Number (RPN) which is used to identify the probability of occurrence of a risk and the effect of its occurrence. This will help in taking a corrective measure at the right time so that the product goes as decided and has customer satisfaction.RPN uses rating scales based on the severity of the consequence for a particular risk, probability of the failure due to its occurrence and probability of a risk occurrence. (Stunell, P. 2003) The rating is done on the scale of 1 to 5 or 1 to 10 based on this rating the severity of the risk is calculated. For example, in the rating of 1 to 5, generally a risk whose value is 5 is very likely to occur than the one having a value 1. The figure below shows a scale of 1 to 5. Then once this is done a graph or scatter plot is created based on the RPN and risk value. Then based on these calculated values a priority list is created for all the risks. A risk response plan is created after the priority is created and the risks are re-evaluated based on the RPN and risk value. Once the risk is identified then accordingly the corrective steps are taken to reduce the risk. After the action is taken again, the calculations are done to see the effectiveness of the action. This helps in knowing the percentage reduction in RPN. (Stunell, P. 2003) Advantages Disadvantages of Risk Management: Advantages: Risk Management helps in early detection of problems associated with the project. It helps in preparing the development team to face the future problems. It reduces overall cost of the development which might increase due to risks associated with the project. Helps in taking the right steps like proper developers, technologies, time scale, etc. Disadvantages: It takes time during the initial stages as it requires analysis and information gathering on the possible risks associated with the project. It may also increase the overall cost of development. My View-Point: This paper is based on my research on the various risks associated with the project development and the methods to minimize these risks. Since the advancement of technology and scope for software development a lot of complex projects are developed. But there are always some risks associated with the development of these large scale projects. Risks can be like cost increase, resources problem, time schedule and many more. Many methods are proposed based on the experience of the managers and other professionals to avoid and minimize the risks associated with software project development. Based on my experience with projects and understanding of these methods I feel that risk management is as important as project development. Risk Management should be a part of software development cycle because it important to manage and identify the risks associated with the development as important it is to develop a full functional product under the given time and cost to satisfy the customer. Many times unexpected problems may arise during the development phase or testing phase which may result in backtrack to the design phase resulting in increasing cost and time scale. At times, developers may leave a project half-way which may result in resource problem. So risk management implementation in project development may give the stakeholders, developers and managers to time to analyze the risks associated with the development and prepare themselves risks to come in advance. From my research on the above methods of risk management, I feel that goal driven approach and FMEA technology are better to be used for various types of project. Goal Driven Software Development Risk Management Model is a goal based approach. In this model the goals of the project are defined at the very start of the project like the error free requirements, end user involvement, scope, business needs, realistic time scale, cost estimation and managing resources. This will reduce the occurrence of unexpected problems during the development process. Even if a risk arises unexpectedly, it has a series of steps to follow like the obstacle- link layer for the obstacles that arise for a decided goal to achieve. Then the analysis layer which is used to analyze the obstacle and the treatment layer where a proper action is taken based on the analysis layer. This approach is really good for small and medium sized projects as they are with one team and the user can be in direct communication with them and the team knows the whole development cycle. FMEA technology is mainly used in managing risks in large complex projects. In this technology first the risks which are likely to occur are decided based on the experience of senior professionals and stakeholders. Then, this raw information is made as a knowledge base and all the other risks are also identified. Then these risks are prioritized based on their value of impact on the project development. After that these risks are analyzed and a document is made. Then based on this analysis a corrective method is decided and implemented to reduce the risk. This really helps in large projects because the basic risks are associated with all the teams working on the project but few risks are face by the teams working on different modules. So these teams have their own set of risks to handle and the basic ones of they occur. This will reduce the time and cost in risk management as teams will face their own small risks to handle rather than a single team on large project handling all the r isks alone. So FMEA technology can be used for managing risks in large scale projects. Other projects are equally useful but they cannot be implemented alone. They are combined with other models to control risks associated with software development. 7) Conclusion: Risk Management is an integral part of any project development cycle. It is something that the software industry needs to pay equal attention to as software development. This is because the statistics show that more than 70% of the projects fail due to various reasons and risks associated with them. There have been studies done in this area and professionals have proposed and implemented various methods for risk management. But still this problem does exist in the industry. Project development should plan a risk management plan along with the development plan to make sure that the project is completed on time, within the estimated cost and to the full satisfaction of the customer. Thus Risk management is very beneficial and extremely important for any project to be successful and satisfy the customer needs. 8) References: Boehm, B. (1989). Software acquisition gold practiceà ¢Ã¢â‚¬Å¾Ã‚ ¢ formal risk management. Retrieved from http://www.goldpractices.com/practices/frm/ Boehm, B. (1991). Software risk management: principles and practices. IEEE Software, 8(1), Retrieved from http://portal.acm.org/citation.cfm?id=625015 doi: 10.1109/52.62930 Boehm, B. (1998, 12 5). Software risk management. Retrieved from http://sunset.usc.edu/classes/cs510_2003/notes/ec-files/Software_Risk_Management.ppt Boban, M. (2003, 11 02). Strategies for successful software development risk management . Retrieved from http://webcache.googleusercontent.com/search?q=cache:HeDQ2Ow8nUYJ:www.efst.hr/management/Vol8No2-2003/4-boban-pozgaj-sertic.doc+risk+management+in+software+developmentcd=16hl=enct=clnkgl=us Dhlamini, J. (2009). Intelligent risk management tools for software development. Proceedings of the 2009 Annual Conference of the Southern African Computer Lecturers Association, 33-40. Examining risk priority numbers in fmea. (n.d.). Retrieved from http://www.reliasoft.com/newsletter/2q2003/rpns.htm Islam , S. (2009). Software development risk management model: a goal driven approach. Proceedings of the doctoral symposium for ESEC/FSE on Doctoral symposium, 5-8. Prikladnicki, R. (n.d.). Risk management in software development: a position paper. Retrieved from http://docs.google.com/viewer?a=vq=cache:EkxHkf-j8d4J:gsd2004.cs.uvic.ca/camera/prikladnicki.pdf+risk+management+in+software+developmenthl=engl=uspid=blsrcid=ADGEESi3waZpt2SvUyFxBL_yCBTqZw3dRNjeK-Q9UorompBDJtxpg4tyvOhcf-25jgS1-2GymhNqyjtfKrUdMVgqa8wPaUo35ZJ_GCCzvA7V7Abvtz6hkEWK2N0BkcCAn5F36b1jpaGzsig=AHIEtbRhFabMWP1F7cCeNUCDQUVFhhh3Hw Stunell, P. (2003). How to Improve productivity in design and development. Retrieved from http://www.stunell.com/PDFs/Engineering%20FMEA-Version-2-2.pdf William, L. (2008, 08 14). Risk management. Retrieved from http://openseminar.org/se/modules/21/index/screen.do