I have frequently discussed the merits of finding a proper balance between speed and transformation, when relocating or consolidating your data centers, and which KPIs are best suited to help you govern your data center projects.
Let’s shift focus for a moment, and reflect over the pitfalls commonly encountered in typical relocation and consolidation projects. I’m outlining the most common pitfalls in bullets below, and in my coming posts I will go through these pitfalls in more detail, outlining my experiences and the lessons learnt from the projects I have worked on and how to effectively counter them to ensure the success of your project.
Organization and people
·       Not having a steering committee with clear mandate
·       Using inexperienced staff
·       Not securing enough people from the line (not having dedicated staff)
·       Start big re-organizations within in the  affected line during the duration of the project
Planning and tools
·       Using not fit for purpose tools
·       Running to many big changes in the IT and business organization at the same time
·       Planning the project with a very long execution time line
·       Not understanding the business and its demand on the IT infrastructure
·       Not involve business and service owners
Budgeting and follow-up
·       Using line processes for every single needed investment instead of having a big project investment that the project can dispose over  
·       doing to big technology leaps, like migrating a mainframe to windows
Just to make sure, the list above outlines the things you should avoid 🙂
And, as in any challenging project it is important to follow standard project management routines, with the usual emphasis on reporting, action lists, risk management etc. and maybe most importantly – be available and visible as project manager.
Don’t miss my old posts on http://www.se.capgemini.com/experts/data-centre-consolidation-and-optimizations/magnus-manders
Magnus Manders, Capgemini Infrastructure Services Northern Europe
PS. I believe that everything should be virtualized until proven not possible