Skip to main content

Why RCV?

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 deliver value, but that we design and deliver services, BETTER, MORE, FASTER THAN EVER BEFORE and at the same time we are being COST effective.

The role of Release Manager, although it is central to the release and deployment process, is much broader in scope than many organizations or managers realize.  This role in Best Practice is separate from Change Manager and from the actual Validation and Testing Manager or even the Change Evaluation role.   Frequently these roles will be assigned to one or more persons.  It does not mean that you have to open several new req's or that you will have to replace people.  What this does mean is that a clear and concise understanding of these processes, roles and functions must be clearly understood in order for organizations to really reap the benefits that they expect from change and release efforts.  Not only do we need to understand the dependencies, but also the workflow of how we can quickly interface with the various functional teams to respond quickly.  Without the proper knowledge and skill for these best practices, an organization could overtime improve but will be less likely to reap the type of optimization and benefits that they had hoped for. Everyone will agree that we can always do better with what we have.

The course Release Control and Validation (RCV) provides in-depth knowledge of the ITIL RCV areas: Change Management, Release and Deployment Management, Service Validation and Testing, Service Asset and Configuration Management, Request Fulfillment, Change Evaluation and Knowledge Management; most importantly the roles and the process interfaces and dependencies.  Best practice can help get the bigger picture, identify gaps, and allow for the practitioner to be enabled for success.   Business requirements are dynamic and we (throughout the design & delivery) must also have processes and models in place to meet those constantly changing business requirements.

In summary, the RCV processes, integration and knowledge enable:
  • response to CHANGING Business Requirements
  • consistent and Repeatable Workflow that result in and successfully deploy faster into the   environment
  • your staff and your organization for real success resulting in less rework and greater productivity
  • results in cost savings for the business
  • the ability to deploy changes quickly with less defects and therefore less business and customer disruption
  • risk reduction while complying with governance and audit requirements 
  • overall improvement in quality resulting in increased value for consumers

 For more information on Release, Control, and Validation:  click here

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…