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: EFlanagan
New Today: 25
New Yesterday: 76
Overall: 143363

People Online:
Visitors: 50
Members: 3
Total: 53 .

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 - Scope of Change Management
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Scope of Change Management

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
bnetra
Newbie
Newbie


Joined: Sep 17, 2006
Posts: 7
Location: Bahrain

PostPosted: Tue Jan 23, 2007 9:29 pm    Post subject: Scope of Change Management Reply with quote

Of the below what can be considered as Change?

1) Change of a user's password
2) Change to an existing report
3) Change in server hardware
4) Addition of new network point
5) Applying latest patches to Windows desktops
6) Increasing the bandwidth of point-to-point WAN link
7) Uninstalling existing software on a server

My questions are:

a) do all the above changes should go through the Change Management process?
b) If there is no existing Change Management in place then how it should be treated?
c) How to define the scope of Change Management - what is to included / excluded?
d) Do all the above Change requests should initially go through Incident management.

Thanks.
Back to top
View user's profile Send e-mail
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Tue Jan 23, 2007 11:46 pm    Post subject: Reply with quote

To give the broad definition of what a Change is may give you a better understanding of how I am approaching these questions. A Change is defined as any change in Status or Attribute of a Configuration Item. In theory, if you have no Configuration Management process in place, then there no reason to submit Change Requests. Practicality speaking, most organizations do not have a fully implemented Configuration Management process and as such have Changes submitted that are unrelated to CIs.

The correct way to define what a Change should be is by thinking "If I lived in a perfect world and did have a fully implemented Configuration Management process, would the Infrastructure I am about to affect be included in the Configuration Management Database?"

Having said that, let's look at each scenario you posed:

- 1) Change of a user's password

Most definitely not. The Configuration Item associated with passwords would be the security systems in place to manage passwords. Are you changing the Status of the security system? No. Are you changing an Attribute of the security system? I would also say no. Changing an attribute of the security system would be like setting the account lock out to occur on 3 tries rather than 10.

Is the request for a password change an Incident? Kind of. It is considered a Service Request. An Incident is an event that causes or may cause the interruption of a service. The service in question here is the security service. Does the fact that a user has forgotten their password affect the ability of the security service to continue to function? No. In fact, the only way it would be an Incident would be if the security service failed to lock out the user's account.

A password reset is considered a Service Request (which in ITIL are tracked in the Incident Management process). A Service Request is a request for information or documentation. The information in question here would be the user's password.

- 2) Change to an existing report

Is that report considered a Configuration Item (in a perfect world)? Probably not. If you tried to track all Reports as CIs, then your Configuration Management process would crumble on the required number of updates. But perhaps this report is the version controlled, financially mandated, most god-important report your company produces. Then maybe this report is a CI. In which case any change to it's status (it won't be available during the update) or attribute (it will change from a monthly to quarterly report) would require a Change Request.

- 3) Change in server hardware

The same answer as above except that most organizations would say that core infrastructure should most definitely be tracked in the Configuration Management Database. So a change in the status or attribute of a server would require Change Requests. Unless you were making a change on a server that was not an Attribute tracked in the CMDB. Let's say that you don't track the mouse connected to server. You decide that the current mouse doesn't have all the buttons you want or a scroll wheel. If the mouse isn't tracked as an attribute, then throw the old mouse away and hook up the new one. No official Change required. That change will probably be recorded in some other system such as Inventory or Asset. Remember that Configuration doesn't replace Inventory or Asset, it is a subset/superset of Inventory or Asset.

- 4) Addition of new network point

Think of this in terms I have already discussed. In a perfect world would you track the nodes of your network in a Configuration Management Database? Would adding a network point change the attribute (network diagram) of the CI? If so, then you will need a Change Request.

- 5) Applying latest patches to Windows desktops

Will the patch level be tracked as an attribute of PCs in Configuration Management? Will you bother to scope you CMDB to include every PC/laptop in the organization? If not, then changes to the desktop configuration do not require Requests for Change.

I will skip the last two since I think it is pretty obvious where my logic is going.

As far as you final questions:

a) do all the above changes should go through the Change Management process? I think I addressed this in my comments above

b) If there is no existing Change Management in place then how it should be treated? Time to invent a RFC form and plan for an Awareness Campaign on when the RFC form should be used and the repercussions of implementing non-approved changes

c) How to define the scope of Change Management - what is to included / excluded? If you don't already have a Configuration Management process, try and think of what you would include in a Configuration Management Database in your environment

d) Do all the above Change requests should initially go through Incident management. No. Some Changes, such as the mouse on the server, have nothing to do with a service interruption. Only events that cause, or might cause, a service interruption AND require changes to the Status or Attribute of a CI would start their life as an Incident and then have a Change Request opened to resolve the Incident.

Hope this helps,
Don
Back to top
View user's profile
matrejekm
Itiler


Joined: May 11, 2006
Posts: 32

PostPosted: Fri Jan 26, 2007 6:49 pm    Post subject: Reply with quote

Although dboylan gives something I can call a perfect answer...

In my case because of lack of security officer - password management is treaten as a Change Management is some part.
Accounts were divided into the ones which has impact on CIs - e.g. administrative passwords, passwords used by applications, etc...
I don't care about user passwords - these changes are done as Service Requests or Incident Management.

In many cases it is a matter of agreement on what is included or what is not in change management scope as discussions can last forever
(even if you consider ITIL definition - it is always related to IT Service - and IT service definition is dependent on your organization).

I am working with something I called a Change Catalogue - I put there not only a Standard Change Types, but all types to clearly identify what is in my scope as Change Manager. That solves most of responsibility issues between me and Incident Management.

regards,
Mariusz M.
Back to top
View user's profile Send e-mail
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3303
Location: London, UK

PostPosted: Mon Jan 29, 2007 3:21 am    Post subject: Reply with quote

User passwords should be just a service request - in order to track those who suffer from Operator Headspace

However, I and the system and network people would use Change mgmt for tracking system passwords. However... we would not put the password in the ticket. That would so wrong in many ways
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Mon Jan 29, 2007 9:04 am    Post subject: Reply with quote

UKVIKING wrote:
User passwords should be just a service request - in order to track those who suffer from Operator Headspace

However, I and the system and network people would use Change mgmt for tracking system passwords. However... we would not put the password in the ticket. That would so wrong in many ways


I would agree that system passwords should be under Change Management. A system such as server, router, mainframe, etc would be a CI. Since it may have an Attribute of "Current Password", it might well be tracked in Configuration Management. Although I think a better Attribute for a server CI would be "Last Password Change Date". By requiring an update to the CI's attribute, you would need to submit a Request for Change.
Back to top
View user's profile
matrejekm
Itiler


Joined: May 11, 2006
Posts: 32

PostPosted: Tue Jan 30, 2007 1:20 am    Post subject: Reply with quote

If you oversee an account which is not related to exact person and is used on e.g. several servers and this servers can be maintained (e.g. hardware changes) independently then this account becomes a CI with relation to selected servers. This makes it to be in scope of Configuration Management.

cheers,
Mariusz
Back to top
View user's profile Send e-mail
jpomales
Itiler


Joined: May 13, 2004
Posts: 31

PostPosted: Tue Jan 30, 2007 10:16 am    Post subject: Replies.. Reply with quote

Let's not forget that there is such a thing as 'routine' changes that do not need to go through the complete rigor of the CM process. I designed a standard form in our chosen tool, back in the day, for user password resets. This form would come prepopulated and my Service Desk reps would only enter the unique user id, along with start and stop times.

I wouldn't consider changing a user's password a 'Standard' Change, unless it's a password reset for a sysadmin/essential service; notice I said 'service' not 'server' and this for a purpose. If we define as a service Databases, for example, something that report writers and designers hit with a set of defined credentials that should go through a rigorous CM process, along with a defined Release Management structure.

Everything else on your list should go through CM.

Cheers.
_________________
audentes fortuna juvat
Back to top
View user's profile MSN Messenger
raroa
Senior Itiler


Joined: Dec 05, 2006
Posts: 54

PostPosted: Fri Feb 02, 2007 7:58 pm    Post subject: Reply with quote

Please do not start from some idealistic position of what "should" be controlled. Be pragmatic. Look at People Process Technology.

Always start with the people: what is culturally acceptable and politically possible? is the place ready for CM? is there a "wind of change"? if you lock up all of the above do you have the power/mandate to do so or will you be ignored as a bureaucratic idiot (it happens). What will you do to tell people of the new regime and get their acceptance (or at least acquiescence)?

Process: can you cope if all the proposed objects become controlled CIs? how will people know what is controlled and what isn't? how much can you get moved into Standard change and how quickly? will the business still function?

Technology: how will you track all the changes? How will you manage workflow? measure compliance? enforce compliance? Detect subversion? If you can't do these things, then what is the point of CM?

Only once you have addressed these questions (and others) can you then plan what is under CM control.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion 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.