Project management capabilities are even more important when working across multiple teams, otherwise chicken hair and mutual ripping make team members push and complain to each other. so how do we manage a project well?
when we are ready to do a project, experienced and business side of the many times to communicate, to carry out demand research, thinking, repeatedly consider the product plan, and interactive visual communication, to give the product a beautiful coat, and finally to develop "tearing", to get "cut" after the "injured" function.
You think you can breathe a sigh of relief, but at this point the product is just an embryo. if you do not do a good job of project management, it is very likely that the fetus is stillborn.
Project management, in the daily work of products, also accounted for a large part of the weight. product capabilities are often externally manifested through project management.
The project management is inadequate and there is a high probability that the project team will encounter a number of problems:
development costs are higher than expected, and products cannot be delivered on time;
project members are not clear about product objectives, and other lower priority needs are inserted during development;
the project member is not clear about the final delivery level and delivery time of his task, you think he knows what delivery is delivered at what time node, and wait until that day to ask him, he is blind;
......
all of these issues appear irrelevant on the face of it and are essentially due to poor objectives and risk management in the project management process. project management capabilities are even more important when working across multiple teams, otherwise chicken hair and mutual ripping make team members push and complain to each other.
so how do we manage a project well?
first, target disassembly
The project leader splits into small teams according to the overall project objective layer, and then breaks down from the team to the individual, each giving a clear delivery and delivery time node, a document known as WBS.
WBS (Work Breakdown Structure), the structure of work decomposition. Factor decomposition is a principle, that is, a project, according to certain principles of decomposition, project decomposition into tasks, tasks and then decomposition into a work, and then assign an item of work to each person's daily activities, until the decomposition can not go on.
that is: project > tasks> work > daily activities.
Tasks must be 100% decomposed, and the finer the particle level, the higher the risk resistance. tasks assigned to each person, each person has to break down the tasks themselves.
Sometimes, the project time is very fast, we get the task and want to start as soon as possible, think they are responsible for the module is very understanding, in fact, some modules exist between the potential logical dependence or time dependence.
When this piece only found that need someone else's support, it is too late, can only wait for others to get well to continue, which undoubtedly to the project extension and "contribute" a force.
So it seems that the force majeure factors encountered in the project led to the project delay, largely because the project before the start of the target dismantling is not enough, everyone on what time node should be delivered at what point, everyone in the "should know" state or do not understand each other's delivery.
Unify team goals
After the wbs documentation is developed, in order to allow project members to clearly see their position in the project and their contribution to the overall project objectives, but also to let the project team members understand what is most important to the project, and then to make more accurate priority judgments about the work in their hands, we should organize a meeting to confirm the content of the wbs documentation, unified team goals.
Everyone needs to have a number in mind, know what they want to do before what time and what external assistance is needed, and ensure that each member of the team has a highly consistent product vision and can only fight around product goals.
The following is excerpted from the ten-cent products act, which is a good illustration of the significance of unifying team goals.
Anyone with experience in project development knows that the project process is always accompanied by a variety of problems, completely without problems, the product is also a great success of the "perfect project" does not exist. what's more, if team members can't think about the modules they're responsible for from a macro, holistic perspective, it's bound to lead to internal design conflicts. because many problems come to the opposite conclusion from a single-module perspective to the overall perspective.
Project members who fight around the target do not fight on their own like this, but rather, they are like a community of destiny, "each member has the habit and behavior to think in the position of product owner" .
Tasks are broken down by the team, but the goals remain intact. there is no "my idea" in such a team, only "better ideas", no position, only rational judgment. they will also have a heated debate about an issue, but only in pursuit of a "better solution" rather than to defend their views.
There is no "your problem" in such a team, only "common problems of the project" and mutual recognition and trust among members.
They believe that they can do a good job of dividing things, but also in a certain link encountered bottlenecks when actively contribute their own strength, together to find a way to solve the problem. when there is a conflict between internal modules, they can also jump out of their roles in time to discuss and examine the problem more comprehensively using relative thinking.
Follow up and synchronize the progress of the project
daily standing morning meetings and project weekly reports are a great tool to control the overall progress and keep project information transparent and smooth.
The boss is most afraid not to know what the employees are doing every day, the project leader is also most afraid not to know what team members are doing every day, the project to what extent.
Every morning session can be very effective in time to expose problems, encounter problems, can effectively ask team members for help. once a risk point occurs, the risk management module documented in the wbs documentation is followed up by the designated person and regularly asked.
at the end of the week, let the project team members help complete the project weekly report, synchronize to the superiors and business leaders, establish an effective communication and reporting mechanism, improve the external transparency of the project.
in order to avoid the weekly newspaper content too much or the leader is too busy to have time to view the weekly report, it is best to contact the leader separately, simply explain the current progress of the project. upward management and its importance, you may have done a lot of things, but the leadership is unaware,
Note that the project weekly report is not a matter for the project leader alone, the project weekly report usually contains: the current project progress, this week's work completed, next week's work plan, the current risk point several modules. project leader to fill in the project progress, work plan, etc. or development test colleagues to fill out the plan must be recognized by everyone after practical, specific to the date.
Core or project process produced by all documents, whether wbs is good, or project weekly report is good, should be recognized by everyone in the project team, the whole process of the project, we all want to be consistent goals.
After the ravages of a project, sum up the above three points, only personal work experience summary, not necessarily applicable to everyone, but also hope to give you some reference, a total of encouragement.
No comments:
Post a Comment