September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
For a technology project it makes sense to create the team(s) first and then let the teams take responsibility for planning. The Scrum framework and its variants are the most popular way to run complex software projects (www.scrum.org) but you should find out what approaches your teams are already familiar and experienced with.
There are many resources to learn about transformations. I did my first in 1988.
Try to stay out of the weeds, in order to be able to jump in if required. Assign good experienced people. Engage sponsor early, establish trust with them (in the end they are likely to make big and ugly decisions and need the safety you give them).
Things to consider (and learn about) are
- organizational change management, including stakeholder engagement, champions, key users
- data migration (setting up the new system with the information status of the old) includung reconcilation
- big bang or staged migration incl parallel runs
- do dry runs if possible
- test, test, test (if possible do automatic and regression testing)
- risk management and fallback plans
- migration weekend - minute by minute planning
- have a hypercare unit ready for approx 3 months
- consequently shut down development after this and move responsibility to operations, support and maintenance
Great tips from Thomas!
A few questions to provoke some ideas...
1. What is your rollback strategy?
2. How clean is the data? How will you confirm that as that is usually a common source of schedule delays and cost overruns?
3. How will you reconcile the migration and what will your stakeholders consider to be an acceptable level of variation?
4. Can you involve operations as early as possible to facilitate the transition?
In addition to what has already been said...
You probably have data issues in your current system - incomplete data, inaccurate data, query performance issues, etc. Working with your team, document the issues and determine which need to be fixed before migrating, which can be fixed in the new system, and if any of them are a result of processes that should be changed. Allow enough time for this. Fixing technical issues usually takes longer than people expect; if it was a known issue that was easily fixed, it probably would have been fixed by now.
Mapping data from one system to another can be a slow process, too.
As well as running more than one practice migration, evaluate system performance during the migration, and be aware that whatever environment you are using for practice migrations, it's probably not a production mirror. The servers probably won't have the same amount of memory or CPUs, network performance may be different, and there might be services running in production that haven't been accounted for. Some systems allow for tools that let you do a slow migration, without downtime, that covers most of the data, and then you finish the deltas during downtime. If you can run the old and new systems in parallel without users on the new system (green field), you might be able to avoid this.
Few very good hints from Thomas and Kiron.
I have not worked on such project directly but following point might help.
1. Defining a good user content for training. I had seen problem on this part as the content was not planned and discussed to end user and it was a disaster during transfer.
2. Defining training plan. Though it is related to first point, I have seen problems on this part also, as users take time to get adjusted to new environment. I have seen in couple of projects where this part was planned poorly and it was a nightmare for project manager as project team was expected to be released.
Please login or join to reply