Yes, but what about the problems.

Red Pineapple — Mon, 14 Jul 2008 10:46:42 +0000

Most changes are a source of problems mainly because I think the change lifecycle described is like throwing dead cats over the wall. Maybe it is because the lifecycle is not fully described with all the relevant checkpoints for validation and due diligence?

On a seperate point, a major source of changes is failure or degradation in production. These dead cats come flying back over the wall with PostIT notes attached, which results in new change requests. I don't see these types of changes being described?

Excellent idea

skeptic — Sun, 13 Jul 2008 10:38:13 +0000

Does point 3 above address this?

An important aspect of change is time

Red Pineapple — Sat, 12 Jul 2008 15:55:59 +0000

I think the perspective of time is missing. It is not mentioned. Whatever, the view (or opinion) of change it is always about a moment in time and a duration.

Differing views of change

cotswolddave — Sat, 12 Jul 2008 12:11:11 +0000

Hi skep,

Agree with your summary that a) change can be split into the sections you idenitfy and also b) that "change management" may viewed as how the different perspectives are reconciled. Because many get the ITIL religion they fail to realise that there is a bigger world than service management with project and development activities requiring their own type of controls compared to the generic change to production systems.

Without going over the same ground about the CMDB concept, your views may it plainly obvious that the CMDB cannot deliver all the knowledge or information required to support, or communicate all types of change. It's enough of a monster without trying to encompass project and development activities (aka ITIL V3).

My experience of implementing "cmdb like" solutions is that the ones that work for production change control are where you map dependencies between services and their underlying components. Asset control is pretty irrelevant for CAB decision making. Release controls are much the same, its the project teams responsibility to identify risks and impacts. So if you want to implement a reasonable effective change management process for the production environment, and you want to make it easy for all to submit changes, log incidents, report on root causes - then focus the CMDB on service mapping and leave everything else out. Alternatively, we have would to map the organisation, the business processes, the roles/responsibilities, the assets as well as the IT services (which some try to do!) By keeping a tight focus, service management teams can deliver the coordination and controls expected. Shame that this is lost in mass of ITIL V3 messages

Maybe a better view of what change management is, makes it easier to understand what supporting knowledge systems will actually help.

Dave

The IT Skeptic - Comments for "Model of Change "

Yes, but what about the problems.

Excellent idea

An important aspect of change is time

Differing views of change