Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: ESumner
New Today: 48
New Yesterday: 89
Overall: 139466

People Online:
Visitors: 69
Members: 2
Total: 71 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - End Time on RFC's
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

End Time on RFC's

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
Zeth
Newbie
Newbie


Joined: Mar 25, 2008
Posts: 10

PostPosted: Tue Mar 25, 2008 8:59 pm    Post subject: End Time on RFC's Reply with quote

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 Very Happy
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3292
Location: London, UK

PostPosted: Tue Mar 25, 2008 9:57 pm    Post subject: Reply with quote

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
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Mar 25, 2008 10:13 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
UrgentJensen
Senior Itiler


Joined: Feb 23, 2005
Posts: 458
Location: London

PostPosted: Tue Mar 25, 2008 11:22 pm    Post subject: Reply with quote

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)
Back to top
View user's profile
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Wed Mar 26, 2008 12:13 am    Post subject: Reply with quote

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
Back to top
View user's profile
Skinnera
Senior Itiler


Joined: May 07, 2005
Posts: 121
Location: UK

PostPosted: Wed Mar 26, 2008 7:57 am    Post subject: Reply with quote

And I make it 5 in a row!! Very Happy

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... Twisted Evil
Back to top
View user's profile Send e-mail
Zeth
Newbie
Newbie


Joined: Mar 25, 2008
Posts: 10

PostPosted: Wed Mar 26, 2008 11:25 am    Post subject: Reply with quote

Thanks heaps for the feedback guys greatly appreciated!!! Very Happy

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 Laughing
Back to top
View user's profile
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Wed Mar 26, 2008 11:35 am    Post subject: Reply with quote

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.
Back to top
View user's profile
Saravanan
Newbie
Newbie


Joined: Jun 18, 2010
Posts: 1

PostPosted: Fri Jun 18, 2010 6:54 pm    Post subject: Reply with quote

Skinnera wrote:
And I make it 5 in a row!! Very Happy

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... Twisted Evil


For some reason if the RFC window is extended by 30 mins and the change is successful, do you mark this change as "Failed".
Back to top
View user's profile
viv121
Senior Itiler


Joined: Dec 15, 2007
Posts: 113

PostPosted: Tue Jun 22, 2010 9:00 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
SubbuA
Itiler


Joined: Jan 28, 2010
Posts: 33

PostPosted: Thu Jul 22, 2010 8:22 pm    Post subject: Mate three date factors are very important for a change Reply with quote

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
Back to top
View user's profile
davey60
Newbie
Newbie


Joined: Jan 25, 2009
Posts: 1

PostPosted: Mon Aug 09, 2010 11:50 pm    Post subject: End Time on RFC's Reply with quote

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.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Aug 10, 2010 2:59 am    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.