Change Originator/Change Submitter - Who ?

[OBXMAN]

Hello - can someone please tell me per ITIL regulations, "who" is responsible for submitting a Change request ? Is it the department "needing" the Change required, or is it the technical party performing the needed Change(s) ? If you can provide book, chapter, verse in ITIL regulations also to back up your response, that would be greatly appreciated. Thanks in advance!

[rpmason]

ITIL regulations. First, ITIL is a framework not a regulation.

Section 8.5.2 of the V2 Service Support book says, "...all members of the organization be authorized to request changes."
_________________
Ruth Mason
USA

[OBXMAN]

Thanks for the response Ruth - do you know section that deals with this for ITIL V3 ?

[Diarmid]

OBXMAN,

I think you missed the thrust of Ruth's answer. ITIL has no opinion on who can be authorized to request a change. Best practice would be to ensure that no change was proceeded with unless the requestor had proper authority for its scope.

At the simplest level there are customer initiated changes and service initiated changes. The customer (not the users) will determine who is authorized to request what from his/her organization, IT services will have policy statements defining who in IT can put forward what kind of changes. The CAB (consisting of customer and service management personnel) will ascertain that the requestor has authority to make the request.

ITIL goes as far as indicating that change requests need authority, but there is no such thing a s generic model for how authority is set up in any particular organization.

Specifically, for your question, whether a customer representative completes a formal change request document which is put into your change system or simply sends a (signed and dated, of course) note to someone in IT, that customer representative is the person who has requested the change and it matters not a jot which way it is done so long as it follows your properly designed and agreed process.
_________________
"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

[noneforit]

In my opinion, it is down to how your business works and what kind of information you want in the change.

We use a Virtual CAB so relevant and specific information is vital in each RFC otherwise it gets rejected.

Our system owners (outside of the IT department) are not allowed to raise thier own changes.

The information contained within our RFC's is very important to the Incident and Problem Management processes, hence the need for good information conatined within them.

If you think your business are capable of raising a change request, let them
If you would prefer the technical teams to do it then go down that route

As mentioned earlier, ITIL is a framework, adopt it to meet the needs of your business and other ITIL processes

[Diarmid]

It is important to distinguish between a request and the set of information relevant for addressing the request.

Just as much as the business user (customer representative) may not be able to flesh out the technical\ aspects and implications of their request, so the technical team taking it forward may not be able to flesh out he business context from which it emanated. This is still true when the source of the request is from within IT services.
_________________
"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

[UKIT]

In our organisation the RFC initiator is always the IT Services Technical Representative who is responsible for generating the RFC and implementing the change once approved.
Should the proposed change be at the request of the business, the RFC will be generated “on behalf” of the business.
The IT Services Technical Representative works “with” the business to ensure their requirements are understood before the RFC is generated.
The business requestor details are clearly documented within the RFC and will be part of the communication plan.