Bundling change requests

[Hena]

Hi everyone,

I'm in charge of change management at our company and have been approached by a project lead regarding a high visibility project our company is working on. The project has been delayed a few times and so far it seems the potential go live date is in May. Through the project life cycle there have been change requests, but now that they are approaching the end they are expecting another 50-100 change requests to be submitted. He is wondering if changes can be bundled together or if each individual change should be a separate RFC (maybe up to 100). We have never done it this way before and I wanted to get an idea of how others have handled a situation like this. As mentioned earlier, this is a high visibility project and is important for our organisation and the service we provide to our customers. Also, whichever way you guys have handled it - how is the communication aspect of it handled (with business units, CAB, other people in the org)?

Thanks!

[Bluesman]

Dunno if you had any input on this one from elsewhere?

Let me guess that this is some kind of software development project you are in.

I can easily appreciate 100 changes from here and there being necessary.
It would be extremely easy to bundle them, just for the sake of less paperwork.

But: different changes will have different owners, implications (i e risks and benefits), and may or may not be practical/economical or even possible.
WOuld you throw out the whole bundle if ONE change was rejected?

Try to see it differently. Ideally, each change should live its own life.
The best you could do to reduce "traffic" is to bundle them into sub-RFCs, grouped by originator, affected part of the system, cost, ease of implementation (minor/major change) or whatever is most applicable for you.

Or make some of these changes "pre-approved". If you (and the CAB) trust the skills of the project developers that would be no issue. The developers need to document every detail, of course, and provide a rollback possibility.

Most changes in e g a web project are smallish issues that can easily be made "pre-approved".

Concentrate on changes that have large costs, major impact or other significant issues. Treat those on a one-by-one basis.

(The CAB for each of the major changes would probably be different, BTW.
Of course, business bean counters need to be involved in most of these cases, and naturally the project mgmt. I have no ideas about the specifics in your place, these are just general ideas that I would stick to in my place, to simplify matters somewhat.)
_________________
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr

[BorisBear]

This sounds like a release - go speak to your Release Manager.......better still, take the PM with you and they can explain why they're circumventing the Release Management process

[Bluesman]

Boris -

what makes you think it´s a release, or even worse - a release mgmt bypass?

And in which post, the OP:s or mine?

(s far as I can see, this is just rationalizing and reducing the tsunami of RFCs a bit, in order to get them through the CM door to begin with, making the flow manageable.)

/R
_________________
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr

[UKVIKING]

All

The issue here is NOT Change management per se. The Chaneg manageemnt should be invoked once the project - application, nw versione tc gets released into Production. Until then, it is a project and does not need to follow ITIL BP guidelines. ITIL is for services that are being provided to the users / business

All changes to the project needs to be handled within the project

There should have been authorative body that said - this is the product that is to be built. IT has the following features and the following capabilities. and authorize the money

If the new service is a product like an application, then the application will need to first built, then tested in a production like environment, then all faults (Defects) identified, then the faults fixed and then the applciation is retested to see if the faults have been cleared. This will continue until the # of defects that are found in the application are ata an acceptable level by the authoratative body to be deployed to Production with the faults.

This is all about code management and release management


Once the application goes live, then these faults are production defects and must be tested and deployed to production under Chaneg management rules.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Bluesman]

True. Of course, the project should deliver a complete result/product and submit it as an RFC.

Good thinking, Mr Viking. Good to know that there are heads with a clear view here. Unlike mine

/R
_________________
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr

[BorisBear]

[UKVIKING]

I too read this a 100 changes to a release / ie Project changes rather than produciton changes
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Hena]

It's a brand new application being built by the project. It is going to be our critical app as it will be our customer and billing system. The reason why we will have so many RFCs is because it will have many touch points with current systems (which will either be fully or partially replaced by the new CIS).

The PM wanted me to have a special CAB meeting for the project where all the proposed changes were listed in the meeting (and not as formal RFCs) and the stakeholders would be there and give the approval. I was not in favour of that.

I'm borrowing some ideas from release management and can see some changes get bundled together as release packages:
- changes to same service/ CI can be bundled together only if they have tested successfully
- We will have a limit as to how many changes are bundled as a package
- If a package fails, only the part that failed needs to be rolled back, not all changes that were bundled together (unless there are dependencies)
- Sign-offs as per normal process
- Regular RFC that outlines procedures, risk etc.

This will reduce the number of RFCs that must be created, but the changes must still be documented and approved by all parties before approval from CAB.

[BorisBear]