Release Policy and Procedures | IT Release Management

Organizations embarking on the creation of a release management practice will need to create a documented policy and procedure that resources using the process will be able to reference to understand what is expected and what processes need to be followed. The release policy defines the scope, strategy, and standards of the release practice within the organization; it is the playbook for delivering a quality, operation-ready release. The release policy should be considered a living document and will continue to be revised and improved as the release practice continues to mature and as the organization assimilates the release process. Care should be taken when creating a release policy not to include concepts and standards that cannot be implemented due to lack of organizational maturity or readiness. In the same vein, however, those concepts and standards that need to be implemented must be included within the policy. 

There is a saying that you don't want to throw the baby out with the bathwater. Organizations that have successfully or have at some level been successful in delivering releases will have some good release practices that should be retained and incorporated into the release processes being developed. The practices that have been used by the organization may not be consistent or documented. These practices should be reviewed to determine their viability and what value they provide. Once this initial assessment has been done, these existing processes can be the starting point for process development and the basis for the standards that will be documented within the release policy. This is the second part of the strategy model—Where are we now? In addition to creating a basis for the creation of standards, using existing processes in some form will lead to fewer changes and create better acceptance of the new processes being introduced.

When creating a release policy or other deliverables within the process, three questions should be continually asked:

• What value does this provide to the user?
• Who is going to use the policy?
• How is it going to be used?

We have all seen processes that appear to be meaningless and the value they bring is questionable. These processes usually break down and fail. Being able to clearly articulate the value proposition of the process will increase the adoption.

Following this approach, the first thing the release policy must address is the purpose and the value of release management. Being able to document the defined strategy and objective, the guiding mission statement, and the defined scope will set the basis for the policy. The release policy should also include the organizational context for release management; this context will define the role release management plays within the organization and the developmental process. There are three roles that release management plays within the organizational context—guidance, facilitator, and governance.

Guidance

One of the primary functions of release management is to define the release process, manage the release, and provide guidance throughout the development of the planned release cycle. In a later chapter the use of the release lifecycle (RLC) will be introduced and discussed. The release lifecycle is a systematic approach that defines and provides a roadmap of the checkpoints and deliverables that need to be produced to provide a value-added release. Consulting with design teams throughout the delivery process provides for successful releases of applications and associated hardware. Release management works closely with the project management office (PMO) to provide training for the project manager's processes and the key deliverables throughout the RLC.

Facilitator

Once the release process has been established and implemented, there will be multiple checkpoints and deliverable reviews that will take place. These reviews will be managed and conducted by the project manager with release management to ensure the required activities and tasks are being completed to ensure the release schedule is being maintained. These reviews should be focused only on release deliverables and tasks; deliverables required by the PMO should be reviewed by the PMO and excluded from this review. Release management helps to facilitate these reviews and to identify any issues or conflicts between competing releases. Release management should have an enterprise view of all releases and can facilitate a review with competing project teams to assist with the resolution of any issues arising from scheduling conflicts.

Governance

The governance role within an organization is either a role that everyone wants or no one wants. The role release management plays should be clearly defined within the organization and documented in the release policy to ensure a full understanding. Generally, governance within the release realm pertains to the tasks related to the quality delivery of the release and the ability of the organization to support and operate the service to the designed service levels. These tasks and deliverables include, but are not limited to, different levels of testing, support documentation, service level agreements, and service continuity plans. These deliverables and tasks should be right sized for the specific release and described in the RLC.

Another governance role release management can play is in the area of regulatory compliance. In every industry and in every country there are specific regulations that need to be met, whether it is Sarbanes—Oxley Act (SOX), Health Insurance Portability and Accountability Act (HIPAA), Federal Deposit Insurance Corporation (FDIC), or JSOX, the Japanese version of SOX, just to name a few, and the release process can be designed to assist in complying with these regulations. How this can be done will be covered further in the release lifecycle.

Release Standards

The release policy and procedure document should also provide direction on standards and guidelines that need to be followed. The guidelines described in the release policy need to be created to ensure that release development aligns with the goals and objectives of the organization. The document should be generic enough so that it doesn't have to be revised frequently, but specific enough to provide the user enough information to use the process. These standards, guidelines, and policies must be created to fit the organization where they are being used. Many generic standards and definitions can be found in various publications; however, to be successful they must be tailored to the specific organization. The concept of the release lifecycle, which was introduced earlier in this chapter, will help development teams understand and use the standards, policies, and guidelines documented in the release policy.

Basic Concepts

The basic concepts of release management should be incorporated into the release policy. However, before they can be included in the policy, the concepts need to be customized to fit the specific organization. A basic understanding of these generic concepts is needed:

• Release models
• Release schedules
• Naming conventions

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.