Thursday, March 11, 2010

Change Management, Versioning good for technical. ………… Good for managing?

In IT we tend to talk about Change Management as some sort of “holy grail”.  If we can just get Change Management implemented on all technical changes the system will run much smoother.

There is also common accepted logic that when you implement a change you should minimize variables or when multiple adjustments are needed you should roll them into one package / release version.  Isolating these changes allows you to see impact form that change in a direct relationship and roll it back if needed.

This all culminates in a methodical, staged approach to ongoing changes.  Thus allowing you to deliberately take moves and actions, see outcomes, advantages, and problems created by those changes.

You are all saying, so ya we have heard this before, it is a main tenant of many IT organizations.

I want to challenge us as IT leaders.   Are we setting a good example? 

The last time you implemented a new way of managing your staff, did you follow Change Management?
Did you have a version rollout, or minimize variables so you could test your before and after state of your change?
Did you document exactly what you were changing? 
Did you gather before and after metrics as to where you were and where you went?
Do you have a schedule for changes in how you manage your staff?
Do you allow for sufficient time between your changes to see impact and relate it to that change?

Being an IT leader should be a process of continual improvement in skills, and I feel we should have a framework around how we as leaders move this forward without causing chaos to our staff.

Please leave me comments.  Am I crazy?  Will this work?  What pitfalls can you see?

1 comment:

  1. You are not crazy! This is a new twist on an older philosophy. Creative, as always!