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
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.
Joined: May 10, 2007 Posts: 8 Location: Wellington New Zealand
Posted: Tue Sep 11, 2007 7:58 am Post subject: Change v Project
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.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Tue Sep 11, 2007 1:03 pm Post subject:
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
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Wed Sep 12, 2007 1:30 pm Post subject:
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.
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.
Joined: May 10, 2007 Posts: 8 Location: Wellington New Zealand
Posted: Thu Sep 13, 2007 7:47 am Post subject:
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.
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....)
Joined: May 10, 2007 Posts: 8 Location: Wellington New Zealand
Posted: Fri Sep 14, 2007 6:45 am Post subject:
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.
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
