Since my last post, I've been busy with a lot of things, but one of the most important things has been change management.
The problems I, and most other IT people always seem to face is the constant influx of half-baked ideas from Management filtering down without proper paperwork.
It has always been a policy of mine to not say "NO" to people without giving their problems/solutions serious thought. Unfortunately this takes quite a toll on my time.
This has been a good policy and I'd strongly advise anyone who has Juinor IT staff, particularly helpdesk people, to take a policy like this onboard. Unfortunately, this doesn't work quite so well in IT Management. Here, we need to take a tougher stance.
One of the worst aspects of being proactive as well as responsive to user requests is that it encourages plausible deniability. Users who get into trouble about a project, or change their mind about it, can easily deny having asked for it in the first place. It doesn't matter that you have emails on the subject unless there is one that specifically says "build me a prototype NOW" or "Spend money on this from Cost Centre X, NOW".
So, the new change management process will hopefully address all of these problems. To begin with, I've created a chart that will help us to identify the levels of authority required.
Green for IT and Business Sponsor (Person requesting the project) only.
Yellow for Business Owner (People who "own" the system - and related systems).
Red for the Internal Management Committee
There's a JPEG of the Chart Below.
The idea of the chart is to force IT and the business sponsor to confront all of the main issues surrounding a project/change and determine the overall rating. My theory is that if it falls into the red at any point - then it's red. If it falls entirely into green, then it's green. In all other cases it will be yellow.
Green changes can proceed without significant delays and are simply logged in the change logs.
Red and Yellow Changes will require a memorandum to be completed. The memo basically identifies the project and then has one heading for each slice of pie in the chart above.
The only other additions to the memorandum are;
1. Proper Details of the Change (what it is and why)
2. Implementation Plan
3. Recovery Plan (for failed changes)
4. Signoff - and commencement date
The memo obviously shouldn't be completed entirely by IT or by the Business Sponsor, but needs to be a collaborative effort. Thus far, I'm finding that the process works. The people who are too sad to accept responsibility don't get their changes started (and take up no more IT time) while those who are willing to support their changes are able to proceed.
The problems I, and most other IT people always seem to face is the constant influx of half-baked ideas from Management filtering down without proper paperwork.
It has always been a policy of mine to not say "NO" to people without giving their problems/solutions serious thought. Unfortunately this takes quite a toll on my time.
This has been a good policy and I'd strongly advise anyone who has Juinor IT staff, particularly helpdesk people, to take a policy like this onboard. Unfortunately, this doesn't work quite so well in IT Management. Here, we need to take a tougher stance.
One of the worst aspects of being proactive as well as responsive to user requests is that it encourages plausible deniability. Users who get into trouble about a project, or change their mind about it, can easily deny having asked for it in the first place. It doesn't matter that you have emails on the subject unless there is one that specifically says "build me a prototype NOW" or "Spend money on this from Cost Centre X, NOW".
So, the new change management process will hopefully address all of these problems. To begin with, I've created a chart that will help us to identify the levels of authority required.
Green for IT and Business Sponsor (Person requesting the project) only.
Yellow for Business Owner (People who "own" the system - and related systems).
Red for the Internal Management Committee
There's a JPEG of the Chart Below.
The idea of the chart is to force IT and the business sponsor to confront all of the main issues surrounding a project/change and determine the overall rating. My theory is that if it falls into the red at any point - then it's red. If it falls entirely into green, then it's green. In all other cases it will be yellow.
Green changes can proceed without significant delays and are simply logged in the change logs.
Red and Yellow Changes will require a memorandum to be completed. The memo basically identifies the project and then has one heading for each slice of pie in the chart above.
The only other additions to the memorandum are;
1. Proper Details of the Change (what it is and why)
2. Implementation Plan
3. Recovery Plan (for failed changes)
4. Signoff - and commencement date
The memo obviously shouldn't be completed entirely by IT or by the Business Sponsor, but needs to be a collaborative effort. Thus far, I'm finding that the process works. The people who are too sad to accept responsibility don't get their changes started (and take up no more IT time) while those who are willing to support their changes are able to proceed.
Comments