Project risk is an uncertain event or situation, once it occurs, it will have a positive or negative impact on at least one project goal, such as schedule, cost, scope or quality goal. So what are the risks of IT project management? Let's see:
(1) technical risk.
The core system upgrade introduces the latest products of outsourcing manufacturers and uses many new technologies. R&D personnel in the industry need some time to get familiar with these technologies, but they will inevitably encounter some technical problems during the project. How can we solve these thorny technical problems quickly? Our approach is: first, appoint the contact person of the outsourcing manufacturer in the industry, who is responsible for communicating with the technical personnel of the outsourcing manufacturer. At the same time, this contact person is also the person who is most familiar with the manufacturer's products in the industry, so that ordinary small problems can be basically solved by this person, and more complicated problems can be solved by the manufacturer, which saves time compared with all problems. Second, buy the manpower of the manufacturer for technical support, and invite the R&D personnel of the manufacturer to come to the development site to research and develop with us. Third, during the online period of the system, make an appointment for manufacturers to stand by on the spot, so as to deal with emergency problems and deal with possible problems at the first time.
(2) Communication risks.
The project involves many outsourcing vendors, many communication channels and high communication cost, which is prone to inconsistent understanding. Therefore, the project team has set up a special PMO, which is responsible for making corresponding communication plans, appointing contacts in the industry for various manufacturers, implementing hierarchical management for internal personnel, organizing regular meetings to solve problems in the project process, preventing project delays caused by inconsistent understanding of requirements, making full use of existing communication tools such as mail, meetings, telephone calls and short messages, and popularizing an instant messaging tool as the main work communication tool.
(3) the risk of demand change.
In view of the inevitable demand change activities in IT software projects, after the project started, our department stopped all new business requirements with a scale of more than 20 people/day except policy requirements, and at the same time formulated a demand change process: all business requirements changes must be put forward by business representatives in a unified way, and the changes must be recorded in writing, and the developers should carefully evaluate whether they are accepted or not. Finally, it was audited by CCB, which had a veto power, thus streamlining some unreasonable requirements. In the middle of the project, IBM's configuration management tool CCCQ was introduced to manage code and defects. All bugs are classified and entered into CQ system to prevent repeated modification, and there is no record after modification. The defects after the migration exercise are all analyzed and reviewed by the system leaders, so as to eliminate the system association problems that may be caused by Bug repair.
(4) schedule risk.
The core upgrade of the project has caused changes in the data structure of the client and some external interfaces, and at the same time, the front-end business platform has also been greatly adjusted, such as developing a new authority system, migrating the authority data of the old authority system of the host to the microcomputer, replacing the transmission protocol XML with JSON, and transforming the framework for the microcomputer to call the host. The development workload of host platform and open platform is huge, so it is necessary to set aside enough time for st and UAT testing, and the project development time is limited. In order to cope with the possible progress delay, we have taken the following countermeasures: First, we have made a detailed progress plan and defined everyone's tasks. Each project team will regularly check the progress of the project every week and correct any deviation in time; The second is to cooperate with outsourcing companies, introduce outsourcing manpower, and temporarily add more new troops to the project; The third is compulsory overtime; Fourth, parallelize detailed design and coding, and strengthen code review, so as to speed up the progress and reduce rework.
(5) Risk of data migration.
The project involves hundreds of systems, the system integration environment is complex, the amount of data to be migrated is huge, and data migration requires high accuracy and integrity of data. The project has formulated a strategy of phased integration and multiple migration drills: preview the migration work in advance and simulate the real online migration scene. After many drills, the problems are greatly reduced, and the risk of data migration on the system is also reduced.
(6) Human resource risks.
The construction period of the project is long, lasting for two years, and large-scale personnel flow may cause the project to be postponed. In view of this risk, the countermeasures are as follows: make two preparations, try to keep the people who are leaving, be rational and emotional, and ask the human resources department of the company to improve the treatment of employees; At the same time, increase social recruitment, arrange backup in important positions, and prevent staff attrition due to accidents such as illness and resignation of members. In the end, this risk did not become a problem.
In the project upgrade project, I am responsible for the open part of two subsystems. Due to the high-level attention to risk management, I also pay special attention to risk control when implementing it. There are four people in the project team, and the communication cost is relatively low. Therefore, code review is conducted every other week to solve some technical problems and coding specifications. Checkstyle is used to check code specifications in actual development, so as to kill possible bugs and irregular codes as soon as possible. Make weekly progress report system for team members to prevent progress deviation; In the face of the most likely demand change in the front end-UI change, I tried to communicate effectively with the business by using the prototype method in the early stage of design, which greatly reduced the need for UI change in the later stage of UAT. Looking back on a project I did when I first entered the company, I didn't consider the risk of UI requirements change, and I didn't communicate UI design in the early stage, which led to a lot of rework in UAT stage, the project was delayed for more than a month, and a lot of human resources were wasted. Imagine that if this kind of risk was identified at that time and the probability of risk occurrence was reduced at an early stage, then the project might be much smoother.
Due to the proper risk control in the early stage, the project I was responsible for went smoothly until the migration exercise, but there were some problems during the migration exercise, one of which was that the library wizard could not be executed normally and appeared many times. My colleagues and I spent a lot of time studying the problem, and finally found that the reason was a configuration parameter problem. R&D personnel used the wrong configuration parameters, and the data in the guide library during ST and UAT was much smaller than that during the real exercise, so it was not found. After modifying the configuration, the environment guide library was successfully implemented. There are still some problems caused by the lack of effective communication. For example, during the exercise, the user reported that the query transaction was slow. After investigation, the backstage staff said that the front desk had adjusted the wrong transaction, and the front desk staff raised an objection: Why is the ST environment query fast? It turns out that the background staff wrote a lot of inquiry transactions, and the new transactions can really improve the inquiry speed, but there is no formal document indicating that the front desk should replace the old transactions with new transactions, and there is no other way to inform the front desk, so the front desk calls the old transactions, which leads to query performance problems. Due to the differences between ST, UAT environment and production environment, it is difficult to expose the above two kinds of problems. Imagine that if there were no migration exercises, this problem would probably appear in production. The migration drill exposed the system defects that ST and UAT couldn't find in advance, which gave R&D personnel enough time to investigate the problems and fix the defects, and effectively reduced the system online risk.
After the baptism of this core upgrade project, I deeply realized the importance of risk management in IT projects. It is precisely because we pay enough attention to risk management and make a risk response plan in advance that we can solve all kinds of risks encountered in the project like experts and finally win the online victory. No project can avoid risk problems. The existence of risks makes it impossible for almost every project to successfully complete the project objectives. Good risk management skills help the project manager to deal with the uncertain factors in the project and ensure the smooth progress of the project.
;