Basic Concepts | IT Release Management



Understanding the basic concepts of release management will provide the foundation on which the practical utilization of release management will be built. Understanding how release management interfaces with various aspects of service delivery, service operation, and all of the Information Technology Infrastructure Library (ITIL) functions within the lifecycle to build a release practice will strengthen the implementation. It is necessary to have a sound understanding of the basic concepts of release management to understand the value they bring to the process. To be effective in practically implementing release management, it is not only important to understand the basic concepts, it is also important to understand the activities that enable them. When implementing an effective release practice there is a need to understand how release activities relate to other developmental processes such as project management, quality assurance testing, technical architectures, and other supporting technical verticals, and having this understanding strengthens and sustains the practice.

Objective and Mission

The basic definition of release management is ensuring that all aspects that are related within an IT service are considered when creating, building, and implementing a new or subsequent release of that service. This definition can also serve as the objective of release management. If this was to be expanded, words such as repeatable, controllable, and scalable could also be used. So if asked what the objective of release management is, the answer would be:
Release management ensures all related components of an IT service are considered when the service is created or modified and provides activities that are repeatable, controllable, scalable, and sustainable.
This objective will differ from other objectives found for release management in that it gives consideration to the concepts that focus on being able to sustain a quality process, namely reusability, control, and being able to scale release activities. After all, creating a process that cannot be sustained either because it is too complex, too laborious, not right sized, or does not have perceived value, is a waste of valuable resources. In addition to reusability, controllability, and scalability being important components of sustainability of the process, they are also important to controlling the cost of release development.
Within the objective, the phrases "ensures that all related components" and "are considered" are key in understanding the role that release management plays within the delivery of quality releases and have an impact on the operational stability of the service. Ensuring that all related IT components of the IT service that are being designed or modified areconsidered defines release management's holistic approach to the delivery of services, which enables the business to meet its strategic goals. In a holistic approach, release management functions in several capacities—as an enabler, in a consultative capacity, and through governance; balancing these roles can be different in each organization depending on the culture and maturity. The actual role that release management plays in each organization is one of the first points where there is a departure from the theoretical to the practical.
Creating an organization-based mission statement describes how release management fits within the specific organization. It plays an important role in the assimilation of release management and promotes ownership of the practice. The generic mission statement of release management is:
Delivering quality, operationally ready releases that will improve the day-to-day operations of IT services enabling the business to meet and exceed their strategic goals and objectives.
This mission statement is simple but calls out the need for the delivery of quality and tested releases. It also sets the expectation that a release of existing IT services will be an improvement to existing functionality and must have tangible benefit to the business. In the most simplistic terms, the mission statement sets forth three significant questions that should be asked when considering whether a release should be done.
  • Is there benefit to the business? Will the release enable the business to accomplish a strategic goal, increase revenue, improve customer satisfaction, or solve a specific business problem?
  • Can the release be planned, built, tested, and delivered within the required cost, time, and quality requirements?
  • Will the new functionality of the IT service improve the day-to-day operation of the business service or will it increase the complexity?
If the answer is "no" to any of these three questions, then the organization should take a serious look at why the release is being built. It is not uncommon for an IT organization to continue down the path of implementing new functionality for a service because there is a perception that it is good for the organization without really understanding how the service is being used. Simply asking these three simple questions before embarking on the creation of a new release can save a lot of time and money. If the answer to these questions is "yes," then a more in-depth analysis should be completed to ensure there is enough return on investment (ROI) to proceed with the release.
A basic concept in creating a strategy for implementing a release practice is creating a vision of what the end practice will look like once it has been created and how this vision is going to be achieved. ITIL introduces a simple strategy model that uses four questions that should be asked when embarking on creating or improving a process: Where do we want to be? Where are we now? How are we going to get there? How do we know we got there?
The first step of this model (see Figure 1) asks "Where do we want to be?" These six simple words should cause the organization to really examine their internal processes and create a vision that will drive the creation of the process. These decisions should be agreed upon by key stakeholders since this will drive strategic decisions and directions. Once this strategic decision has been agreed upon, the mission statement and objective can be created and used to communicate the strategy. The mission statement and objective statement should also be used as the guiding principal when creating the process and practice; it should be referred to often to ensure that the developmental activities remain aligned with the organization's strategy.

 Figure 2.1: Simple strategy model.

0 comments:

Popular Posts