Change Evolution is 'The Way'

I'm working on a paper, document, anything, (probably just this post now since my schedule is so busy) on something that's been in the back of my mind for a while now, and every time I speak to a new opportunity or a customer I always wished that I had something substantial to leave behind to show that yes, it is possible to achieve the desired future state without pain.

What I'm talking about is how to get from A to Z without pain, fear, risk, or increased cost and time.

'A to Z' is an expression that we all use, but in Lehmann's terms it is getting to the desired future state from the current state.

What is the future state? For example a server migration project of 1000 Wintel servers into VMware infrastructure in 6 months.


So if A is the origin and Z is the destination, then the journey of getting from A to Z is the experience. It is the experience that is all too important. In a project's lifecycle, the primary purpose of a project is to bring benefit to something (an organisation for example). But the experience can vary dramatically. Z can be achieved but at what cost? Z can be achieved but it could take a long time. Z can also be achieved but after how many mistakes, issues and actions that were required to achieve Z?

Is there a way to define the experience? To reduce the amount of risk and unplanned change, to limit the exposure to mistakes and unknowns. To cap the amount of time and cost to achieving Z. 'The Way' then is called a methodology. A methodology is a collection of processes and frameworks which are used to control the execution of change within a project.

So while I’m in a pessimistic mood, let’s go over why there are difficulties from having a comfortable journey:
• Lack of planning
• Lack of clear objectives
• Lack of support and acceptance (See Steve Chamber's Barriers to Virtualisation)
• Lack of risk management
• Lack of a business case or project justification
• Lack of change control


Why is change so feared?

Let's assume that your project justification and initiation are all good and that your project plans, objectives, business case and RAID are all up to scratch and now you are ready to embark on a project that changes your IT infrastructure. Have you considered how you will manage change? Are there push backs from the business or application owners who don't really need or want anything to happen to their precious server due to changing the way a workload is run?

How can you alleviate their fears and introduce controlled change?

So let's take the classic CIO/IT Director from a few years ago at a time when x86 consolidation using virtualisation was still in its infancy (there are those that still think transitioning to a virtual infrastructure is a risk too far). These CIOs had fears around change - change of management, change of skills, change of processes and changes with operations. These fears were prevalent then and are still prevalent now. In my view the main enablers for change are the frameworks that can be used to get from A to Z.

Without change, an IT organisation will never be able to evolve into an IT organisation that has more reliable infrastructure, more efficient processes and more streamlined operations. Those companies that do embrace change and evolve are considered to be the most high performing IT Organisations.

The consensus is basically this: change causes fear, therefore projects such as P2V take forever to do, and without the correct methodology your P2V project could fail before it has actually begun. But by introducing controlled change and then putting the processes and governance in place; the strategy controls, manages change and provides a framework for effective management and delivery of the project.

The barrier to evolution is due to a fear of change, we alleviate this fear by controlling change. Change then becomes the enabler for evolution: please welcome Change Evolution.

So what is Change Evolution?

Change Evolution is a framework that uses ITIL/Visible Ops methodologies to control migration to virtualisation projects. It expedites ROI due to enablement of change management as part of BAU/Operations.

Change Evolution is a framework for delivering projects with

• less Risk
• less Time
• less Cost

How is this accomplished?

1. With baselined standard operating environments (SOE) which are standardised and adhere to strict change control.
   
2. With Standard Operating Procedures (SOP) which are auditable, repeatable and measurable and are strictly controlled. Because these procedures are defined and controlled as part of the framework, it is possible for any member of the project to use these procedures to assist with the grunt work of the project. These procedures enable the 'turning the handle' method of migrations where the migrations are streamlined into the control processes.
   
3. By working closely with the change control board (CCB). It is strategic to keep the CCB on your side, we are not re-inventing the wheel with change boards, we embrace them, but the amount of requests is submitted in a ‘turning the handle’ method in which P2V migrations are requested weeks in advance and each one follows the same migration methodology, processes and SOPs. Therefore these migrations can actually be integrated into operations quicker and with no risk.
   

By using a defined methodology that integrates with the change control processes it is possible for you to 
deliver 
record‐breaking 
project 
successes 
without
 risk 
and within 
strict
 time scales
 and
 budgets and above all with no pain.