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.

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.

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?

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

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.

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

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?

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.

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

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.

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)

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.

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