A replacement project replaces an existing software system with a new custom-built system, a commercial off-the-shelf (COTS) system, or a hybrid of those. There are some challenges that most replacement projects share, including stuffing in unnecessary functionality, degrading the organization’s operational performance, users refusing to adopt the new system, and having such a large project that it never deploys. Focusing requirements practices on addressing these issues directly can increase the likelihood of a system replacement that delivers the desired value and is accepted by the users.
Replacement projects are most commonly implemented to improve performance, cut costs (such as maintenance costs or license fees), take advantage of modern technologies, or meet regulatory requirements. However, be wary of letting unnecessary new functionality slip into replacement projects. The main focus of replacement projects is to migrate existing functionality. Customers might imagine that if you are developing a new system anyway, it is easy to add lots of new capabilities right away. Many replacement projects have collapsed because of the weight of uncontrolled scope growth. You’re usually better off building a stable first release and adding more features through subsequent enhancement projects, provided the first release allows users to do their jobs. Replacement projects often originate when stakeholders want to add functionality to an existing system that is too inflexible to support the growth or has technology limitations. Use the anticipated cost savings from a new system (such as through reduced maintenance of an old, clunky system) plus the value of the new desired functionality to make sure you can justify a system replacement project.
Look for existing functionality that doesn't need to be retained in a replacement system. Don't replicate the existing system's shortcomings or miss an opportunity to update a system to suit new business needs and processes. For example, the business analyst might ask users, “Do you use <a particular menu option>?” If you consistently hear “I never do that,” then maybe it isn't needed in the replacement system. Look for usage data that shows what screens, functions, or data entities are rarely accessed in the current system. Even the existing functionality has to map to current and anticipated business objectives to warrant re-implementing it in the new system.
Existing systems set user expectations for performance and throughput. Stakeholders almost always have key performance indicators (KPIs) for existing processes that they will want to maintain in the new system. A key performance indicator model (KPIM) can help you identify and specify these metrics for their corresponding business processes. KPIMs are further discussed in Visual Models for Software Requirements (Microsoft Press, 2012). The KPIM helps stakeholders see that even if the new system will be different, their business outcomes will be at least as good as before. Figure 1 shows an example of a KPIM.
Figure 1: A simple example of a KPIM.
For replacement systems, prioritize the KPIs that are most important to achieve. Look for the business processes that trace to the most important KPIs and the requirements that enable those business processes: these are the requirements to implement first. For instance, if you're replacing a loan application system in which loan processors can enter 10 loans per day, it might be important to maintain at least that same throughput in the new system. The functionality that allows loan processers to enter loans should be some of the earliest implemented in the new system, so the loan processors can maintain their productivity.
You’re bound to run into resistance when replacing an existing system. People are naturally reluctant to change. Introducing a new feature that will make users' jobs easier is a good thing, but users are accustomed to how the system works today, and you plan to modify that. You're potentially changing the entire application's look and feel, its menus, the operating environment, and possibly the user's whole job. You have to anticipate the resistance and plan how you will overcome it, so the users will accept the new features or system. An existing, established system is probably stable, fully integrated with surrounding systems, and well understood by users. A new system having all the same functionality might be none of these upon its initial release. Users might fear that the new system will disrupt their normal operations while they learn how to use it. Even worse, it might not support their current operations. Users might even be afraid of losing their jobs if the system automates tasks they perform manually today. It's not uncommon to hear users say that they will accept the new system only if it does everything the old system does—even if they don't personally use all of that functionality.
To mitigate the risk of user resistance, you first need to understand the business objectives and the user requirements. If either of these misses the mark, you will lose the users' trust quickly. During elicitation, focus on the benefits the new system or feature provides to the users. Help them understand the value of the proposed change to the organization as a whole. A poorly designed user interface can even make the system harder to use because the old features are harder to find, lost amidst a clutter of new options, or more cumbersome to access.
One caveat with system replacements is that the KPIs for certain groups might be negatively affected, even if the system replacement provides a benefit for the organization as a whole. Let users know as soon as possible about features they might be losing or quality attributes that might degrade, so they can start to prepare for it. System adoption can involve as much emotion as logic, so expectation management is critical to lay the foundation for a successful rollout.
Replacement projects often need a critical mass of functionality in the new application before users can begin using it to do their jobs. Incremental development doesn’t always work well. It’s not practical for people to use the new system to do a small portion of their job and then have to go back to the old system to perform other functions. However, big-bang migrations are also challenging and unrealistic. It's difficult to replace in a single step an established system that has matured over 10 years and numerous releases.
One approach to implementing a replacement system incrementally is to identify functionality that can be isolated and begin by building just those pieces. We once helped a customer team to replace their current fulfillment system with a new custom-developed system. Inventory management represented about 10 percent of the total functionality of the entire fulfillment system. For the most part, the people who managed inventory were separate from the people who managed other parts of the fulfillment process. The initial strategy was to move just the inventory management functionality to a new system of its own because it affected just a subset of users, who then would primarily work only in the new system. Retaining the original system and turning off its inventory management piece provided a clear boundary for the requirements effort and reduced the risk of deploying the replacement system.
Replacement projects can be difficult to deliver successfully because of their size. A few good requirements practices can help increase the chances of delivering a replacement system that delivers the desired value to the business.
Authors: Joy Betty & Karl Weigers
Joy Beatty is a Vice President at Seilevel, www.seilevel.com. Karl Wiegers is Principal Consultant at Process Impact, www.processimpact.com. Karl and Joy are co-authors of the recent book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.