7 common project management problems for new product managers

In the work of the product manager, in addition to demand research, demand analysis, and prototype drawing, project management is also the key to the success of the product launch. In this article, the author summarizes 7 project management problems that product managers may encounter, hoping to bring you some help.

Source：https://www.woshipm.com/

After entering the workplace, I deeply felt that demand research, demand analysis and prototype drawing are only a small part of the work of product managers. Project management is also the key to the successful launch of the product. Some companies with more detailed organizational structures will draw a clear line between the product manager and project manager, but most of the enterprises that I know require product managers to have the ability of project management.

After graduation, my first job title is "demand analysis engineer", which belongs to the project department. Usually, when we work externally, we will be unified as the project manager, but our actual work content covers all the responsibilities of the product manager + project manager. Therefore, in addition to learning how to better design system products, I also upgraded and grew up step by step in the process of project management.

Next, I will talk about the seven major problems encountered in the process of project management from the perspective of a new product manager, and interpret and give suggestions on these seven problems in combination with work experience, relevant books read and knowledge learned in the process of preparing for the pmp exam.

In addition to "PMBOK", the main books involved are "IT Project Management Case Analysis" and "Easy to Know and Hard to Do: Analysis of 58 IT Project Management Cases ". If you have time, you can look at Liu Ling's "Easy to Know and Hard to Do: Analysis of 58 IT Project Management Cases". Each case in the book consists of three parts: "case story", "case analysis" and "summary". There are various types of cases, from a single project to multiple projects, from Party B's project to Party A's project, and from individuals to organizations, revealing the reasons for the success or failure of the project from all aspects and perspectives.

The relevant roles mentioned in the following cases are uniformly referred to as "project managers", but these may also be problems that product managers will encounter.

These include: what kind of work logic should be followed, how to take over the new/half projects, what to do if you don't understand the technology, how to clarify the requirements, what to do if the progress is behind schedule, what to do if the customer's requirements change frequently, what to do if the customer requires a compressed schedule.

I. What work logic should be followed

The project manager is responsible for solving all problems in the project. But the same problem for different project managers to deal with is likely to appear with very different results. There are many factors that cause this phenomenon, including the project manager's project management experience, communication and coordination ability, resource allocation ability, and the work logic followed. For new product managers, experience and ability need time and project precipitation to obtain, and can be more quickly learned in the correct work logic (top-level work logic).

Work logic is divided into bottom work logic and top-level work logic.

What is the bottom work logic?

It is a series of management plans and monitoring and control during the project implementation and delivery process that the project manager when facing various problems related to project management, will mainly from the perspective of the project, in order to meet the key indicators such as full payment collection, high-quality delivery and customer satisfaction.

What is the top-level work logic?

When facing various problems related to project management, the project manager will identify the core objectives of the project (profit/customer information/experience/talent/pilot/other strategic objectives) from the perspective of the company's strategy, deeply understand the core value of the project to the company, and then find appropriate solutions from the corresponding perspective, instead of just making decisions to meet key indicators such as full payment collection, high-quality delivery and customer satisfaction.

Next, I will use my own experience to show how people who follow different work logics would handle the problems in their work.

1. Case Background

The author's company, a company specializing in providing IT services for the government, signed a contract with the government in August 2022 for a project to build a municipal system, which was expected to go online in November 2022. In mid to late September, the customer suddenly proposed to change the requirements, because the provincial system had been built first, and in order to prevent duplication, the city government requested to stop all development work and let the company send someone to conduct research on the new requirements, instead of the modules specified in the original contract. However, at this time, the company's development progress for the original project was close to 70%, and if the client's intention was followed, the project would bring a huge loss.

The company was caught off guard by the sudden change. In order to make the project not lose money, the company's marketing staff repeatedly negotiated with the client, hoping that it could continue the development, and the duplicate system could be used for data flow back to facilitate local management of data, but the client was not satisfied with this proposal. However, the government funding for this project had already been applied for, and the process was complicated and tedious if the budget was to be further reduced, so the client wanted the company to re-enter other government departments to conduct research and design some new systems instead of the original proposed functional system. In order to meet the full payment of the project, it seems to be the only way to do so, but this will cost more human resources and time, and the overall view is still a loss. The two sides were at a standstill and the project was headed for a bad end. 

2. Solution

After reporting the matter to the leader, the leader took me along to visit the decision-maker of the client's project. After two hours of conversation, the client was satisfied and sent us out, and expressed his wish to learn more about the company's projects and to cooperate more in the future.

What happened in those two hours that caused such a big change in the client's attitude, and what made the project that would have been likely to fail become the basis for the company to get more business opportunities in the future?

In these two hours, the leaders spent about half of the time chatting with the client, not just chattering, of course, but more to understand what internal business needs the client had that was not handled efficiently enough and needed to be brought online through the system. While understanding their pain points, we then introduced our company's product lines that could solve these problems.

At that time, the company's R&D department was developing a new set of artificial intelligence technology, and the research and development were in the final stage, but since there was no customer at the moment, there might be some undetected loopholes in the technology, and it was urgent to conduct a pilot to optimize the product, and this new technology could solve part of the customer's regulatory needs. The leader said he could provide this pilot service for the customer free of charge, and could additionally help the customer to add new functional modules to solve new needs, and these new contents need not be changed in the contract, they are all done for the customer free of charge. But the construction content of the original contract also hopes to continue to go on according to the process, and the final acceptance also according to the original plan.

The client was very impressed to hear this, but also asked, "Isn't this a loss for you?" The leader smiled and said it was all as it should be. The client was very satisfied, and at the same time took the initiative to ask me to organize a document detailing the company's existing projects and send it to them, saying that they had many other business needs they wanted to communicate with us.

3. Results

The project then proceeded in an orderly manner based on the results of this conversation. In the end, the project was successfully accepted, the company's new product received pilot feedback, and the company received high praise from the client.

If we look at the project cost and the return, the project is a loss. But was it really a loss?

After understanding the top-level work logic, it is easy to see that the leaders of this conversation mainly from the perspective of the company's strategy, the core objectives of the project as customer service and pilot, maximum customer satisfaction, and less focus on profit. On the premise of understanding the customer's needs, the company's corresponding pilot product was recommended. This move was undoubtedly a success.

Also because of this incident, I understand more deeply that the success of a project can be judged not only from the perspective of profit but mainly by what is the guiding core of the work. For example

Project A: Final project profit of 20%, low customer satisfaction, no improvement in project experience.

Project B: final project loss of 20%, high customer satisfaction, the project did a new pilot innovation.

Project A is clearly more successful if profitability is the core guiding work; however, Project B is clearly more successful if viewed through the lens of project sustainability.

Although the top-level strategy for the company's projects is mainly decided by the top management, project managers and product managers should also understand the core objectives of different projects when working, and use the top-level work logic to see the problems and solve them.

II. How to take over (new / halfway) projects

After a new person joins the company, he/she must start to take over a project after understanding the company's business. Then there are only two results, either they are independently responsible for a brand new business of 0-1, or they take over a project halfway. Both are essentially the same, that is, both have to face a brand new business and a brand new team, which is a test of project/product capability.

Then the newcomer to the workplace is likely to face headaches in contact with the new business, and in the face of different problems, the author gives some suggestions.

Problem 1: The project process is complex and involves many people, it is difficult to figure out the logical details of the project in a short time

Solution:

1) Top-down thinking about the problem

Contact with a new project at the beginning of the project is easy to get caught up in the details, then you need to promptly pull away, to do top-down thinking problems. At the same time, looking for various department managers + business key person interviews is a good way to understand the project from a macro perspective, to identify problems, so as to develop a plan to solve the problem.

2) Recognize that "there are specialties in the field"

Some project managers, in this aspect of technology, will be tangled for half a day, some people cannot tolerate their ignorance of the technical understanding of the project, spend a lot of time to tackle, the results of the technology has not learned, the project out of control. Therefore, we need to know that understanding technology is a plus for products and projects rather than a must and can spend time learning in their spare time, but in the project management process to play the role of the project manager rather than the developer's job responsibilities.

Problem 2: A project taken over halfway is likely to have many hidden problems left by the previous project experience, how to identify and solve them?

Solution ：

1) Get a comprehensive understanding of the project, and write a detailed report to the relevant leaders on the current status of the project, the problems that exist, and the risks that may arise.

2) Follow up the project process and pay extra attention to the leadership and the customer's timely communication, on the one hand, this is the project management needs; on the other hand, it is also to let the leadership know the status of the project, and later can reduce some of your own pressure.

3) Communication should have a closed loop. Many projects on the management of program bugs are relatively scattered, and in terms of communication is very easy to produce serious loopholes. A problem from the proposed record to analyze to solve generally will involve at least 3 people and links, so the problem registration must be standardized to do. To avoid shifting the blame, ring communication is the most appropriate, as shown in Figure 1. And many projects using chain communication as shown in Figure 2 is not appropriate.

                                                                                                                                                                                                     Figure 1 ring communication

                                                                                                                                                                                                    Figure 2 chain communication

III. What should we do if we don't understand technology

In the project implementation process, there are often some technical and business issues that the project manager does not know much about, and do not understand the situation, which is quite normal. The key to establishing credibility at this time is that the project manager should know how to respect the professional, fully exploit the talents and potential of the staff, and be able to arrange trusted technical personnel to be their right-hand man, with the assistance of technical experts to choose the best solution, which can win the approval of subordinates.

The project manager cannot be limited to his own day-to-day, buried in hard work, but must spend time and energy through regular project meetings, technical seminars, project reviews and other forms of face-to-face communication, as well as various types of project technical documents, management documents and other ways to communicate with everyone. If it is impossible to hold regular meetings every week, we should focus on technical documents, and strive to make developers understand the requirements comprehensively and thoroughly through the documents. But from time to time feedback and meetings are still necessary.

IV. How to clarify the demand

The author's last company mainly does e-government projects, in different cities, or even the same city in different districts of the government for the same type of business process requirements are different, so the project is generally a custom-developed system. The custom-developed application system, due to the specificity of its needs and high personalization requirements, will be affected by the user's ideas, concepts, expectations and preferences, as well as the constraints of the leadership style. It has a considerable part of emotional content, which is difficult to describe quantitatively, increasing the difficulty of obtaining and accurately understanding the requirements.

Therefore, the following points can be noted in the requirements research process.

1) Figure out who the key decision makers are, what their characteristics are, and what exactly they want.

As mentioned earlier, e-government projects are highly personalized and demanding and can be influenced by users' thoughts, perceptions, expectations and preferences, as well as the constraints of leadership style. It is likely that a single word from the leader will affect the direction of the entire project, so it is necessary to find out who the key decision makers are, what their characteristics are, and what they really want before the requirements research.

2) Develop a communication plan

In order to facilitate efficient work in the future, some system-based training can be carried out before the formal start of the demand survey, so that the customers participating in the survey have a general impression of the system and can't talk about it in a casual manner; Demand management should also be guided by knowledge to let everyone know that the demand is not to say what they think, but to communicate based on the framework of contract scope, which cannot go beyond a certain range; Or organize the questions that need to be asked during the survey into a questionnaire and distribute it in advance; Or guide them step by step on the spot according to the questionnaire. The demand survey should not go to the main person in charge at the beginning but should be carried out step by step within the scope of the contract or technical agreement, from bottom to top, from rough to fine.

3) Document constraints

Special attention should be paid to the requirements that have not been determined in the early stage of the project, or have some factors that are likely to change in the future, and should be clearly described in the "assumptions and prerequisites" clause of the user requirements instruction (or requirements specification); For the external environment that restricts the implementation of the system, including funds, talents, resources, conditions, policies and other constraints, the necessary investigation and analysis should also be Carried out; for the external interface of the system, database, parallel operation, communication protocols and other aspects can be given specific technical restrictions. These contents are important judgment bases for later technical design and system testing and acceptance.

4) Understanding the implicit requirement information of the project

This includes understanding the customer's organizational structure and mechanism, understanding the customer's current problems and the possibility of improvement, collecting information before researching the requirements, doing your homework, not blindly betting on someone on the other side, and ensuring that the customer, the end user and the developer reach a consensus.

5) Understand clearly the performance indicators of the system

The application system construction requirements analysis, not only focuses on the user's functional requirements but also pays attention to business functions outside the requirements of other aspects such as performance, security, interfaces, etc... These aspects are often not mentioned by users when introducing business requirements, and people are generally not aware of them, so we can say they are potential. Only when the system is in interconnection and operation, their impact will be exposed, and they are likely to be the key factors triggering system failure or even crash.

6 ） Demonstration first and then development

In the case that the requirements are not clear in the early stage of the project, it is recommended that the developer should not rush to develop the formal system first, but adopt the method of rapidly building a prototype system to express the abstract user requirements, operation interface and future operation of the real system with the prototype system and virtual data simulation, as an effective medium of communication with the users.

The abstract concept is turned into a visible and tangible object so that the end user can see the system "like" intuitively. This can effectively increase users' perceptual understanding of the future product and trigger them to ask for deeper functionality and performance requirements. Since it is easier and faster to modify and adjust the prototype system, the resources invested in several iterations are relatively small. After both parties reach a consensus on the requirements and then develop the formal system as a blueprint, it can effectively reduce project risks and input costs, avoid rework, and accelerate the overall implementation progress of the project.

V. How to do when the progress is behind

The project management process will inevitably encounter the work progress and the initial plan inconsistent situation, whether the work is completed ahead of schedule or behind schedule, the beginning of the progress plan cannot be unconnected (work completed ahead of schedule does not mean that there is no problem with the project, which instead indicates that the project schedule at the beginning is not scientific, the arrangement of the work plan is not saturated, a waste of manpower). And compared to the work completed ahead of schedule, we will have more sense of panic for the progress of the backward. What should the project manager do if the project progress has fallen behind?

1) Adjust your mentality and stabilize the team's mood

The project manager is the core of the project team and is the soul of the person. Once the adjustment schedule is irrevocable and must be implemented, the project manager himself cannot be shaken, at least not in front of the team members to show fear, the worst is to complain about the customer and the company with the group members. While adjusting their own mindset, they should also lead the team to unite and work toward the goal. When the progress is seriously behind the project team members are likely to face over time, then the following can be done for them.

• Emphasize the great significance of project completion for the company, and stimulate the group members' sense of responsibility and honor.

• Encourage everyone to go beyond themselves, such as the normal completion of the project, company-wide publicity and recognition, etc.

• When adjusting the plan, pay special attention to the role of the backbone, so that they feel reused and trusted.

• Carry out some game-like competitions and group gatherings to build harmonious and warm interpersonal relationships in the team.

• At the technical level, there are many ways to optimize the schedule, such as identifying the dependencies between activities, analyzing the critical path, optimizing the combination of resources, etc.

In short, project managers have a lot to do, firstly, they have to adjust their mindset, and secondly, they have to make some efforts and encourage their team members to put in efforts together for the project.

2) Cannot blindly increase the number of people

The first consideration of the progress lag should be the preparation of the plan, the division of labor, and whether several parts of the regular project meeting have been completed and adjusted accordingly. If you blindly increase the number of people, there will also be a cost for new people to learn the business and get started. And if there are problems in the planning division and follow-up of the whole project at this time, then there will only be more problems later, making the progress more backward.

VI. What should we do when the customer needs to change frequently

1) Develop written specifications for requirements change

First, a written registration must be provided for all project issues and needs. You can use the company's problem registration system or the excel table, whichever is better (considering that some project sites are not convenient to access the Internet). Either way, each question must be numbered and unique. During the registration process, several key fields should be clearly written, such as "problem number", "problem proposer", "on-site analyst and suggestion", "development comments and reply", etc.

2) Customers need to participate in the first round of demand analysis

No matter what problem, the project manager must organize customers to participate in the first round of analysis, and organize regular problem induction and review within customers; Invite the customer's business manager and the customer who raised the question to conduct an internal review first. This review doesn't matter. If they find many problems, they will "shoot" themselves, and will also let many customers who raised questions casually take a warning. We must guide our customers to think carefully and ask insightful and high-level questions.

3) Internal review

Review issues and preliminary comments. Both the project manager and the development manager must be present to review the problems summarized in the problem summary table one by one, regardless of size, and clarify the categories and priorities of the problems, then form the minutes of the meeting, sign for confirmation, and incorporate them into the development plan. The conclusion of the meeting cannot be changed easily, and the seriousness of the review conclusion must be guaranteed.

4) Prioritization

Many unimportant issues are listed in the product version release plan, and there are many good and common requirements that are included in the standard product R&D plan. After the development, the customer is also satisfied; For those that are technically difficult or have to be postponed, put them back. We understand each other and can't grasp everything at once.

These steps can enable both sides to fully communicate their differences at the meeting, which can greatly reduce the phenomenon of passing the buck and procrastination. During the process, the project director should participate in the whole process to ensure the seriousness of the meeting.

VII. What should we do if the customer wants to compress the schedule

1) Communicate with the customer and tell the worst result

If the customer suddenly proposes to compress the schedule, for example, the 5-month project cycle should be 1 month ahead of schedule, which is 20% ahead of schedule. If the original schedule is reasonable, the schedule pressure will be too high. If the company can't increase its staff, then the project manager should take the initiative to find the customer to analyze the possible consequences, just like the patient's family members should sign to explain that they understand the possible consequences of the operation, and then the patient's family members should decide whether to operate.

In reality, it is difficult for IT project managers to ask customers to sign a similar "informed consent", so it depends on the communication and expression ability of the project manager. I restored the conversation scenario of this problem in my work.

After informing the customer that the company has insufficient resources and cannot compress the progress well：

Customer: "The lack of resources is not my problem. You should ask your leader for feedback. My requirement is to complete it one month in advance, and I don't care if there are not enough people, you figure it out yourself."

Project Manager: "Well, I can understand your position very well. Our company's resources are arranged according to the plan in advance according to the business line. We also consider how to deal with emergencies in advance. If the time compression is not too strong, I believe we can handle it well according to the original risk control plan. But because the cycle has been compressed by 10%, it is more unexpected and difficult than usual. Of course, we also will try our best to use resources to achieve the original goal, but from the perspective of our project's responsibility, we want to inform you in advance of the worst possible outcome. You can evaluate it, and you can also prepare some countermeasures in advance so that we can work together, and the project will certainly develop in a better direction. "

This paragraph contains several points, which are progressive:

• Affirm some points of the other party

• Show the importance of the project, and euphemistically indicate that the other party's requirements are unreasonable

• Inform of risks

• Express the need for the coordination and help of the other party, everyone is a team

• Finally, a certain positive commitment, of course, should not be too specific, so as not to achieve the broken promise

In this way, customers usually follow the ideas of the project manager.

However, if the company's leaders support the customer's request to compress the schedule, but the resources are insufficient. Or if the leaders did not express their opinions, the problem should also be solved. It is necessary to compress the schedule. Even if the reduction is not achieved, we should actively seek solutions.

2) Adjust mentality

When there is a sudden change in the project duration requirements, the pressure on the project manager will become greater. At this time, the project manager should first adjust his mind and not affect the team members.

3) Attempt to modify project scope

The core elements of project management - scope, time, cost and quality - are mutually affected and constrained. If the schedule is advanced, can the scope of the project be adjusted with the same cost and quality? Some non-core projects will be implemented in Phase II.

4) Technical adjustment

At the technical level, there are many ways to optimize the schedule, such as identifying the dependency between activities, analyzing the critical path, and optimizing the resource combination.

The above are the scenarios and solutions of the 7 common project management issues for new product managers. Due to the limitations of the author's cognition, it may not be the optimal solution. We welcome your criticism and correction.

What's more：
What Is The Difference Between Agile and Waterfall
Project Management - A Tree Swing Story