Posted: Thu Mar 01, 2012 12:34 am Post subject: Making the connection between Project and ITIL Change Mgt
Hi fellow ITILers,
I am currently working on implementing Change, Release & Configuration Management processes for a client.
Although I believe I have understood most of the concepts for each of the processes distinctively, working out on how they integrate with each other tends to prove me wrong.
Regarding Change management, any changes can be initiated through strategic, design, transition, operational and continual improvement needs.
Considering a basic operational change such as firewall rule modification or a VM creation. The regular Change process approval would consider: Recording, Reviewing, Prioritizing and Classifying Change to select the adequate Change Authority which would review and assess impact and risk and then approve it only if required information is provided e.g: implementation, test and backout plan.
Then, change is being scheduled in the FSC, taking into account other changes and maintenance window so that implementation is likely to impact the least the services.
*First Question*: What happens if wished implementation dates do not match resource or maintenance window availability? Is the change directly rejected or is there somehow a discussion after change authority’s feedback? Or should the Change Manager had already remarked this detail and organized the Change Authority and the Change Owner meet and discuss this with all stakeholders? Or, after being rejected, can the Change Owner propose a new date?
Now, let’s consider it is “approved”. Here, whether it is a firewall modifications or a VM creation, it is more likely to be passed to “Authorized” status because the implementation would be directly processed provided we have a clear implementation, test and backout plan as mentioned above.
Finally, after implementation, the change would be reviewed and closed.
This is a simple example and I am quite sure I have not left out any details.
But what happens if the Change comes from a strategic/design perspective? Many people tend to say that ITIL and Project are meant to be integrated while I believe ITIL is meant to replace projects by providing a more “service” oriented perspective. From an IT standpoint, a new business request such as an application would be the addition of a new service and all the considerations would have to be made at the Service Strategy level.
Then, design would be considered as to the “Service Design” level with the SDP being the final specification package referencing all the documents required for introducing the service into the live environment.
Then, we would have to consider Service Transition for building, testing and release and deploy this into the live environment.
And then, Service Operation would take over.
Now, I often read that release and deployment is to be associated with new software release… Which, as I said don’t quite fit the equation considering everything I wrote before is true…
So, considering all of this… Where does truly fit Change and Release deployment into all of this?
When considering addition of a new service or even a new business application, it is a strategic decision. A RFC, which would be more likely to be a BRFC (Business Request for Change) with more financial aspects would have to be considered. ITIL 2011 addresses this point, I believe, with the notion of Change Proposal.
But, then, what happens to the Change Management process for a “simple” change described above? A unique change process would not work at that point because at a strategic level, many “approval” steps might be required before “authorizing” to implement a change.
So let’s say we decide to go with a RFC attached to a Change Proposal and some idea of a planning. Change Authority would assess it and approve the project for resource and time allocation. A Project Manager would be chosen and the whole planning / designing phase would start (which I would assimilate to Service Design?)
SDP would give every single required piece of information for Service Transition, right ?
So a RFC would be raised to implement this into ‘live environment’. Assessing if everything is there to consider further resource allocation for build, test and production deployment. In that particular case, there would be an approval phase for build & test or for rather for passing it to Release & Deployment process until it is build, tested and authorized for ‘live’ implementation.
Then, in the end it would be reviewed and closed appropriately.
Once again, if I got it right, it means that there are several levels of Change Management which make sense but how do we relate these ? I mean, it goes back to the definition of one big change which would generate several smaller change.
A Strategic RFC would most probably spawn a Service Design Change which would spawn a Service Transition change up to the ‘live’ environment where it could encounter Service Operational changes.
While Strategic / Service Design changes look manageable to me. Service Transition changes might include many complex and sub-changes under Release & Deployement process ranging from software licenses, environment creation, passing a release from dev environment to further test and pre-prod environments etc.
What is the approach for such big “projects” ? Once SDP is delivered, do we consider that when the Service Transition change is raised, a detailed scheduled and implementation, test and backout plans are provided so that it all sub-changes / tasks are approved alongside and considered into the FSC ?
Do we have to consider several level of Change Management separately? I remember one of the master ITILers telling ITIL Change Management is different from "Project Management"...
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Thu Mar 01, 2012 3:51 am Post subject:
Phew! too much for me.
Your "first question":
you are thinking backwards. Yes changes should be scheduled for least disruption and greatest chance of success, but no it is not logical to reject a change because it is required to be applied outside of maintenance or change windows. Either you obtain agreement to move it to such a window or you accept that it is too important to be so constrained. The business imperative must take precedence.
Now, the rest:
Change Management is not a substitute for project management and nor is vice versa.
Remember that ITIL (or ITSM) Change Management is focussed on changes to the service or that impact service or both. Certainly I have argued before that it makes sense to ensure that a new development will actually be able to be run within the infrastructure before it is developed, but the actual development is a project that has to take account of how the change will be effected, but not driven by change management.
There is a certain looseness in the way the term project management is used in IT. It is often linked directly to development and thought of as the province of developers. Properly it is the province of project managers and is just as applicable for any activity that requires planning and control of resources and events.
I think what you really need to consider is not a multi-layered Change Management process, but a diverse approach to projects according to their scale and business significance.
It is possible, and probably wise, to regard any change plan as a project. The project management activity is not the change management activity, because the project management is about doing it right and the change management is about defining what right is in each case. Taken this way, change managment remains the relatively simple concept it needs to be.
A project, for me, is required for any legitimate activity for which there is no predefined procedure in place. And any project affecting service must be carried out with due regard to the requirements of service management and conform to all relevant policies, rules and defined actions of your service management system (and higher levels also, of course). _________________ "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
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