As discussed previously, the abandonment strategy can be an effective digital transformation approach for those carrying a large amount of unsupported brittle and unstable, legacy technology. Instead of attempting to modify, upgrade, modernize or transform, simply replace with modern technology.
While this strategy makes sense on paper, it comes with a lot of perils. Failure is commonplace for a variety of reasons. execute the abandonment strategy, the following are some considerations:
Firmly anchor on customer needs.
Internal needs e.g getting on new sexier or manageable technology is often the driver.
Your customer may in fact be fine and accustomed to the experience of your application.
Customers and users are generally averse to change. You may roll out something significantly better and newer and they will completely reject it because it is not what they are familiar with.
Understand what their most pressing problems are and ensure that your replacement solution fully address these problems.
Doing this will practically eliminate your eventual struggle to migrate customers to your new solution.
you will get more grace from your users when there are issues. You were after all, solving a problem that is important to them.
Carefully consider the solution.
What does the existing legacy solution do well?
What does it do really poorly?
Should you overhaul the solution or focus on replacing the problematic sections of the application?
What is the right technology and solution architecture?
De-risk the delivery?
Before committing fully to a large multi-year program, it can be very productive to pressure-test your plans and fail fast if necessary.
For critical projects get an objective third party to review the solution, team and delivery plan.
What are the risks/unknowns in the new proposed solution?
Does your delivery team sufficiently balance domain expertise,
Implement targeted proofs of concept to prove out areas with uncertainty.
Identify ways to sequence delivery in order to reduce risk and avoid a big bang deployment.
Do your estimates fairly reflect the effort, cost of the new solution. Don't under-estimate complexity, effort or cost of implementing and rolling out the new solution.
Build a robust retention plan.
Few things will seek an abandonment strategy faster than the loss of key staff.
On the legacy side, loss of staff will mean that a) the things that have to be done to keep legacy chugging along are no longer happening. This will in turn leads to system degradation and outages. b) there will be poor levels of support for customers and employees that depend on this system.
For the new solution being implemented, loss of talent may mean lower quality, lack of ownership, delayed delivery targets which will strain the resources of the organization.
It is therefore important to quickly identify the critical people in both the new and old solution and ensure that you take action to ensure that you don't lose key resources at a suboptimal time.
Ensure stability of the legacy platform.
You may abhor your legacy platform for its failures, But chances are that is still supports or drives your business.
If you don't properly manage your legacy platforms, your transformation plans are likely to fail.
Issues from legacy platforms draw resources and attention from the new platform, prolonging delivery.
Customers that experience increasing issues in the old platform are more likely to switch to a competitor instead of to your new platform.
To ensure stability in your legacy platform,
Document the known fragile areas of the system,
Document the ongoing actions that are critical to keep your platform running smoothly.
Identify the people that are critical for performing those actions,
Ensure a strong team retention plan for the people that are critical for keeping your legacy platform running smoothly.
Stop or significantly slow down any system changes in your legacy platform.
Beef up your monitoring and application testing infrastructure (both functional and performance testing).
Rigorously prepare for peak usage periods. For many organizations, usage is predictable. It may vary seasonally or even intra-day. Using the low usage period to harden the system and prepare for peak usage will keep you from having to react to issues during the critical period.
コメント