Aug 7, 2015

Since the 2008 financial crisis, the financial services industry has been subject to an environment of intense regulatory pressure causing unprecedented levels of simultaneous change across all areas of financial services organisations. Previously, in low change environments, systems, applications and platform releases were scheduled ad-hoc in self-contained silos. In a high change environment, impacting multiple areas simultaneously, the risks associated with change increase substantially. Which measures can be taken to mitigate this increased risk? Scheduled release cycles are a vital tool change practitioners should use to mitigate this risk, maximizing efficiency and successfully delivering their change portfolio. The approach that organisations employ to implement and manage change, and transition to new processes and systems will be critical to their future success.

What is a scheduled release cycle?                                                                                         

A scheduled release cycle dictates that an organization can only make releases into production during pre-determined deployment windows. These deployment windows will coordinate multiple projects’ changes within one release into production. The frequency of scheduled release cycles and deployments will depend on factors such as risk level and volume of change.

What are the benefits of scheduled release cycles?

Every individual or team impacted by the change will be conscious of the release window, increasing awareness and accelerated detection of deficiencies across the organisation. Scheduled release cycles improve resource management and reduce costs by optimising the use of resources across common change management activities such as planning, training and “go-live” activities.

Testing is a critical phase in every project to manage and mitigate the risks of the changes being proposed. In an environment with multiple regulatory compliance deadlines and budgetary constraints, testing, in particular regression testing, is often compromised. Following scheduled release cycles, regression testing can be managed across multiple projects simultaneously minimising the associated risks.

tl pic

Figure 1.0 demonstrates how 8 projects (A to H) can be managed effectively and efficiently across 2 scheduled monthly release cycles optimising regression testing and “go-live” activities. It is imperative the latest code base must be deployed into the central regression environment by each project targeting the release date. Testing too soon and on a code base that is not locked down may lead to invalid testing, significantly increasing the risk of undetected issues when the code base is released into production.

What is the best frequency of a scheduled release cycle?

The frequency of scheduled release cycles is often dictated by organisations appetite for risk and the volume of change. Annual or semi- annual release cycles will struggle to meet high demand for change. As this demand for change increases and pressure builds, an organisation may choose to adopt quarterly or monthly release cycles.

Quarterly release cycles are often cleaner than monthly, with less overlapping testing phases, more stringent release entry criteria, reducing the risk of invalid testing. Although, in a high change environment the scope of quarterly releases may quickly reach their risk ceiling, which may result in already signed-off changes being de-scoped to reduce deployment risk. Monthly cycles will facilitate more change but result in overlapping resources and, if the timelines of a project slips, limited time for correction before the next scheduled release cycle.

Are scheduled release cycles the only method to successfully mitigate risk in a high change environment?

No. Introducing the right governance and control bodies to manage and monitor the release cycles is as critical as implementing the release cycle themselves. Change Control Boards assess any changes to a project’s codebase after it has been merged into the central regression environment and before it is released into production. An effective Change Control Board will be made up of project managers and application specialists who have the required expert knowledge of the application undergoing change. In parallel, a robust programme governance framework is essential to consistently monitor and manage the lineage and interdependencies across projects so that risks can be mitigated holistically across the entire change portfolio.

In a high change environment, scheduled release cycles are a powerful tool to mitigate the risks associated with a large Change Book of Work. By optimising change resources throughout the release cycle and increasing awareness to users impacted by the change, scheduled release cycles will minimise the risks of multiple simultaneous change projects. With the continued regulatory and cost pressures, it is unlikely that the amount of change across organisations will slow down. Implementing consistent organisation-wide programme and project governance frameworks will force organisations to manage their change more effectively ensuring successful delivery while reducing the risks associated with this amount of change.