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: LSampson
New Today: 43
New Yesterday: 64
Overall: 148296

People Online:
Visitors: 55
Members: 0
Total: 55

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 - Conducting Post-Implementation Review
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Conducting Post-Implementation Review

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


Joined: Feb 04, 2011
Posts: 1

PostPosted: Sat Feb 05, 2011 12:31 am    Post subject: Conducting Post-Implementation Review Reply with quote

Hello,

As the change manager I'm trying to define the choices below in Remedy ITSM for status reasons when closing CRs.

The choices are:
Successful
Successful w/issues
Unsuccessful
Backed Out

The project has asked for definitions of the above and after reading several posts on the forum I have come to a fork in the road.

Feedback would be greatly appreciated for
Successful w/issues & Backed out

Cheers,
Jared
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Sat Feb 05, 2011 3:12 am    Post subject: Reply with quote

Jared,

you need to start with the why, not the what.

Why do you want to record those four classifications? What do you intend to do with that information? Without answering this, you have four meaningless and useless classifications. Is four the right number. Would not three or five be better?

Once you know the answer to those questions it is very easy to turn the answers into definitions for the classifications. And it is also, then, very easy to know how many classifications to have and what to call them.
_________________
"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
Rocker
Newbie
Newbie


Joined: Feb 10, 2011
Posts: 2

PostPosted: Fri Feb 11, 2011 9:31 am    Post subject: Conducting a Post Implementation Review Reply with quote

Hello,

Definitions of the choices in Remedy can be defined as per your companies policies and procedures for change management, however if these are not set the most common definitions are:

Successful - a change that was implemented according to the specifications outlined in the change ticket

Successful w/issues - a change that was implemented with minor issues. These types are changes are usually due to the fact that the original change did not have a platform to be tested prior to implementation and a problem ticket is raised to correct the minor issues.

Unsuccessful - a change that was implemented and was unsuccessful in correcting the problem that the change was raised for in the first place.

Backed Out - similar to the above - change was implemented and was either unsuccessful or has issues during implementation and was required to be backed out and another change raised when the issues are corrected.

In the case of 2,3,4 above a detailed report should be provided and attached to the change ticket before it is closed, as well as an Incident ticket raised to correct the issues.
Back to top
View user's profile
SubbuA
Itiler


Joined: Jan 28, 2010
Posts: 33

PostPosted: Wed Feb 23, 2011 11:09 am    Post subject: PIRs Reply with quote

I think you are a little conservative about customising the Remedy tool to suit your requiements.

As said to you earlier - first check your change execution trend and determine what level of closure codes you would need based upon why would you need such a closure code and how much of an value does it add to your overall process refinement work.

You will get your answers much better than a booking standard tool definitions for the closure codes.

I can have
closed
cancelled
backout
closed with objectivity of change being success but execution time slot missed
closed with obejectivity partially met
closed with unsuccessful for it already triggered an incident
and many many more

but do i really need them all is what should be ur question first
_________________
Regards,
Subbu A
ITIL Certified and well experienced
Back to top
View user's profile
Rocker
Newbie
Newbie


Joined: Feb 10, 2011
Posts: 2

PostPosted: Wed Feb 23, 2011 12:28 pm    Post subject: Reply with quote

Jared, I had assumed that you and your project team had already completed their due diligence on identifying what the company requirements were on the change management closure statements in the tool. If not, then yes, you need to look at all options first and choose those most appropriate for your company. Please let the forum know if you require any further assistance with your final selection.

Regards
Rocker
Back to top
View user's profile
Myaudry
Newbie
Newbie


Joined: May 14, 2008
Posts: 3

PostPosted: Sat Feb 26, 2011 6:35 am    Post subject: PIRs Reply with quote

We too use Remedy (heavily customized due to opinions) and suffer from the illness of too many codes with subjective descriptions that will take a miracle to redesign. Why subjective? - we let our implementers/owners make the final decsion of the stat at their leisure. Evil or Very Mad Of course this leads to skewed metrics because we have a 99.999% success rate. Imagine that! No value add here...

My concept of PIRs is to ensure proper management of all result types have run through the loop(s) to its closure; capturing Problems, Incidents - true results, true measurements.

You cannot do this with subjective closure options or with too many options.
My company has spent 10 years creating and then defining, redefining and then reinventing again what our codes should be. (Everyone has an opinion and those who speak loudest usually win).

The net net on that is our closure codes & definitions mirror Rockers which is really good!

Regardless of the types or amount of codes, how you design your PIR process will determine your success & give meaty metrics to what is / is not acceptable measurements, ulitmately to help in your business reporting and on to your process improvement phases.

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