Introduction to software project Risk management

Software project risk refers to the budget and progress encountered in the software development process and other aspects of the problem and the impact of these issues on the software project. Software project risk will affect the implementation of the project plan, if the project risk becomes reality, it may affect the progress of the project, increase the cost of the project, even the software project can not be achieved. If the project risk management, you can minimize the risk of occurrence.

Project Risk Management

Project risk management refers to the science and art of identifying, distributing and coping with the risks in the project life cycle in order to achieve the best objectives of the project. The goal of project risk management is to maximize potential opportunities or returns and minimize potential risks. The main processes involved in risk management include risk identification, risk quantification, risk response plan development and risk monitoring, as shown in 1. Risk identification is carried out at the beginning of the project and is ongoing in the execution of the project. That is, risk identification is a continuous process throughout the life cycle of a project.

(1) Risk identification: Risk identification includes identifying the source of the risk, the conditions under which the risk arises, describing its risk characteristics and determining which risk events may affect the project. Risk identification is not a one-time thing that should be done on a regular basis throughout the project.

(2) Risk quantification: An assessment of the interaction between risk and risk is the process of measuring the impact of risk probability and risk on the project objectives. The basic content of risk quantification is to identify those events that need to be developed for response measures.

(3) Risk response Plan development: In order to reduce the negative effect of project risk, the process of risk coping strategy and technical means is formulated for the result of risk quantification. The risk response plan is based on risk management plan, risk sequencing, risk perception, etc., and the risk response plan, residual risk, secondary risk and the basis for other processes.

(4) Risk monitoring: Addressing the risks involved throughout the project management process. The output of this process includes corrective actions to address risks and updates to the risk management plan.

The tools and methods used for each step:

PMI divides risk management into the following 6 processes

• Planning Risk Management : The process of defining how to implement project risk management activities;
• Identify risks : The process of judging which risks affect the project and document its characteristics;
• implement qualitative risk analysis : Evaluate and comprehensively analyze the probability and impact of risk, prioritize risks, and provide a basis for follow-up analysis or action;
• Implement risk Quantitative Analysis : The process of quantitative analysis on the impact of identified risks on the overall objectives of the project;
• Plan Risk Response : The process of developing programs and measures to improve opportunities and reduce threats in response to project objectives;
• Monitor risk : Implement risk response plans throughout the project, track identified risks, monitor residual risks, identify new risks, and assess process effectiveness of risk processes;
  

Success factors in project risk management

l recognition of the value of risk management-the investment in project risk management is potentially positive in terms of organizational management, project stakeholders (internal or external), project management, and project members. Therefore, project risk management should be considered to be extremely valuable.
L Personal commitment/responsibility – both project participants and stakeholders should be willing to take responsibility for risk-related activities. Risk management is actually a matter for everyone.
• Open communication – Everyone should be involved in the project risk management process. Any act or attitude that hides risk will reduce the efficiency of project risk management relative to active processing and effective decision-making.
Organization-level Commitment-organization-level commitment can only be established when risk management is aligned with the organization's goals and values. Project risk management requires a higher level of management support than other project management principles, because some risk response needs to be approved or acted on by more senior management than the project manager.
L quantify the investment in risk management in a project-project risk management activities should be consistent with the Organization's determination of the value of the project objectives, the degree, scale, and other organizational-level constraints of the risk itself. In particular, the costs associated with project risk management should correspond to the value that risk management can bring to the project and the organization.
L Integration with Project management--project risk management does not exist independently of other project management processes. Successful project risk management needs to be integrated with the proper execution of other project management processes.
These key success factors are as shown in

The role of Project manager in Project Risk management

Project managers have a unique role to play in the risk management process. The project manager assumes overall responsibility for delivering a successful project that fully meets the intended objectives, and the project manager is responsible for the daily management of the project, including effective risk management. The responsibilities of the project manager include:
L Encourage senior management to support project risk management activities.
L Negotiate with stakeholders to determine the acceptability of project risk.
L Prepare and approve the risk management plan.
l Promote the project risk management process in the project.
L Communicate the risks to the project team, senior management and other stakeholders openly.
L participate in all aspects of the project risk management process.
• Review the risk response and the corresponding action plan before implementing the action.
• When the risk occurs, approve the activation of the project contingency reserve to address identified risks.
L supervise the risk management of subcontractors and suppliers.
L regularly report the status of risks to key stakeholders, provide appropriate decision-making recommendations, and measures to be taken to maintain a certain level of risk.
• Raise identified risks to the top management level at the appropriate time, including those that are outside the scope of the project manager's authority or control, the risk of other inputs or actions other than the project, and the risk of the need to use the management reserve.
L supervise the efficiency and effectiveness of project risk management process execution.
L Audit the effectiveness of risk response and record lessons learned.

Risk Management in software projects

1. Risks in Software projects

The risk of a software project is nothing less than four things: demand, technology, cost, and schedule. There are several common risks in IT project development:

(1) Demand risk

1. Demand has become a project benchmark, but demand is continuing to change;

2. Poorly defined requirements, and further definitions extend the scope of the project;

3. The ambiguous part of product definition takes more time than expected;

4. Customer involvement is not enough in demand;

5. Lack of an effective management process for demand changes.

(2) Planning risk

① plans, resources and product definitions are verbal and not entirely consistent with the client or upper-level leadership;

② plan is optimized, is "the best state", but the plan is unrealistic, can only be regarded as "the desired state";

The ③ program is based on the use of specific team members, and that particular team member is not actually expected;

④ Product size (number of lines of code, function points, and percentage of previous product size) is larger than estimated;

⑤ complete the target date in advance, but does not adjust the product range or available resources accordingly;

⑥ is involved in unfamiliar product areas and spends more time designing and implementing than expected.

(3) organization and management of risks

① only by management or market personnel to make technical decisions, resulting in a slow schedule, the planned time is extended;

② Low-efficiency project group structure to reduce production rate;

③ Management Review decision-making cycle time longer than expected;

④ budget cuts and disrupt project plans;

⑤ Management has made a decision to combat the initiative of the Project organization;

⑥ lack of necessary norms, resulting in work errors and duplication of work;

⑦ the work of non-technical third parties (budget approval, equipment procurement approval, legal review, security assurance, etc.) longer than expected.

(4) Personnel risk

① tasks (such as training and other projects) as prerequisites cannot be completed on time;

The poor relationship between ② developers and management leads to slow decision-making and overall impact;

③ lack of incentive measures, low morale, reduce production capacity;

④ Some people need more time to adapt to the unfamiliar software tools and environment;

The ⑤ project later joins the new developer, needs to train and gradually communicates with the existing member, thus causes the existing member's work efficiency to reduce;

⑥ due to conflict between project team members, resulting in poor communication, poorly designed, interface errors and additional duplication of work;

⑦ the members of the project team were not removed from the project team, which affected the enthusiasm of the other members;

⑧ did not find people with specific skills that were badly needed for the project.

(5) Development of environmental risks

① facilities are not in place in time;

② facilities, although in place, but not matching, such as no telephone, network cable, office supplies, etc.

③ facilities are congested, cluttered or damaged;

④ development tools are not in place in time;

⑤ development tools are not as effective as expected, and developers need time to create work environments or switch to new tools;

⑥ New development tools have a long learning period and a wide range of content.

(6) Customer risk

① customer is dissatisfied with the final delivery of the product, requires redesign and redo;

② the customer's opinion has not been adopted, resulting in the product can not meet the user requirements, and therefore must be re-done;

③ customers to plan, prototype and specification of the audit decision-making cycle longer than expected;

④ the customer does not or cannot participate in the planning, prototyping and specification phase audits, resulting in unstable demand and changes in the production cycle of the product;

⑤ the time of the customer's reply (such as the time to answer or clarify questions related to the requirement) longer than expected;

The poor quality of the components provided by ⑥ customers leads to additional testing, design and integration work, as well as additional customer relationship management efforts.

(7) Product risk

① correction of unacceptable quality products requires more testing, design and implementation than expected;

② development of additional unwanted features (gold plating) to extend the schedule;

③ requirements for compatibility with existing systems require more testing, design and implementation than expected;

④ requirements are connected to other systems or systems not controlled by this project group, resulting in unpredictable design, implementation and testing efforts;

⑤ unexpected problems arising from running in unfamiliar or untested software and hardware environments;

⑥ development of a new module will take longer than expected;

⑦ relies on the technology under development to extend the schedule.

(8) Design and implementation of risk

① design quality is low, resulting in repetitive design;

② some of the necessary features cannot be implemented using existing code and libraries, and developers must use new libraries or develop new features themselves;

③ Code and library quality is low, resulting in the need for additional testing, correction errors, or re-production;

④ overestimated the savings of the planned progress of the enhanced tools;

⑤ modules developed separately are not effectively integrated and need to be redesigned or manufactured.

(9) Process risk

① a large amount of paper work causes the process to be slower than expected;

Pre-② Quality assurance behavior is not true, resulting in the subsequent duplication of work;

③ too irregular (lack of adherence to software development strategies and standards), resulting in insufficient communication, poor quality, and even need to be re-developed;

④ too formal (dogmatic adherence to software development strategies and standards), leading to excessive time-consuming and useless work;

⑤ to the management of the process of writing processes to occupy more time than expected developers;

⑥ risk Management is careless, leading to failure to identify significant project risks.

Software Project Risk Management model

In view of the risk management problem in software project, many experts and organizations put forward their own risk management model. The main risk management models are: Boehm model, CRM model and Serim model.

1 Barry Boehm Model

Model: Re=p (UO) *l (UO)

where re represents the impact of risk or risk, P (UO) indicates the probability of unsatisfactory results, and L (UO) indicates the destructive extent of bad results. At the heart of Boehm's thinking is a list of the 10 major risk factors. For each risk factor, a series of risk management strategies are given. In the actual operation, Boehm the 10 risk list as the basis, summarizes the current project specific risk factors, after the evaluation of the Plan and implementation, at the next regular meeting on the 10 major risk factors to summarize the resolution of the new 10 major risk factors table, and so on.

2 Sei's CRM (continuous Risk Management) model

Sei

The risk management principles of the CRM model are: to continuously assess the factors that may cause adverse consequences, to determine the most urgent risks to be addressed, to implement strategies to control risks, and to evaluate and ensure the effectiveness of risk strategy implementation. The CRM model requires a focus on risk identification and management at all stages of the project life cycle, which divides risk management into five steps: risk identification, analysis, planning, tracking, and control.

3 Serim (software Engineering Risk model) models

Serim analysis of software risk management from two aspects of technology and commerce, including cost, schedule, technical performance, and so on. It also provides a number of indicators and models to measure and predict the risk, because the data from a large number of practical experience, it is very convincing.

The MSF risk management process

The MSF risk management principles promote proactive risk management, ongoing risk assessment, and decision integration for the project or operational life cycle. Risks should be continuously evaluated, monitored, and actively managed until they are resolved or converted into manageable failures. The MSF Risk management principles described in Figure 1 define the six logical phases in which a project team manages existing risks, plans, executes risk management policies, and acquires knowledge for the enterprise.

The six phases of the MSF risk management process are:

? identify

? analysis and grading

? planning and Scheduling

? Tracking and reporting

? control

? Learn

risk Identification allows the individual to identify risks and thereby enable the project team to become aware of potential failures. As input to the risk management process, risk identification should be implemented as early as possible and frequently repeated throughout the life cycle of the project.

risk Analysis translates the specific project risk estimates or data found in the risk identification process into a form that can be used by the project team to prioritize decisions. The risk sequencing allows the project team to manage the project resources so that the most important risks can be managed.

The risk Plan extracts the information obtained from the risk analysis and uses it to articulate strategies, plans, and work. risk scheduling ensures that the plan is recognized and integrated into the standard daily project management processes and infrastructure to ensure that risk management is performed as part of the daily work of the team. Risk scheduling explicitly uses a project plan to correlate with a risk plan.

Risk Tracking monitors the status of specific risks and their progress in their respective work plans. Risk tracking also includes the probability, impact, exposure, and other factors that monitor change risk, which can change priorities or risk plans, project characteristics, resources, or schedules. Risk tracking defines the visibility of the risk management process in the project from a risk level perspective, which is the opposite of the standard Business Project management process task completion. Risk reporting ensures that teams, sponsors, and investors understand the status of project risks and manage their plans.

Risk Control is the process of implementing a risk work plan and related status reports. Risk control also includes the initialization of the project change control request, and changes in the risk status or risk plan may result in changes to the project characteristics, resources, or schedules.

Risk Learning enables the formalization of knowledge and corresponding project cases and tools, and the extraction of knowledge within the team and within the enterprise in a reusable form.

Note that these phases are logical phases, and you do not need to strictly follow these stages for any given risk. The project team will often cycle through the identification-analysis-planning three steps, and only periodically enter the learning phase to capture knowledge for the enterprise.

CMMI Process-RSKM Risk Management

SG 1 preparation for risk management

Establish and maintain strategies for identifying, analysing and mitigating risks. This strategy is generally prepared as a project risk management plan. The risk management strategy deals with the specific measures, resources and management methods applicable to the control of the risk management outline, including the planning of the sources of risk, the risk classification scheme and the evaluation, definition and control parameters of the risk. The corresponding convention:

• SP1.1 identify sources and categories of risk
• SP1.2 Defining Risk parameters
• SP1.3 establishing a risk management strategy

The sources of risk are manifold, and the more common sources of risk for IT projects are uncertain needs, people mobility, the use of new technologies, unreasonable progress, and lack of developer skills. The category of risk is also multifaceted, the larger classification can be divided into the project management category of risk, business risk, technical risk and so on. Note the purpose of identifying risk sources and classifications is to provide a mechanism for collecting and inducing risks to ensure that the risk can lead to management concerns. On the one hand, the different risk categories and sources have the risk probability, impact, stakeholder, risk threshold and other basic parameters may be not the same.

The key to defining the risk is to determine the criteria for the definition, evaluation, and sequencing of the risk. An important part of this is determining the thresholds for each type of risk. The risk threshold is the monitoring and control point for the risk, and the risk mitigation plan must be considered when the risk is ultimately assessed to have an impact over the threshold. The implementation of a risk mitigation plan can be implemented immediately at the critical risk we evaluate, one of which is that although it is not yet a critical risk, the mitigation plan must be implemented if the risk exceeds the threshold.

The content of the corresponding SP1.3 can be directly understood as a risk management plan, which should be an important part of the project plan. The risk management plan needs to define the members of the project Risk Management team, the risk parameters used in the project, the methods and tools for risk identification, the risk mitigation strategies that the project may adopt, and how the project monitors the risks.

SG 2 Identify and analyze risks

Identify risks and analyze them to determine their relative importance. The degree of risk affects the allocation of resources to deal with risks and determines when appropriate management concerns are needed. Risk analysis is the identification of risks to internal and external sources, and then each risk is evaluated to determine the likelihood and subsequent outcome of its occurrence. The types of risks identified based on the established risk classification approach and the criteria developed for risk management strategies will provide the necessary information for the processing of risks. Related risks can be grouped in order to effectively handle risks and use risk management resources. The corresponding convention:

• SP 2.1 Identifies risk
• SP 2.2 Evaluation, classification, and sequencing of risks

There are many ways to identify risks, such as brainstorming, questionnaires, risk checklists, and risk banks, all of which can be considered. The risk of product and technology must be identified by WBS work breakdown structure. In the risk identification phase we will form a risk register, to complete the risk of the name, source, category and other basic risk attribute input.

The content of risk qualitative analysis in SP2.2 is mainly referred to in Pmbok. The main factor is to determine the impact of each risk, the risk value = the probability of the risk occurring * the impact of the risk. Each risk that we identify should be given a final risk value and then prioritized for the risk. The risk probability influence matrix is introduced in the qualitative risk analysis, and both the organization and the project can define the scope of the risk value in terms of the probability influence matrix to be the project key risk. When a risk is assessed on the key risks of my project, it is necessary to consider the risk response and mitigation.

SG 3 Mitigating Risks

Address risks and mitigate risks when appropriate, thereby reducing the adverse impact on achieving project objectives.

The steps to deal with risk include advising on the risk, supervising the risk, and executing the risk-handling activity when the specified threshold is exceeded. Proactively mitigate the potential impact of risk exposure by developing and implementing mitigation scenarios for selected risks. Such scenarios may include contingency plans for dealing with the impact of the selected risk in the event of an occurrence, irrespective of the intention to mitigate the risk. The criteria, min values and parameters used to initiate risk-handling activities are defined by the risk management strategy. The corresponding convention:

• SP 3.1 Develop a risk mitigation plan
• SP 3.2 Implementing a risk mitigation plan

The criteria, thresholds, and parameters specified in the Risk management strategy are used to determine when a risk-handling action is required. A risk mitigation plan is only a critical risk for the project and only supervises the general risk. The common measures for risk mitigation, acceptance, avoidance, transfer, etc., suggest that there should be more than one mitigation response for the key risks. In SP3.1, you determine the level and threshold of risk, and they indicate under what circumstances the risk will become unacceptable and the risk-handling action will be initiated. In addition, the risk mitigation plan also needs to include how to change the risk into a post-problem emergency treatment.

The implementation of the risk mitigation plan requires that the implementation leader of the mitigation plan be defined and that the risk is mitigated after the mitigation plan is implemented on a regular basis. Whether the probability of occurrence and the degree of influence of the risk have been reduced. With these traces and re-evaluations, the risk status and priority can be re-updated.

Level three to risk management requirements is that risk management has risen to the organizational level, the organization has a standard definition of risk management procedures, risk parameters, and the project can be cropped. In addition, the organization will form a corresponding risk bank for project identification risk use. Level four requires quantitative management of risk, which needs to be quantified into sub-processes of risk management, such as risk identification and risk analysis. The risk analysis should adopt some sensitivity analysis, Monte Carlo simulation and other quantitative risk analysis methods.

Project Risk Management Experience

1 Risk management should be early. Hainfa said: "Any unsafe accident can be prevented." And the cost of prevention is obviously better than to mend, good risk management planning is a guarantee of project success;

2 Do not neglect to refer to previous related project experience. project Management is an accumulation of practical process, "precedent, the teacher after the car", the previous project, whether from risk identification or risk response can give the current project some inspiration and experience;

3 The attitude of the project members to risk should be fully considered. risk management is not a project manager of a person, the need for full participation, and the different members of the risk attitude will often be to some extent determine the risk response measures. For the risk-chasing group members, it is necessary to consider the risk analysis and understanding is not biased to optimism, but also can not be due to some risk-Conservative member of the attitude of the risk of the stalled;

4 with the associated risk management tools. such as GS Risk,deltek risk+ and so on. In this way, RPM is able to provide effective risk management from planning to monitoring to the control phase by centralizing the cataloging of risks and responses and generating measures or tasks to identify issues related to the recording project, while its robust risk database can also provide a template for project risk.

--------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------- --------

Hope to your company's enterprise information it architecture and management help. Other articles you might be interested in:
Introduction of enterprise project management
One of intelligent Enterprise and informatization
From the basic qualities of entrepreneurs
Method and practice of quality assurance of agile software
Build efficient research and development and automated operation and maintenance
Introduction to it operation and maintenance monitoring solution
Quality management of it continuous integration
Talent company environment and corporate culture
The Balanced scorecard of enterprise performance management system
Corporate culture, team culture and knowledge sharing
High-Performance Team building
Food chain Company It informatization solution One

If you want to know more software development, system it integration, Enterprise informatization, project management, business management and other information, please follow my subscription number:

Petter Liu
Source: http://www.cnblogs.com/wintersun/
This article is copyright to the author and the blog Park, Welcome to reprint, but without the consent of the author must retain this paragraph, and in the article page obvious location to the original link, otherwise reserves the right to pursue legal responsibility.
The article was also published in my Independent blog-petter Liu blog.

Introduction to software project Risk management