How to break down project management issues? Source

Translated

"Project management" is a cliché that has always been a big issue in product implementation. The project must be monitored and managed to deliver a product on time and with smooth output.

Project management is a professional discipline, and the study of its methodologies is different, but the final focus is on two key points: Persons and Events.

Products are also divided into different types of nature one is project-based products and self-directed products; the project refers to a specific enterprise or government through the public way to tender or claim the project, from the drafting of the project tender to the completion of the project, the main needs of the tenderer and the established program as the core of a series of project activities, the final output is a project-based product, such products are highly targeted, low generality, and the cycle time will be the project-based products. The final product is a project-based product, which is highly targeted, low in generality, and has a limited cycle time. The company initiates the self-directed type to meet the company's business development or improve efficiency or reduce costs, or support profits of standard products; the basic functions of this product are more applicable, the face of the rich object is not limited, there is a lot of room for expansion or set aside for transformation space.

No matter what type of project it is, it is the same that the project team needs to be equipped with the related resources, including workforce, equipment, time, space, money, and other basic elements.

Common project processes include the development of a charter, limited scope, plan control, cost management, Quality approval, Risk prognosis, and Closing out the project.

Small and light Internet companies like to use agile development, small steps, and low-cost trial and error. In contrast, the medium-not-slip companies have to take the shape of the project as a standard for the team to measure the output because of the limitations of their scale or the construction mode of the product.

However, in non-traditional project-based enterprises, in the process of information transformation, not all production lines are equipped with project managers as important and business-savvy dedicated staff. Product managers often perform such work.

That is why we often hear that product managers also need to know project management. In fact, in addition to the lack of dedicated staff, part of the understanding of project management can not be easily trapped in staying on the surface of the project; only understanding its processes can not guarantee the quality of the project and ultimately achieve the desired goals, so the depth of the business should also have certain requirements. In addition, even with the role of project manager, he has multiple projects in parallel, and it isn't easy to assist the product focus on advancing the progress and management of the product line. Therefore, product managers and project managers are like two brothers who collaborate.

However, the problem is that when there is no project manager but a product staff, most products need the right or responsibility to ask about the arrangement and process of project members. Relying only on personality or personal charm will only consume personal emotions and a positive work balance. The following are a few suggestions：

1. When organizing a project meeting, invite relevant stakeholders to join, especially the technical team leader and the product team leader, as well as the joint leader of both parties, and give them a clear mandate, including the right to allocate resources, manage the team, and collect progress reports. If the leader is not available to attend this meeting, a written statement or email is required to inform the relevant people who will be responsible or act as such. Don't seem simple. In fact, within many companies with insufficiently standardized processes, the authority needs to be better defined, leading to different degrees of shirking responsibility by the relevant personnel. In addition, the verbal statement recorded in the group chat is unreliable.
   
   

2. Project reporting time control, time for once a week or twice a week is appropriate. The record's content needs to contain the current stage of the personnel of the week according to the schedule grid record of the development progress, as well as the status of whether the normal, delayed, the percentage of completion rate. Suppose there are notes to declare the specific circumstances of the personnel, such as leave, temporary tasks, other matters, etc. In that case, remedial measures are transferred to overtime, delayed to a later date, or completed ahead of schedule without the need to transfer and other instructions to ensure the development plan is kept up. Progress is copied to the project team members once a week, using the public's supervision to exert appropriate pressure and responsibility, rather than the product manager alone to a technical team.
   
   

3. The clear system, clear rewards, and punishments once the plan is confirmed, the executive in the implementation process, except in special circumstances, otherwise not at will to modify, there is a clear reward and punishment system, there is also certain reward system, but the reward needs to be at the company level to make decisions, so not necessarily all, so the department to see if the project members through other means to reward. To a certain extent, the incentive of bonuses will promote the motivation of members. Rewards and punishments can regulate the restraint of project members. Otherwise, the establishment of the project can not be completed on schedule for irrelevant members, and the urgent may be the product manager himself.
   
   

4. Create a sense of participation and achievement, no matter who. When a product is made and praised by others, the inner sense of achievement is self-evident, a reward for their efforts and self-seeking identity. So the project process, to ensure that project members can get something they want from it, experience or money, praise or selection encouragement, can all promote members' motivation. The bad thing is that if the product manager is fighting alone, the project could be easier to promote. The relevant rights and responsibilities of different people to be responsible for the best allocation of resources.
   
   

5. Project plan allocation, different project plan templates are different to what extent is determined by different companies, but work tasks must be broken down; WBS (Work Breakdown Structure) is one of the most common ways. The overall project is divided into different work packages and deconstructed from long-term to short-term, which is quite suitable for product managers' daily thinking mode, overall - deconstruction - analysis - implementation --Complete, WBS can visually and quickly show the task points and goals for each phase, to assist in clearly following the plan, but also to facilitate rapid problem finding.
   
   

6. Risk control risk generally includes qualitative and quantitative risks, and this part is more on the intellectual side. The limited personnel experience often needs to do a better job of comprehensively predicting risk. Senior products are also because of the continuous summary in the project to avoid the potholes encountered. Therefore, at the end of the project, doing a good summary or learning the dimensions of the experience of previous projects is an important way of primary identification of risk control. Secondly, you can brainstorm and organize the potential problems that project members will encounter in the modules they are responsible for, as well as the possibility of events when the product manager and other departments interface, such as process changes, personnel departures, changes in requirements, etc., list the table, set aside time to solve. In quantitative terms, the risks are uncertain but quantifiable. The book definition is a numerical analysis of the probability of occurrence of each risk and the impact it will have on the project objectives and the scope of the overall project risk. This type of analysis is targeted by the magnitude of the probability of occurrence and the measures taken to avoid it.
   
   

7. Requirements change. As the requirements initiator and project monitor, such a thing is a dilemma for people. On the one hand, we need to complete the project as scheduled, and on the other hand, we need to change to increase the development. Of course, requirements can only be changed if you want. Often, the project needs to be adjusted and redirected in time because of the company's rigid requirements, urgent requirements issued by the leadership, discrepancies with the initial requirements during acceptance, changes in core interests or market policies, such as changes in product trademarks, the introduction of the Personal Information Privacy Protection Act, and other uncertainties. The risks and impacts of changes at different project stages are different. The scope of the changes involved is also different, with changes that do not involve process changes as an example：
   
   

   The degree of impact: before the project < the project is not developed < the project is developed < the development is completed < testing < acceptance, the longer the time, the greater the risk cost.

   • After the project is established, it starts to enter the beginning of development, when the risk of making changes is less, and the project plan can be adjusted accordingly.
   • When entering the development stage, technology and product will repeatedly confirm the requirement points. Regarding the corresponding module, the technology at the front and back ends will be confirmed (not to miss any side), adjustments will be made, change matters will be added to the development plan, and the plan will be rearranged.
   • When the development or testing phase is completed, this time to propose changes has been completed. The rest is to change the bugs and other acceptance, but the product manager picks a problem. Patient communication and the need for change are very important at this time. We often talk about the leadership behind his back. Still, if we stand in the leadership position, I'm afraid that will also be in the heart of whispering, 'just know that the back talk, his ability to work is not very well.' So asking the leadership to help can only be done sometimes. After all, this may also be the last bottom card. Over time, the leadership may be unsatisfied with the product people's self-suggestions, and the implication will be solidified and not easy to eliminate.

So what to do? To this, dare not say I must have seen results. After all, project management has a history of a hundred years, and experts have yet to figure it out, only through my experience to share.

Maslow's needs principle is becoming more and more well-known. Treating everyone to a meal does not seem to make up for the need for personal emotions, and I am unable to do. Therefore, it is better to look for moderate ways to move the project forward, such as (objectively) letting the project stakeholders understand the reason and importance of the requirement changes, clarifying the content of the requirements, and finding the smallest change executable solution, calculate the potential value or changes can bring benefits, conduct meetings are also necessary, private notification is not supportive. (Subjective) Let them know that the product is thinking from their point of view, discussing the source of the change but with a hopeless attitude together.

Requirements changes are common, and product managers must filter requirements to control the project. Large changes will likely interrupt the project, so you must recognize this. Product in the middle of the marketing department and project management department is a dilemma, in addition to a demand for a microphone tool, I think, more in which to play their initiative, there is no product proposed immediately can be made, good products worth waiting, and the project process is the time and effort spent on our waiting. Still, only the market can verify whether this wait is worth it.

------

Need more help? Check out the Zentao blog. They have more articles on project management tools, software management, building cross-functional teams, and so much more.