What you are actually doing is passing the responsibility of approving a change to the line manager and the responsibility of approving the release to the CAB.

ITIL tells us that change, config and release are closely integrated, which is why change process flow diagrams always have an element of release in them because you can't implement a change without release management, no matter how small.

ok thanks for your comments.
I have a question regarding authorization.
According to the post from UKVIKING the flow has only one authorization step (Filter Prioritize classify assess authorize build implement work?) does this mean you have 2 authorization steps in a row? For example the line manager authorizes the change in terms of feasability, resource availabilty and budget and as soon it gots approved the CAB also needs to authorize it?

one further question. I'm a bit confused regarding the terms 'categorize' and 'prioritize' in comprehension to the approval steps. I mean both terms are right now not clearly seperated for me.

I understood that the category determines who has to approve the request.
E.g category = standard --> no approval neccesary

but how does the priority (urgent, high, medium, low) fit into this picture?

Additionally I understood that the CHG Mgr is responsible to set those values e.g. category = normal, priority = medium)
But I can imagine that this can be quite hard to determine what the correct values are since the CHG Mgr usually does not have that much insight knowledge regarding the change.

Filter means determine whether the RFC is a RFC
Categorize means put the change in the right (your right) association you use for a type of change
Prioritize means the change should have some sort of classification as to priority// urgency etc

I have the ITIL book infront of me together with some other books and ITIL PowerPoint workshops. The point is that the terms:

- classification
- categorization
- prioritaziation

together with Normal, standard and emergency Changes are often used differently respectively not consistent.
I'm looking for sharp distinction between those terms and then a statement on how all those combinations will affect the approval / decision flow.
e.g. immediate priority --> emergency request etc ...

They are used differently by different people and in different contexts because they are generic words and not technical terms.

Classification and categorization have a considerable overlap of meaning. You just have to decide how you use them consistently within your organization and you have to treat them in context when talking to the wider world.

The purpose of classifying or categorizing things is to help to control, understand and analyse entities and events. So you set up classes or categories to suit your purpose.

Prioritization is a more specific word which, properly, is used to indicate how you decide which of two or more tasks to perform first, given a conflicting need for resources in the execution of the tasks. some people have labels like "urgent", "emergency", "normal", back burner" for priorities and then they call that a classification or categorization of the change. This is especially likely if they have different change protocols for the different priorities.

So it is easy to get confused if you do not keep in mind what the context is.

It gets even worse when software (like helpdesk software) insists in using these labels (class, category, priority) with specific attributes and restrictions within their system._________________"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

Prioritization is a more specific word which, properly, is used to indicate
It gets even worse when software (like helpdesk software) insists in using these labels (class, category, priority) with specific attributes and restrictions within their system.

Diarmid I know you know this, but I'll state the obvious anyway:

It's all about the doing things in the right order; run your projects correctly and start with requirements gathering, rather than seeing what a I product will do for you. Gets me madder than a bag of cats every time I come across bad PM.

Interesting discussion.
Andy,
I would propose you keep strict on the definitions in the ITIL book.
You may define your own terms and/or definitions of change blablabla but in broader events the understanding of the book will help you speak with people.
I can speak alot about change classification, categorization, prioritization but that would mean I'll be dragging you into my world, as I'm sure other posters would think the same, that it's not right.

Sorry I did not get involved sooner, but I have been on my happy holidays.

The flowchart referred to in Andy's initial post is mine from a manual paperbased system. The Release side of life is far from perfect, but did allow for release into live. We have moved on since that was posted and it is not a fully mature process

I, with the other posters, would encourage study of the books to ensure that you understand the subject fully. One of the biggest areas of misunderstanding comes from the difference between a Categorisation of Emergency and a Priority of Urgent._________________Regards