How to become a good project manager(Part.2)

4.Set The Rules

No rules, no standards. The project team is large or small, but the management process is similar. To ensure that all the project team members can carry out their work in a normal and orderly manner, the key is to set reasonable internal rules, that is, reward and punishment measures.

As the saying goes, under heavy money, there must be a brave man. Under conditions, the project manager should strive for reasonable project rewards. Note that this is a reward, not a bonus, because there are many ways to reward, including cash, rest, and travel. and many more.

Conversely, those who violate the system within the project and adversely affect the development of the project will also be punished for responding. Including non-participation in regular project meetings for no reason, deliberately creating conflicts within the project team, etc.

But one thing to note is that the rewards and punishments of the project team must be "less than" and not clearly defined in the company system to avoid receiving multiple rewards or punishments.

5.Prevent Risks

Regarding the importance of risk prevention, it should be something that everyone has been shouting from the beginning of the project. However, in actual projects, there are often some risks that are not well identified, which leads to unsuccessful project development and lighter delays. , It fails again.

The author has a real example. My friend’s company was doing power construction projects before. From accepting the contract to equipment research and development, there was no problem. It was not until the equipment was transported to the actual site that there were two power equipment that needed to be installed. On a small island, there was no way to install cranes on site, and it was impossible to move the poles manually. As a result, not only did Party A pay a high amount of compensation, it also affected the company’s reputation, even this basic The risks are not identified.

For software projects, risks are everywhere. According to the author's actual experience, risk identification needs to be analyzed from the following aspects.

There is also an association relationship between each type of risk. It is very likely that the occurrence of a certain risk will cause a chain reaction of other risks, which is somewhat similar to the butterfly effect. Therefore, correct identification of risks is very important.

The project manager should analyze it together with the core role of the project team and formulate corresponding measures to avoid a good response when a risk occurs.

5.1  Time Risk

This mainly refers to the project schedule. Software project delay is very common, so the time risk is easy to identify.

The project manager needs to make a detailed project plan, make a WBS, and track the plan every day, as well as analyze the problems that arise.

For the failure to normally output the results within the agreed time, it can be compensated by appropriate overtime work. For the time delay caused by the quality problem, on the one hand, the architect needs to guide the developers in the technical processing, on the other hand, it is necessary to strengthen the testing efforts, as soon as possible Find quality problems and solve them as soon as possible.

5.2  Personnel Risk

The change of project team personnel is also a common problem, the most troublesome is the change of core personnel. Therefore, for the prevention and control of personnel risks, project managers need to make a backup plan for personnel so that they can fill positions in time after personnel changes occur and minimize the impact on the project.

Project managers need to always pay attention to the status of project team members. For employees who are at risk of resignation, they must be able to identify as soon as possible, especially before the peak of job-hopping at the end of the year and the beginning of the year, they must have a certain preparation plan.

In addition, the design materials in the software project development process must be output and updated in the form of documents, which can also prevent quick take over after personnel changes.

5.3  Technical Risks

If the project manager can do a good job in the project plan and WBS, technical risks are easy to identify, because all technical implementation issues will be considered when planning and evaluating the workload.
So do we have other technical risks that are easy to overlook?

The answer is yes.

When the author was responsible for the development of a certain product, one of the technologies required to rely on the existing technical capabilities of a third-party company. However, when the project was about to enter the final stage, a message suddenly came that the third-party company was due to its own technological achievements. Involving intellectual property issues, it is impossible to achieve commercial output. This has dealt a heavy blow to our project. Because we did not make any backup plans, the project had to be postponed, and re-selection, re-business negotiations, and re-development of technical interfaces were finally The project was postponed for more than half a year, causing huge economic losses.

Therefore, in terms of technology, in addition to the need to well identify the technical risks within the project, if there are external dependencies, a backup technical plan must be made. This aspect also includes the selection of the project’s hardware supplier. Generally speaking, there will be Two or three suppliers will never rely solely on them.

5.4 Target Risk

One of the principles of agile development is to embrace requirements. In fact, there is the possibility of changes in project goals. This kind of risk is the most difficult to prevent and control, because it is often caused by investors, bosses or sudden changes in the market. For this kind of overall risk, the author believes that it needs to be controlled from two aspects:

Close the project as soon as possible, and then re-establish the project according to the new goal;
To ensure the effectiveness of the output of the milestone goal, at least to ensure that the project has certain results, and some technologies must be settled in time. These can basically be reused to minimize losses.

6.Get Results

As mentioned earlier, the goal of project development is the success of the project, and the project manager must bring the project team members to ensure that the project is completed on time with quality and quantity at all costs. For project managers, project results are also key KPIs.

From the author's point of view, the project process will be a relatively long period of time, and the project needs to output the results in stages. On the one hand, this is the basis for achieving the success of the project, and on the other hand, it is also like the company's executives to show their own capabilities. Therefore, the project manager cannot just pursue the final result. That is not only risky, it is also not conducive to proving themselves.

In addition to the goal of project success, the project manager also needs to pay attention to the achievement of the project team members' "capacity improvement".

This is something that many project managers tend to ignore. There are two reasons for this:

First of all, if the project fails, but the ability of the project members has been improved, it can also recover a little loss for the company;

Secondly, in other project work in the future, the project manager will probably need to continue cooperating with this wave of people. Everyone will miss you. If the team members can improve their ability, they will definitely be in the follow-up work. More handy.