A project I have done, how can I deliver it smoothly

Let’s briefly talk about the project background first. Project A can be considered as a new demand (derived new business) derived from the original business system. The original business system is a relatively large system, and it is also a fist product in the company. Dozens of sets have been sold, and there are several people maintaining it + secondary development + defect repair, etc. (human resources are tight). The executives of the early company just said that they would definitely do this project, but due to human resource problems, they did not decide to start the project (another important reason is that the leaders hope to sign 1-2 typical customers before starting the development of project A), and It's just that the sales are going to those dozens of customers to sell new business, which is hype, and there is some competition in the market, so you need to pull the list first. These things are mid-year things.

In the second half of the year, the market reacted strongly to this new business. Some customers have already said that they will see the prototype before signing the contract, because competitors have already produced prototypes. At this moment, the company thought that the high-level decision to start the project development immediately, saying that the prototype should be made first, with a deadline of one month. And the middle-level leaders were still due to the shortage of manpower, so they randomly assigned 4 developers, half of which were novices with less than 1 year of work experience, so they rushed into battle. Due to limited manpower, tight time, and clear business requirements, the four developers are not clear about many business details. Only one of them understands the business but is not proficient.

The project plan was set for one month, and the plan was basically arranged on a daily basis, and the prototype of the system came out one month later. But it is relatively rough, there are many defects, the design is basically not done, and the code quality is relatively poor. After taking it to the customer and installing it, the customer thinks that the system is too rough, [the customer will not think it is a prototype system when it comes to the customer]

At this point, according to the conventional project management practice, the real customer needs and business processes should be reorganized And functional design, architectural design, outline design. . . .
But things didn't work out that way. Because the customer is eager to see the progress of the project on a weekly basis, the leader decided to expand and modify the prototype system. As a result, it is difficult to execute the plan after it is formulated, and it becomes a weekly plan, mainly according to the customer's needs. need to change.

Finally, the version is basically stable before the end of the year, but the business process and functions are only relatively warm, and the defects have begun to converge.

However, after New Year's Day, the test version was installed at the customer's site, and the customer put forward a lot of demand changes and new modules for this version. At this moment, the trouble is relatively large, because the flexibility of the system's architecture is relatively poor, and the modification will have a relatively large impact on the original code and the scope of changes is large. As a result, the time is tight, and the workload is the workload. As soon as the function is implemented, the customer starts to urge when to test it. Defects were consistently high, so it was decided to spend 2 weeks devoted to bug fixes.

So far, the development is basically complete. But the problem is also more prominent:
there is a problem with the performance of the system (some module customers have great opinions, but technically speaking, the change will be relatively large, and it cannot be solved in one week)
. The stability of the system (related to 1)
function Usability (some functions were designed according to the developer's thinking in the early stage, and the customer put forward new ideas to the customer, and this experience demand was suppressed during development, but it still needs to be changed in the follow-up)
The demand development of the second phase is about to start. This is more troublesome

---------------------
So far, the risk of the entire project is still relatively large. I summarize the following reasons:
1. The project's goals and business processes , The general requirements are very clear, but the detailed requirements are in the early stage of the project, and the entire project team is half-understood, resulting in a large follow-up rework, and customers and developers, including company leaders, have great opinions on quality;
2. The project starts from the beginning Up to now, the division of labor between leaders and project managers is not clear; because people are teamed up, we have not cooperated before and do not understand;
3. After the prototype system came out, the project managers spent most of their time solving customer needs, communication and pre-sales support. , a small part of the time is spent on real project development;
4. The overall plan and progress of the project have been underestimated, resulting in the project plan being in name only, and it is entirely up to the developers to do what they do;
5. The leaders in the middle and early stages did not pay attention to this project. After the New Year's Day, when they found that the problem was serious, they temporarily dispatched people to assist. On the one hand, the people who just came in were not the ones the project manager wanted (still newbies), and on the other hand, due to the The business of the system is relatively strong, and it will not work within 1-2 weeks after the newbies join in;
6. Test engineers, the 2 test engineers sent here are added later, and they are not familiar with the business. Familiar with, and at the customer site, the test engineer can't deal with the customer's problem at all, that is, the customer's demand test engineer does not understand or is not familiar with it;

roughly that's it.