Gathering Requirements for Migration Projects (Part 2)
On Tuesday I began an overview of the processes behind gathering requirements for a migration project and how these activities differ from a system with new functionality. I began by talking about scope, understanding business needs and working with end users. Although these activities have a lot in common with the approach for a new system, there are some key differences that were uncovered. Today, I am going to finish the discussion by drilling into a couple of additional areas that differ significantly – discovering the end-to-end functionality and working with IT.
Discovering the end-to-end functionality:
As with any project, it is important to capture the entire set of functionality. One of the great advantages of a migration project is that you do have an existing system to work from, including user and system interfaces. For user interfaces, the menus can be used to decompose the functionality. The existing screens can be clicked through to discover the alternate paths through the system. For system interfaces, you can get a complete list of the interfaces and what data is passed between them to ensure they are covered in the requirements.
In meeting with the end users to understand how they use the system, you can easily capture use cases. With new functionality, use cases are a crucial model to discovering all the functional requirements, though that advantage is less notable in migration projects. The use cases are still valuable to give the full picture of how the functionality fits together to accomplish user goals, and they provide an organizational structure for the requirements. The significant difference in writing the use cases is that there should be more reliance on using the existing user interface design.
In the case where no one knows exactly how something works, there is a convenient option to just look at the code and the database schema to understand the actual implemented business rules. In fact, theoretically, the development team could just use the original code to develop the new system. Though realistically, this is dull and error-prone for a developer.
Working with IT:
In a migration project, it should be expected that there is far greater involvement from IT in the requirements phase of the project. In discovering new functionality needs, IT may not be fully engaged early in the project to avoid stifling the creativity of the business users. However in a migration project, it is crucial to engage them as early as possible, and there is absolutely no risk to that involvement.
The development team can help with a technical decomposition of the system functionality. They will have a clear view of the data elements and ensuring those are all well understood in the existing system. For example, in the migration of a financial system, there are many underlying matrices of data and business rules. The business users cannot recall the all of specific detailed business rules around those matrices. It would be far more efficient for a developer to look at the existing code to help understand the specific matrices and the associated behavior.
One of the great risk mitigations for a migration project is that the development team will be looking at the code of the existing system and therefore it can serve as one last checkpoint to ensure functionality is not overlooked.
Discovering what is not used:
The scope of a migration project should include identifying functionality that is not used, so that the development team does not waste cycles building it. This is precisely why defining the requirements is not as simple as just reusing the original requirements specification or having the development team build it straight from the existing system code.
A suspect list of unused functionality will be discovered in the user interviews. For example, if users are asked “What happens if you select this option on the screen?” and there are consistent answers like “I don’t know, I never do that”, then this is functionality to be flagged for removal. In an ideal world, IT may be have data on what screens are never accessed or what data elements never are updated in the existing system.
It may be difficult for the business to sign off on saying that a piece of functionality is not used. However, that is exactly what is necessary. Once there is that list of target functionality to be removed in the new system, every single one of the identified user groups of the system must be interviewed to confirm the list.
Resource skill set:
I think any great product manager can identify the requirements for a migration project. However, this is one type of project where a product manager with a technical background can be a great advantage. Such a product manager will have the capability to actually read the code and architecture diagrams if required to gather the requirements.
In the end, certainly there are many similarities in the requirements efforts of migration projects and new functionality projects. However, there are some important differences, and it is critical to the project’s success that these variations are recognized before starting the requirements phase of the project.
Discovering the end-to-end functionality:
As with any project, it is important to capture the entire set of functionality. One of the great advantages of a migration project is that you do have an existing system to work from, including user and system interfaces. For user interfaces, the menus can be used to decompose the functionality. The existing screens can be clicked through to discover the alternate paths through the system. For system interfaces, you can get a complete list of the interfaces and what data is passed between them to ensure they are covered in the requirements.
In meeting with the end users to understand how they use the system, you can easily capture use cases. With new functionality, use cases are a crucial model to discovering all the functional requirements, though that advantage is less notable in migration projects. The use cases are still valuable to give the full picture of how the functionality fits together to accomplish user goals, and they provide an organizational structure for the requirements. The significant difference in writing the use cases is that there should be more reliance on using the existing user interface design.
In the case where no one knows exactly how something works, there is a convenient option to just look at the code and the database schema to understand the actual implemented business rules. In fact, theoretically, the development team could just use the original code to develop the new system. Though realistically, this is dull and error-prone for a developer.
Working with IT:
In a migration project, it should be expected that there is far greater involvement from IT in the requirements phase of the project. In discovering new functionality needs, IT may not be fully engaged early in the project to avoid stifling the creativity of the business users. However in a migration project, it is crucial to engage them as early as possible, and there is absolutely no risk to that involvement.
The development team can help with a technical decomposition of the system functionality. They will have a clear view of the data elements and ensuring those are all well understood in the existing system. For example, in the migration of a financial system, there are many underlying matrices of data and business rules. The business users cannot recall the all of specific detailed business rules around those matrices. It would be far more efficient for a developer to look at the existing code to help understand the specific matrices and the associated behavior.
One of the great risk mitigations for a migration project is that the development team will be looking at the code of the existing system and therefore it can serve as one last checkpoint to ensure functionality is not overlooked.
Discovering what is not used:
The scope of a migration project should include identifying functionality that is not used, so that the development team does not waste cycles building it. This is precisely why defining the requirements is not as simple as just reusing the original requirements specification or having the development team build it straight from the existing system code.
A suspect list of unused functionality will be discovered in the user interviews. For example, if users are asked “What happens if you select this option on the screen?” and there are consistent answers like “I don’t know, I never do that”, then this is functionality to be flagged for removal. In an ideal world, IT may be have data on what screens are never accessed or what data elements never are updated in the existing system.
It may be difficult for the business to sign off on saying that a piece of functionality is not used. However, that is exactly what is necessary. Once there is that list of target functionality to be removed in the new system, every single one of the identified user groups of the system must be interviewed to confirm the list.
Resource skill set:
I think any great product manager can identify the requirements for a migration project. However, this is one type of project where a product manager with a technical background can be a great advantage. Such a product manager will have the capability to actually read the code and architecture diagrams if required to gather the requirements.
In the end, certainly there are many similarities in the requirements efforts of migration projects and new functionality projects. However, there are some important differences, and it is critical to the project’s success that these variations are recognized before starting the requirements phase of the project.
posted by Joy at 3/02/2006 10:26:00 PM
0 Comments:
Post a Comment
<< Home