Project Management: How to avoid project delays?

I. What causes project delays?

1. Product requirements change frequently

For frequent changes in product requirements, we have to ask 3 questions: Why do product requirements change frequently? What are the negative effects of frequent changes in requirements? What kind of processing method should we adopt to avoid frequent changes in requirements?

The reasons for frequent changes in product requirements are as follows：

• Flawed thinking in the early stage, you think the problem is so simple that many details and logic are not taken into account, and only in the development stage do you find many problems, so you have to add requirements or change the original requirements.
• Technical research is not in place, you think you can do the function based on the current support of the system can not be iterated out on time, resulting in the use of alternative solutions and change requirements.
• The solution developed in the early stage has a deviation in understanding the requirements, and after the later alignment and communication to find the wrong understanding and then change the requirements.

2. What is the impact of frequent requirement changes?

Requirements are created to solve certain problems and loopholes in the product or market, so all requirements must have a positive meaning for the whole product. In the product lifecycle, requirements identification is the first process.

Frequent changes in requirements can lead to refactoring of product design, development logic, and test cases or can invalidate completed workloads.

The more times the requirements are changed, the more the team's overall workload increases and time decreases, and the more the pressure on themselves and the team will increase. Performance, forming a vicious circle.

Example：

We previously made a horizontal version of the non-sliding timeline function in the touchscreen terminal. The task period will lead to an incomplete text display. However, still insisted on completing this requirement, the timeline display logic, front-end development, and testing have invested a lot of energy. But the user feedback said the timeline is useless or more practical to make a list. During the review, we concluded that the root cause of the problem was the imaginary user scenario, and we did not communicate with the user sufficiently, which led to redoing the requirements, increasing the workload, and creating some unnecessary friction with the front-end students.

3. How can we avoid frequent changes in requirements?

1) Use tools to help sort out the logic

When faced with the complex logic of the module can use brain maps and flowcharts to assist in sorting out the logic of the security application of a small module, for example, you can use brain maps and flowcharts to assist in sorting out the logic to avoid missing data, functionality, and logic.

Example - tool to assist：

2) Thinking about extreme values

That is, when the data in the product is 0 or the maximum value, what should be the processing logic? In order to avoid missing logic, pages, and functions, extreme value thinking is used to summarize the statistics of the data generated in the product and make the assumption that the data value is 0 or the maximum value to check whether there are missing requirements.

Example - extreme value thinking：

For example, Zhihu's answer later function shows an empty page when the data is 0 and guides users to view the recommended questions.

3) Preliminary technical research

To avoid the developed requirements because of the existing resources and a specific period can not be completed, requirements, programs, and teams to conduct comprehensive technical research and communication, you can go online to view the relevant information, and technical staff to discuss more communication, to ensure that the program based on the existing technical strength and controllable time frame is feasible.

4) Demand research

Compared with competing products, do market research and full communication with customers. You can first explain their design solutions to customers to ensure that the demand is real and can solve the problems users face, to ensure that their understanding of the demand is correct.

II. Customer ad hoc requirements

1. What is the impact of a customer adding a requirement on an ad hoc basis?

When a customer temporarily adds a requirement, the time cost increases if the number of personnel remains the same or the number of project personnel increases. Either option will undoubtedly increase the cost of the project, put pressure on the team, and cause the project to lose money when project revenue exceeds expenses.

I have taken over a similar project to meet the needs of the client quickly and invested too much staff, resulting in a large number of layoffs near the completion of the project, the root cause is the project input, and output ratio is out of balance, to ensure that the projected revenue can only reduce the staff.

2. How to deal with the customer's temporary increase in demand?

1) Get the real demand

To avoid later demand changes or to work overtime to make the function not meet the expectations, it was rejected by the whole situation. When encountering the customer's temporary increase in demand, more need to determine the customer his true needs. And the customer to do their best to communicate, to facilitate the customer's full can an intuitive understanding of the design program, and you can use illustrations and text to explain the way. If there are conditions, it is best to be in the customer's use of the scene and experience the customer's use of the pain points to dig out the features that the customer wants.

2）Replacement requirements

Under the premise of ensuring the normal use of product functions by customers to rationalize the allocation of project resources, you can reasonably replace the needs proposed by customers based on the existing logic and functions of the product and provide reasons and solutions. Understand what problems the customer wants to solve, compare which solutions are feasible with the existing resources of the system, and provide the most cost-effective solution.

3）Demand forbearance

In order to achieve the best results of the core requirements within a certain period, prioritize the requirements and put the lower priority requirements temporarily in the next version, using the existing resources of the system using simple logic, it easier to achieve the solution, so that the cost is small, the effect is achieved. If the direction is correct, the later iteration can be optimized.

III. The risk forecast cycle is too short

1. What are the reasons for the short-risk forecast cycle?

1) Major problems are found too late, or many problems are found close to the release, resulting in the inability to deal with the problems in time and thus affecting the publication. It may be due to the lack of good communication in teamwork, such as the team's unclear understanding of the requirements, the priority of the requirements is not mastered, the bugs are piling up, the testing packaging frequency is not enough, etc. This can lead to this situation.

2) Requirements are not prioritized, the R&D schedule is not arranged, and all requirements are handled according to the same priority, resulting in tasks with high priority not being completed on time.

3) Work-flow problems, the lack of effective processing mechanism, the same problem occurs frequently. It is likely a problem in the process, which should be bottom-up to improve the missing processing mechanism.

2. In the two processes of R&D and testing, how can the product be driven?

1) Track the progress of the project every day

In order to keep track of and deal with the problems encountered in the development phase of the project, in the R&D process, you can split the requirements into small functional points according to the division of labor between the front and back ends, set the development staff and time, and track the progress every day. When a small task has been postponed, we can evaluate the risk of postponement together, and readjust the personnel allocation if necessary, such as developers encountering technical problems can meet to discuss the optimal solution, and when the actual task volume and the expected task volume have a large gap can be adjusted on time.

2) Product function acceptance

When the developers finish a set of functions, the product can accept this set of functions. If there are problems with the product design can be corrected in time. If there are problems with the R & D implementation can also be repaired as early as possible bugs can reduce the pressure and workload of product quality acceptance, bugs can be dealt with as early as possible, found that there are problems with the logic can also be corrected as early as possible. The quality of the product and the progress of the project have a positive impact on the promotion. It has a positive effect on product quality and project progress.

3) Setting requirement priorities

In the testing process, the functional modules to be tested can be prioritized (generally according to the priority of requirements). The modules with important requirements and complex logic can be tested first to avoid difficult failures before the release. When R&D personnel fixes bugs, they should also evaluate the priority level of bugs to fix.

IV. Near the release only to find a feature that does not match the requirements

This point and the third point [risk forecast cycle is too short] overlap before the release of the implementation of features or logic, and requirements found to be inconsistent with the situation do not often occur. Still, once it happens, the project will face a much higher risk of delay, so he is listed separately as the fourth point to discuss solutions.

1. What is the reason for this problem?

1). The document is not clear or detailed, resulting in deviations in the understanding of different people, such as the document states that it supports dragging sorting but does not write the specific sorting method to replace the sorting or sequential arrangement, resulting in A, B two ways of implementation, the product that the use of program A, the development of understanding is program B, resulting in understanding deviations. The problem is not easy to be found.

2). Product, R & D, and testers do not have good communication, each with their understanding to think about the problem is the first point of the derivative situation when the document has generated ambiguity, and no full offline communication will lead to requirements. The realization of the function does not match.

3). No functional acceptance. After** the function is completed, the product students do not verify whether it is consistent with their requirements, probably because the company has not set up this process. Still, the product students do a good job of functional acceptance and can expose the most serious problems the first time so that they can be corrected on time.

2. Impact

Such a major mistake will not only lead to project delays but also because of the number of people involved in the mutual blame affecting team harmony and causing team conflicts. Because the function cannot be completed accurately and on time, it often requires other solutions or more time to remedy.

So how to avoid this situation is especially important?

• Quality requirements document: write the product document in detail, describe what you want and understandably, and if there is a problem with the language organization, you can refer to the existing features on the market and convert them into a spoken form to describe.
• Team communication: Communicate fully with R&D and testers to make sure they understand what kind of features you want, and use prototypes to demonstrate the effect you want to achieve.
• Product acceptance before testing: The product manager can accept the consistency of the functionality and the correctness of the logic after the developers have finished development and before testing to ensure that the product is going in the right direction. Testing based on errors wastes the staff's energy and time and ultimately does not achieve the expected results.
• Quality acceptance: After testing for product quality acceptance, the product should have no major, obvious bugs at this time. The product is mainly on the aesthetics of the page and the smoothness of the operation to verify that no error can be issued.

V. Summary

Hope that the product "students" are more self-driven and find their problems in each link to find the solutions they can do.