Internet Project Risk Management

No risk is the greatest risk.

Charlie Munger often quoted a proverb: "If I know where I'm going to die, I will never go there." This reverse thinking model is one that we can use in our work.

Image Source: quotefancy

Every project is a big or small battle, and risks are everywhere in project management. If we know what risks will arise, we can prepare in advance, thus greatly improving the delivery rate of our projects. Project managers always worry about various uncertainties, requirements, decisions, team members, schedules, etc.

In addition to the concern, we need to have a holistic view of the project, carefully consider all kinds of constraint risks in advance, and accumulate a set of systematic risk management methods in various practices. With such a method to do risk management, we can have a well-thought-out plan to minimize risk and maximize project delivery efficiency.

I. List the risks of the project at the early stage

Project managers try to prepare in advance by listing all the risks they can think of in the project.

The number of risks in a healthy project should decrease with the timeline to be within control.

When an event is uncertain whether there is a risk, it is counted as a risk point. It is possible to have risk, and risk control is to ensure that some risks do not happen or that there are countermeasures.

To this end, we can maintain a list of common risks for Internet projects.

At the early stage of the project, check the risk list one by one to form an early risk list of the project, and publicize it to the stakeholders of the project team in a timely and transparent manner so that everyone can be aware of these risks in advance and work together to produce corresponding solutions.

Today's problems are yesterday's risks.

Where do the risks of Internet projects come from?

In general, we can divide risks into the following categories:

1. Demand

• Increasing demand.
• Demand change frequently.
• Changes in demand lead to adjustments in project plans.
• Changes in demand lead to the risk of test case adjustments and test work changes.
• Demand planning and positioning need to be clarified.
• Stakeholder decisions on demand take a long time.
• Changing management needs to track records and inform all sides to develop and test on time.
• Module refactoring leads to additional work.
• The new product direction takes more design time.

2. Personnel

• Project understaffed.
• Someone left before the project ended.
• New project members cause additional communication costs.
• Problematic members slow down team productivity.
• The project needs more key personnel.
• The assignment of tasks does not match the skills of the people.

3. Process

• Lack of necessary standard specifications.
• Too much documentation affects progress.
• Progress tracking needs to be more accurate.
• Writing progress reports to management takes the developer more time than expected.
• Software project risk management takes longer time than expected.
• JIRA task information was not updated on time.
• Task description information needs to be more sufficient, resulting in high communication costs.

4. Plan

• An ideal but unrealistic plan.
• The P0 task needs to be included in the plan.
• The workload is greater than estimated.
• There is no buffer time (study, review, sharing).
• The tasks need to be allocated properly.
• Too much overtime affects efficiency.
• Prerequisite tasks cannot be completed on time, affecting subsequent tasks.
• People on vacation.
• Efficiency decreases around holidays.

5. Communication

• There are too many inter-team coordination and management, and communication links.
• There need to be incentives, leading to low efficiency.
• Information communication must be in place due to conflicts among project members.
• Communication and information transmission mode needs to be clarified and consistent.
• Not communicating well with other external dependencies.

6. Technology

• Complex technical research and selection take a long time.
• The unstable development environment led to the delay of the joint investigation.
• An online emergency problem fix affects the current development schedule.
• The launch plan could be better.
• Testing environment problems affect testing progress.
• The quality of the R & D test that is lower than expected affects the test schedule.
• The design has a logic bug causing rework.
• More scheme design reviews should be included.
• Preliminary investigation and evaluation of technical difficulties.
• Code review fails to detect code problems in advance.
• There needs to be more than the development self-test.
• Code management is below standard.
• The difficulty and complexity of testing should be fully considered in advance.
• The unfamiliar deployment process takes a long time.

7. External Dependencies

• The external dependent interface needs to be delivered on time.
• The external dependent product is unstable.
• The external cooperation details still need to be put in place.

8. Equipment and Environment

• The server cannot use in time.
• Whether the mobile terminal device models are comprehensive.
• Laws and regulations.
• Trends in Technology.
• Business model.
• Competition in the market.

With the above list, you can prepare countermeasures for many risks.

II. How to deal with risks?

First, we need to have a good mindset. It's good to anticipate these risks early, so we can handle things that are completely out of control. For example, the test leader will leave the company, the developer, the team's leadership will change, the project will be canceled temporarily, and so on. Especially for weak matrix project management, worrying too much about these risks will affect the effectiveness of coordinated execution. Therefore, we should keep an optimistic attitude to deal with these risks.

Secondly, do research on the project at the early stage: clarify user needs and product direction to reduce the changes at the later stage; prepare technical research early so that senior technicians can make the best technology selection according to the present situation of the project. For common risks (constantly increasing requirements, poor code testing quality, inaccurate schedule, not fully known change records, irregular release process, and so on), the corresponding process that is more perfect can be used to mitigate and prevent the occurrence of problems.

For example, it is stipulated that new requirements are not accepted in a fixed time box: centralized code review is adopted, multiple code reviews are arranged, Jira and Git warehouses are connected to do function follow-up, and the scope of smoke test cases is expanded; appropriately change the functional scope of the project to ensure the successful launch of the plan; the schedule fully takes into account holidays, learning, meeting, review and other buffer time; maintain the wiki page of public demand change record, set up chat groups and mailing lists for each role of the project, and inform stakeholders of any changes in time; Standardize the release process, including Release note, Code review report, functional test report, abnormal test report (if any), and performance test report (if any). In addition, it is required that the development leader, the important stakeholders of development, QA, and PE/SA/DBA must participate in the review and give opinions.

1. Learn to delegate risk to a professional team.

For example, a professional DBA is responsible for the database module; a professional performance test team is responsible for performance; legal Specialist and patent teams are responsible for drafting and reviewing legal provisions; Submit work orders to apply for Information Security Department to do professional security testing; If the safety requirements are high, you can also apply for funds to invite external white hat team to do further safety testing.

2. Learn to make plans, and many tasks can be planned in advance.

For example, can we prepare the recruitment process in advance if there is a change in personnel? If there is no quota, which can be the backup personnel?

After the project launch, we need to analyze the relevant data, so we should do a good job of event tracking and distinguish the data sources in advance. It is expected that the operation will have multiple activities according to holidays, so switch well in advance and switch multiple banners.

III. At The Last

Learn from each project to improve your risk management capabilities, from being tired of dealing with problems after they occur at the very beginning to being able to mobilize resources to solve problems, then predicting risks in advance. From qualitative analysis to quantitative analysis to make effective preparations. It would be even better if we could turn problems into opportunities. If every risk is a pit, learn how to jump gracefully and walk with a spring in your step, or fill it and use it as a stepping stone for the next jump. The higher you go, the wider the view.

Finally, I would like to share Aaron Wildavsky's phrase, "No risk is the greatest risk."

Need more help? Check out the Zentao blog. They have more articles on project management tools, software management, building cross-functional teams, and so much more.

---

Author bio :

Li Hui, PMP in NetEase Hangzhou Research Project Management. Successively engaged in operation and maintenance services and process management. At present, She is focused on agile project management in the Internet industry. As the project manager in the NetEase Account Center, She is responsible for the overall project management and committed to efficiently delivering the Internet team project. She is also one of the main editors of Micro Major in NetEase Internet Project Management.