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: C7397
New Today: 11
New Yesterday: 50
Overall: 146274

People Online:
Visitors: 43
Members: 2
Total: 45 .

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 - Relation between Change and CI
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Relation between Change and CI

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


Joined: Mar 31, 2008
Posts: 34

PostPosted: Wed Apr 02, 2008 2:13 am    Post subject: Relation between Change and CI Reply with quote

Hi,

I'm tasked with defining the difference between a change, task and a project.

A task is a subprocess of a change (backup, upgrade, ...).
For us a project is something spanning a collection of scheduled changes (due to dependencies) - for example planing, developing and preparing for a software release.
My problem is with the scope of a change. A change is always related to a CI in some way, but is it correct to relate it to more than one CI?

For instance I might say that a roll out of an upgraded office desktop PC platform (an upgrade of the word processor for instance) might concern only one CI: the package that is rolled out on all office desktops. It, however, affects many other CIs. On the other hand... it could also be considered as a **** **** of changes. Or am I wrong? It certainly seems impractical.

Another example could be the replacement of an old server. It clearly covers at least two CIs (one comming in and one leaving) and it clearly affects the CIs for the services on top of the old server. Is this one change or maybe two? And if this is two changes - what is the difference between a change and a project?
Back to top
View user's profile
elewis33
Newbie
Newbie


Joined: Apr 01, 2008
Posts: 12
Location: Salt Lake City, UT USA

PostPosted: Wed Apr 02, 2008 5:39 am    Post subject: Re: Relation between Change and CI Reply with quote

pel wrote:
Hi,

I'm tasked with defining the difference between a change, task and a project.

A task is a subprocess of a change (backup, upgrade, ...).

I agree that changes have tasks associated with them.

Quote:

For us a project is something spanning a collection of scheduled changes (due to dependencies) - for example planing, developing and preparing for a software release.

I'd also agree with this.
Quote:

My problem is with the scope of a change. A change is always related to a CI in some way, but is it correct to relate it to more than one CI?

I believe you have to determine what is right for your organization regarding more than one CI per change. Personally, if the change is managed well and the correct group of CIs were able to be clearly referenced you could do multiple CIs with a single RFC.

Quote:

And if this is two changes - what is the difference between a change and a project?


The project is what initiated the whole thing and allowed you to recognize which 2 servers needed to be changed. But just because you're changing 2 servers doesn't necessarily mean you have a project. You could also get to the same place via incident management and problem management. Once a known error is identified and the fix is confirmed and tested you could enter the change management process from that route.

This is just my 2 cents, but I take a very pragmatic view of all of this ITIL stuff. If something adds enough value to the process then you might want to consider including it.

Earl
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Wed Apr 02, 2008 10:02 am    Post subject: Re: Relation between Change and CI Reply with quote

Hi,
pel wrote:
Hi,

My problem is with the scope of a change. A change is always related to a CI in some way, but is it correct to relate it to more than one CI?
...
what is the difference between a change and a project?


The key word is management. You want to manage changes. Whether it is one CI or a thousand, it can be one change to manage if that's what makes sense. The acid test is if the approval required has a certain unity.

With the examples you cite, I can hardly imagine more than one change being raised. Even if you decided to phase the roll out, say for different sites, you don't need to make it a second RFC. You could, and it might make sense if you might consider not rolling out to the second site.

As for projects, well changes require projects and Change Management puts a project cloak around any change. There is risk and cost identification, approval, planning scheduling, resource allocation, review and there is someone driving the thing forward (project manager or change manager).

Now, changes that are going to take a long time, a lot of resource, involve high costs or risks, you might want to impose a formal project management method onto the process and appoint an experienced project manager to run with it. In that case the requirements and constraints of Change Management are fed into the project.
_________________
"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
pel
Itiler


Joined: Mar 31, 2008
Posts: 34

PostPosted: Wed Apr 02, 2008 5:06 pm    Post subject: Re: Relation between Change and CI Reply with quote

Thank you for the input!
I can't even begin to describe how useful it is to have others besides your coworkers to talk to.
Diarmid wrote:
The key word is management. You want to manage changes. Whether it is one CI or a thousand, it can be one change to manage if that's what makes sense. The acid test is if the approval required has a certain unity.

I completely agree. Knowing this "certain unity" is quite easy using common sense; distilling this common sense, however, into a clear definition is not as easy though. Smile
A clear definition is rather useful when the organization has independent (silo) departments (who shares infrastructure and data) that needs to interact.

Diarmid wrote:
As for projects, well changes require projects and Change Management puts a project cloak around any change. There is risk and cost identification, approval, planning scheduling, resource allocation, review and there is someone driving the thing forward (project manager or change manager).

You mean that changes requires releases (i.e. release mgmt.), not projects?
Projects, in my opinion, are something bigger that fits well with what you describe below.

Diarmid wrote:
Now, changes that are going to take a long time, a lot of resource, involve high costs or risks, you might want to impose a formal project management method onto the process and appoint an experienced project manager to run with it. In that case the requirements and constraints of Change Management are fed into the project.

I completely agree.
Actually that was a lot leaner than my original definition. *steals* Very Happy
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Wed Apr 02, 2008 6:52 pm    Post subject: Reply with quote

Hi pel,

I'm not sure you can have a clear definition for anything like this.

- A bunch of CI changes that meet a single objective : perhaps, but if the bunch is too large and/or disparate, then you would want to break it down into sub-projects and one way of doing that would be to increase the number of RFCs in some cases.

- a series of CI changes that are interdependent : sure but too tight; it excludes a lot of desirable situations.

I think it really a learning exercise for your silos. Provide guidance and then assess RFCs as they come in. The CAB can always ask people to combine or break up their requests if they think that is most practical. Then everyone will iteratively come to understand what works best. Strong review will also help.

In all this keep the Silo staff involved; don't just tell them what to do; get them to participate in the decision making.
_________________
"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 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.