Risk response planning is the process of developing ways and identifying actions to increase opportunities and reduce threats for project purposes. This process begins after a qualitative and quantitative risk analysis.
Planned risk response operations should be commensurate with the severity of the risk, be cost-effective in addressing the problem, timely, realistic in the context of the project and agreed with all participants.
According to, four methods of risk response are possible:
• Risk avoidance.
• Risk transference.
• Risk mitigation.
• Risk acceptance.
Risk avoidance involves modifying the project management plan in such a way as to eliminate the threat posed by negative risk, to insulate project objectives from the consequences of risk, or to weaken goals that are at risk (for example, to reduce the content of the project). Some of the risks that arise in the early stages of the project can be avoided by clarifying the requirements, obtaining additional information or conducting an examination.
For example, you can avoid risk by abandoning the implementation of a risky functional requirement or by independently developing the necessary software component, instead of waiting for the delivery of the product from the subcontractor.
Risk transfer implies shifting the negative consequences of a threat with the responsibility of responding to the risk to a third party. Transferring risk simply shifts the responsibility for managing it to the other party, but the risk does not go away. The transfer of risk almost always involves the payment of a risk premium to the party taking the risk. For example, an order on the development side of a risky 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 record the assumption that the manufacturer will not change the cost of licenses for the underlying software.
Reducing risk involves reducing the probability and/or consequences of a negative risky event to acceptable limits. Taking precautionary measures to reduce the likelihood of risk or its consequences are often more effective than efforts to eliminate negative consequences undertaken after the occurrence of a risk event. For example, early resolution of architectural risks reduces losses in the early closure of a project. Or regular revision of deliveries by the customer can reduce the likelihood of his dissatisfaction with the final result. If there is a high probability of dismissal of employees in the project team, then the introduction of additional (redundant) human resources into the project at the initial stage reduces losses when team members are dismissed, since there will be no cost of "entering" the project context of new participants.
Finally, risk acceptance means that the project team has consciously decided not to change the project management plan due to the risk or has not found a suitable response strategy. We are forced to accept all the "unknown risks".
Acceptance is something that always happens when we don't manage risks at all. If we manage risks, we can insure risks by laying a reserve in estimates of the completion date and/ or labor costs. Being proactive about the risks taken may consist of developing a risk response plan. This plan can only be put into effect under predetermined conditions if there is confidence and a sufficient number of signs that the plan will be successfully implemented.
It is important to be aware of secondary risks arising from the application of risk response, which must also be identified, analyzed and, if necessary, included in the list of managed risks.
The main risks of software projects and ways to respond
My list of the top five reasons for the failure of software projects is as follows:
• Customer requirements are absent / incomplete / subject to frequent changes.
• Lack of necessary resources and experience.
• Lack of working interaction with the customer.
• Incomplete planning. "Forgotten Works".
• Errors in estimating the labor intensity and timing of work.
It sounds trite, but no matter how many times it is said earlier, you still have to deal with software projects in which there are no specific goals and requirements. Quote from life: "A good program would be developed, and what process to automate with its help, we will find." To this we can add only one thing: "When a man does not know to which pier he is making his way, for him no wind will be tailwind".
Frequently overlooked requirements include:
• Functional
• Installers, settings, configurations.
• Data migration.
• Interfaces with external systems.
• Help system.
• System-wide
• Performance.
• Reliability.
• Openness.
• Scalability.
• Security.
• Cross-platform.
• Ergonomics.
As a rule, these requirements "pop up" during the preparation and conduct of acceptance tests and can greatly delay the project in time and increase the labor costs for its implementation. To prevent this from happening, it is preferable to reach an agreement with the customer on all of the listed points at the stage of project initiation. For example, if there is no requirement for the portability of the product to different hardware and software platforms, then it is advisable to include this in the section of concepts with project assumptions.
If the probability of changes in the requirements of the project is high, then the following approaches are possible to respond to this risk:
• Re-evaluating the project every time requirements are added/changed (evasion).
• Iterative development. Contract with reimbursement of costs on the basis of "Time & Materials" (transfer of risk to the Customer).
• Taking into account in the estimates of labor intensity and timing the possibility of growth of requirements, for example, by 50% (risk reservation).
And yet, when collecting requirements, Voltaire's principle of 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 is applicable: 80% of the value of the product is contained in only 20% of the requirements for it.
If we do not have enough qualified specialists in the project, we can reduce the consequences of this risk by applying the following actions:
• Involve expert consultants in the initial stages.
• Take into account the costs of training employees in the assessments of labor intensity.
• Reduce turnover losses by initially attracting an excessive number of participants.
• Take into account in the estimates the "acceleration time" for new employees.
To establish an open and trusting relationship with the customer, it is necessary to take the following steps:
• Constant interaction.
• Coordination of user interfaces and development of a prototype of the product.
• Periodic delivery of test versions to end users for evaluation.
When planning work on a project, it is often "forgotten":
• Teaching.
• Coordination of works.
• Clarification of requirements.
• Configuration management.
• Development and support of auto-build scripts.
• Development of autotests.
• Create test data.
• Handle change requests.
And one more thing. Do not hope that the project participants will work every week for 40 hours on your project. There are a variety of reasons why they won't be able to work on a project 100% of their time. The list of the most common reasons for this includes:
• Maintenance of existing systems.
• Upgrading.
• Participation in the preparation of technical and commercial proposals.
• Participation in presentations.
• Administrative work.
• Vacations, holidays, sick leave.
The recommendation is to plan that the developers who are assigned to your project will actually work on your tasks for an average of 24 to 32 hours per week.
Errors in estimating the complexity and timing of the project and campaigns that allow them to be minimized, will be devoted to the next lecture.
Project management aimed at reducing risks
At the stage of project initiation, the assessment of its labor intensity has an error from -50% to +100%. That's 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 several times greater. Unless special efforts are made, this "sword of Damocles" of uncertainty will hang over the project throughout its length.
The project should be managed so that the risks of late delivery and overspending of resources are constantly reduced.
Earlier we said that 80% of the value of the development is due to only 20% of the requirements for the product, without the implementation of which the product for the customer becomes simply unnecessary. The remaining requirements are usually the so-called "decorations", some of which the customer can usually refuse in order to receive the project on time. Therefore, key functional requirements should be implemented first.
But there are also architectural risks. It is known that Pareto's law also applies to the consumption of computing resources: 80% of resource consumption (time and memory) falls on 20% of components. Therefore, it is necessary to implement architecturally significant requirements in the same place, first of all, creating a "representative" prototype of the future system, which "shoots" the entire stack of technologies used. The prototype will allow you to measure and evaluate the system-wide properties of the future product: availability, performance, reliability, scalability, etc.
It is a mistake to implement easy requirements first to demonstrate the rapid progress of the project.
Risk mitigation management can significantly reduce uncertainty in the early stages of a project.
Elaboration of key functional requirements and detailed planning of their implementation allows to reduce the spread of initial estimates by about 2 times: from -30% to + 50%. Detailed design and development of a prototype of the future system will allow you to get even more accurate estimates of the total labor intensity: from -10% to + 15%.
It may turn out that according to the results of prototyping, updated estimates of the total labor intensity will be unacceptable. In this case, the project will have to be closed ahead of schedule, but the losses will be much less than if the same thing happens, when the project is already 2 times higher than the initial estimate of labor intensity.
If it is not possible to find a mutually acceptable solution with the customer during the initial evaluation of the project, then it is reasonable to try to agree on the implementation of the project in 2 stages with self-financing:
1. Exploration. Business analysis, requirements refinement, solution design and prototyping, refinement of summary estimates of labor costs. This work typically requires 10% of the total work and 20% of the time of the entire project.
2. The implementation itself. If the refined estimates of labor costs are acceptable to the customer.
With sane customers, this is often successful.
Risk monitoring and control
Risk management should be carried out throughout the project. Not monitoring risks during a project is like not monitoring fuel levels when traveling by car.
Risk monitoring and management is the process of identifying, analyzing and planning the response to new risks, tracking previously identified risks, and verifying and executing risk response operations and evaluating the effectiveness of these operations.
In the process of monitoring and risk management, various techniques are used, for example, the analysis of trends and deviations, for the implementation of which quantitative data on the implementation of the project are necessary.
Monitoring and risk management includes the following tasks:
• Risk review.
• Risk audit.
• Analysis of deviations and trends.
Risk review should be carried out regularly, according to the schedule. Project risk management should be one of the items on the agenda of all project team meetings. It's a good idea to start each status meeting with the question: "Well, what other trouble awaits us?" Identification of new risks, and revision of known risks occurs using the processes described earlier.
Risk audit involves the study and provision in documentary form of the results of assessing the effectiveness of measures to respond to risks related to identified risks, studying the main causes of their occurrence, as well as assessing the effectiveness of the risk management process.
Trends during project execution must be validated using execution data. To monitor the implementation of the entire project, earned value analysis and other methods for analyzing project deviations and trends can be used the outputs of these analyses, it is possible to predict the potential deviations of the project at the time of its completion in terms of cost and schedule. Deviations from the baseline plan can indicate consequences caused by both threats and opportunities.
Conclusion
Refusing to manage project risks is like not having fire extinguishers and an evacuation plan in the event of a fire in a movie theater.
Everything we do when managing a software development project should be aimed at combating the risks of not meeting the deadline, overspending resources, developing the wrong product.
The objectives of project risk management are to reduce the likelihood of occurrence and/or significance of the impact of adverse events for the project.
The main reasons for the failure of software projects:
• Customer requirements are absent / incomplete / subject to frequent changes.
• Lack of necessary resources and experience.
• Lack of working interaction with the customer.
• Incomplete planning. "Forgotten Works".
• Errors in estimating the labor intensity and timing of work.
No comments:
Post a Comment