Three Steps of Project Management Source

Translated

Suppose we want to prepare for a project. In that case, we will often communicate with the business side, do demand research, scratch our heads and puzzle over how to submit the perfect product proposal, communicate with related staff to provide numerous visual effects and behaviors, argue with the developers, and obtain the modified function finally.

We may feel relaxed at this time while the product is just an embryo. If the project is not managed poorly, it could be stillborn. Project management plays an important part in daily work. The capacity for developing new products is often manifested through project management. There are some problems in the project team with poor management:

• The cost of development is higher than expected, causing products cannot be delivered on schedule;
• Project members are not clear about the product goal, and some requirements with lower priority are inserted in the development;
• The project members are unclear about the task, final delivery, and delivery time. You may think they know what a deliverable is and when to deliver it, but they are confused when you ask them.
• ......

These problems seem unrelated, but they are due to the poor management of objectives and risks in the project management process. The capacity of project management is more important when working across multiple teams. Otherwise, the team members may blame each other for disorders and pass the buck. So how to manage the project?

So how to manage the project?

1. Break Down the Goal

According to the project's overall goal, the project leader breaks it down into each small teams, then the individual. Each person should provide a clear deliverable and delivery time called WBS.

WBS (Work Breakdown Structure) is the same principle as factorization: breaking down a project into different tasks according to certain principles. Then the tasks are broken down into different works assigned to each person's daily activities until the tasks cannot be broken down.

That is: Project > Task > Work > Daily Activities.

The task must be 100% broken down. The smaller the task, the stronger the risk resistance. The task assigned to each person must be broken down by themselves. Sometimes the time for the project is very tight, so we want to start as soon as possible after getting the task. We know the modules we are responsible for, but there are potential logical or time dependencies among some of them. It may be too late to muster the support of others when we do this. We can only wait for others to finish it before we continue, undoubtedly resulting in the project delay.

Therefore, the force majeure in the project results in the delay due to insufficient target disassembly before the project initiation. Everyone is not clear about what to deliver and when to deliver. They are in the state of "I should know" or have different understandings of the deliverable.

The following is an example of WBS for reference, in which the risk module is discussed in Part 3.

2. Unify the Team Goals

After creating the WBS document, we should hold a meeting to confirm the contents of the WBS document and unify the team goals, hoping the project members develop a clear understanding of their position in the project, the contribution to the overall goal of the project, what is the most important thing for the project, and then make a more accurate judgment of the priority of their work.

It is necessary to have a clear idea of what to do when to do it, and what external assistance is needed to ensure that everyone in the team has a consistent product vision and focuses on the product goal.

The following content is excerpted from Tencent Product Law, which explains the meaning of unifying team goals.

Anyone with experience in project development knows that there are various problems in the project process, and there is no "perfect project" with no problems and successful products. More importantly, if team members fail to think about the modules they are responsible for from a macro and holistic perspective, it will inevitably result in internal design conflicts because the conclusion from the single perspective is opposite to that from the holistic perspective for many problems.

Project members fighting for a goal are like a community of destiny instead of working in isolation. "Each member has the habit and behavior of thinking from the product manager position."

The team breaks down the task, but the goal remains complete. There is no "my idea," only "better idea," no position, only rational judgment in the team. They will argue passionately about an issue only to pursue a "better solution" instead of defending their ideas.

There is no "your problem," only "project problem" in the team. The members recognize and trust each other. They believe they can be responsible for their part and will actively contribute their strength and find ways to solve the problem together when the project hits a bottleneck. When there is a conflict between internal modules, they can also move out of their role to discuss and use the opposable mind to look at the problem more comprehensively.

3. Follow up and Synchronize the Project Progress

The Daily Scrum Meeting and weekly project report are good tools to control the project's progress and ensure transparent information.

The boss is afraid of not knowing what his employees do, and the project leader also does not know what his team members do and how far the project is going. The Daily Scrum Meeting can effectively expose problems timely. You can effectively ask team members for help when encountering problems. Once some risks occur, they should be recorded in the risk management module of the WBS document, followed up by the designated person, and asked periodically.

At the end of one week, ask all project team members to help complete the weekly project report and synchronize it with the superior and the leader of all business parties to establish an effective communication and reporting mechanism and improve the external transparency of the project.

To avoid too much content in the weekly report or the leader being too busy to check the weekly report, it is better to contact the leader separately and briefly report the project's current progress. Reporting work is incredibly important. Otherwise, you may do many things your boss doesn't know about.

The weekly project report is not the sole responsibility of the project leader. The weekly project report includes the following modules: current project progress, completed work, next week's work plan, and current risks. The project progress and work plan filled in by the project leader or the plan filled in by the developers and testers must be feasible and specific to the date after being accepted by everyone.

The core is all documents produced during the project. Everyone on the project team should approve the WBS and the weekly report. Throughout the project, everyone needs to be on the same page.