You'll need to do some discovery, first, which will help identify processes, checklists, or templates you may need. Below are some considerations. Some answers will need to come from the vendor, some from your company. The vendor may also have templates and/or guidelines and, as Stephane mentioned, should be able to guide you through the upgrade process.
- Who are the users?
- Will there be new features/functionality?
- Are there features/functionality currently in use that will be deprecated or significantly changed?
- What features/functionality are changing that you will need to train the users on?
- Will any new processes be required?
- Has your company made changes, separate from the vendor, that will get overwritten by the upgrade or that the vendor is unable to test?
- Are there any time constraints for when the upgrade has to be done by, when the upgrade can be deployed, or how long the system can be down (if there will be downtime)?
- You'll want to balance the vendor estimates for discovery, development/config, and testing against project team members availability and knowledge of the product. The more available your employees are during discovery, development/config, and testing, and the more knowledgeable they are about your configuration and processes, the faster it can go. However, testing can take longer than expected because of unexpected errors and retesting. If you have a hard deadline, don't plan your launch date to immediately follow a 2 week testing period. Saving Changes...
If your project is to implement a new version of existing software, then it is essentially a validation and verification effort. If and when issues are encountered during that effort, you need to determine if you must change they software to fit your needs, or you need to change your processes to utilize the software in its current state.
Validation is ensuring completeness. Does it do all the things you require? For that, you may have defined requirements such as in a requirements traceability matrix and/or other architectural views, or you may need to establish that yourself through use cases.
Verification is ensuring the correct result. That establishes that not only does a product perform a function, but that it does so correctly. That often requires test cases where you execute your processes and evaluate the software outputs.
The bottom line is that you must first define what "good enough" looks like, before you plan how to establish good enough. Saving Changes...
Community Champion
