Note: this was originally published in 2016 and explains the ITIL V3 lifecycle phase "Release, Control, and Validation (RCV)." In 2024, the ITIL 4, the concepts of RCV are integrated into various practices, notably Change Enablement, Release Management, and Service Validation and Testing, which are essential for managing and ensuring successful service changes, releases, and validations.  For a more detailed understanding, ITIL 4 Specialist modules like " Create, Deliver and Support " offer comprehensive coverage of these practices in a modern context. --- I was recently asked the following: “I want to take the “Release, Control and Validation” (RCV) class. As a Release Manager, I know it will help but I need to justify this for my manager. What is the value of taking this class?” Every organization can be effective with release and deployments. What is needed today is for us not only to get the job done but to do it efficiently. Efficiency infers that we deliv

Note: this was originally published in 2016 and explains the ITIL V3 lifecycle phase "Release, Control, and Validation (RCV)." In 2024, the ITIL 4, the concepts of RCV are integrated into various practices, notably Change Enablement, Release Management, and Service Validation and Testing, which are essential for managing and ensuring successful service changes, releases, and validations. For a more detailed understanding, ITIL 4 Specialist modules like " Create, Deliver and Support " offer comprehensive coverage of these practices in a modern context. --- RCV stands for Release, Control and Validate. These are critical activities that are required for every deployment. Proper Release, Control and Validation (RCV) is achieved as a result of integrated process activities. In today's dynamic business climate, service outages cause real bottom line impact to the business. Mature processes are critical in enabling IT organizations to smoothly transition new and ch

The question about how to manage virtualization and configuration items pertaining to the Cloud continues to challenge service management practitioners and managers who are trying to strategize and architect a working solution to provision business services.  Some would say the idea of the CMDB (Configuration Management Database) is dead because we use the infamous “Cloud”. Let’s start with a refresher about the structure and purpose of a CMDB and system and then move into how that relates to the management of virtual Configuration Items or Cloud services. Configuration Management System The key to a CMDB, or the sets of data that comprise your broader Configuration Management System (CMS), is “Relationships”.  When provisioning a service, the service provider must be able to manage and control all of the items necessary to produce “Value” to the consumer.  All elements in the end to end service that need to be managed and controlled are referred to as a Configuration Item

Knowledge Management provides value to all stages of the service lifecycle by providing secure accurate and up to date knowledge, information and data that is needed to manage and deliver services. Knowledge Management is particularly important within Service Transition since current and applicable knowledge is one of the key service elements being transitioned.  Effective Knowledge Management is a powerful tool for people in all roles across all stages of the service lifecycle. It is a best practice method for individuals and teams to share data, information and knowledge about all components of an IT service. Having the right information in the right place at the right time will enhance all stake holder’s ability to make informed decisions based on the most current knowledge about their environments. Successful management of data, information and knowledge will enable the service provider staff to have a clear understanding of who uses the services, how they use those servic

When an organization is planning on a major change that will incur significant cost, risk, time and engagement of resources along with organizational impact, it is best practice to initiate this activity through the Service Portfolio process.  Before this new or significantly changed service is chartered, it is important that it be reviewed for how it may impact the short, medium and long term support of other services currently being delivered, the pool of limited resources that will be utilized for this undertaking and on the change schedule itself. The Change Proposal is used to communicate a high level description of the change and is normally submitted to Change Management for authorization.  Authorization, however, is not an approval for implementation, but is a measure to allow the service to be chartered so design activity on the service can begin. In some cases the proposal may be created by someone other than Portfolio Management, such as the PMO or SMO. This high le

In today's dynamic business climate, service outages cause real bottom line impact to the business. There are documented best practice processes and known critical success factors and yet outages that throw support organizations into reactive firefighting turmoil are far too common. Mature processes with just enough control are needed to smoothly transition new and changed services into production, helping to ensure stability for IT and the business.  Most organizations will confirm that they do have Change and Release Management processes in place.  Service Providers will usually have some level of Service Asset and Configuration Management control.  There is generally a lot of buzz and focus on three core processes for Service Transition and the success and integration of these three are critical to business success.  Three Core Processes for Service Transition are: Change Management Service Asset and Configuration Management Release Management Most IT organizations

IT is a large and growing slice of the overall budget for many companies. That money spent on IT is anticipated to create business value and support business growth. However in many IT organizations, a considerable percentage of this budget and IT labor is consumed on managing of incidents. First, second and third tier levels of support along with support technology and tools can become expensive to retain and maintain. In fact this is unplanned work which inhibits value creation and business growth. Many people will advocate a solid proactive problem management process to eliminate the root cause of these incidents and I am right there alongside them. However, I think we need to look even earlier in the service lifecycle. The standard statistic that I see most often quoted is that up to 80% of all incidents are cause by undocumented and unauthorized changes.  So for the sake of this argument let us take that as our baseline and discuss critical success factors facing service tran