Technology Transformation: Do’s and Don’ts
Published On -
Quaero passed a major milestone on May 11th, 2020. On that day, we literally pulled the last plug out from our data center and completed our migration to the cloud (AWS). The accompanying picture memorializes that moment.
It has been a remarkable journey over the last few years as we have successfully stayed ahead on the technology curve to support our customers, built a world class Customer Data Platform (CDP) and simultaneously transformed our internal processes.
Getting the pace of technology change right to manage our clients’ customer data was tricky. Our clients have to cater to their consumers’ behavior and preference along with complying with industry regulations and privacy rules. As a strategic partner, we had to bring appropriate solutions to our customers, constantly innovating to transform technology, improve efficiency and reduce operational cost.
The timeline below highlights the major technology transformations we have gone through in the last decade.
The learning from these transformations has been incredibly valuable, sometimes painful but necessary, and rewarding for our entire team, who have had the opportunity to constantly learn new skills and stay abreast of the latest technology trends
Apart from the technology, there is much I have personally learnt through this journey and feel is worth sharing:
Have clear business objectives outlined and socialized with your business and technical stakeholders (both within the company and at the client) and get their buy-in. Keep people supportive of the organization direction close, but keep the naysayers even closer. Understand their perspectives and watch for signals that may potentially derail a project.
Budget and TCO:
Define total cost of ownership (TCO). It may include software licenses, annual maintenance, ongoing operations cost, including people and infrastructure, hardware, cost of implementation, and potential savings from discontinued operations. Don’t buy into vendor’s sales pitches on TCO and idea of zero cost of ongoing resources to maintain an environment. Verify these independently, by talking to real customers who have had the experience
There are choices when it comes to new technology. Evaluate vendors and conduct POCs with a defined use case for a time bound of 4-5 weeks max, to finalize a vendor and learn the technical nuances and pitfalls.
The use case should include urgent and/or high priority business objectives, technical considerations and support considerations. Be prepared to document technical details of your current environment such as size, data volume, no. of users, query patterns, data complexity. The more prepared you are, the better outcome will come out of the POC.
Scoping and Planning:
For migration projects, consider a plan with 40% design, 30% migration/development, and 30% testing as a general guideline. Most design items are related to testing complex logic on new tech, validating rules, refactoring code, and testing performance. Have clear visibility on these items prior to developing a project plan. Don’t spend time developing a detailed plan until the design phase is ready because most likely it will change.
Avoid “agile planning”. It’s a myth. Planning needs to be a waterfall, but the execution needs to be agile. You need to have a plan with a gantt chart of epics, tasks, dependency, resources and dates.
Define success criteria, roles and responsibilities, and articulate them clearly within the team
Identify the right resources, aligned to roles and responsibilities, with the right skill set. While your team may be able to handle most of the technical work, you need someone who has deep expertise on the new technology. Deep expertise means someone who has made a living working on that technology. Engage a managed service provider, if they are available.
Prepare for Project Delays:
This may sound strange, but it’s real. The question is not whether the project will be delayed, but when. The key is how early you can detect the delay, so you can adjust the execution plan and communicate accordingly.
Resist the temptation to add more people to mitigate the delay. In most cases, it doesn’t work. On the contrary, it may frustrate the existing team as they need to onboard new team members while working on a tight timeline.
Plan for ample time for parallel environments and have end-users engaged to validate in both environments. In addition, you should set expectations with the business for a variance between the two environments. It is unlikely the result from both environments will match 100% due to many factors. Setting this expectation early, will help smooth acceptance later on.
Prepare for a go-live day:
Schedule go-live over a weekend or long holidays to minimize business impact.
Plan the team on a rotation basis, round the clock to support migration and validation
Align the project manager, account manager, product manager, and executive sponsor to communicate internally and externally to the right audiences. The communication format should be well structured and appropriate for each audience, to minimize confusion or misunderstanding
Don’t forget to celebrate!. Take a few days break before bringing the team together for a retrospective. There is usually plenty of feedback. Listen to them, acknowledge them, document the lessons and remember to incorporate them before the next project.
During the project, remember to set aside some time for fun, try and keep the team in good humor and keep motivating the team. At the end of the day, this is just software, so don’t let it overrun your life.