End Time on RFC's

[Zeth]

Hi All, newbie here.

Just want to get some feedback in regards to including the End Date/Time of a change within an RFC. Over the last few years working in Change I have always included this within the RFC. Now I am with a new company and moving towards a Global model I need to be open to "Change".

The company out of the U.S current work of a Start date and an estimated duration, no clearly defined "End date/time".

I am thinking maybe it is a personal thing, but I prefer to have the end date/time clearly stated in an RFC for reporting purposes, etc.

I welcome your feedback on this

[UKVIKING]

Zeth,

IMNSHO, all changes should have the following

start time
duration of implementaition
duration of implementing the backout plan
end date

both for the planned and the actual

the start time and end time should represent the window where the change is active. the difference between the start and end date/time should equal at leat the duration of the implementation plan and the duration of the backout plan if implemented

but that is my opinion

the change request record should have the above as explicit as possible so that you can perform date/time mathematics and calculations
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Diarmid]

Hi Zeth,

I agree with John.

By way of elaboration, I would just add this: if you don't know how long it will take and when you are able to do it, are you ready to commit to a change? It's the end date commitment that keeps minds focussed. To be sure there might still be slippage occasionally and it might be for legitimately unforeseen reasons, but your change review will pick that up and prevent any silly finger pointing.

I can envisage two scenarios:

a) the estimates that are presently used are normally pretty well confirmed by the actions - so why not pin them down as commitments in the first place?

b) the estimates presently used are often significantly out - so the estimating process is letting you down; applying committed dates will certainly focus on the need to improve the estimating.
_________________
"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

[UrgentJensen]

Yup, agree with Viking and Diarmid.

Forget the 'best practice', I can't envisage how a serious business can make changes to production environment without definitive start/end dates and times. It's asking for trouble if you don't know what work is happening when.

On a slight tangent I would add that I always ask for 'request submitted' date/time so that I can measure planning around changes.

Cheers,

UJ
_________________
Did I just say that out loud?

(Beige badge)

[asrilrm]

Make it four. I'm in.
You can educate your folks that start date and end date will help keeping them focus, as Diarmid said.
In my experience, giving such tolerance (i.e. no end date) was always got abused by some people as an escape clause

[Skinnera]

And I make it 5 in a row!!

I specifically class as Failed any RFC that extended beyond it's Planned Finish Time without authority from the Service Controller (regardless of the naming of this role, it's the guy who is in charge of Service at any given point).

I also report on those RFCs that are closed outside of their Planned Finish Time and follow up with the implementers...

[Zeth]

Thanks heaps for the feedback guys greatly appreciated!!!

I just wanted to clarify 1 thing, as I think I was not clear in my original post.

The current practise is that the Start Date/Time + the Estimated Duration = the End time

e.g
Start: 26th March 10:00 +
Estimated Duration 4 hours =
End time 26th March 14:00

The issue I have is that the End Date/time is not captured within the RFC, therefore when reviewing/reporting etc we need to make that quick mental calculation to determine the "End Date/Time", where I prefer to have the End Date/Time staring me in the face and clearly stated within the RFC (especially when reviewing etc a high volume of changes).

Am I asking for too much? lol

[asrilrm]

If you can have all three of them, it would be good.
In my RFC template, only the submit, start and end date are there.
I put duration (time) in the Forward Schedule of Change, after clarifying with the requestor in the CAB Meeting.

[Saravanan]

[viv121]

Saravan,

It depends how you want it and more specifically what you have agreed with your customer. I think you shouldn't call it a 'failed' change if it over runs the project TSO time. However, you run in a risk of losing on money if the downtime goes beyond what you have agreed with your customer.
_________________
regards,

Vivek
"the only statistics you can trust are those you falsified yourself"
Winston Churchill

[SubbuA]

One

Requested Start/End Date/Time of implementation
Planned Start/End Date/Time of implementation
Actual Start/End Date/Time of implementation

Your Requested Start/End Date/Time of implementation will let the implementer know - when is this change actually needed for the business. So that they don't end up planning a change for July when a business has got subsequent dependent plans for the change to be completed by June end. You get it? I need this will help you assess the need for the change (is the change alligned to the business)

The planned start/end date/tme of implementation should be as close to the requested date/time to meet the needs... However, the requested date/time for implementation of a change as would be provided by the business might have a good possibility that they can not estimate the duration required for implementation of the change... So it is post your planning (complete planning and very accurate planning) they you will arrive at a planned start/end date/time for any change

The actual start/end date/time needs to be captured automatically and should allow no manipulation. This is to record where you stand in accordance to your plan. This will allow measure the effectiveness of your change plan and will help plan you better in future

all these three dates help in assessment of the change for the change manager. We as change manager also would like to see - the age of the request (meaning the submission date of the request) to see what level of planning has gone through - just to get the confidence factor

[davey60]

An additional question - would the valadation be included in the PS/PE times. For example a report and database change may take 15 minutes to install - but the report will not be ran for another month. Thanks.

[Diarmid]

Davey60,

you are confusing activity and management aspects.

Planned start and end times (I do hate cryptic TLAs) wrap around activity and are not to do with beginning or ending the management process for the change. So validation activity is included if during that time the service has not been made fully available, either still being down or being inhibited until confirmation has been achieved.
_________________
"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