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: SValerio
New Today: 53
New Yesterday: 72
Overall: 139743

People Online:
Visitors: 69
Members: 2
Total: 71 .

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

Change v Project

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


Joined: May 10, 2007
Posts: 8
Location: Wellington New Zealand

PostPosted: Tue Sep 11, 2007 7:58 am    Post subject: Change v Project Reply with quote

Hi All,
I'm currently tasked with reviewing and redefining our Change processes. One of the activities will be to define a process to distinguish what comes to Change management and what goes to Project management.

At the moment there is a matrix which is pretty much based on the amount of time involved to complete the task, however this isn't working at all and some very insignificant work is going through a complicated approval process and is subsequently lost in the project register.

Any help, examples or advice would be appreciated.

Cheers,
Mark.
Back to top
View user's profile MSN Messenger
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Tue Sep 11, 2007 1:03 pm    Post subject: Reply with quote

Hi Mark,

Let's start by saying that the only material that should go through the CM process, to the CAB for review, is a list of what "is" changing. By this point, the RFC itself is long gone because a single Request for Change can actually lead to many Changes (something ITIL doesn't get).

- Projects can yield Change Requests and/or Changes.

- Change Requests don't always yield Projects. This will require an analysis, usually based on Time, Effort, Dollars, etc.

- Software Releases are a special form of Project that can often go on independent of the Project Management Process, since small Releases usually encompass small changes.

- Sometimes, Change Requests can be executed directly, through pre-approved Changes, in the form of approved Service Requests.

I know this all sounds random. However, if you break it down, you will find that they all "connect" and can be applied to your decision matrix.

I hope it helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL Platform
Back to top
View user's profile Send e-mail Visit poster's website
dsemeniuk
Itiler


Joined: Feb 06, 2007
Posts: 41

PostPosted: Wed Sep 12, 2007 1:04 am    Post subject: Reply with quote

Hi Frank,

What process would this go through.

If somebody wanted to add a new business application into our infrastructrue to say help with doing a different type of line of business.

Is this an RFC? A major change request? Or does this go through some of the uppoer management process to be reviewed and validated?
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Wed Sep 12, 2007 1:30 pm    Post subject: Reply with quote

Hello dsemeniuk,

dsemeniuk wrote:
What process would this go through.

If somebody wanted to add a new business application into our infrastructure to say help with doing a different type of line of business.

Is this an RFC? A major change request? Or does this go through some of the upper management process to be reviewed and validated?


This would typically start as a planned "Project". The Project will plan for the procurement and construction of Products and Assets, both, physical (such as machines) and virtual (such as software processes). The Project will do things like plan for Product "Releases". For example, you will "Release" version X.Y.Z of a software Product through your environments, ultimately to Production, and you will test that Release through all environments. As part of the Project and Releases, "Changes" will be planned for execution in "each" and "every" environment. If people are doing their jobs correctly, anything associated with the movement and application of virtual Assets will be automated. All Changes will be planned for, tested, and rolled up into the Release, as all Changes are a symptom of the Release and should be tracked back to it (the Release will be tracked back to the Project, which will provide that level of traceability).

In short, if you want to role out an application, you would:

    1) Plan for a Project to do so, provide justification, get approval, get budget, etc.
    2) The Project would plan for all work that needs to be done, such as what "Release" (i.e. Version) of the software will need to be deployed
    3) The Release will yield planned Changes to "all" your environments that must be documented, tested, etc., and that must be executed as part of the Project. In other words, thing in your environment will have to "change" in order for the Release to work properly (new software, new machines, modifications to existing software, modification to exist servers, etc.)
    4) As the Release progresses through its environments (Dev, Integ, UAT, Prod, etc.), planned Changes will be appropriately reviewed "before" application of those Changes to said environment.
    5) In earlier environments, it's usually smart to keep the CAB out of the process, as they will typically not understand the work, in detail, and only serve to slow you down. However, the CAB should get involved to understand and evaluate the Changes before they get applied to the Production environment, at very least.

If you're doing your jobs correctly, you will see Changes be planned for and executed, long before they need to go into your Production environment. The CAB will have a very clear view of their Forward Schedule of Changes and Forward Schedule of Releases.

It is important to understand that a Release will act as a roll-up of "many" Changes. In other words, a Release is a "coarser" entity, while a Change is far more granular.

It is also very important to understand that the deployment of a Release to one environment might entail Changes that are different than the Changes that are implemented in the next environment. So, for example, it is not always financially feasible for many companies to have a UAT environment that matches Production, identically. This means that Changes to UAT and Changes to Production may sometimes have to be different to get the Application (i.e. the Product Release) to act consistently.

I can tell you, in hindsight and with a great deal of painful experience that one of the biggest messes an enterprise will create for itself is to allow Changes to go through the Change management process without their being associated to formal Product "Releases". Remember, every Product has a Release (version) and every Release needs an accounting of incremental Changes made to it, which is really what the Change Management process is all about (ITIL doesn't clearly specify this, which makes me wonder if the authors really understand the correlation of the bigger picture).

It's also important to understand that the world of software development already works in accordance with this paradigm (Product->Release(s)->Changes(s)). It always has. And, if infrastructure engineering and support teams don't align with this, you will get instant conflict between them and your software developers & vendors, who do move to this drum beat.

Anyhow, I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL
Back to top
View user's profile Send e-mail Visit poster's website
dsemeniuk
Itiler


Joined: Feb 06, 2007
Posts: 41

PostPosted: Thu Sep 13, 2007 3:51 am    Post subject: Reply with quote

Hi Frank,

The one thing I didn't see mentioned here was when does an RFC get created to do this new project? Are RFCs just used to get approval to release something into an environment?

As well, you stated that Change Management/CAB should not get involved so much in the earlier environments but we are treating our Testing and Staging environments like production and are tracking in our CMDB the CIs that make up these environments. So we do want to be involved with changing or adding any new CIs to these environments.
Back to top
View user's profile
sparkz
Newbie
Newbie


Joined: May 10, 2007
Posts: 8
Location: Wellington New Zealand

PostPosted: Thu Sep 13, 2007 7:47 am    Post subject: Reply with quote

Frank,
thanks for your replies. I have the change process pretty much mapped out in the way you've already described. What I don't have is the mechanism for the business, or IT department, to decide where the boundries are for a piece of work. How do you decide what is a Project?

This is probably the biggest challenge I have at the moment, and the area which is causing the most contention in the organisation. I would imagine that this is normally something outside the boundries of the change process itself...(?) but I have inherited this as something that is part of the change process.
Once this is defined and working I would see this as more of a Project Management Office function.


Regards,
Mark.
Back to top
View user's profile MSN Messenger
jpgilles
Senior Itiler


Joined: Mar 29, 2007
Posts: 123
Location: FRance

PostPosted: Thu Sep 13, 2007 9:50 pm    Post subject: Reply with quote

Hi,

That looks a strange question to me.... Project Management is part of Change and Release Management.

What do you do before starting a project? You evaluate the needs, costs, benefits , constraints, impacts and then need to find authorization, budget and ressources ... This all part of the CM process (the CAB delivering the authorization or not based on costs vs benefits, impacts, and so on..).

What do you do after project delivery and implementation: you review the projet and the deliverables met what they were supposed to be: that is the Post Implementation Review in Change Management

everything PM activities in between are Change management / Release management relevant.

The grey area seems for most companies to determine is PM is part of:
- change management only
- release management only
- both change AND release management

I have no preference , provided it works efficiently. Personnaly I would say both. Project Management is just a method of conducting , preparing and delivering a (rather big) change to ensure it meets all the requiterements and expectations.

If you are going to replace ONE server, you will agree it is a CHANGE but not necessarily needs to be handled as a project (you may have some pretty standard ways of doing this type of operations). If you are going to change 1000 over different countries and continents servers (to cope with next application version for example) across different countries and continents, that is also a CHANGE, but you would better run this as a project...

This is just to highlight that CHANGE MANAGEMENT is not only related to software development. Projet Management neither !!!

to sum it up: PM is a method to conduct some changes (if you are running projects that do not derive from an approved change, I would seriously challenge your organization....)


best regards

JP
_________________
JP Gilles
Back to top
View user's profile Send e-mail
sparkz
Newbie
Newbie


Joined: May 10, 2007
Posts: 8
Location: Wellington New Zealand

PostPosted: Fri Sep 14, 2007 6:45 am    Post subject: Reply with quote

Hi JP,
thanks very much for this. It certainly makes sense and has given me a different slant on things. This would definitely work here and I guess the success of the process is then reliant on the correct members of the CAB.

I'll think about this further and relook at my model.

Regards,
Mark.
Back to top
View user's profile MSN Messenger
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.