Difficulties arising from changes to CRM project requirements

A British scholar said that any change, even in a positive direction, is always accompanied by setbacks and pains. This statement breaks through the troubles in the project demand change process. This annoyance is not only shared by our implementation consultants, but also shared by corporate customers.

1. Changes to project requirements may increase implementation costs.

Project demand changes are often accompanied by an increase in the implementation cost of Enterprise CRM projects. If you want to add a field to the customer information and then bring the field to the sales order. This user may think it is relatively simple, but it is not simple at all. As a background developer, you should consider the type of this field, for example, number type or character type; consider whether this field will participate in subsequent operations; this field must be a required or optional field. When opening a sales order, you must determine whether or not the customer information contains this field, and whether the content of this field can be changed in the sales order. If yes, whether the content of this field in customer information can be automatically updated after the change. Therefore, if you consider so many factors for such a simple requirement change, the number of codes is very large. If you consider the cost of this second demand change based on the amount of code, it is also a considerable cost. A demand change may have a relatively low cost. However, if there are too many demand changes, the accumulative cost will be very high.

2. Changes to project requirements may extend the implementation cycle of the project.

The enterprise may accept the increase in costs. However, if the CRM project cannot be launched on time, it is not so easy for enterprises to accept.

For example, when I implement a CRM Project for a customer, the customer puts forward the need to change the handling of a customer complaint in the dual-line parallel system stage, which cannot be completed by system configuration alone, secondary development is required. In addition, users cannot compromise in the project implementation process. They must wait until the development is complete before they can end the dual-line operation and discard the manual account. After many persuasion, the user had regressed. Except for the customer service department, all other departments gave up manual accounts one month later, while the customer service department gave up manual accounts only after the second development, this is a month ahead of the original plan. We all know that dual-line parallel processing is equivalent to doubling the workload, and the customer service department staff are very dissatisfied with the customer service department and are not impressed with the CRM system, put all the gas in this system. Finally, although the project was successfully completed, it was a month later than the pre-plan.

Therefore, changes to project requirements are often accompanied by the extension of the project implementation cycle.

3. Changes to project requirements increase the risk of CRM projects.

As a large-scale information-based enterprise management system, CRM has a relatively high implementation risk. If there are more changes to project requirements in the middle, the risks will multiply.

From the technical point of view, we can see the risks of demand changes to CRM projects from the adverse impact of employees on demand changes, which increases their resistance to the system. As shown in the above demand changes, Project changes have extended the parallel time of two lines, increasing the workload for customer service personnel. Although this demand change will be applied to their subsequent work, however, in the middle of the process, they are very disgusted and not cooperative. Finally, if it weren't for the above mandatory requirements, the consequences would be unimaginable and the CRM project would be resisted by the customer service department, as a result, the project may end in failure or affect its final implementation effect.

It can be seen that the CRM project requirement change is very unfavorable for the CRM project. So how can we minimize this loss, or even eliminate the need for changes during project implementation?

1. demand changes should be made as early as possible, and the more serious the impact of the subsequent costs and risks will be.

When the demand changes occurred, I communicated with some users and asked them why they didn't propose it before? A large number of users said that they had discovered this problem before, but at that time they thought that this requirement was not very important and was dispensable. But they did not expect it, now the system is getting more and more familiar, the better the use, the problem is also getting bigger, feel that it is necessary to implement, otherwise, the work will not continue.

In fact, many enterprises have this problem. Indeed, there is a big difference between manual and system automatic operations. In some handicraft industry, it may not be a big problem. However, when the management system is used for automated operations, it is discovered that this problem has become a major obstacle to information-based operations. This situation exists in not only one enterprise.

However, from the information project perspective, this is a very dangerous signal. Why? When we build a house, if we find that the original design is wrong and we need to re-overturn and recreate it, the cost and time will be wasted, Which is immeasurable. For CRM projects, it is similar. If your project is about to be completed, you will find that the original requirement is wrong and you need to change it, the loss will be very high. Therefore, the closer the project ends, the greater the loss to the enterprise if the demand changes.

Therefore, we need to do a good job in demand research, system demonstration, and system training in the early stage, and strive to explore the potential needs of users to the greatest extent possible, and find the places where the needs may change, ask the user to change the requirement as soon as possible. During the project implementation process, I usually set the request change or confirmation time for new requirements at the latest in the system training phase. That is to say, after the system training is complete, before preparing for dual-line parallelism, enterprise users can also apply for a change request. However, when the system starts to operate on Dual-line, users are not allowed to submit similar requests, such as request changes. In the future, any new requirements and demand changes must be placed on the project. Of course, it is not enough to rely on the consultant alone. during project implementation, I will negotiate with the enterprise owner to tell them the potential risks of demand changes. Let him run the dead command, which is more effective than the hundreds or thousands of sentences on the platform.

In short, the sooner the demand changes, the better the discovery. The later you find out, the more time, cost, and project risks you may encounter.

2. If demand changes cannot be solved within a short period of time, a compromise plan should be adopted.

When we encounter some demands that cannot be solved within a short period of time and need to take a month to solve them, we should not take the bull's corner, rather we should think about it, if there is any temporary compromise, you can "handle" it first, while using the system for secondary development.

This is mainly to reduce the impact of demand changes on the project cycle, and to ensure that the CRM system can be launched on time. Sometimes, in order to ensure the realization of this big goal, it is worthwhile for us to make such a compromise, whether it is an implementation consultant or an enterprise.

For example, I met a customer a long time ago. When the project training was completed, the sales director of the customer company asked me if there was any customer funnel management model in our system. Customer funnel management tools are common in current CRM systems. However, they were rare in CRM systems a few years ago. Because the customer's funnel management model is designed not only for functional differences, but also for background technologies. Previously, many CRM software using the C/S (Client/Server) mode were unable to implement this function. Although we have just started to adopt the B/S (Browser/Server) mode, we have not considered this function.

What should I do? Users have two options: one is to perform secondary development to implement the funnel management model. However, this will undoubtedly increase the implementation cost, and such a complicated management model, it is not something that can be done in a day or two. It is difficult to implement it without months. The second option is not to use funnel graphical management, but to provide only some report data, sales funnel management, etc. When we upgrade the system next time, we will give priority to help enterprises upgrade to implement this function. Therefore, enterprises do not have to spend any money on this upgrade because it is a version upgrade.

How should we choose? I showed the sales director the reports and forms of simulated sales funnel management. He found that although the use of labels and forms is not as convenient as a graphic tool, it is acceptable from time, cost, and other factors. Therefore, after accepting our second solution, we first moved to use it. After our system was upgraded, we managed it using the sales funnel.

Demand changes have a very large impact on the project. However, just as it is raining, we cannot fundamentally eliminate it. What we can do is to take some effective work to minimize this probability; or take some remedial measures to minimize the loss of demand changes to CRM projects.