Requester or Implementer who should raise Change Record?

ITIL Experts share updates and answer questions
Post Reply
vikaspanse
Newbie
Newbie
Posts: 1
Joined: Mon Feb 25, 2019 4:14 am

Mon Feb 25, 2019 4:21 am

Hi,
In typical operations where both Application and Infrastrucutre teams supporting the environment.
If an application is not performing as per expected level and needs a memory upgrade on a Server.
Who should raise a Change Request in system?
Is it application team who will have outage on system and need to do pre-post check after during change and coordinate with business for outage approval
Or
Is it Infrastructure team who will bring down server, upgrade memory and then bring server back

In this requester is application team but change is fully implemented by Infrastructure team in coordination with application team.

who should raise Change request in system and present it to CAB?
is it Requester or Implementer?


User avatar
Corde Wagner
Itiler
Itiler
Posts: 9
Joined: Fri Nov 10, 2006 7:00 pm
Location: El Dorado Hills, California
Contact:

Mon Feb 25, 2019 8:40 pm

This is an age old situation and question that I've asked and been asked. As with many things in change management (now in ITIL v4, the Change Control practice), the answer is: "it depends". As with many things in the Change Control practice, the answer is: "it depends"

Scenario #1
1. Degraded performance is identified, incident is created (monitoring or by human)
2. Infrastructure team gets the incident and identifies that more memory is required to resolve the issue
3. Does it meet the definition of an "Emergency"? for sake of discussion, "no", then it can wait until next maintenance window
4. Is the server "clustered"? For sake of discussion, "yes", the work can be performed during the next maintenance window and service won't be interrupted as they bring down individual nodes to add memory
5. Infrastructure created the CR and ensures it's approved
6. Infrastructure works with Change Management to schedule work during maintenance window
7. This can now be considered a "low risk change", so the CAB should not have to review

Scenario #2

1. Degraded performance is identified, incident is created (monitoring or by human)
2. Infrastructure team gets the incident and identifies that more memory is required to resolve the issue
3. Does this meet the criteria of an Emergency? For sake of discussion, lets say "Yes". As an emergency, the change cannot wait
4. Depending on Emergency Change procedure, in this example, we'll say the infrastructure team must first get a verbal approval from the appropriate Change Authority (it can be the Change Manager, or perhaps an "Emergency CAB (ECAB)).
5. Is the server "clustered"? For sake of discussion, "no", therefore it cannot be performed by updating one server at a time and therefore service will be interrupted as they bring down the server to make the upgrade. Special consideration needs to be given to notify impacted users or customers, etc. Follow the Emergency Change procedure
6. Change Authority approves the Emergency Change and the Infrastructure team performs the work
7. The Implementer from the infrastructure team creates the Emergency Change Request (ECR) after the fact, and submits in for review/approval
8. Depending on local Change Management policy, the Change Manager can bring the ECR up for CAB review as part of the standard CAB agenda.
9. If approved and then agreed to by CAB, the CR is resolved.

In the above there are many variables that would or could be taken into consideration, but the two scenarios do provide a fair set of the variables (clustered or not clustered, emergency or not, etc.), which may help you answer further questions. If this doesn't quite get what you were looking for, let us know.

Cheers,

Corde
Corde Wagner
ITIL Expert & CASM
Post Reply