How to simplify management processes to secure process success

 

Broadly speaking, the process of a project management is divided into the following stages:The project initiation - project planning - project execution and monitoring - project closure. If you use a diagram to represent it, it will probably look like this:


in the whole process of project operation, from the initial strategic planning from the leader to start the project, to the early project plan, demand transformation and medium-term project execution and follow-up, as well as the late project closing summary meeting, each link has a product manager.

especially in startups, product managers also take on the role of project manager most of the time. therefore, for startup products, it is even more important to understand the general process of project management and allocate resources reasonably.

let's sort out one by one, if the product manager is responsible for the management of a project, what work to do at each stage.

the project initiation phase

any project that can be started, at least from the strategic level, is recognized and supported by the company, which means that the project is saddled with the realization of a certain strategic goal of the company. before the product manager starts the project, there are several issues that need to be understood and familiarized in advance:

• why set up a project?
• what are the project objectives?
• who are the people involved in the project?
• how to set up a project?
• the first question is, why set up a project?

At this time, as a product manager, you need to understand the ins and outs of this project, the best way is to communicate with your superiors or bosses, because they have far more information than you and more than you, so by communicating with them and understanding themselves, you can have a clear understanding of the reasons for the project."

of course, sometimes the project establishment may be a regular iteration of the product version, and the product manager is probably more aware than anyone else about why the project should be established.

the second question is, what are the project objectives?

the product manager, as the person in charge of the project, must understand what the goals of the whole project are, and then find out the core goals in it. for example, some projects are time (the faster the better, it doesn't matter how much money is spent), and some projects are money (it doesn't matter if you do it slowly, but you have to spend the least amount of money). you can talk to your leader about this information, and after knowing the project goal, you need to write down the goal in accurate text.

yes, it must be written down, because there is no basis for verbal talk, and then another thing that is written down can become the direction and guideline for everyone to implement.

the third question is, who are the people involved in the project?

The project related personnel can consider from these perspectives, such as which people or departments will be affected by the project results, and who can provide resources (people, money, materials) for the project. of course, in internet companies, common relevant personnel are bosses, product managers, project managers, project teams (including design, development, testing, operation and maintenance, etc.) and users.

Once you've found the people involved in the project, all you have to do now is tie the team members to your own boat. You need to understand the core KPIs of each member of the team, which is what their needs are for the project and what they can bring to the project. If the project is not included in the member's job evaluation list, you need to communicate with his boss.


in my experience, 85% of the time you don't contribute is because your project doesn't do anything positive to the member's kpis at all. of course, if communication with his boss is ineffective, there is a last resort: emotional investment, ask the member to string, eat, and use his feelings to let him help you do this project well.

the fourth question is, how to set up a project?

usually, this is the time to hold a project kick-off conference. the purpose of this kick-off meeting is to bring together the project team members, get to know each other first, the product manager leads the meeting, and then clearly communicate what the project is going to do, what the goals are, why it should be done, how to do it, who will do it, and so on.

in addition, like all kick-off meetings, the kick-off meeting of the project also needs to give the team members some chicken soup and chicken blood. product managers need to unify the team's thinking, clarify the management and operation mode of the team, and the communication mechanism of the team, etc. product managers need to mobilize team members to actively participate in the project and complete the project with high quality.

at this time, the project-related documentation should actually have been completed, because only when the detailed product requirements document is available, the development team can estimate the project time and milestones. there is also another case, that is, the project itself includes a requirements analysis phase, so the detailed requirements documentation is not started until after the project is established.

in any case, clear product requirements and detailed requirements documents are the basic prerequisites for the smooth progress of the project, so the planning ability of the product manager and the ability to write documents are particularly important at this time.

project planning phase

after completing the start of the project, the next step is to start the project planning, the so-called project plan, its main work is the decomposition of work tasks, task prioritization, resources, duration, cost estimation, as well as risk planning and communication planning.

work task decomposition

work task decomposition, also known as "work breakdown structure" (wbs) in project management, refers to the grouping of project elements oriented towards deliverables. it actually summarizes and defines the entire scope of work of the project, starting from the project goal, decomposing, descending layer by layer, and each layer of descent represents a more detailed definition of the project work.


product managers in each version of the iterative planning, need to fish out some of the more important requirements from the product demand pool to put into the project requirements, which is in line with the idea of agile development, the meal is to eat one bite at a time, the project is the same, it is impossible to get all the requirements at once. therefore, we need to complete through a version of a version, when doing the work task decomposition of the version, we must decompose the task until it can no longer be divided, the granularity of the task must be fine, if it is too coarse, it is likely that some tasks will be ignored, thus affecting the progress and planning of the entire project.

the general work task decomposition methods are: decomposition according to the physical structure of the product, decomposition according to the functional modules of the product, decomposition according to the implementation process, or according to the geographical distribution of the project. it is more commonly used to decompose according to functional modules, and then decompose them in combination with the implementation process of the product.

take the development of wechat public account as an example:

the development of wechat public account involves the development of wechat terminal and the development of pc management background, at this time, if the task is decomposed, the most basic direction should be divided into wechat end task development and pc management end task development.


it should be noted here that in the process of decomposing tasks, the tasks need to be described clearly; otherwise, the team members will not be clear about what they want to do, or what kind of goals they want to achieve.

The decomposition of the work tasks of the project can also be checked using the MECE principle we mentioned earlier: the work tasks must be comprehensive, clear and subdivided, the task responsibilities need to be people, and each sub-task can estimate the workload and duration.

task prioritization

tasks are assigned, but there is always a priority. the prioritization in the project requires the product manager to identify the interrelationships and dependencies of various tasks in the project task list, and arrange and determine the order of the tasks in the project according to his own judgment of the priority of the requirements.

in layman's terms, what a product manager defines is which tasks to do first and which tasks to do later. in fact, at this time, we often use the tool kano model we use in demand management, which sorts out the priority of the task by clarifying the importance and urgency of the task, and the priority is to deal with important and urgent tasks.


when dealing with the prioritization of tasks, there is another very important point to understand, that is, there is a front-and-back relationship between some tasks and tasks, and only when one task is completed can we start the next task. so when planning priorities, you need to take this situation into account.

plan presentation – gantt chart or other

Many project management books recommend the use of Gantt charts for the production and presentation of project schedules, generally through microsoft projects and other professional software for drawing, you can also directly view the critical path of the project through these professional software. There are also some product managers or project managers who directly use Excel to make project schedules, after all, their proficiency in the operation of tables is enough to control the schedule production of a project.

i'm a user experience person, so i don't really use the above two tools very much; in general, i prefer to present project plans through the project management function in team collaboration software.

for example, the following:

• tower's project management interface
• risk control

in layman's terms: risk is the probability of an unfortunate event. any project has risks, just as any operation has risks, risk is actually ubiquitous, is a kind of thing that does not depend on the will of man, but exists independently of people's consciousness.

let's first take a look at some of the common sources of risk:

a. the customer is not involved in the project

if one of your company's projects happens to be a customized product for the customer, but in the project initiation, planning and execution stage, there is no customer participation, the customer just gives a document at the beginning, and then accepts it at the end of the project, without the slightest participation in the project. then once the customer finds that the final result is far from the needs he originally envisioned, the result will become very bad. therefore, the customer may not agree to the acceptance of the project and ask the project team to rework the development, and the loss of workload and time caused by this time, and the impact on related events are immeasurable.

b. the requirements are unclear or incomplete

product manager's requirements document is not clear or incomplete, the probability of project risk will be relatively large, because the development members of the project are around the requirements of the design document for development, testing, if the product manager can be on call, and the development of timely discussion of the requirements, it can also recover a certain loss; and if it is off-site development, the entire project will be more sad.

c. unreasonable project plan

if the project is not completed as scheduled, it is likely that the project plan itself is problematic. for example, the division of labor among team members is unreasonable, the schedule is unreasonable (generally 3 months to complete the task, you have to be required to go online within 1 month), the resources are not configured in place, the decomposition of the work task is not refined and there is no responsibility to the person (which will lead to the team members of the project team not being very clear about their tasks, even if they are decomposed, no one is specified, it will also be found to affect the progress of the project), and there is also an unreasonable prioritization of the task, resulting in the completion of the later tasks being affected.

d. the mental state of the team members

Whether a project can be completed on time and in quality, the most important factor is still the human factor, so the mental state of the team members is also one of the risks affecting the success or failure of the project. If the project members are like the team members mentioned in Scrum Agile Development, they are all self-organized and managed, and the enthusiasm for participating in the project is relatively high, and the project risk will be greatly reduced. If the project members have a problem with their work attitude, often shirk their responsibilities and complain to each other, then the results of the project are very worrying.

e. leadership change

the leadership change here mainly refers to the project development to the middle of the road, the leader suddenly said that this demand is not right, should be developed in another demand direction, then we call it a leadership change. the changes here are roughly divided into two cases:

one is not too nerve-wracking, that is, it is only a small demand modification, which does not involve the reconstruction of the underlying architecture; the other is that the planning and positioning of the product is not clear enough, resulting in modifications that are more nerve-wracking. a change in the direction of demand may allow development to rebuild the background architecture, and many pages in the front end must also be modified.

of course, sometimes product managers often make such a mistake, that is, change requirements in the middle, which requires product managers to think clearly about the requirements when planning the project, and minimize the sudden change of requirements in the project development to half.

f. technical risks

the technical risks mentioned here refer to the members of the development team of the project, who will implement the project with code and a series of unexpected situations will occur. for example, to develop a function that has never been done before, it may be necessary to conduct technical research at this time, and the final result may be that the investigation event alone takes a week or two, and there is almost no time left for development. for example, the website is hung, and once it is processed, it will go in one day, and the original project in hand will have to be delayed for a day.

here are some common technical risks, product managers in the process of project management, or a little understanding of the next is better:

having said all the sources of risk, is there any better way to avoid these risks?

the answer is yes, but it is still difficult to avoid all the risks.

do you feel the same way: projects deviating from schedules are rarely due to work that takes longer than expected? the more common reason is: work that is not planned at all makes the project muddy? if you, who are also project managers, feel the same way; then we can realize that the risks in the project can be interconnected, yesterday's problems are today's risks, and your problems are likely to be my risks.

therefore, one of the better ways we can do this is to refer to and troubleshoot the above risk sources one by one at the beginning of the project to see if there is any problem. of course, the more hidden risks may not be discovered by this one-by-one method; the more critical point is the insight into the state of the daily project, so that all the core risks can be presented.

risk management is a very laborious thing, if the product manager does the project management work part-time, he must be prepared for the relevant psychological preparation, after all, the inner strength is also a personality trait that the product manager must have.

after completing the project planning phase, the task decomposition, prioritization, plan presentation and risk control of the project plan are carried out, and it is time for the project execution and monitoring phase. this stage is mainly for the implementation of the project to communicate, the implementation progress of the entire project to monitor, so that it in the time, quality, cost to achieve a certain balance.

project execution and monitoring

mainly, this stage will contain the following things:

process tracking: mainly the tracking and monitoring of the project execution process, to prevent team members from deviating from the understanding of the plan, resulting in some problems in the implementation stage, and the tracked things include team members, tasks, expenditures, etc.;

routine project meetings: the so-called routine meetings are actually to develop a fixed communication channel for a project, so that team members can communicate more efficiently;

review of phased deliverables: for a long-term project plan, it must be dismantled into several implementation stages, then it is necessary to review the phased deliverables, which is also a very important means of monitoring;

milestone report: the project has reached a milestone, then you can come to a milestone report;

change management: in order to adapt to the changes in various factors related to the project in the process of project operation and ensure the realization of project objectives, some adjustments to the project plan are called change management;

the first thing is process tracking

in order to grasp the progress of the project and grasp the status of each work, the product manager has to carry out a monitoring and tracking of the project process. only then, when problems arise, can we make appropriate resource adjustments and scheduling adjustments, re-plan the start and end times of a task, and record the actual progress.

then, in the actual work process, how to track the project by the product manager can be considered from the following three aspects:

1. steward - the task of monitoring the project

many product managers have a habit that the first thing they do when they come to the company every day is to run to the project development team to walk around and gather everyone to a place for the project standing meeting, the regular meeting does not take long, but it plays a great role in monitoring the progress of the project task. on the one hand, it can avoid some colleagues immersed in their own world in the process of the project, and the direction is deviated from their own discovery. on the other hand, it can help everyone overcome the laziness of human nature and form a moderate pressure on everyone in the daily report on the progress of work.

the daily stand-up will be held at the same time and in the same place, the meeting will start on time, preferably no more than 15 minutes, every member of the development team must speak, there will be no discussion in the meeting, and the following information should be provided:

• what was done yesterday
• what's going to happen today
• what difficulties were encountered

many teams will also combine kanban to sort out tasks when holding daily station meetings, as shown in the following figure:

daily stops will be kanban

through such a simple meeting format, all members of the project team can be kept informed of the latest progress of each task. this allows you to monitor which tasks are lagging behind schedule and take appropriate action to correct them (usually overtime) so that the progress of the project is not affected.

of course, we not only need to know that the progress of the task is lagging behind, but also need to understand what the reasons for the backwardness are, so that different measures can be taken according to the specific situation to restore the project to the normal track.

for example, if the progress of a task lags behind the plan, and it is found that the task was missed when the task was decomposed or the task was not responsible for people, then after discovering this situation, the measures that can be taken are: let the development work overtime, increase manpower investment, extend the time, or replace the more efficient members to complete the task.

these are all remedies, and after we have remediated them, we can actually further think about whether there is anything lacking in our project management process, and whether we can improve the workflow, methods and tools, so as to reduce the probability of the above situation.

2. manage people - monitor the team members of the project

don't misunderstand that the role of the product manager is to be a spy, and to steal intelligence from the project team members. in fact, the so-called team members who monitor the project here are more to record the performance of each member of the project team, give appreciation and affirmation to the outstanding performance, and criticize the poor performance accordingly (of course, many times the product manager is not actually the leader of the development department, and it is better to pay attention to the wording).

another point is that the product manager should communicate more with the members of the project team, which is not only a communication at work, but also a chat about life, which can not only promote the relationship between you and the project members, but also know their living conditions in time, which is also conducive to project management.

3, manage money - monitor the cost of the project

general software project development does not involve project expenses, because basically all expenses are labor costs. however, there are special circumstances, especially the project management related to operational activities, which often involves the problem of project expenditure, and the monitoring here is actually mainly to record all the expenditure flows to see if there is any excess compared with the budget in the initial stage of the project plan.

at this time, you can communicate well with the relevant colleagues of the operation, find out the specific cost excess, analyze the reasons and find the corresponding solution.

the second thing is a routine project meeting

A master of management, has a famous saying called "management is to communicate, to communicate, to communicate again". in fact, let's think about whether in the practice of project management, we often encounter the following situations:

for example, the project boss runs to inquire about the progress of the project every three to five minutes, in fact, because no one reports the progress of the project to him, but the boss is more worried;

for example, after you send the first part of the demand through the email, no one returns the email to put forward their opinions and questions, and you also think that the demand will go smoothly, but that day i inadvertently talked to the team member about the need, and the member immediately raised his own objection, and barabala said a call. sometimes you don't ask, others will not take the initiative to tell you his ideas, this time may realize that in fact, you need to give the team a communication opportunity to talk about these things;

also, in project practice, the problem has already appeared, but after a period of time to notify all members of the project team, which leads to the asymmetry of information about the progress of the project, it is easy to lead to a delay in the construction period;

therefore, in the process of project management, communication is an important link that cannot be ignored. to put it bluntly, one of the most important tasks of a project leader is communication, and the time spent may account for 75% to 90% of the work. because only good communication can obtain enough information to identify potential problems and better control over all aspects of the project.

Earlier we mentioned that the project has relevant stakeholder members, but because the positions and responsibilities of each member are different, the project information that everyone pays attention to is different, and the frequency of their attention to the information is actually different, some are more frequent, and some may be asked two or three times in the whole project process. because everyone's habits are different, so their means of obtaining information is not the same, some people like wechat, qq, some people like email, and some people like to get information in the form of meetings.

In this case, it is necessary to establish a set of communication mechanisms belonging to this project and unify the methods and channels of communication. For example, the most urgent things can be communicated by telephone, and the tighter things can be communicated through WeChat or QQ, and the less important things are solved at the daily station meeting or the weekly meeting of the project. At the same time, the spirit of active communication should also be promoted in the team, which can not only establish a close relationship between the teams, but also show the importance that the member participants attach to the project.

the third thing is the review of the phased deliverables

in the process of project progress, there will be a lot of deliverables, and the product manager can review the following stages of deliverables in the process of managing the project to ensure that the overall project planning and execution will not have major deviations:

1. list of needs

the product requirements list is a sorted list of functional requirements, a continuously improved list that contains all the things that the product needs and is the only source of changes in product requirements. the product requirements list contains all modules, functions, features, requirements descriptions, business values, priority descriptions, etc.

the content, availability, priority, etc. of the requirements list are managed only by the product manager.

2. task list

a task list is a plan that is specific enough to contain a task breakdown of a requirements list. the development team will modify this list throughout the iteration process, for example, the development team has more understanding of the requirements and needs to add some new development tasks to the list.

modifications to the task list can only be done by the project manager (product manager), which is used to identify the tasks of project team members.

3. weekly project report

the project weekly report is a summary of the work content of the project team this week, as well as a report on the work plan for the next week, and the project weekly report needs timely feedback on the problems existing in the work of the week and the resources that need to be coordinated by the leadership.

in the weekly report of the project, we must not report good news and not worry, and reflect the real situation of the project.

the fourth thing, the milestone report

when the project progresses to a critical point, a milestone occurs, the milestone represents a major event in the project life cycle, is a high-level method of measuring the overall progress of the project, and can be used to report high-level progress to project stakeholders and project teams.

on the other hand, as the project progresses, it is also very useful for drum team members to achieve the milestone by letting the project team members know about their efforts to achieve the milestone.

for example, at the end of each iteration, the project team members gathered together to hold a summary meeting to review what was done well and what was not done well in the process of this iteration, and identify potential things that could be improved as a future improvement plan. iterative summary of the meeting minutes is the basis for such a list of recorded meeting processes that has been followed up.

usually there are some milestone events: requirements analysis, detailed design, system development, system testing, official release, etc., product managers in the management of their own projects, according to some key nodes of their own projects to do a milestone summary, to achieve the purpose of project reporting.
 

To obtain the true scriptures. this is like a project management process that has gone through a lot of hardships, and this experience is actually that as a product manager, you also have the opportunity to experience.

Project closing phase

in the whole development process of the project, we have experienced the start-up of the project, the planning of the project, the execution and monitoring of the project, and finally reached the closing stage of the project, and for a moment, you will feel that everything is worth it, because the victory is in front of you, and the dawn of hope seems to be glimpsed tomorrow.

the final stage of the project is mainly to evaluate and accept the indicators of the project and summarize the lessons learned from the project. however, as the person in charge of the whole project, even at the last minute, we still can't take it lightly, and there are many examples that demonstrate the importance of carefulness and seriousness.

For example, a simple server modification function, due to too much contempt, did not go through the test process, directly released to the internet, resulting in the collapse of tens of thousands of users' mobile phones. although the later investigation is found to be due to the programmer's negligence caused by the parameter error, but in fact, here has been exposed that there are still many problems in the project process, especially in the process of project closure, product testing is a very important link, products that have not been tested, can never be released to the public, this is a blood lesson.


Then, specific to the end of the project, it involves all aspects of acceptance and inspection, all members of the project team should be put into the team of self-inspection and project inspection, so as to ensure the normal and stable launch of the project.

functional bug testing

testing is an important part of the product launch link, accompanied by the entire product life cycle, so product testing is an important part, requiring special personnel to engage in related testing work, this part of the people is the test engineer. all currently internet companies have test engineers.

of course, depending on the size of the project, the size of the test team varies greatly. some projects require test engineers with the same number of development teams, while some teams of developers and product managers take on the role of testing.

in the development process of the project, we should try to make automated test tools for some basic functions and continuously improve the test cases. this allows the testing team to put more effort into testing new features, rather than worrying about whether existing features will be broken every time a release is released. the test engineer is the last link in the product launch, responsible for the user, is the "god" taster, and their position is the product gatekeeper.

In general, the main responsibilities of a test engineer in a project are divided into the following parts:

• write test plans, plan detailed test scenarios, write test cases;
• build and maintain a test environment according to the test plan;
• perform test work, submit test reports, including writing automatic test scripts for testing, recording test results completely, writing complete test reports, and other related technical documents;
• detailed analysis and accurate location of problems found in testing, and discussion of defect solutions with developers;
• put forward suggestions for further improvement of the product, summarize and statistically analyze the test results, track the test, and provide feedback;

After the test engineer has completed the above related tasks, it is considered to have completed the final work of the functional bug testing part of the project.

Developer's walk-in

Although most of the functional bugs are found by testers and fed back to the developer for processing and modification, developers still need to check some of their own work to improve the safety factor of the entire product.


the developer's walk-in mainly contains the following contents:

• do you do high-risk function scans?
• do you scan for security vulnerabilities?
• has the unnecessary log been deleted, and is the log information clear and complete?
• does it affect the functional performance of other related modules?
• has the pressure on its own system been assessed?
• have load changes in the back-end support system been evaluated?

of course, here are only some of the more common development checks, and the specific development check arrangements still depend on the leaders of the development department to specifically plan and promote the arrangements.

Product checkout

as the person in charge or leader of the entire project, the product manager should also carefully check his job to determine that there is no problem in product planning, which is the responsibility for his job responsibilities and the responsibility for the project.

usually, product managers need to check the following things at the end of a project:

• have the requirements list been adjusted or updated? for example, whether each functional feature has a definite input, processing, and output;
• is the requirements document complete or up-to-date? for example, whether the interaction diagram and design have been updated;
• whether the product update documentation has been submitted and conducted for customer service training;
• whether the product page copy has been checked (including but not limited to page text, advertising slogan);
• are the changes to existing functions and logos covered in other modules?
• are the statistical needs clear? is the data reported normally?

these are very detailed and trivial tasks, and product managers often need more patience and care when dealing with these things, so as to be thoughtful and comprehensive, and ensure that they do not cause any loss to the project within the scope of their work.

interaction and design walk-in

this part is mainly the work to be done by interaction designers and ui designers, because even the most exquisite design draft is only a picture in the designers' computers, and only after the front-end engineers in the project and the products developed and realized can they be seen by the majority of users.


therefore, after the front-end and back-end development is completed, the link between the designer and the developer is essential. products that are launched without confirmation often have omissions in product details, such as the details of certain page styles that do not match the original design draft, which causes a decline in the user experience of the product.

in this part, the usual work of interaction designers includes the following:

• interactive actions, operations and feedback of the page;
• confirmation of various states of interactive controls, initial state, normal, boundary state, error state, etc.;
• other interaction details, such as whether the default value is correct, the height of the first screen, product copy, etc.;

What ui designers have to do is mainly to check the visual style of the product, such as whether there is chromatic aberration, size spacing, picture quality, whether it conforms to the grid, etc.;

A walk-in of the product operations staff

if the project is put into the market after it is done, then the product operator must also make relevant operational preparations before the product is launched, so as not to fall into the embarrassing situation of no one after the product is launched.

So, in general, what work needs to be done in this part of product operation?

• has the cold launch of the product been prepared, and has the recruitment of seed users been started?
• is content operation planned? has the content update mechanism been confirmed and deployed, is it automatically updated, or is it updated manually?
• Is the event operation planned? is there a person in charge? are periodic activities already accompanied by operational templates?
• Is user operations planned? what are the key steps to new, retain, and revitalize?
• Has the account operated by the new media been established, and is there a person responsible for it?
• Is channel expansion planned? development agent? are partners introduced, and what should their qualifications be?

Summary

After watching the successful release of the product, the project team was finally relieved, and this time the project was successfully delivered. at this time, the product manager can summarize the harvest and successful experience of the entire project, such as the use of task prioritization to ensure that the main process of the product project can be smoothly launched on time.

In the whole process of project management, it must also expose many problems of team members, such as the research and development stage, before the loose and tight, always close to the test, only hurriedly closed; this often leads to poor quality of the test, or the test time is delayed, the risk accumulation to the test stage before the concentrated outbreak, and eventually lead to the project postponement, or with the explicit bug online.


Faced with these problems and pitfalls, product managers need to lead the project team to prepare for the challenges. the most important thing is to be able to build a learning team and an efficient communication team, summarize the project experience and lessons in a timely manner, so as not to repeat the same mistakes, and the team continues to learn and improve in the development of the project.

The last thing to do is to file some documents and project celebrations, which must have been encountered in the daily project management process, and will not repeat it.