Corner of Project Management

Everyone is a leader in project management. I have been immersed in project management for more or less a few years. I want to avoid it and talk about the gray area of the corners. It is really the main purpose of this Article.
Most of the project management processes focus on the process rather than on accumulation, and have clear methodologies and practical experience in process control, resource allocation, and progress monitoring, however, risk management in the early stage, experience management in the project construction, and summary and evaluation in the later stage of the project are at a loss.
The post-project evaluation questions are relatively broad. Even if you already have a paper, you still feel that it is thin. After you have accumulated some experience, we will discuss this aspect again. I will not mention it this time.

Experience Management in projects

I personally think that in project management, the experience of teamwork, the accumulation of leadership, the improvement of personal technical skills, and communication skills have accumulated some experience at a macro level, but they are limited to individuals in the project. For a simple example, for problems such as encoding changes caused by an operating system, it is limited to members of a group, and most of the messages delivered are in the form of words and deeds, in other words, there is no clear answer if you do not have an active question. This means that information cannot be fully shared even if there is sufficient communication between the project members and external members throughout the project construction process. The reason is that most of the projects are managed based on their current projects. There is no global concept and there is no mechanism to support global project management. It is true that there is no error in project management based on the current project's starting point, but as a whole, or an enterprise, project communication is still incomplete. So I fixed what I said just now. in project management, there is a lot of attention to individuals and less attention to the entire enterprise.

Experience Management aims to store and share the experience gained from implementation of various projects in an enterprise in a unified manner. Experience Management must first solve the problem of "What is experience ", experience is an unquantifiable entity. Indeed, a small tip in code, a summary of a customer's behavioral habits (for example, Manager Zhang only prefers Hongta), and a Member's work summary, these are experiences from an individual perspective, but they are invisible to the Enterprise. In my opinion, at the early stage of experience system construction, no matter the system's experience provider, experience recipient, or experienced system management personnel cannot accurately determine what experience is, we can adopt a brainstorming approach like "delaying criticism, focusing on quantity instead of results", and then constantly pick them out during the accumulation process of the system.

An experience management system may be a wiki, a BBS, A SharePoint site, or even a portal maintained by a separate department. It doesn't matter how experience management is implemented. As long as it can achieve its goal, even a QQ group is reasonable. The construction of an experience system requires continuous Contributions from members of various departments of the enterprise and a complete organization system. An experienced system should have the following features:
1) simple and effective query. Although this description is simple, it is an important criterion for measuring the sharing capability or success of an empirical system. Multiple factors should be considered for implementation, such as full-text search, keywords, tags, and so on.
2) for a complete directory, the simple tree directory cannot meet the query requirements of the experience system. Therefore, the directory should be constructed using tags, keywords, users, and other attributes.
3) one or more administrators are responsible for classifying and even evaluating experiences.
4) a large amount of enthusiasm or enthusiasm of members. This is an important indicator to determine whether an experience system is effective. It must be assisted by the policy to be effective.

Risk Management

The reason why I consider risk management as a gray area is that risk management also has a substantial operability of documents or materials. Due to the uncertainty of risks and the risk differences of different projects, it is impossible to apply a unified and predictable risk model to a new project. Risk management is vague. Risk management needs to solve the following problems:
1) How to accurately determine risks in the project?
2) How are risk conversion indicators determined?
3) How can we evaluate the practical degree of emergency measures?
5) how to implement risk inspection?
6) how to assess the accuracy of the risk matrix?
It is necessary to briefly clarify the terms above. Risks refer to any things that may have a negative impact on the project; problems refer to things that have already had a negative impact on the project; risk conversion refers to a process from risk to problem. Risk inspection refers to the process of risk monitoring during the project process.
The main topic of risk management is to quantify risks and then form an operable and comparable table, because there is no complete actual operation, let's talk about the actual operations of using the risk matrix table for risk assessment and some trivial issues.
If risk management is attributed to an instance of the knowledge system, I personally think that the project experience management system mentioned above can include some risk management information and experience.
The accuracy of risk estimation is an interesting topic, after the completion of the project, evaluate the gap between the potential risks estimated by PM or management personnel in the initial stage of the project and the expected impact of the risk assessment. This can be used to evaluate the PM or administrator's initial control over the project. This behavior should be self-managed by PM or management personnel. Only the risk evaluators themselves benefit from this behavior.

Not an out-of-the-box remark

Project management is free of Class, Class, and class. The rule is the outline, the reward and punishment is the goal, and the outline is also called. The rationality of a specification does not depend on whether it takes all aspects of project management into account, but on how powerful the implementation of this specification is. On the one hand, it is the enterprise's policy orientation, on the other hand, employees should be stimulated rather than forced to execute the regulations. Rewards and Punishments are also essential in management, but the implementation process is debatable. Throughout the process, we should pay attention to the principles of fairness and transparency of rewards and punishments) it is a guarantee for rewards and punishments.
A management method or method is not important for implementation. It is the result of an empirical study. Therefore, project management should not be regarded as a process-based management job, but a job similar to knowledge accumulation and empirical work. It should be a job that individual and enterprise departments continuously develop.

Some comments have made progress. jeason is not arrogant. You may be in the palm of your hand.

Whether it's post or original, this article is from the site of jeasonzhao (Shen shengyi) Happy journey