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: Margre4362
New Today: 2
New Yesterday: 97
Overall: 149943

People Online:
Visitors: 45
Members: 1
Total: 46 .

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 - lead time activities
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

lead time activities

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


Joined: Nov 18, 2009
Posts: 9

PostPosted: Thu Nov 19, 2009 2:05 pm    Post subject: lead time activities Reply with quote

our process requires lead times of <1,3 & 5 days for emerg, urgent and normal changes respectively. The lead times are invoked following receipt of all approvals, including change manager approval, and prior to the implementation date. I would be interested in knowing whether others have similar lead times and if so what activities are typically expected to be completed during this span of time.
Back to top
View user's profile
mnsmith
Senior Itiler


Joined: Mar 31, 2008
Posts: 109
Location: North West England

PostPosted: Thu Nov 19, 2009 10:31 pm    Post subject: Reply with quote

We have a similar concept of lead times as follows:

emergency - 1 minute (to ensure they are logged before the event)
minor - 1 day
significant - 1 week
major - 1 month

Like you these are measures from the date/time of provisional approval, rather than submission, to avoid issues where changes take a long time to impact assess.

During this lead time, we expect all of the build & test activities to take place, including documentation updates, communciaton and training.

We measure the changes that are implemented within the lead time so that we can reported on the % of late changes, which corresponds with a business plan target to ensure changes are raised and assessed in plenty of time.

Hope that helps

Mick
_________________
Mick Smith
Change, Configuration and Release Manager
Back to top
View user's profile
procman
Newbie
Newbie


Joined: Nov 18, 2009
Posts: 9

PostPosted: Fri Nov 20, 2009 6:02 pm    Post subject: Reply with quote

Thanks much for the reply. It is interesting to see how different best practice frameworks are interpreted and implemented.

In our case all resource assignment, window availability, testing, documentation, implementation planning etc is expected to be done prior to approval. Approval in our case is approving that everything is now ready for the actual tasks of implementation, not that we plan to have everything done by the implementation date.
In your case if all is being done during the lead time following approval what is the approval actually approving? and is there a secondary approval prior to implementation which indicates that all is ready to go?
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Fri Nov 20, 2009 7:15 pm    Post subject: Reply with quote

procman

It actually just depends on the environment and your requirements

for example

In the network area, I manage; most changes are f/w changes - which can not be tested and are bascially amend / add / delete rules

So the lead time can be short as the approved work is farmed out to the third party

coversely, I also deal with application which can be measures in days/ weeks
_________________
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: Fri Nov 20, 2009 7:21 pm    Post subject: Reply with quote

procman wrote:
In our case all resource assignment, window availability, testing, documentation, implementation planning etc is expected to be done prior to approval. Approval in our case is approving that everything is now ready for the actual tasks of implementation, not that we plan to have everything done by the implementation date.
In your case if all is being done during the lead time following approval what is the approval actually approving? and is there a secondary approval prior to implementation which indicates that all is ready to go?

Naturally, there are at least two stages of approval, one to commit resources to planning, developing testing etc., and another to confirm "good to go". This second approval will be defined as having met the quality criteria established in the plan as with any project.

procman wrote:
It is interesting to see how different best practice frameworks are interpreted and implemented.


If you think of ITIL as a set of guidance rather than as a set of rules you will see how natural it is for one organization to apply the guidance in one way and another in a different way.
_________________
"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
procman
Newbie
Newbie


Joined: Nov 18, 2009
Posts: 9

PostPosted: Tue Nov 24, 2009 12:46 pm    Post subject: Reply with quote

Thanks much to all who replied however I still feel unclear as to the reason for the lead time. It seems that simply put, best practice is to apply the guidelines in a manner that best suits the organization as requirements vary from organization to organization and lead time may make sense for some Changes but not for others.

Despite the variation in application of the guidelines, it would seem that approval is required once all parties have their ducks in a row and are ready to go. Receipt of all approvals should have taken place prior to implementation but not necessarily prior to the start of the lead time. If all effort to prepare for the Change, ie, documentation, testing, training etc. is done prior to approval the lead time between approval and implementation is simply a wait time. This is what I am try to understand better - ie, what is the purpose of the lead time if all effort to prepare is complete.
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Tue Nov 24, 2009 4:45 pm    Post subject: Reply with quote

procman

there is nothing really in itil about lead time

lead time mere is the application of the following word / phrase

P Hex

prior planning prevents piss poor performance

and manage expectations

if a change has a 3 day lead time for approval, then the team can shcedule the work and the idiots wanting can frigging plan
_________________
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 Nov 24, 2009 7:59 pm    Post subject: Reply with quote

procman wrote:
I still feel unclear as to the reason for the lead time.


You have to think backwards. Lead time is the time before which you cannot do something (for some practical reason) not the time after which you can do it.

I know, these are the same time, but if you think about it that way round it should be clear why you may need it.

To go back to your original post, I don't see what you are using these lead times for. By the time you have got to the stage of a fully approved, planned and prepared change the priority level has no logical influence over when you do it. your plan should already have determined that on the basis meeting the urgency of the task.

I can no more see why you would delay a lower priority change without reason than you would apply a high priority change before you were ready to do so.

In Change Management the place to have priority-based lead times is at the very start. A low priority change can wait to be considered at the next scheduled meeting of the CAB, for example, and that is your lead time. A high priority change can be expedited by calling a special CAB to deal with it, thus shortening your lead time.

All other times down the line need to be determined in the planning process according to circumstances. For example you may need to await a delivery ... but that is just project management and everyone knows that.
_________________
"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
procman
Newbie
Newbie


Joined: Nov 18, 2009
Posts: 9

PostPosted: Wed Nov 25, 2009 10:43 am    Post subject: Reply with quote

The situation is this, at this organization. Prior to receipt of all approvals, ALL ducks must be in a row. No approval is to be provided unless, testing, documentation, training, notification prep, planning etc have been done. If a task is required to have been completed in prep for the implementation and it has not been done by the required approval date, the instruction is to reject the rfc, not to approve it trusting that is will be done by the time the implementation date arrives. There is no secondary approval just prior to implementation which states all is now done as that is the purpose of the first approval at this organization. At this organization all prep work has been done with only the implementation activities remaining at the time of approval. Since, at this organization, the lead time (varies by urgency from 1-5 days, but not by the type of activity being completed) begins following receipt of all approvals, there is little to nothing being done during the lead time, hence the reason I am looking to others regarding the activities that they complete during the lead time period leading up to the implementation date.

It seems to me that most organizations actually do have tasks throughout the lead time period unlike the situation at this organization. It makes sense to have lead time if this is the period of time in which planning etc is done but I am not so sure of this if all preparation was done prior to approval. I guess what I am wondering is, is this normal practice at other organizations to implement in this manner?

Thanks to all for responding, I much appreciate to feedback, but at the risk of sounding like a broken record I would like to ask again whether other organizations are actually completing tasks/activities during the lead time and what they are or is it simply a wait period as it is being used for at this organization?
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Wed Nov 25, 2009 5:36 pm    Post subject: Reply with quote

Hi Procman

Having read all the thread with great interest, it seems to me that your authorisation is, in fact, a Release authorisation, as opposed to a RFC authorisation. As such you will have work going on during your lead time. We used to do it that way until we separated our process into RFC and Release.

Now we have RFC approval with approriate lead times for the RFC, we also have a 'Planned Implementation date' and the lead time for the RFC does not relate to this at all.

Release approval follows the RFC approval, and is concerned with how the implementation of the Change affects the customer / environment at the planned time i.e. the technical side.

Ttypically the RFC approval is more about the business case.

Diarmid is spot on for me
_________________
Regards

Ed
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Wed Nov 25, 2009 7:16 pm    Post subject: Reply with quote

procman wrote:
No approval is to be provided unless, testing, documentation, training, notification prep, planning etc have been done.


Are you saying all these activities go ahead without approval? Someone thinks up a "good" idea for a change, corrals staff and gets them to develop and test and plan the change and then asks if it is okay to do this change? If the change got rejected as a rubbish idea, who would carry the expenditure?

On your basic question, what is lead time for if nothing needs to be done?

By definition lead time is the amount of time required to be able to achieve something and thus be in a position to act on that. For example:

You may want to press a button, but ten people need to be notified first so that it does not shock them. your lead time is the time it takes to phone each person and confirm that they have received the message.

If everything is ready and everyone is primed then any mandatory waiting would be an anagram of leady (delay) not lead time. Are you really talking about delay?
_________________
"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
Inhisgrace
Newbie
Newbie


Joined: Apr 16, 2010
Posts: 4

PostPosted: Sat Apr 17, 2010 4:31 am    Post subject: Lead time Reply with quote

I realize I'm joining this discussion very late, but I am tasked with making similar decisions as we move toward a Change Windows environment. My feeling is Lead time begins to tick AFTER the change is fully prepared and approved. It is the time spent notifying stakeholders that the change is imminent in the hope that risks can be identified before the change goes into production.
Back to top
View user's profile
SubbuA
Itiler


Joined: Jan 28, 2010
Posts: 33

PostPosted: Thu Apr 29, 2010 6:18 pm    Post subject: Lead Time Reply with quote

Procman - you are talking about Production Release Management and not an actaul RFC.

In your case, it is necessary that before the work on a change is agreed to be started, it is taken to the business and the technology/implementation leaders and all nmutually finalize on the budget, the effort, the approx. time for release etc. This is pretty much like an RFC approval on resource planning and effort estimation, necessity for the change etc. And it is mandatory that this is done - if not through a formal CAB then theough some formal documented meetings between all parties involving the change

Once this is done and the build is developed - then your leadtime should apply after the submission of your change for approval. In such way of delaing with a change - you will really need a release window for each type of change so that the changes happening in the environment do not technically clash and create adverse effect. During this lead time - the implementing team is expected to notify the stakeholders of the approx. date/time of the change, work on the readiness of their implementation plan & backout plan, get the UAT approval signedoff, conduct required tarining, get the training documentation and other relevant documentation ready, etc. Things like non-UAt testing, preparation of coomunication plan should have been ready prior to the submission of the change.

So ideally, you will need a greater lead time - time between submission of your change for approval & the review date of your change.

Once your change is approved - again a second level of lead time is required before implementation- which is much shorter in comparison to the earlier lead time.

What is done during this period is - ensured that last moment check on resource avaiability, and other technical necessities are relooked. Very importantly the brodcast communication is sent out on your change so that other businesses are notified about it to allow them plan their work accordingly (mind you the key stake holders and the directly impacted users need to be notified with approximate date prior to the approval of your change)

Hope this helps - I know I am very late to reply
Back to top
View user's profile
Myaudry
Newbie
Newbie


Joined: May 14, 2008
Posts: 3

PostPosted: Tue May 11, 2010 6:31 am    Post subject: Lead time Reply with quote

We established lead-times (which begins from placement on the Forward Schedule calendar) purposely to give enough time to fully prepare the various types of change to be installed; meaning the less intrusive the change, the less lead-time required. We recently incorporated this calculation to be part of the automated tool we use that helps enforce these lead-times - but its pretty much a nightmare right now Smile

In the end without reasonable lead-times in place & enforced as part of your Change Management requirements, you are helping negate the purpose of managing change.
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Thu May 13, 2010 9:35 pm    Post subject: Reply with quote

Inhisgrace,

lead time does not "begin to tick".

As Myaudry suggests, lead time is the time needed to perform the required steps to achieve delivery.

Lead time answers the question: "If I put in a request today, when will you despatch it?"

The answer might be: "Well, there is a CAB meeting tomorrow, but there is no time for the members to evaluate your request before then. To make sure everyone can fit it in to their work, they need the information three days ahead of the meeting. So, unless you have an emergency, it will go to CAB in eight days."

In this example, the "lead time" is three days plus time to subsequent CAB meeting. You can qualify all that with information about how long similar things usually take and you can establish special arrangements to make certain kinds of change more predictable or more immediate - emergency change being the most obvious.

Then, if it is approved, there is planning, developing, testing to be done before it can be scheduled for implementation. But all these steps are done on a priority basis and the request may be queued for some time, depending on its business value. It is only at the planning stage that actual delivery can be discussed. In practice, how long it takes to deliver is more impacted by how much work is involved than on any priority unless there is a chronic shortage of resources.
_________________
"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.