When releases fail, we often point a finger at the release manager, expecting that person to make the necessary corrections to prevent similar failures in the future. In doing so, we miss the real target – the service delivery flow. This flow, with its many inputs, is in disarray in most organizations and the solution seems daunting. This article proposes that there is a simple, inexpensive, and self-healing approach to improving the flow of service modification.
When a Release Goes Bad
The scene is too familiar. The service desk, on the verge of panic, is swamped with increasingly irate calls. The boss is on a bridge line with a host of managers and technicians trying to restore order. The business units, demanding action, are banging on the CIO’s door and the echoes reverberate throughout IT.
Last night, IT distributed a major release of a critical business application. Today, users are converging on IT with torches and pitchforks. The business application update had an enormous impact on productivity and revenue. The impact continues as the business owner demands that the changes be “backed out” – a request that IT finds exasperatingly difficult to satisfy.
When the dust settles, it is not uncommon to see root cause analysis identify the numerous mistakes made in the “release”. The list might include:
Who is to blame? Release management? Of the 11 mistakes listed, 9 belong to groups outside release management. Yet, in many cases, release management will still take the heat. The purpose of this article is not so much to absolve release management but rather to bring understanding to the larger service lifecycle in hopes that the readers can address the true causes of release failures.
Know the River
Release and deployment management is just one part of a much larger lifecycle. Think of it as a port along a river. A business service starts out as an empty barge on the business dock. In ITIL terms, the manager of that dock, Business requirements management (BRM), loads the barge with service requirements. In the diagram, this is the “Identify” stage.
The barge makes a number of stops on its way down the river. Along the way, the manifest of the barge is equivalent to the seldom referenced (but, in some form, always present) service design package of ITIL.
When the barge, stacked with cargo, finally pulls into the release and deployment dock, the only issue should be how to transport the contents of the barge effectively and safely to the appropriate recipients. One could think of release and deployment as a trucking company. The truckers did not design or build the cargo. Nor are they to blame if the item in the package performs poorly.
I recently ordered a manual online. The package arrived in the expected time frame and was intact. As I read the manual, I noticed that an entire section was missing. Should I blame the trucking company? Of course not. Likewise, we should not hold the release management responsible for defects over which it has (by design and best practice) no control.
The following table might help to identify the “river ports” where the service barge might be picking up sub-standard cargo.
In order to effectively manage and improve the delivery of a release, we need to focus on three major points:
- Transition review
- Service delivery package
- Project charter
The objective of the transition review (post implementation review) is simple: Learn from your mistakes. When an organization first commits to regular PIRs, they may be a bit disorganized. As inputs and outputs become better defined, so will the overall process. The transition review is the spawning ground for improvement of this lifecycle.
Service Design Package
Although few enterprises seem to understand the concept of the SDP, it is, in my opinion, a brilliant addition to ITIL v3 2011. When organizations address the output of Transition Reviews, they inevitably make adjustments to the SDP because it is the mechanism for improving consistency, governance, and effectiveness for the service modification lifecycle.
In most shops, the service modification lifecycle begins around a table of senior managers. The beginning of a project needs to be less about hierarchy and more about process because this is not a hand-off; this is a flow. Four players are critical to the project charter.
- Business relationship manager – understands business requirements.
- Service portfolio manager – understands the pipeline and service catalog.
- Service level manager – understands issues that might impact service levels and process.
- IT architecture – understands the importance of a consistent framework.
With these, the organization understands business requirements, process, and infrastructure within the context of service delivery.
Completing the Circle
With the project charter, service design package, and Transition Review, we have completed the deming circle (Plan, Do, Check, Act).
Most shops fall short in planning and checking because these activities are poorly governed and too loosely integrated into the overall flow. As Yoda would say, “Without plan, no do; without check, no act.”
Start Small but Start Smart
When a release fails (especially when it fails in a spectacular way), the fault generally lies in the process. If, as I assume, this is common knowledge, why do these broken processes persist? Because most enterprises perceive that process optimization costs too much money, takes too much time and does not meet more immediate business objectives.This reticence is understandable given the typical consulting approach. A consulting firm will probably suggest starting with a comprehensive assessment that forms the basis for a massive proposal that drains resources from business-critical initiatives.
Instead, insist that any partner (consultancy) starts simply.
Enable the Flow to Manage the Activities
The degree to which this lifecycle is managed is inversely proportional to the likelihood of failure. The simplest way to manage a lifecycle is shown above in the Deming diagram. The idea is to implement the organic lifecycle flow and let the flow improve the subordinate activities.To accomplish this, we need to implement the flow with the associated roles.
Step 1 – Establish and Empower the BRM Role
The business relationship manager role usually exists in some tainted form. We need to plug this role into the organic flow. This role seeks to understand the needs of the business but, just as important, collaborates on those requirements throughout the service lifecycle. As mentioned above, the BRM is critical to project initiation.
Step 2 – Establish and Empower the Enterprise Design Coordinator Role
The enterprise design coordinator is really the key to success. There are three main tasks for this role. Aside from coordinating design and build activities at a high level (not an application development manager), this role also a) ensures that the input from the BRM is adequate and b) ensures that the service design package is complete and accurate.
Step 3 – Establish Policies and Procedures for Transition Review
The release manager (hopefully already in place) will collaborate with the BRM, design coordinator and stakeholders to create policies and procedures for transition review. The guiding principle for transition review should be that it examines service transition output (incidents, issue logs, metrics) to identify opportunities for process improvement.
Step 4 – Establish SIP Procedures
The output from the transition review will sometimes include a service improvement plan. The organization needs a standardized procedure for initiating and implementing an SIP.
Step 5 – Do it and Keep Doing it
We have created the organic flow. We only need to execute it. Each SIP will improve the effectiveness of the service modification lifecycle.
Note on Change Management
Change management, from an enterprise perspective, plays a significant role in controlling the flow of the service lifecycle. Most organizations perceive change management from an operational rather than an enterprise perspective – an outgrowth of legacy implementations of IT change requests. This narrow focus deprives the organization of the true power of this governance process. I would have enjoyed weaving into this article the benefits that a cohesive and integrated change management process could provide but it deserves a separate piece.
Release and deployment relies, for its success, on a number of upstream processes. Business relationship management and design coordination, both new to ITIL v3 2011, are key to managing the upstream service lifecycle. Though they may seem unfamiliar, everyone has implemented these processes to some degree but few have implemented them effectively. This oversight poses a risk because any enterprise that does not consistently manage the entire lifecycle does not control the operational outcome. In other words, every release is a roll of the dice.