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
0 comments:
Post a Comment