Re-opening Change Requests

[MG_ukexpat]

Hi all,
First I must say this looks like an excellent site, glad I found it. I am new to Change Management and have come across an issue that I am unsure on what stance to take. The history is:

1. A testing Change was opened, implemented and closed for a particular application v. 5.x.x
2. A Prod change has been opened to implement this change into production.
3. Now since then a new Service Pack has been released v.5.x.x (SP2).
4. The initiator doesn’t want to create a new testing rfc for this, just to re-open the original one and add this in.

My question is, should we be going back and re-opening Change Requests for this or should I stand my ground and make them open a new one? My thought is that once an change has been closed we can’t let people go back and re-open them without a very strong reason to do so.
Thanks.

[DYbeach]

New change request.
How can you report on what happened in a closed change request if you then open it and use it for something else?
Really, how long does it take to create a new RFC? Can they copy it off the old one?
Tell them suck it up, Princess
_________________
DYbeach
ITIL V3 Release, Control & Validation,
ITIL V3 Operation SUpport & Analysis
PMI CAPM (R)

"In times of universal deceit, telling the truth will be a revolutionary act." George Orwell

[Diarmid]

A request is a request. It is not something that can be opened closed reopened.

The fault lies in how you are dealing with the new Service Pack. Who authorised it to be implemented without taking into account other current change activities?

your scenario is simple:

1. a change is tested
2. a service pack change is requested
3. a) decide to schedule the SP change after the other change(s) is/are completed.
or b) implement the service pack, and go back to the beginning with the other change, revalidating, scheduling and testing; i.e. open a new test change request.

Perhaps you need to look at the degree of separation between tests (involving test changes) and the changes that require them?
_________________
"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

[SubbuA]

Well - nice question and happy that you asked......

Please bang the person who is reluctant to open-up a new CR for this one...

I am to blame the person planning implementation for this new version release.... but that generally happens - a product gets releaed and a service pack follows....

new CR for each one mate

Regards,
Subbu A

[Al_Rel-EZ_Al]

Hi MG_ukexpat,

Yeah I understand your dilemma. I have been putting together a system of my own to handle Database Change Requests and automatically applies them etc... and one of the issues I have is the consideration as to how much flexibility I am allowing people to edit a change. Eg :- when a change has been applied, can it EVER be opened/edited again? From an auditing perspective, to me that's a "HELL NO!"

But then we ask... what if a mistake was made in the process? etc etc

Anyway... the position I have decided to take is that once a change request has been fulfilled it is then closed off and if something similar needs to be applied, we allow
1) a PROMOTION feature which allows the SAME change request to be propagated to another environment, say from PROD1 to PROD2 also, or TEST to PROD etc
2) or allow them to CLONE a feature so that a SIMILAR change request could be made, saving the end user the hassle of writing all the same stuff again, but allowing all fields to be editable so they can modify anything they want.

Finally to tackle the 'mistake' that happened in the process but now closed... I'm allowing a CLONE with a BACKLINK, ie saying that this Change Request was a result of another previous one.

So that's where I am heading at the moment... wouldn't mind some feedback on the process.

Cheers,
Al_REZ_Al

[DYbeach]

Maybe if you explained why using the same RFC is not appropriate, then you would not get this question (who am I fooling?)
You are capturing authorisations to change a CI. Also you are recording evidence that certain pre work has been done - the work has been approved to be undertaken at a certain time and within other constraints. Various preparations have been done - planning, sign-offs, risk and impact analysis and mitigation etc etc etc.
Also, you use the RFC to measure success, effectiveness, efficiency and the rest of it.
If you have a closed change request, and then open it to track a completely separate piece of work, your metrics are not worth a pinch of the proverbial. And remember boys and girls, metrics are all about the bottom line.

However, there are several ways you may wish to help your client base to lessen the unbearable pain of creating change requests.

For example:

You can create templates which pre-populate new change requests (if your tool has this functionality)

You can use pre approved changes (standard changes) but this needs to be controlled appropriately and you need to be prepared to take an active role in administering this.

In the case of changes where the SDLC has been applied, you may be able to link tasks such as unit testing, system testing, QA etc to the one record. However you need to design this carefully in order to actually simplify rather than over complicate the process.

What does everyone else think?
_________________
DYbeach
ITIL V3 Release, Control & Validation,
ITIL V3 Operation SUpport & Analysis
PMI CAPM (R)

"In times of universal deceit, telling the truth will be a revolutionary act." George Orwell