How to resolve issues of project management?

To deliver products on time and produce smoothly, projects must be monitored and managed. and this work usually falls on the product manager, no matter which methodology, the management of the project can not bypass people and things two key points. based on their own work experience, the author of this article on how to carry out project management to express their views, share with you.

"The project management" this old thing, has always been a product landing big problem. if you want to do good things, you must first benefit from the product delivery, smooth output, you must monitor and manage the project.
 

The project management is a professional discipline, the study of its methodology has its own changes, but ultimately around two key points: people and things.

Products by project is also divided into different types of nature, one is project-type products, one is self-guided products, the so-called project-type refers to a specific enterprise or government through the open way to project bidding or claim, from the drafting of the project target letter to the completion of the project. 

 

To the main needs of the tenderer and the established program as the core of a series of project activities, the final output is for the project-oriented products, such products targeted, low versatility, and cycle time will be clearly defined. 

 

The self-guided type is initiated by the company, in order to meet the company's business development or improve efficiency or reduce costs or support profits of standard products, the product base function applicability is high, in the face of object rich not limited, there is a lot of room for expansion or reserved transformation space.

no matter what kind of project, the project team is also required to be equipped with the corresponding resources, including manpower, equipment, time, space, capital and other basic elements.

common project processes include the development of charters - limited scope - plan control - cost management - quality approval - risk plan - closing.

small, lightweight internet companies prefer agile development, small steps, low-cost trials and errors, while companies that don't slip in the middle have to use the shape of their projects as a measure of output because of their size or product construction patterns.

Goose, non-traditional project-type enterprises, in the process of information transformation, not all production lines have the project manager this important and business-savvy full-time staff. this type of work is often done by a product manager.

So why, we can often hear that product managers also need to understand project management. In fact, in addition to the lack of dedicated staff, part of the understanding of project management can not easily be trapped in the surface of the project, only to understand that its processes ultimately can not guarantee that the quality of the project to achieve the desired goals. So the depth of the business also has certain requirements. in addition, even with the role of project manager, it is difficult for him to assist the product focus in advancing the progress and management of the product line when he has multiple projects in parallel. therefore, the product manager and the project manager are like two brothers who work together, cooperate with each other.
 

 

However, the problem is difficult, if there is no project manager and there are product personnel to serve, most products do not have the right and responsibility to ask project members about the arrangement and process, relying on character or personal charm alone will only consume personal emotions and work surplus. here are a few suggestions:

1. When organizing a business meeting, invite relevant stakeholders to join, especially the technical team boss and the product team boss, as well as the boss of both sides, to give them a clear mandate, including the deployment of resources, management team, progress reporting collection rights. if the boss has no time to attend this meeting, he or she will need to make a written statement or email to know who is in charge of or in charge of such work. don't seem simple, in fact, in many processes are not standardized in the company, authority is not clearly defined, resulting in different degrees of the relevant personnel to dump the pot and delay the sense of responsibility to continue to fish, in addition, group chat record oral statements are not reliable.
2. Project reporting control, once a week or twice a week is appropriate, the record of the content of the current stage of the person's week by schedule grid recorded development progress, as well as status is normal, extension, completion rate percentage. if there are notes to declare the specific situation of the person, such as leave, temporary tasks, other matters, etc., the remedy is to rest overtime, delay or finish in advance without adjustment instructions, to ensure that the development plan is kept up with. progress is copied once a week to project team members, using vw's oversight to exert appropriate pressure and responsibility, rather than the product manager being alone on a technical team.
3. Clear system, reward and punishment points clearly, once the plan is confirmed, the implementer in the implementation process in addition to special circumstances, otherwise can not be arbitrarily modified, there is a clear reward system, there is a certain reward system, but the reward needs the company level to make decisions, so not necessarily, so the department to see if other ways to reward project members. bonus incentives to a certain extent will promote the enthusiasm of members, reward and punishment can regulate the constraints of project members, otherwise, can not be completed on time for members have nothing to itch, anxious 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, is their own dedication and self-pursuit of identity. so in the course of the project, to ensure that the project members can get what they want from it, experience is good, money is good, praise or selection encouragement is good, can promote the enthusiasm of members. it is very bad that if the product manager is alone, then the project is really difficult to promote, the relevant rights and responsibilities to different people responsible, is the best allocation of resources.
5. Project plan allocation, different project planning templates have different, fine to what extent due to different companies decide, but work tasks must be disassembled, wbs (work decomposition structure) is the most commonly used way, large and small, small into nothing. dividing the overall project into different work packages, deconstructed from long-term to short-term, is quite appropriate to the product manager's daily thinking model, the whole - disassembly - analysis - execution - complete, wbs can intuitively and quickly show the task points and objectives of each stage, to assist in clear planning, but also to quickly find problems.
   
6. Risk control, risk generally includes qualitative risk and quantitative risk, this part is more knowledge-based, limited experience of personnel often can not do a comprehensive prejudgment of risk, advanced products are also because of the project's continuous summary, avoid encountered potholes. therefore, it is an important way to identify the initial risk control in the dimension of summary or learning from the experience of previous projects at the end of the project. second, you can brainstorm, organize potential problems that project members will encounter in the responsible module, and possible events such as process changes, personnel departures, requirements changes, and so on, to list forms and set aside time for resolution. quantitative means that the risk is uncertain but quantifiable, and the book is defined as a numerical analysis of the probability of each risk occurring and the impact of its project objectives, as well as the scope of the overall risk of the project. such analyses are targeted at different measures to avoid by the size of the probability of occurrence.
7. Demand changes, as demand sponsors, and as project monitors, such things are simply a dilemma, on the one hand, the project needs to be completed on schedule, while the need to change to increase the amount of development. of course, demand is not what you want to change, want to change can change, often because of the company-level rigid requirements, the need to lead the urgent issue of the need for acceptance and initial needs, affecting core interests or market policy changes, such as product trademark changes, the introduction of personal information privacy protection law and other uncertainties, resulting in the project process needs to make timely adjustments, transfer direction. the risks and impacts of changes at different stages of the project are different.

The changes also involve different scopes, with changes that do not involve process changes as an example:

The impact: 

< project before the project is undeveloped< the project has been developed< the development has been completed< the test < acceptance, the longer the time, the greater the risk cost.

• After the project is started, it begins to enter the beginning of development, at which point the risk of proposing changes is less and the project plan can be adjusted accordingly.
• Entering the development phase, the demand point is repeatedly confirmed between the technology and the product, and when the corresponding module is reached, the front and rear technology is confirmed (no sides should be left out), adjustments are made, changes are added to the development plan, and the plan is rescheduled.
• Development or testing stage, this time proposed changes, technology must have their own small temper, has been completed, the rest is to change bugs and other acceptance, bald hair can finally slow down; so move out of the leadership things can not be too frequent, after all, this may also be the last under card, over time, the leadership of the heart of the product people are not satisfied with the self-suggestion, and, the implication is solidified and not easy to eliminate.

So what do we do? 

in this regard dare not say that there must be results, after all, project management also has a history of more than a hundred years, experts have not pondered it, can only say through their own experience to share.

 

Maslow's principle of demand is more and more well known, but the final return is too general, please eat a meal seems not to make up for the need for personal emotions, and i can not do, after all, born cold king. So it is also to find a moderate way to promote. 

Such as (objectively) let the project related person understand the reasons and importance of the change in demand, clarify the content of the demand and find the least change of the executable solution, calculate the potential value or change can bring benefits, the meeting is also necessary, private notification is not supportive. 

(subjective) Let them know that the product is from their point of view to think about the problem, together spitting groove changes the source of but helpless attitude.

 

Demand changes are really common, and the product manager himself needs to filter the demand, control the project, big changes are also likely to interrupt the project, so can not ignore this. Products in the middle of the marketing department and project management department is a dilemma. 

 

In addition to a demand microphone tool person, i think, more to play their own subjective initiative in it, no product proposed immediately can be done, good products worth waiting for, and the project process spent time and energy is our wait, but this waiting value is not worth, only the market can verify.