1. Internal and external processes and communication mechanisms are not smooth.

2. Progress control issues.

3. Resource management issues

4. Risk assessment issues

5. The acceptance result is unclear

6. Result assessment and incentive measures are unclear

1. Business department input: customer supplied 2D/3D, RFQ documents, acceptance requirement documents

2. Technical department output; risk assessment manual

Register stakeholders, assign roles and permissions, and prioritize

Project requirements document requirements tracking matrix

Record the customer's needs and check the "Project Requirements Confirmation"

Define and select project requirements

Prepare scope statement

Agree with stakeholders (mainly internal functional departments within the company)

Task Breakdown (RACI) Roles Considerations

PERT diagrams are actually PDM diagrams and ADM diagrams.

human Resources

Material resources

Combined with customer needs, plan project time based on project resources

Achieve project progress consistency with project stakeholders (internal departments, external customers, suppliers)

Develop the project schedule and task planning document based on the early WBS and project time planning.

Integrate the PERT chart and use CCM (Critical Path Method) and CPM (Critical Chain Method) tools to integrate some tasks in advance

organizational process assets

Customer requirements document

Company quality requirements

Customer requirement list, stakeholder review meeting

Technical agreement or other confirmation signature

What truly ensures safety are reasonable processes and mechanisms.

At the start-up stage of the project, the project manager must stay calm (sometimes withstanding pressure) and first sort out the requirements, plans and work models. Problems that can be solved in one day at this stage sometimes take three months to solve during the execution stage of the project.

❶ First, clarify the needs and what to do? Why do it? How to check and accept? What are the acceptance criteria?

❷ Then, obtain senior management authorization, establish a work team, and implement the required resources.

❸ Finally, clarify the internal division of labor, working mechanisms and processes.

The sign of completion of the project startup phase is not the kick-off meeting (perhaps in form), but that the requirements are clear, authorization is obtained, and the process and mechanism are determined.

How to coordinate and compromise? Are there any guiding principles? Yes: Understanding true motivations is the basis of communication, and being business-oriented is the basis of compromise.

But no matter what style, the most important thing is to find a "sense of rhythm", which means that you push things forward instead of being pushed by things.

How to find this rhythm seems to be a relatively "mysterious" topic, but there is a basic pattern: the medium and long term rely on milestones, and the short term relies on the reporting cycle, which is the regular meeting of the project.

The project manager has two important lists, one is the risk list and the other is the problem list. These two tables are what must be discussed at every regular meeting, and they are also a mechanism to implement the project plan into action.

The risk mechanism does not necessarily ensure that problems do not occur, but ensures that the occurrence of problems can be recognized at the earliest possible time and countermeasures can be taken in a timely manner.

For many problems, there is no solution at the end of the day, but if you know it in advance, you will have a solution.

We mentioned that the project manager has two tables, one is the "risk table" and the other is the "problem table". The ideal situation is that most problems appear on the "risk table" and the "problem table" There is very little content. If the opposite is true, your project has turned into a nightmare.

The work related to acceptance starts from the first day of the project. Don’t wait until the acceptance node is approaching to communicate detailed requirements, acceptance criteria, and methods with users.

As for documentation, this is a job that many people dislike very much. I only emphasize that a lot of seemingly meaningless work at the "personal" level is very valuable at the "organizational" level. A lot of documentation work is to accumulate process assets for the organization, so project managers must learn to work according to the organization's architectural process.

Project documents must not only comply with internal requirements for document specifications, but also be valuable to relevant stakeholders. At the same time, more importantly, they must be able to help you achieve the goals you want.

Some incorrect ideas:

If the project manager is very weak and it is difficult for you to influence the salary and promotion of team members, then why should the project members listen to you?

You need to convince everyone about your skills, attitude and even character.

Maintain adequate communication with management.

It's unrealistic to completely eliminate change, but there are at least a few things you should strive to do:

Demand obtained through indirect channels is often seriously distorted, and it is difficult for you to understand the true thoughts of customers.

The project manager may not have the right to reject certain change requests from customers, but requires the customer to follow the process and submit the changes to the correct level for decision-making.

The system may be rigid, but in many cases it can only be "rigidized first and optimized later." Rigidity is actually a process of standardization. If you hope to "optimize" from the beginning, in fact it is often not optimization, but "simplification", which in disguise returns to the chaotic state of fighting each other.

There is no strong "position power", so communication skills must be used to achieve the goal.

For project managers with senior technical background, there are two most common problems:

The so-called communication model refers to the division of labor, processes, interfaces, models, approval processes...these factors that affect communication between departments and teams.

What’s important is not just how to solve a specific problem, but how to prevent the same problem from recurring in future project communications.

Whether stakeholders are satisfied often does not depend on whether the problem itself is solved, but on whether sufficient and good communication has been carried out with them.

Project managers need a certain amount of authorization and a performance feedback mechanism to facilitate work.

Project managers are not experts, at least you can no longer position yourself as an expert, but should pay more attention to business and management.

The project manager is a "driving force" for the enterprise. In the enterprise, many things will never be moved if there is no one to "push" them.

The value of a project manager is to help management push things forward, especially those tasks with high resistance.

The value of being a project manager is to help your boss (or client) think, push, and turn their ideas into reality.