Serious inconsistency between contract scope and demand analysis scope and Analysis

As a software developer, every time the demand analysis ends, we will sigh, how is this requirement completely different from the same as above? As a customer, we can't understand what the difference is between 1-2-3 and 4-4?

I think the first problem is that the customer's requirement is to solve the business problem. In the big aspect, the assumption is divided into 1-2-3-4, this is generally okay. If a problem occurs, the customer can agree to make adjustments. In addition to business problems, the actual operation habits mainly involved in demand analysis can be roughly divided as follows:

Decision-making layer (cost-effective): how much we need to solve these problems

Management layer (superior at the operation layer): To solve this problem, we should divide it into these steps and what other problems should we have?

Operation layer (User): to do this, I hope ********

When we sign a contract, we often achieve the first and second layers, and the first layer should be clear. The second layer is often the developer's speculation, however, the customer's management does not pay much attention to it and thinks there is still a demand analysis behind it. This is the root cause, and the operation layer is generally not involved. Time and cost cannot be involved.

When analyzing requirements, we need to analyze the problems that need to be solved from the decision-making layer to the management layer. Because every enterprise has a situation where the opinions of the management layer are not uniform, therefore, it is very difficult to control the operation layer. after entering the operation layer, we will be lost in the huge operation requirements.

In addition, customers often have a kind of money that I have already spent, so you can solve anything for me. It also adds a lot of things that are not considered by the Decision-Making layer, and the operation layer sometimes solves a lot of problems for you. If there are some conflicts with customers, you will be more painful.

Once again, some on-site staff of software developers are not sure about the project's objectives (the Decision-Making layer's requirements) and cannot continuously strengthen the customer's Leaders' intentions to the management and operation layers through appropriate communication methods, cause misunderstanding.

Fourth, the field staff of software developers cannot effectively and clearly express the situations and trends of changes in contract scope and demand scope, which are drowned in a large number of complicated documents. By the end of the demand analysis, both parties were eager to carry out further work, resulting in a rush to confirm.

These problems are very serious. I don't want to talk about solutions. I only want to talk about two aspects. 1. From the perspective of industry development, we should encourage customers to split their needs and implementations into two projects, independent. This requires constant calls from people in the industry and increased customer awareness.

The second aspect only involves how to make customers and developers have a very clear understanding of the scope of the project and strengthen and compare the demand analysis process. Developers must set up two tools. First, the question raised by the Decision-Making layer should be refined, and the advertisement should be posted in the meeting room for requirement analysis or carried at any time, it can be used at any time as a tool to verify whether we are away from the target. Second, the developer must prepare the project contract WBS when starting the requirement analysis, and obtain the customer's approval. This is the basis for demand analysis and research. Ensure that no deviation from WBS is ensured. If any deviation occurs, review and correct it at any time. After the demand analysis is complete, create a new project's WBS, and make a comparative analysis between the two to clarify the impact on the workload, duration, cost, quality, and other factors with the customer, after an agreement is reached, the party will proceed with the subsequent work.

Because our demand engineers are naturally fond of doing things perfectly, they will also join out-of-scope things, and they are not very concerned about the impact on the project, sometimes the customer will make some commitments at the site, resulting in a larger scope of the project. Therefore, each enterprise must make qualification requirements for the requirement engineer, conduct training, assess the changes in contract workload and demand workload, and clearly inform the requirement engineer that he has not obtained the relevant authorization, you cannot make a commitment to the customer. To constrain the demand engineer.

Of course, we should formulate corresponding solutions to the problems mentioned above. Here we will not discuss them one by one. Let's talk about the above.