As everyone knows, projects to replace the legacy system with a new one are planned because of several reasons like to increase performance, reduce costs (such as maintenance costs or license fees), take advantage of modern technologies or meet legal requirements, etc.
Replacement projects are much more challenging and have a much higher risk of failure compared to the projects that aim to develop new system (greenfield projects). Some common challenges are shared below, and focusing on these issues in requirements management practices will increase the likelihood of a successful change project.
- Filling the scope with unnecessary functionality,
- Reducing the operational performance of the organization,
- Users’ refusal to adopt the new system
- Having a project that can never be put into operation
Scope Management in Accordance with the Project Goal
The main focus of change projects should be to carry existing functionality. Customers can imagine that if you’re still developing a new system, it’s easy to add many new features right away. Many change projects have failed due to the weight of uncontrolled scope growth.
Measures to be taken against risks arising from unmanageable scope:
1- It should be kept in mind that there may be functionalities that do not need to be carried in the current scope
Making this decision will not always be easy. The concern that something is missing in the new system can prevent these evaluations. However, it should not be forgotten that these should be evaluated meticulously in terms of the success of the project. It would be beneficial to carry out various analyzes and evaluations to support the making of this decision.
- Unnecessary functionality can be detected by interviewing its users or analyzing usage data showing which screens, functions and data assets are rarely accessed in the current system.
- In addition, it should be noted that some of the available functionality will not match current business goals..
2- The new requirements that may arise during the project are meticulously evaluated and included in the scope.
It will not always be possible to simply migrate existing functionality to the new system. There may be new requirements that are mandated by business or need to be covered to meet legal requirements. It would be the right approach to include them with meticulous evaluation and the detection of the really necessary ones.
3- Putting the new system in a production with incremental development
It is difficult to replace an established system that has matured for more than 10 years and has many versions, in one step. Big bang transitions are often challenging and unrealistic. It is usually better to create a stable initial release and add more features through subsequent development projects, provided the first release allows users to do their job. The most important constraint in this approach is the user experience. You should have plan that will not adversely affect the user experience. While users are doing a very small set of functions on the new system, it is not practical to return to the old system for most of the work. It is necessary to be able to identify the business-critical set of functionality that can be isolated for a phased roll-out approach. For example, if the functionality in the current system is using a certain user set, it will be appropriate to transfer this part to the new system in the first stage. On the other hand, the transfer of intensely used functionality at the first stage should also be considered, leaving less used functionality to the next stages.
Not Causing a Decline in Operational Performance
Existing systems determine customer expectations in terms of performance and production. Even if the new system is different, the business results should be at least as good as the old and the customer should be able to see it.
The key performance indicator model (KPIM) helps you define and determine these metrics for the relevant business processes.
For new systems, by giving priority to the KPIs that are the most important to reach, the business processes that follow the KPIs and the requirements that make these business processes possible should be managed as requirements with high priority.
Overcoming User Resistance
It is inevitable that you will encounter resistance when changing an existing system. People are naturally reluctant to change. Acknowledging that there will be resistance, it must plan how to overcome it.
To reduce the risk of user resistance, you must first understand the business goals and user requirements. Lack of any of these will quickly cause you to lose users’ trust. From the beginning of the project, you should focus on the user benefits of the new system or feature. Even if system renewal projects provide benefits for the organization as a whole, it may be possible for certain groups to negatively affect KPIs. That’s why you should help them understand the value of the proposed change for the entire organization. Users should be notified as soon as possible about features that might be lost or quality attributes that might be dropped so they can begin to prepare for it. System adoption can involve emotion as well as logic, so expectation management is critical to establishing the foundation for a successful presentation.
As we said at the beginning, the main key of a successful replacement project is to focus on the issues addressed in our article in requirements management practices. Transferring the functionality of the existing system to the new system at once by adding new features may be attractive in terms of initially low costs. However, due to the difficulties we mentioned, the risk of failure of the project is very high, so the cost incurred could be much higher than planned. The scope to be managed in accordance with the project objectives and the commissioning plan with a phased approach if possible are very critical for the successful completion of the project.
