Who Raises the RFC - Tech Teams In Dispute!

[Helen]

We're having an issue in my organisation at present with regards to who raises the Change Request. The scenario is this.

There are three divisions. Two IT 'business' divisions, and one 'central' IT division who manage the infrastructure and datacentres across the org.

Essentially, the two business divisions encompass all of the application IT support & projects, and the central division supports the infrastructure across the piece. All in house.

Very often, the business divisions (IT application support, projects, service management, service desks) are requesting changes which the infrastructure teams are the implementers on. However the business divisions argue that they dont have the technical detail to be able to raise the Change Request.

Our process dictates that whoever initiates and owns (requests) the Change, raises the Change, and the implementer updates the record in a draft format, with the technical implementation plan etc. The request is passed between the two areas before its submitted for approval.

The only exception is when the Change is incident related, whereby the incident has been assigned to the infrastructure team and they raise the change to fix the issue (if its their kit that has failed in some way).

We understand that Change Requesters can also be implementers. Most of our application change is raised and implemented by the same team. However when there are two different technical areas involved, who has overall responsibility to raise the change request. Does ITIL give any guidelines on this?

[UKVIKING]

Helen

No. ITIL Does not really care about this.

This is an issue that irritates all

The only real answer is that it depends

Let me tell you how I allow it

First, what kind of change is being requested

The network people raise the network changes
the system people raise the system change requests
etc etc

If there is a major change that involves a set of services and disciplines, a Project mgmt type raises the change request.

The change request is a container - which may have several related pieces of activities
Deployment request / tickets for non production
tests for nonproduction
deployment tickets for production and DR
etc
documentation etc
and of coruse the CAB data - the meeting it is disucessed, the approvals of the members, the approval of the board etc

then the change itslef has a lifecycle
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Helen]

Hi John,

Thanks for taking the time to explain your process. It makes sense in many ways & would certainly simplify the process of raising changes for the teams (even though our infrastructure teams prefer the current method as it cuts their admin!). However, when you have one organisation but multiple businesses, how will changes to be attributed to the correct driving area? For reporting purposes.

Because if infrastructure raise their own changes, which have been requested by one part of the organisation, that work, the resources, the costs, are all logged against the Requesters department.

I suppose if we have some way of recording this in the tool, it wouldnt matter so much! Business owning group or something.

I did read something that said the Change Requester has "end to end responsibility" for the Change and as such is accountable for confirming that it has fulfilled the initial requirement (including selecting the closure code). Im not sure the implementer (infrastructure in this case) would be qualified to do that for the business division.

Its a tricky one!

[UKVIKING]

Helen,

A change request is for the Change Advisory Board.
The information in the CR is for the analysis and risk assessment of the change against the production environment by the Subject Matter Experts

The change may have work that is to be done by any number of groups - internal, external - using any number of ticket systems that may or not be available to the change presenter per se.

The gauge I use to define the presenter - is the person who presents should be quite aware of what the change is going to do - whether that person is the technical type - ie the Network team lead for a network only change or the system team lead for a system change or a non technical management type - project mgr or mgmt type.

Once the ticket is approved, the change requestor / owner is responsible for starting the process for implementign the change.
Now, if there is a common ticket system that CM has access to, then those tickets would be in the CM queue awaiting approval and transfer to the action queue.

However, everything depends on the policy that has been written for CM
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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