lead time activities

[procman]

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.

[mnsmith]

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

[procman]

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?

[UKVIKING]

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

[Diarmid]

[procman]

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.

[UKVIKING]

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

[Diarmid]

[procman]

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?

[Ed]

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

[Diarmid]

[Inhisgrace]

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.

[SubbuA]

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

[Myaudry]

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

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.

[Diarmid]

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