Pre or Post implementation reviews

[changeborg]

With our process, we allow changes scoped as low impact (no user impact/no outage) to proceed through the process after a technical review of the change request has been completed. We have a debate in our team right now surrounding whether we as a change team should be doing reviews of the changes after the technical review has been completed or after the change has actually been implemented and assigned to us for closure.

To give you a bit more detail, our toolset sends our team an email when each of these have completed the technical review process and the emails contain all the critical information which would tip us off to the major defects. IMHO, by reviewing these before the implementation we will be able to stop any major defects plus catch folks who are abusing the Low impact business rules in the toolset.

Thoughts?

[Diarmid]

What about your risk assessment? Who approves the risk? I think of a change in risk levels, even temporary, as an impact on the customer.

Assuming you incorporate that in your "technical review", then I suggest the following. answer to your question:

Your technical review is a documented change management process with specified criteria for its use. If this is not true, then you have nothing.

It is entirely up to you (i.e. there is no ITIL reason to drive your decision) whether you design it as the entire change management process in these defined circumstances (in which case your Change Manager comes back into the loop by controlling the review process for each change or periodically for this class of changes) or or you design the process to involve handover to change management team prior to implementation.

The issue hinges on the practicalities of the different approaches, taking into account risk, process complexity, management capabilities,appropriate authority, and probably some other stuff.
_________________
"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

[sumituprit]

A change should be reveiwed in 4 stages
1. change request reveiw
2. Technical imact reveiw
3. Buisness impact reveiw
4. Post Implementation reveiw (PIR)

as a change management team, your job is to reveiw the first one and then anlyze for technical reveiw report and buisness impact report before the implementation phase. after implementation PIR should be done with help of technical team.
_________________
------------------------------------------------------
ITIL V3 Certified --Intermediate level
Service Transition management.
Manage the change and change the management to an improvised tool

[prathap_buna]

Hi,

Could you please explain whats the difference between technical impact and business impact. As far as I know if there is any technical impact, business will impact automatically. Please correct me if I am wrong.

Regards,
Prathap

[Diarmid]

Prathap,

keeping it simple, just one example:

If your entire network goes down unexpectedly, that is probably a significant technical impact. But if it occurs when all your users are asleep in bed and you get it fixed before daybreak, then the business impact is probably negligible.

It would be even easier to conjure up an example in the opposite direction.

Business impact goes to the heart of service provision, technical impact is related to service delivery costs (i.e. IT's costs).
_________________
"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