Lecture
Risk response planning is the process of developing ways and identifying actions to increase opportunities and reduce threats to the objectives of a project. This process begins after conducting a qualitative and quantitative risk analysis.
Planned risk response operations must be appropriate for the severity of the risk, cost-effective to solve the problem, timely, realistic in the context of the project and agreed with all participants.
According to [3], four methods of responding to risks are possible: ■ risk avoidance.
Risk avoidance involves changing the project management plan in such a way as to eliminate the threat caused by negative risk, protect the project's objectives from the consequences of the risk, or weaken goals that are at risk (for example, reduce the content of the project). Some of the risks that arise in the early stages of a project can be avoided by clarifying requirements, obtaining additional information or conducting an examination. For example, you can avoid risk if you refuse to implement a risky functional requirement or independently develop the necessary software component, instead of waiting for the product to be supplied by a subcontractor.
Risk transfer involves shifting the negative consequences of a threat with responsibility for responding to risk to a third party. The transfer of risk simply transfers responsibility for its management to the other party, but the risk does not go away. The transfer of risk almost always involves the payment of the risk premium to the party taking the risk. For example, an order on the development side of a high-risk component at a fixed price. In IT, it is often necessary to formulate risks in the form of assumptions, thereby transferring it to the customer. For example, when evaluating an implementation project, we can write down the assumption that the manufacturer will not change the cost of licenses for basic software.
Reducing risks involves reducing the likelihood and / or consequences of a negative risk event to acceptable limits. Taking precautionary measures to reduce the likelihood of a risk occurring or its consequences are often more effective than efforts to eliminate the negative effects made after a risk event occurs. For example, early resolution of architectural risks reduces losses in case of early closure of a project. Or regular inspection of deliveries by the customer can reduce the likelihood of the risk of his dissatisfaction with the final result. If the project team has a high probability of dismissal of employees, the introduction of additional (surplus) human resources at the initial stage of the project reduces the loss of dismissal of team members, since there will be no costs for “entering” the project context of new participants.
And finally, accepting risk means that the project team consciously decided not to change the project management plan due to risk or did not find an appropriate response strategy. We have to take all the “unknown risks”.
Acceptance is something that always happens when we do not manage risks at all. If we manage risks, then we can insure risks by laying a reserve in the estimates of the completion date and / or labor costs. A proactive attitude to accepted risks may consist in developing a risk response plan. This plan can be put into action only under predetermined conditions, if there is confidence and a sufficient number of signs that the plan will be successfully completed.
It is important to remember about secondary risks (Secondary Risks) arising from the application of a response to risks, which must also be identified, analyzed and, if necessary, included in the list of manageable risks.
The main risks of software projects and how to respond
My list of the top five reasons for failing software projects is the following:
It sounds trite, but no matter how many times it has been said before, you still have to deal with software projects that lack any specific goals and requirements. A quote from life: "A good program would be developed, and we will find what process to automate with its help." To this we can add only one thing: “When a person does not know to which pier he is on his way, no wind will flow for him” (Seneca Lucius Aney, philosopher, 65-3 BC)
The frequently overlooked requirements include:
As a rule, these requirements “emerge” during the preparation and conduct of acceptance tests and can greatly delay the project in time and increase labor costs for its implementation. To prevent this from happening, an agreement should be reached with the customer on all the listed items, preferably at the stage of project initiation. For example, if there are no requirements for portability of a product to different hardware and software platforms, it is advisable to include it in the concept section with the project assumptions.
If the likelihood of changes in project requirements is high, then the following approaches are possible to respond to this risk:
And yet, when collecting the requirements, the principle of Voltaire's minimalism should be observed: “The story is finished not when there is nothing to add to it, but when there is nothing more to throw out of it”. For most software products, the Pareto principle applies: 80% of the product's value is contained in only 20% of its requirements.
If we do not have enough qualified specialists in the project, then we can reduce the consequences of this risk by applying the following actions:
To establish an open and trusting relationship with the customer, the following steps should be taken:
When planning work on a project, they often “forget”:
And further. You should not hope that the project participants will work every week for 40 hours on your project. There are many reasons why they will not be able to work on a project 100% of their time. The list of the most common reasons for this include:
A recommendation to plan that developers who are assigned to your project at 100% will actually work on your tasks on average from 24 to 32 hours per week.
The following lecture will be devoted to errors in the estimates of the labor intensity and the project timeframes and the campaigns that allow them to be minimized.
Risk Reduction Project Management
At the stage of project initiation, the assessment of its labor intensity has an error from -50% to + 100% [4]. This, if the score is good! And if it is bad, then the uncertainty, and, consequently, the risks of disrupting the deadlines and exceeding the planned labor intensity, can be many times greater. Unless special efforts are made, this uncertainty of Damocles will hang over the project along its entire length (Figure 31).
The project should be managed in such a way that the risks of late delivery and cost overruns are constantly reduced.
Earlier we already said that 80% of the development value is due to only 20% of the product requirements, without which the product for the customer becomes simply unnecessary. The remaining requirements, as a rule, the so-called "decorations", from which the customer can usually refuse to part, in order to receive the project on time. Therefore, you should first implement key functional requirements.
But there are also architectural risks. It is known that the Pareto law is applicable to the consumption of computing resources: 80% of resource consumption (time and memory) accounts for 20% of the components. Therefore, it is necessary to implement architecturally significant requirements as well in the first place, creating a “representative” prototype of the future system, which “shoots” the entire stack of applied technologies. The prototype will measure and assess the system-wide properties of the future product: availability, speed, reliability, scalability, and so on. (Figure 32)
The mistake is to implement light requirements first to demonstrate the rapid progress of the project.
Figure 31. Uncertainty is not reduced if management is not directed to early resolution of risks.
Figure 32. Prioritizing requirements for the first iterations of the project
Management aimed at reducing risks can significantly reduce uncertainty in the early stages of a project (Figure 33).
Figure 33. Risk Reduction Management Reduces Uncertainty
Elaboration of key functional requirements and detailed planning of their implementation allows reducing the spread of initial assessments by approximately 2 times: from -30% to + 50%. Detailed design and development of a prototype of the future system will provide even more accurate estimates of the total labor intensity: from -10% to + 15%.
It may be that, according to the results of prototyping, the updated estimates of the total labor intensity will be unacceptable. In this case, the project will have to be closed ahead of time, but the losses will be significantly less than if the same happens when the project already exceeds the initial estimate of labor intensity by 2 times.
If the customer fails to find a mutually acceptable solution during the initial evaluation of the project, it is reasonable to try to agree on the project implementation in 2 stages with self-financing:
With sane customers this is often possible.
Risk monitoring and control
Risk management should be carried out throughout the project. Not to monitor risks during the project is the same as not to monitor the level of fuel when traveling by car.
Monitoring and risk management is the process of identifying, analyzing and planning to respond to new risks, tracking previously identified risks, as well as checking and executing risk response operations and evaluating the effectiveness of these operations.
In the process of monitoring and managing risks, various methodologies are used, for example, the analysis of trends and deviations, for the fulfillment of which the quantitative performance data collected during the project implementation are necessary.
Monitoring and risk management includes the following tasks:
Risks must be reviewed regularly, according to a schedule. Project risk management should be one of the agenda items of all project team meetings. It is good to start each status rally with the question: “Well, what other troubles await us?” The identification of new risks, and the revision of known risks occurs using the processes described earlier.
Risk audit involves studying and documenting the results of evaluating the effectiveness of measures to respond to risks related to identified risks, studying the main causes of their occurrence, as well as evaluating the effectiveness of the risk management process.
Trends during project execution are subject to verification using performance data. To monitor the implementation of the entire project, the used volume analysis and other methods for analyzing project deviations and trends can be used (see Lecture 8. Project Implementation). Based on the outputs of these analyzes, it is possible to predict potential deviations of the project at the time of its completion in terms of cost and schedule. Deviations from the baseline may indicate the consequences of both threats and opportunities.
findings
Refusing to manage project risks is the same as not having fire extinguishers and an evacuation plan in case of a fire in the cinema.
Everything that we do, managing a software development project, should be aimed at combating the risks of not meeting the deadlines, overspending resources, developing the wrong product, which is required.
The objectives of project risk management are to reduce the likelihood and / or significance of the impact of adverse events for the project.
The main reasons for the failure of software projects:
Comments
To leave a comment
software project management
Terms: software project management