In this second part of “Data Center Transformation and Transition made easy,” Ljiljana Katchkin, one of our senior program managers in the Capgemini global Data Center Transformation team, continues to outline some of the nine key steps to address in order to ensure a successful Data Center Transformation and Transition project.
Step 3—Establishing a sense of ownership & managing the blame game
Most DC Transformation and Transition projects risk coming to a standstill just a few months into the project and the key reason is the large number of resources and third parties involved in this type of projects. An obvious mitigation is to avoid having a large number of contractors involved and instead source as a project with one DC Transformation and Transition party responsible to lead and manage the project. In reality, however, there are still many parties involved and obstacles to remove for the project to run smoothly.
I recommend a number of activities from early on in the project to create a sense of ownership and commitment, targeting both the project team itself, the client stakeholders and key third parties as well. This is easier said than done; clarity and honesty across all communications channels are essential components of a successful communication strategy. Combined with a correct governance set-up, with regular progress updates including financial analysis and updates of any key decisions and activities plays an important role in creating that sense of ownership. It comes down to creating KPIs allowing all parties working together towards a common goal, succeeding as a team as well as failing as a team.
A framework focusing on creating a sense of ownership and common goals should typically include the following components:
- Clarity—by providing clear directions and clear expectations on all involved.
- Honesty—a typical transition project tends to expose the shortcomings of the legacy solutions, a consequence a chain of decisions taken over many years. Honesty and avoiding a blame game is essential to encourage existing support and operations staff to come up with innovative workarounds and fixes to ensure a risk free cut-over whenever needed.
- Standardization—supporting the planning and execution teams with standardized templates, enabling an approach of reusability. This will lay the foundation for a more industrialized and quicker migration, with less effort.
- Communication—constant communication to all relevant stakeholders and the project organization is a necessity, both from a governance perspective, but more important from a stakeholder management perspective. When pushing for hard and difficult changes, clear and unambiguous communication is a key success factor.
This may sound like nonsense, but when forcing so many people out of their comfort zones, a strong team spirit and clear understanding and acceptance of what needs to done will carry you a long way towards a successful project outcome.
Step 4—Securing the right skills, in the right place, at the right time
Most successful Data Center Transformation and Transition projects put an emphasis on governance and planning, which is necessary to avoid delays and a negative financial impact. Done right, migration execution is a very precise operation, executed after business pre-approvals during a very short time and with no surprises. It involves many people with multiple skills and from many different towers and organizations.
To ensure a smooth migration, less than 20% of the time is actually spent on execution. The majority of time is spent on planning and preparation. A big part of that work is about identifying the right skills needed at the right time in order to ensure a successful migration and cutover for every individual change migration batch. By doing so, you will be able to:
- Secure a controlled execution with the right skills in each area
- Ensure successful cutovers
- Reduce risk of rollbacks
- Minimizing negative business impact
- Eliminate the need for “fire fighting” after the cutover
- Maintain full control of the costs
- To ensure a happy client.
Adopting such an approach requires a fair amount of analysis, verification and planning before even commencing the execution of the first migration batches. However; lengthy preparation times are not always easy to explain in a legacy environment where the desire to move at a fast pace is high and tangible results are required on a daily basis. This is where many DC Transformation and Transition projects go wrong; the desire to quickly start the execution leads to 80% of the effort being spent on execution. While that may sound like time well invested, usually it isn’t, because these projects typically experience problems such as:
- Lack of control over execution
- Numerous rollbacks
- Extended down time and service window breaches, with negative business impact
- Constant business disruption and extended “fire fighting” post cutover
- Difficulty maintaining costs and achieving the benefits defined in the business case.
In such a scenario, maintaining a happy client is virtually impossible. I recommend applying the 80/20 rule in terms of planning vs. execution. It will result in better control and higher quality, avoiding uncontrolled cutovers and unplanned downtime for the business. By doing this, you will be able to optimize the use of resources with the right skills in any given phase of the project, resulting in a favorable result.
Step 5—Establishing flexible and fit-for-purpose governance
Fit-for-purpose governance is important in all projects to deliver on time and on budget. Data Center Transformation and Transition projects are highly dynamic and involve many different parties, more so than most projects. Any governance model put in place must be flexible in its approach, while offering the necessary rigidity and control needed to protect scope and costs.
Typical Transformation and Transition projects are characterized by a challenging legacy infrastructure, application owners reluctant to commit to transformation or transition of their applications, outdated documentation and CMDB data, if available at all. Migrating individual systems are not difficult per se; it’s the dependency mapping between applications and systems that requires attention. By identifying migration batches, “first-time execution” becomes easier, minimizing extended downtimes and fire fighting, while building the confidence of the business community.
My recommendation? Set up a governance model that caters for flexibility in terms of allowing for handling of “quick wins” and migration of well documented systems as early as possible in the process, but rigid enough to enforce control and an ITIL compliant Change & Release Management Process. This will allow well documented and standard change batches flow through the Change Control Process with little effort, while spending more effort on complicated change batches and systems. In practice this means establishing regular Control and Approval Board (CAB) meetings, with pre-approved standard migrations, GO/NO-GO meetings, clear escalation routes and emergency CAB sessions, etc. Combined with the normal steering committee meetings, weekly project planning meetings including regular and accurate progress reporting, this caters for a clear ownership and less blame gaming. Done correctly, it fosters a “One Team” project culture and team spirit.
By standardizing templates and documentation packs, CAB meetings enables each change migration batch to go through a familiar standard approval process, including pertinent information for each migration, such as:
- Detailed cut-over plans
- Clear task ownership
- Clear task duration
- Detailed roll-back plan
- Detailed communication plans with check points and GO NO-GO meetings.
Using this approach, we avoid roll-backs and fire fighting post cutover, while securing the timelines and budgets. By building up the business community’s trust in our abilities to deliver, as the project progress we can gradually start to address more and more complicated change batches with the business community’s support and sponsorship.
In Part 3, the final part of this series, we’ll take a closer look around standardization and industrialization, using a one team approach, which helps secure the migration cut-overs.