End-to-end projects and programmes have been supported by life-cycle methodologies (processes) and Enterprise Management platforms (tools) such as MS project for many years. This article looks at best priactices for release management in banking.
Projects and programmes are an investment risk, viewed through a quality and performance lens, right up to the point of release. At this point, it becomes an operational risk and, where core systems are impacted, they become a major operational risk and vulnerability for the bank. The majority of major incidents find their root cause in some kind of change.
What is a Release event?
Big projects and programmes that are technology enabled typically require core system processes to be suspended so that new or enhanced services can be released. Data is often imported or migrated and live confidence testing has to be performed efficiently and effectively to meet sign-off criteria. Robust plans have to exist for a “go forward” or a “go back” outcome of Go/No Go decision.
Release Events have limited time windows of opportunity. End of month, Bank Holiday weekends all require the mobilisation of a large organisation out of hours. The cost of failure is high on many levels.
A “Go Back” decision is effectively a Major Incident in terms of recovering a BAU position back to a Start of Day position for next working day.
Release Management Events are made up of highly orchestrated multi-threaded events and activities taking place in the spectrum of hours, minutes and seconds, rather than the years, months and days that the broader project would have been managed by. Success can be contingent on being able to make key decisions when confronted with the unexpected, for which there is only a limited amount time to analyse and to make decisions on.
The support and professionalisation of this area is a gap that allows significant operational risk to persist. Support is required to ensure Release Management events do not lead to major incidents and do not waste precious release slots. In addition, many Release Managers are placed under a significant level of personal risk, due to the use of existing methods and toolsets. Conduct risk protection for the bank or organisation and the Release Manager is required. These events should not continue to be supported by spreadsheets, email updates and protracted rounds of status calls.
5 Best Practices
Release Management Events need to have a clear identity of their own and must be identified as a specific event, with the PMLC/SDLC and not just a set of activities bolted on at the end of the project plan. The Release Management Event requires its own detailed planning, managed by dedicated Release Manager who is accountable to the sponsors of the events. The Release Manager will establish the quality gates that the project will need to have satisfied before moving into RM.
A Release Management Tool needs to provide a planning capability that is simple, intuitive and accessible to the contributors, stakeholders and sponsors associated with the release. It is not a complex Gantt Chart with hundreds of tasks and inter-dependencies but a focused plan on the risk events and milestones that take us through to a Go/No Go decision. The planning capability must have the ability to model and assess the impact of delay to support “in-flight” re-planning.
Collaboration and Communication
The creation and execution of a Release Management Plan (RMP) requires a high level of collaboration and communication, managed by the Release Manager and supported directly by RMT tools. This should provide an integral dynamic approach for providing real-time status, the facilitation of conference calls and SMS/internal Instant Messaging and effectively a mission control for the RME.
The RME can be a major risk event and therefore there is a need for industrial strength risk and control processes and capabilities. These must underpin the accountability and responsibility of all contributors, stakeholders and sponsors. This includes CRAID management functionality and the ability to record all key decision making, as well as a repository to store the artefacts and data points that underpinned those decisions.
The concept of Post Implementation Review is now somewhat outdated and these activities now go beyond reviewing what simply did and didn’t go well. The tooling needs to support knowledge-based continuous learning and provide a “black-box” capability. This must support forensic analysis of the event, particularly where we are faced with conduct risk and reputational risk questions associated with post-release major incidents. There is a need to be able to “rewind and replay” the critical areas of decision making.