It was found that many students who do projects will neglect to manage the risks of the project, so that they will become the fire captains of the project and deal with various emergency incidents. in order to make the project run more smoothly and avoid the problem of both chaotic and tired projects, tactical diligence should not be used to cover up strategic laziness, and the risk management of agile projects should be sorted out and summarized.
Usually, risk management in the project is aimed at increasing the probability and impact of positive events in the project and reducing the probability and impact of negative events in the project. first of all, we first review the risk management knowledge points elaborated by pmp in traditional projects, then share how to carry out risk management in our software and hardware projects, and finally share the risk management dry goods summarized by the engineering efficiency department.
first, the risk management
of traditional projects 1.planning risk management
is mainly in the project planning stage, defining how to carry out risk management process, including risk identification, risk qualitative analysis, risk quantitative analysis, risk response strategy, and how to monitor;
the usual methods used, brainstorming, risk planning will be discussed and analyzed. output project risk management plan and risk decomposition structure;
conventional risk management plan and risk decomposition structure, which can be from the company's project management template, or from the project manager's previous project experience, or from the necessary data column;
2. Risk identification
is mainly in the project planning stage, the possible risks of the project are identified and confirmed, and updated to the risk registration form, so as to facilitate risk analysis and determine the response plan;
the usual methods are brainstorming, document review, information collection, checklist analysis, diagram analysis, hypothesis analysis, SWOT analysis, expert analysis. Output of an updated risk register;
general risks come from, demand (change), cost (high), quality (high standard), team (separation or drawdown), communication (poor information), stakeholders (special expectations), procurement (level of support from partners), schedule (extensions), as well as risks in similar projects and past risk experience of project managers;
3. risk qualitative analysis
is mainly in the project planning stage, the identified risks, conceptual analysis, determine the risk priority, the modification is updated to the risk registration form;
through the methods used, risk classification, risk probability impact matrix, risk urgency assessment, expert judgment. output the updated risk registration form;
regular prescriptive analysis, determine the risk classification (business division), determine the probability (1-5), determine the impact (1-5), determine the urgency (1-5), determine the priority (1-5), let the big bull participate in the assessment, and update to the risk registration form;
4. risk quantitative analysis
is mainly in the project planning stage, the risk that has been qualitatively analyzed, the data quantification and modeling, in-depth analysis and presentation of risk, the modification is updated to the risk registration table;
the usual method, three-point estimation, risk expectation currency value, decision tree, tornado chart, sensitivity analysis, expert judgment. output the updated risk register;
routine quantitative analysis, three-point estimation of risk, calculation of risk expectation currency value and decision tree calculation, risk probability and impact quantification, and update to risk registration form;
5. the risk response strategy6. risk monitoring and landing
is mainly in the project planning stage, the identified and analyzed risks, the construction of the response strategy, the formulation of plans and measures to improve the opportunity and reduce the threat, the modification is updated to the risk registration form;
the usual method, positive risk or opportunity response strategy, negative risk and threat response strategy, emergency response strategy, expert judgment. output the updated risk register;
conventional risk response, according to the positive strategy: explore (ensure opportunities), improve, share, accept; negative strategy: avoidance (eliminate threat), transfer, mitigate, accept, determine the risk response plan;
is mainly in the project execution and monitoring stage, tracking the process of identifying risks, implementing risk response plans, supervising residual risks, identifying new risks, and assessing the effectiveness of the risk process;
the usual methods, deviation and trend analysis, status review meetings, risk re-assessment, risk audit, and reserve analysis. output risk registers, change requests and organizational process assets;
routine risk monitoring, deviation analysis of identified risks, follow-up review of risk status, reassessment of new risks, and reserve deviation analysis, and update modifications to the risk register. initiate a change request for changes arising from risk monitoring, and organize the information in the entire risk management process as a team wealth to form an organizational process asset;
traditional risk management, basically, is to do things with a plan (risk management plan), to understand things (risk identification), to analyze things (risk qualitative and quantitative analysis), solutions (risk response), and implementation plans (risk monitoring). risk management, in the planning stage, to carry out risk identification, risk qualitative analysis, risk quantitative analysis, risk response plan; in the implementation and monitoring stage, to continue to identify, analyze, respond, follow up monitoring, basically throughout the entire project, and the risk registration form also needs to be constantly updated and maintained, the closure of old risks and the registration of new risks.
Second, the risk management of software and hardware projects briefly introduces the background of the project, with the development of the Internet of Things, the application of embedded technology and sensing technology, the improvement of the national Internet of Things infrastructure, smart home, smart community, smart city, slowly from the original concept fire, evolved into a commercial project that can be landed.
The company follows the trend and carries out the research and development of intelligent products, involving user interaction terminals, hardware devices, software platforms, mobile apps, public accounts and small programs; involving team organization forms, team internal (JAVA, IOS, Android, Web front-end, design, testing, project, product), team outside (embedded, structural design, hardware design, testing, project, product), outside the company (embedded engineers, tests, projects), involving multi-terminal, multi-functional engineers, cross-team, Cross-departmental, cross-company communication and coordination.
Because it is a project that combines software and hardware, the research and development cycle of hardware, especially the research and development of new hardware, the change of related accessories, and the timeliness of sample equipment, will also interfere with the progress of software joint commissioning.
1. demand ambiguity risk
(1). analyze the reasons:
the demand submitted by the product or market, especially the demand for one sentence, is the most undesirable, and it will doubt whether there is a good needs analysis and design work; it is only the rumors of the leader or the market, lack of independent thinking and functional involvement of the product;
(2). evaluate the impact:
ambiguous requirements will make the design rendering experience not smooth, or even unable to design; development business implementation can not be closed-loop, or even functional design; test case test logic is not rigorous; resulting in optimistic project plan scheduling, or even unable to schedule;
(3) response plan:
in the project iteration planning stage, the product manager provides relative fidelity prototype interaction, as well as related flowcharts, infographics, and requirements simple documents; and clarify the needs of team members;
2. The risk of demand change
(1). Analyze the reasons:
due to the lack of closed-loop verification of business data circulation; the evaluation of hardware procurement accessories suppliers is not in place, and it is impossible to continue to cooperate; the personalized emergency needs proposed by the boss; the customer experience stage, the detailed requirements are proposed;
(2). The impact is assessed:
Requirements changes will make the UI interactively change the design; develop functional logic, change processing logic; test functional use cases, change use case logic; resulting in the project original plan to be blocked, the project schedule is delayed, or even can not continue to carry out;
(3).
In the project iteration planning stage, the product publicizes and clarifies the requirements, does sufficient closed-loop verification of user business, strengthens the review and constraint of partners, avoids the problem of replacing suppliers, adjusts the priority of project function delivery, and prioritizes delivery to meet the urgent and important needs expected by stakeholders; establishes a change control process, constrains changes, can remain unchanged, or relative changes under acceptability; and reserves buffer time for project plans to respond to urgent needs and changes;
3. communication information consistency
(1) Analyze the reasons:
due to the cross-team, cross-departmental, cross-company communication and coordination, there are problems in which each company arranges the task priority and delivery time according to the internal research and development situation; the functions delivered by all parties have problems that are repeated, the problems are continuous, and it is difficult to clean up; the part of the functional joint debugging of all parties has the problem of mutual evasion and is not responsible for the
(2) Evaluate the impact:
self-prioritization, resulting in functions that all parties rely on, the pre-task is not completed, and the post-task cannot be carried out; the delivery time is determined by oneself, resulting in the total delivery node of the project cannot be achieved, the function is not perfect, and the smooth experience cannot be experienced; the delivery function, the problem is repeated and the problem is continuous, resulting in the function being delayed; the problem of joint investigation is mutually shirked, resulting in the problem cannot find the root cause, the problem cannot be solved quickly and thoroughly, and the project progress is delayed;
(3) Response plan:
all parties arrange their own priorities and decide the delivery time, need to carry out unified scheduling of the priority of each task of the project, and formulate the total delivery plan of the project, and reach a consensus with all parties on the delivery node; the delivery functions of all parties, the repeated and continuous problems of the parties, register the problems to the project management tool, form a test regression rhythm, round of acceptance tests, strictly restrict the delivery quality; the parties jointly coordinate and shirk, and carry out centralized office. jointly check the relevant data and logs of the problem, and focus on a few days to repair and verify the joint investigation problem;
4. Timeliness of hardware provision
(1)Analyze the reasons:
Due to the combination of software and hardware projects, in order to achieve control and data display of hardware, it is necessary to analyze the hardware-related protocols and conduct joint debugging verification of data. The research and development of new hardware, the procurement of prototype accessories materials is relatively troublesome, ID design, structural design, proofing and other processes, the relative cycle is long; the perfection of the hardware platform, the local agreement adjustable, and the possible hardware specifications are problematic, etc., which will lead to the untimely provision of hardware;
(2)
If the hardware platform has accessories replacement, protocol changes, it will also cause interference to the entire adaptation of the joint commissioning;
(3) Response plan:
the software development plan and the hardware development plan to maintain synchronization in progress, the completeness of the hardware as the pre-task of the joint commissioning, in the delivery time node, earlier than the joint commissioning time node, and reserve the relative cache time; supervise the hardware development plan, consider the relevant risks, and strengthen the delivery review of the supplier Carefully consider the specifications of accessories, and minimize the problem of replacing suppliers, replacing parts, and changing protocol interfaces;
5. supplier delivery timeliness
(1) Analysis of the reasons:
due to the procurement partner's technical solutions or direct outsourcing to the supplier's development, there will be problems such as insufficient technical ability of the supplier, insufficient manpower investment of r&d personnel, insufficient project management ability, insufficient delivery quality control, etc., resulting in untimely delivery of relevant functions;
(2) The functional modules delivered by the supplier are part of the overall project delivery.(3) the response plan:
Some involve the joint investigation of the front and rear modules, and the delivery is not timely, which will seriously affect the project schedule; for the overall project outsourcing project, the delivery of the various nodes of the project is not submitted in time, one delivery node is delayed, the next delivery node cannot catch up, one after another is delayed, then the entire project plan will definitely be delayed;
when purchasing suppliers, make a full assessment of the supplier's r&d capabilities, r&d manpower, management level, delivery quality, etc., so as to improve the level of supplier access, which will greatly improve the timeliness of the supplier's delivery function; ensure consistency with the overall project plan for the functional modules delivered by the supplier, and reserve a certain risk buffer time; strictly control the supplier's plan and strictly accept the deliverables of each node for all outsourced projects to the supplier;
6. project risk monitoring and management
In the early stage of the project, full project risk identification, analysis and response, then will be largely avoided on the hot pot of ants phenomenon, risk events have a relative response strategy, the project development is smoother. the response plan formulated in the early stage of the project should clarify the completion time and responsibility to the person, and regularly review the risk list to confirm whether there is still a risk, whether it has been dealt with, and whether it needs to change the degree of impact.
In addition, it should be noted that the risk management of the project will accompany the development of the entire project, from the project establishment to the project completion, there will be a continuous derivation of new risks, and new risks need to be identified, analyzed, responded to and monitored in a timely manner, so as to be proactive and strategic.
Of course, the project manager has a strong ability to respond to emergencies, is a strong embodiment of project management ability, encounter unknown risks, can calmly deal with, the response plan is considered perfect, smooth processing in the project progress, and gradually reduce the risk to the minimum.
No comments:
Post a Comment