Many IT projects I have written requirements for are focused on migrating existing functionality to a new system. The goal of the project may be to move to a new platform, build a new system from the ground up with the exact same functionality, or to move a piece of functionality from one system to another. Justifications for such projects include moving off an unsupported technology, gaining performance improvements or integrating with other enterprise systems.

The requirements gathering effort for migration projects is notably different than for a new system being built from scratch or for adding new functionality to an existing system. At a high level, the distinctions are in scope definition, understanding original business needs, working with end users, discovering the end-to-end functionality and IT involvement.

Scope:

As with any project, the scope definition on a migration project is critical. The variance in this type of project comes from the specific considerations in scope. Scope discussions should take into account whether to include the following:

• migrating all functionality
• phasing pieces of functionality over a rollout timeframe
• adding or changing functionality
• updating user interfaces

Prior to the requirements phase, a decision should be made regarding whether all functionality is being migrated immediately. If only a piece of a system’s functionality is being migrated, a clear boundary must be drawn around what is in scope for the project. As an example, we worked on a project where inventory management was about 10% of the total functionality in the existing system. This piece was being moved to a new system that was only going to house the inventory functionality. The original system stayed in place, and the inventory management piece was turned off in it. This defined a very clear boundary for the requirements gathering effort.

A joint business and IT decision must be made when considering if any new functionality will be developed. Often, migration projects are driven by IT needs, but the business cannot wait for a new system to be completed before getting additional functionality. The trade-offs have to be weighed, because not adding new functionality may simplify the project allowing an earlier launch.

When working with systems that have user interfaces, there is a choice to whether the changes will be limited to bug fixes, simple style changes or a complete overhaul. This decision should take into account the users’ needs. If you are working with a call center application where minimizing total call time is crucial and the sales reps are skilled in the existing user interface, changes to the interface should be minimal to avoid impacting the reps’ learned efficiencies in the current user interface.

Understanding business needs:

If there is a detailed requirements specification for the original system, a valid question to entertain is whether you can just reuse that specification to build the new system. In theory the answer is “yes”, but in reality, that can be a risky path to take. Even though you are replicating the existing system, you still need to ensure that you are not redeveloping functionality that was incorrectly defined in the first system. To avoid this, start with the original specification, and then interview users to establish how they use the actual functionality.

On the other hand, there may be a temptation to ignore the original specification, even as much as to ignore the existing system, and build the requirements from the ground up. This would require revisiting the true business needs and developing new requirements. If you rebuild the requirements from the ground-up, you will spend more time in gathering and writing the requirements and development will spend more time building them. It actually may be more cost efficient to build what you have and modify it in future releases. In fact, with this approach, it really is no longer a migration project and instead is just building a new system with new functionality to support existing business needs.

Each project will be unique regarding which side of the spectrum is most appropriate. However, somewhere in the middle of these two, there is an approach that uses elements of both to get to the best system in the most cost effective manner.

Working with end users:

As with any requirements gathering effort, you still need to utilize the end users, but in migration projects, there are differences in how you work with them.

In developing new functionality, it is helpful to work with users at a higher-task level to grasp the goals of their activities. And while that view of their role is still essential, it is also important to understand how they actually do the tasks in the existing system. The difference in migration projects is that significantly more of the overall requirements effort will be spent understanding the current system usage.

Similarly, with new functionality, it is often appropriate to discourage the user from focusing on user interface design. While in a migration project, it makes perfect sense to focus on the existing user interface. As an example, the sales rep in the call center application can describe the generic steps to find a product in the catalog, add it to a cart, capture the customer’s information and checkout. However, it is more useful to actually observe the sales rep doing this task and capture exactly what the screen choices are.

If the goal is explicitly to just migrate functionality, then while you should still ask the users “What do you need to be able to accomplish in the system?”, there is a much greater focus on “How do you use the system you have to do it?” and very little focus on “What do you want the system to do that it doesn’t already?”. The unfortunate news here is that the users may not see how this type of effort will benefit them, so it is important that they understand the business objectives behind the project.

I’ve discussed the first three critical PdM activities for a migration product today. Come back Thursday when I will be covering the discovery of end-to-end functionality and the involvement of IT.