10 Lessons from Delivering Technology Transformation Programs

I wrote a blog in 2010 about lessons learnt while working on several back to back technology transformation programs. Most of the lessons listed are still relevant, hence thought of sharing it with wider audience. This article is a reproduction of my original blog with refreshed content wherever applicable. Original blog is referred below.

Technology vendors are continuously innovating and releasing products/platforms more often. It is essential for the enterprises that are leveraging these technology platforms to continuously evaluate "risk of running" their business on an old/outdated/unsupported platform or technology. One of the outcome of such risk assessment is to initiate a technology modernization program.

Technology Modernization Initiatives are Different than usual BAU Projects

Technology modernization (upgrade/migration/transformation) is one of the necessities of today’s IT world, moreover, these programs are quite different from usual functional enhancement projects or business initiatives.

The scale of change for Technology modernization programs is massive and more importantly it is difficult to get a single Business/IT stakeholder that provides you with the detailed requirements. Many a times requirements are one liner – “we want to upgrade our application server from version 10.x to 12.x” !

Few call them Technical or Non-Functional projects, because there is no one involved from functional/business side to guide the initiative or even clarify your doubts. Others call them IT only projects, as their benefits are not directly visible to the business users.

We have faced a practical problem where project managers themselves find it very difficult to prepare a project plan for such initiatives because they don’t find phases like “Requirement Gathering”, “Design”, “Build” etc fitting into it or vice versa.

Nevertheless, these projects are quite different and have their own set of challenges. The usual time ratio spend in various lifecycle phases no longer holds true here. These projects may not have a huge build cycle but will surely have a long test cycle. Given the nature of these programs, architects play leadership role in such initiatives.

Lessons Learnt

Between 2009 to 2011, I was part of multiple such initiatives where we upgraded literally everything – from Operating system to Database system, Middleware platform to Integration technology, Build & Release processes to Deployment architecture - everything was modernized except end user functionality (we had separate initiatives for them :-))

The challenge was to manage such a massive change within given time frame along with “important” business initiatives without impacting them. Based on those experiences I have tried put down my learning.

• Never go big bang

 You need sufficient time to play with the new platform/technology to understand the impact of the larger rollout. Never try to conquer entire piece of puzzle in single move. Always divide your initiative into at least 2 parts - Pilot & Actual Upgrade. If possible divide the entire initiatives into multiple phases by logical grouping of components or impacted business.

The best practice that I learnt is to always pick peripheral and non-business critical components first and build your confidence with new platform/technology. Once you have sufficient experience in going through the entire lifecycle, you will be in better position to adjust your subsequent journey.

• Prepare for co-existence of existing and new technologies

This is specifically critical for large transformation programs with huge impact on exiting IT landscape. Dividing an upgrade into multiple releases means that you always have to prepare for the co-existence of existing and new technologies. It is also important in case you have to de-scope certain items from your original plan due to factors not in your direct control. Planning co-existence or co-habitation of old and new technologies means you will enjoy flexibility of playing with scope and will be better equipped to handle risks originating out of the program.

• Form a cross functional (system) team

You are lucky if your system is abstracted out intelligently so that upgrade doesn’t have any impact across other interacting/interfacing systems. However, I found it rare true and most of the time you see that any such program ends up in impacting most of the interfacing systems as well. Having a cross functional & cross system team would give you cushioning in case you run into cascading impact on the interfacing systems.

• Always devise a Rollback Strategy

As they say, "Hope for the best but prepare for the worst" - it is always wise to rehearse a rollback scenario in case of unforeseen issues once you go to production. It need not be your mistake but sometimes new products/technology have certain undiscovered bugs which you discover only during your last days or even after going to production. Having a rollback strategy will help you manage such risks. You can also see this in conjunction with the "Co-existence" strategy.

• Build automated Regression Test suites. 

Testing plays important role in technology upgrades. First, you won’t find a usual business user who would do acceptance testing for such initiatives. Secondly, you would need to execute the cycles multiple times whenever you make a fundamental change in the system. It is always wise to invest in automation of tests so that you can leverage benefits in multiple such initiatives. It is advisable to invest in upgrading/enhancing regression test suites during or even before pilot phase.

Always plan sufficient time for business acceptance as well.

• Remain one step ahead of other business initiatives

A common scenario is to wrap technology change initiatives along with a business initiative. There are several reasons for doing so but most important one is securing budget. It is easy to add some delta cost to a business initiative to also upgrade underlying technology. However, such bundling of initiatives put a huge risk on business initiatives. If you really want to piggy back upon some business initiative, you should finish your technology transformation work before changes for the business initiative starts. You would be really amaze to see how other projects teams help you in identifying corner issues that was almost impossible for you to find and test. Apart from that it drastically reduces effort & errors of re-conciliation and provide you plenty of time to monitor the system, while others are using it. And most importantly you can better manage risk on your business initiative.

• Automate, Automate, Automate

There is no limit to automation. While DevOps is a fundamental to such initiatives, but you can go beyond just the build and release. Your system is always built around some recurring code patterns. When you discover a change, most likely it has to be applied at multiple places. It is always advisable to automate such find/replace kind of patterns.

• Setup your own continuous integration and validation environment

This is very obvious step. While you are making changes for the target platform, you need to ensure that it has not impacted any working functionality. You should plan for additional environments for such programs. Setting up of a continuous build & integration environment always helps you breakout from the usual release calendar and upfront test your system.

• Don’t forget supporting stakeholders

It is very common to concentrate more on the functionality of the component to be upgraded/migrated and in this process losing sight from other important but supporting processes. The impact analysis has to be holistic. It should take into account impact on all of the supporting (operational) processes e.g. Release or Patch process, configuration management, system monitoring etc. We often overlook such areas while focusing more on the application run time.

• Create a change Rollout strategy

Though this lesson is listed at the end but this is probably most significant in the chain. It is important to create awareness of the change at quite early stage of the program. Try to create multiple touch points with the impacting stakeholders and engage them in the process of transformation. They should feel part of the process and ensure that their concerns/suggestions are taken along. The change would be much smoother when stakeholders feel part of it. Secondly, it is important to thing beyond technology - it is important to benchmark your KPIs before and after change to objectively call out benefits. It goes long way in justifying investments and ROI.

Conclusion

Learning are always context sensitive. Though I am sure that many of the lessons listed above will directly apply to your context but always take these learning with pinch of salt. In mature enterprises, you will find well defined processes for selecting and adopting technologies, whereas in relatively less mature enterprises you may have to consider additional guardrails.

Credits

Delivering successful transformation programs require a great deal of team work. These lessons originated from a great team. I may not remember all the names (almost 9 years now) but would try to recall as many as I can. Please do not feel offended if I missed your name as it is not intentional but just a side effect of my fading memory. The names are in no particular order:

Stefan Mampaey, Sunita Mizar, Puneet Sahani, Nakul Bhuwalka, G.K. Sriniketan, Gaurav Giri, Siddharth Dubey, Akhil Gupta, Rishi Ahuja, Amit Bansal