By Sairam Bollapragada
In the times of recession where the budgets of CIO/CTOs are shrinking each year and they want to see scissors on all the initiatives, it is not unusual to find clients who would ask for faster and quicker transitions and cutovers. The key here is – it is not quick-and-dirty. The expectation is without letting down the quality of transition, the cost must be brought down. Nothing literally changes from client’s considerations except the crashed timelines.
The following parameters are critical to be factored while thinking of Accelerated Transitions:
- Support Levels and Definitions
- SLA adherence
- Client’s Risk appetite
- Application coverage
- Complexity parameters
- Operational Support Structure and relevant documentation
- Response times for support
- Resource Skills
While all of these need to be addressed, each of these parameters has tricky shades to it. Support Levels need to be understood well before your confidence levels prompt you to say “Yes – take it on!. “
- Support Levels & Definitions are often interpreted by each service vendor in a way for reasons best known to them. The ideal situation is to reiterate the definitions and clear off the expectations so that the deck is set for takeover.
- SLA adherence is also quite tricky – especially if it also comes in with the penalty clause. We should carefully negotiate for the baselining period (usually kept at 90 days period) if baseline metrics are non-adherent or non-existent. If it already exists, you negotiation points hover around the call volumes, complexities, TAT, and the resource skills and capability. Hence most of the times, the senior and more experienced resources are required to be engaged early in the game. Negotiation for a penalty-free period post KT is critical in the above case.
- Client’s risk appetite is something which should be gauged upfront. There are several symptoms that we must watch out for : pressure to let go of current vendor (anti-incumbency or vendor comfort zones?); pressure to bring down the OpEx drastically and quickly southwards; tendencies of let’s do it and if something breaks, we will see; I need to do this transformation at any cost, etc.
- Application coverage support windows are easier to factor into the plans to take over ones which have smaller windows and lower response time needs. The tricky thing here is gap, if any, between the current SLAs and support window versus to-be SLAs and support windows. Thus it is critical to understand the existing coverage versus what the service provider or his sales would have committed or sold.
- Complexity parameters that may exist with changing scenario of an existing business critica; application. If there is a core set of business critical application under transformation and there are strong linkages to the other applications in scope, the interfaces, their impact analysis will provide insight into the way the ticket volumes may move north or south. Any changes (ANY) to the existing applications landscape must be watched and analyzed meticulously so that when you are hit with larger call volumes due to these changes, you have a baseline to reason the change and negotiate the changed scenario. In all such circumstances, it is wiser not to brave into committing for an accelerated transition.
- Operational Structure also plays a major role in the accelerated transition. If the existing operational structure does not allow peek into detailed operational journey of the application, undocumented and unstructured change patterns should be treated as risky items to adventure into. The operational support structure is key since the factors like connectivity, security, applications accessibility; onboarding processes, etc. are primary prerequisite to keep the lights on!!If the structure is near accurate and has every piece of puzzle in place, with info owners, source code owners, version control in place with production controllers, documented change logs, etc, then that is a perfect candidate to accelerated transition, else it is ticking bomb on your commitments.
- Proper documentation of the applications is another thing that should be considered before signing up to take over an application on accelerated mode. Poor documentation renders your knowledge acquisition phase as ineffective. Documentation should be checked for details on technical, operational and domain related contents and briefing. A decent document would narrate the story around these three critical areas and would provide sufficient information which can help accelerate transitions. Tacit knowledge with the client employees can ruin the Accelerated Transition Party as the only way to get that knowledge is to hire the incumbent support engineer so that transition can also be de-risked.
- Resource Skills is the one focal point of success (or failure) for any transition. The positive aspect of this factor is it is dependent on the vendor organization to understand how, when, what and how many of the skilled manpower is required to execute the transition faster and better. The faster the knowledge is absorbed, the sooner the cutover can be called. In the scenario where the vendor is asked to absorb the transition cost, it is in the interest of the supplier to bring in the best (yet optimized) set of resources who can aggressively participate to call the cutover soon.
The eight parameters listed here are quite interconnected and coupled with each other hence they play key role in allowing to assess if the cost needs for transition can be really met.