Standard Change Types \ List of....

[PB]

Hi All....Happy New Year!!

Hope you can help with a query...!

I am implementing a change process & need some guidance on what classifies as 'Standard' change....?

Just to clarify & without wanting to teach you to suck eggs etc, etc; what I mean by 'Standard' change is - low \ no risk, repeatable, understood, pre-approved changes. Activities that are pre-approved as required but simply need capturing to understand all change that occurs.

I am trying to clasify this by technical stack \ layers .i.e:

- Application (depends on the company although some could be common).
- Database
- Telephony
- Network
- Server
- Mainframe - struggling with this one so any assistance (I owe you a pint!!)
- Desktop

Is there a list on the web that you know about...?
Have you got this list as a generic list, not company specific that could be shared?

(Can't be the only person to be attempting this...!)

Hope you can help, any questions please ask.

Thanks & Regards,
PB

[Diarmid]

I'm not able to answer your question because I have a very different perception of what should be a "standard change". Well, actually, I don't like the term at all, because it gives a false impression of meaningfulness.

First and foremost, I don't accept that a change can be pre-approved. Ever.

What I would accept is that there can be a change type with well-defined criteria that can go through a specific approved approval process rather than the generic/universal change procedure. In other words approval criteria and authorizing persons can be pre-identified. It is still a formal process and it is still subject to change management. At the very least scheduling needs to be approved in the context of what else is happening, and I would go a lot further than that.

I'm also not convinced that such changes are necessarily low risk, although most will be in all probability. It is perfectly possible to defina a specific process for managing a repeatable change irrespective of the risk level.

I'm also not sure what benefit there is in categorizing "standard changes" by "technical stack \ layers". Many changes will not fall easily into such categories and even more changes will have impacts well beyond these boundaries.

Is there a benefit in looking for "standard changes" at all? Is it not better to simply identify candidates and document them as tey pop above the parapet. Why not clearly define (for your organization) what is meant by a standard change, how its management procedure should be designed, implemented and reviewed (all this is necessary policy), and let people come forward with proposals. Do not use examples as a substtute for definitions.

The list you seek is unlikely to exist and even less likely to be useful. There is nothing generic when you try to bring the wooly concept of "standard change" up against a set of real requirements.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[UKVIKING]

To add to Diarmid

Here we bring all changes to the Change board

if the change is to be done multiple times - ie a data fix or a piece of work where every thing is constant - same plan, same process, same b/o, well documented and done successfully multiple time, then the CAB decides if it warrants being 'standard'

The thing is - that all the required documentation is still done, the CM and the core people get notification -
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[aballester]

in my organization one thing that has helped us with identifying what "standard changes" are is with our implementation of risk scores. All change requests have a tabulated score of 0 - 21. Those that score 0, are processed without formal CAB approvals. Our tool sends out a notification to me that a risk0 was processed, and I can review to ensure that the change request was properly documented. With this information, after several months, was able to devise a short list of weekly/daily change categories based off of all of the risk 0 requests processed in a 6 month period that are deemed "standard".

[Diarmid]

Just a small point: the use of the value zero in your system could lead people to the cosy, but erroneous, belief that there are changes that involve no risk at all. There is always residual risk because a change that cannot possibly go wrong cannot possibly do anything of value.

These low risk changes still require to be managed and, in my view, require specific procedures written to govern how they are actioned.

May I repeat that to confine "standard changes" to those with minimum risk is to lose out on considerable benefit.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[himanshusri]

We do have a concept of pre-approved task list in our organization which covers system changes that support team can take up without getting into change management process.

Frankly I also don't agree too much with this but it is a trade-off between resolution time vs risk and practically unavoidable.

Most of the cases are related to parameter changes, small organization strucure additions etc..

[Diarmid]

So your support team are judge, jury and executioner for thse change tasks.

At the very least you would want them to understand that they are performing change management when they make their decision. They need to be consciously considering consequences, risks and who should be consulted/warned. They also need to be recording their actions. That would be a change management process.

It's one thing to balance risk against speed when speed has benefits; it's entirely another to let people think "hang the risk, I know what I'm doing".
It's also another to assume that the risk is constant for the same task, no matter the specific circumstances.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718