Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: ameqiso
New Today: 12
New Yesterday: 34
Overall: 231584

People Online:
Visitors: 125
Members: 0
Total: 125



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

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.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - When does a Task Become a Change?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

When does a Task Become a Change?

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

Joined: Aug 24, 2010
Posts: 5

PostPosted: Wed May 09, 2012 6:36 am    Post subject: When does a Task Become a Change? Reply with quote

In my organisation, for historical reasons RFCs have been created to get approval to implement a change which in itself constitutes several changes each recorded within a Task. This has meant everyone who has a change (task) needs to approve an RFC and the whole approval thing gets out of hand.

Implementing Remedy 7.6.04 out of the box has highlighted this issue as Remedy 7.6.04 is geared to approvals being requested based on impacted area, Op and Prod Cats, CIs, Service CIs etc of the change not the tasks. Ad hoc approvals is possible but determining who should be added as an approver based on the task information is cumbersome. The other thing of course is that ad-hoc appovals get wiped when someone rejects a change and they have to be manually added back in.

In my opinion we should be recording changes more granularly and where these changes can be done so, they should be classed as standard changes with minimal approval. Changes that need to be performed in sequence or in a certain order should be related.

Tasks should only be used to track tasks necessary to implement a change for example

Freeze.Unfreeze a cluster
Suspend/resume alerts
Perform pre/post implementation checks
Inform users that service is going down/service is resumed

We may end up with more change records, but overall they will each be dealt with more efficiently as the risk and impact will be easier to determine and the number of approvers per RFC will be reduced.

Anyone disagree?
Back to top
View user's profile

Joined: Jun 07, 2007
Posts: 12

PostPosted: Wed May 09, 2012 7:24 am    Post subject: same as above Reply with quote

My orginization uses standard RFCs heavily. 60% of all RFCs are standards. We do about 600 changes a month. One of the limitations of our system is that it doesn't support tasks.

Here is my vision:

We are migrating different customer segments e-mails in a three week span. 15 tasks (one for each migration) on one RFC.

I didn't think that tools with tasks required approval for each task, just for the RFC itself. If this is true my owners and approvers will kill me (I'm looking for a new toolset currently). This paradigm will not be acceptable.

I am tired of see RFCs that span 21 days on a calendar. I was hoping that tasks within an RFC would fix that problem. I guess I'm going to have a whole new set of problems Crying or Very sad
Back to top
View user's profile
Senior Itiler

Joined: Mar 04, 2008
Posts: 1894
Location: Helensburgh

PostPosted: Wed May 09, 2012 7:43 pm    Post subject: Reply with quote

It is better to focus on your requirements of the tools than on the tools requirements of you.

The granularity of what constitutes a "change" (in the context of a change request) is an entirely practical matter and should be determined with a view to minimising bureaucracy without compromising your ability to control what you are doing.

Even more importantly, one of the purposes of so-called "standard change" is to focus approval seeking appropriately for that change, not to minimize it.

Also important (unless I misunderstand your post), task tracking is not an alternative to change tracking. Every part of making a change is a task, but tasks do not need approval in the same way as changes do.
"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

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.