Software requirements for migration projects

Joy Beatty, director of services at Seilevel, has published an excellent two-part post about gathering requirements for migration projects (here and here). A common enterprise software project is the replacement of a legacy system – duplicating functionality in a new system that exists in an old system. This type of project usually has very different constraints than a “new application” project. We will look at the characteristics of migration projects to understand how we should approach them to assure success.

The techniques that have been designed for development of new applications do not always work when migrating an existing software system to a new platform. In a migration project, change management plays a key role in determining how we manage the requirements, prioritization, and scheduling of delivery. The impact that change-management has is determined by where the migration project lies on the migration continuum.

The migration continuum

We can think of every software development project as being a migration. There is always a before, and there is always an after. Every project is a migration from before to after. In the following diagram, we show the continuum of migration projects. On the extreme left we are running projects where there is no precedent for the new software. On the extreme right, we are rewriting an existing application, designed to do exactly the same things, in exactly the same way.

It’s rare that the before state is “no process.” New software development is really a migration from “some process” to “some other process.” The projects that Joy describes are on the right side of the spectrum – migration from “some process” to “the same thing” or incorporate very minor process changes.

We can break this continuum up into four separate areas. Our individual projects may not fit squarely into one of the areas. It may straddle the boundary between two areas. When faced with one of these projects, we should use our judgment to apply ideas from each area.

Completely new process.

This is uncommon. We have a completely new process when we are implementing software to support a business process that is completely new to our customers.

Imagine a company that sells tires directly to consumers over the internet. If that company decides to establish a network of distributors and resellers, then new processes will be introduced for the company. Sales channel management, product distribution, promotions, joint marketing, etc. A company that introduces an online ordering website to augment their catalog sales will also introduce a series of new processes.
If we are building software in conjunction with a change to our customer’s business, then it is a completely new project.

Major process changes

This is the most common “new software” project. Enterprise customers rarely engage software companies to help them “do something new” – they often engage us to “do something better.” IT departments historically are not innovators for their companies, and they are generally treated as cost centers, not profit centers. IT projects are therefore often targeted at reducing the costs of existing processes. When a company talks about software to support a new process, they almost always mean a radically different process.

A company that has traditionally published a quarterly price book for their products has an initiative to create customer-specific pricing for their products. This is a process change, and a major one. Previously, someone determined prices for all customers (perhaps with different prices for different groups of customers), and those prices were communicated via the mass-publishing of a price book.

In the new version of the pricing process, prices are determined for each customer, perhaps to reward higher volume or more loyal customers with special pricing. Pricing may change in the new system on a daily basis (perhaps raising prices as inventory levels drop for a product). The communication mechanism may be very different – customers may need to log in to a web site to get current quotes, or they may have to call a sales rep who has access to an internal pricing system.

We can validate for ourselves that the process is pre-existing by stepping back and taking a high level view. In both processes, prices are determined with a goal of maximizing profits (or market share). Prices are communicated to customers. The differences are “in the details” even though they can mean significant changes, and have significant value to customers.

Minor process changes

Alan Cooper suggests that most customers are not innovators (at least with respect to software). Their ideas are evolutionary, not revolutionary improvements to existing processes.

A company that sells products internationally has sales teams in each of their target-market countries. The company’s product managers determine which products are available in each country. When a salesperson wants to sell a product, they have to confirm that the product is available for sale in that country, then contact a pricing specialist to determine the proper price to charge in the local currency.

In the modified process, an intranet page is created that accesses a database of country-availability information for each product. The salesperson can now access the website, find the product (and it’s country-specific part number) and the proper price to charge in the local currency.

This is a minor process change. Note that the absence of software in the previous process does not mean that the process did not exist. It has known constraints, objectives and goals. It is relatively straightforward to define requirements for this type of project, as Joy points out.

Identical process

We are migrating to an identical process when there is already a system in place, and the goal is to replace it with the same system, but on a new platform. This is common when migrating to new software and hardware platforms (moving from a standalone application onto a department web server, consolidation of SAP instances, etc). These are the IT-driven consolidation or cost reduction projects. These can are the projects with the highest propensity to be waterfall projects, as stakeholders will have a driving objective of system replacement (or sunsetting). “Must do everything the existing system does” is the common theme.

Often, scope creep affects these projects, as there are always opportunities to improve existing systems. The customer may have been living with inconveniences that were too expensive to fix in the old system. Someone will try and attach these minor improvements to the migration project like congressmen attaching riders to a budget bill.

This isn’t a bad idea, as the improvements are usually valuable, and may have good ROI characteristics if incorporated into the scope of the migration project. If these requests are ignored, they may become lost opportunities. What we have to make sure we remember is that these improvements are “minor process changes” and we may need to manage them distinctly or differently than the other areas of the project.

How do we use this continuum framework?

One size does not fit all when it comes to software development processes.

Stakeholder priorities and objectives will vary. The level of effort in different areas of the process will vary. For example, interaction design efforts will not be well received in an identical process project, but they are invaluable for major process changes or the introduction of new processes.

Different techniques can be used in different places on the migration continuum. As Joy points out, in an identical process project, someone can even read the existing source code to reverse engineer a particular required behavior.

We talk more about how best to approach projects in different places along the continuum in Organizing a software migration project.