Insights

Helen Wartnaby

Release Management pitfalls and common customer qualms

My last blog '10 Key factors for ensuring successful Release Management' covered Release Management basics for beginners. This blog continues the thread and talks about pitfalls that may be encountered in the process of release management and how to address customer misgivings about adopting a Release Management strategy.

So what are the pitfalls?

The biggest pitfall for Release Management is being able to control the release timeline. As a consequence of this the delivery of the release gets delayed - which leaves business stakeholders with a poor impression of Release Management through no fault of its own. There are many factors that can contribute to delays to the overall release schedule.  Some of those that are within the control of the Release Management team are as follows:

Late requests: Demands from the business for functionality that must be incorporated into an up and coming release may well delay the release drop date.  Successful Release Management relies on the ability of and the empowerment for the Release Manager to say no to such requests.

Critical Path projects: The biggest project within the release will necessarily dictate the release date.  If this project or any other project on the critical path delays then it is almost inevitable that the release drop date will be delayed.  The key to this is realistic planning and careful management of large or critical path projects within the release, and the management of business expectations for other projects or changes regarding the release dependency.

Other factors outside of the control of the Release Management team might include shifting priorities based on market conditions or the economic climate, or perhaps due to mergers or acquisitions.

Customer qualms

Customers may have misgivings about a full blown Release Management approach, not least because it is expensive to set up and manage. Typical concerns are as follows:

"But it's expensive to buy, manage and maintain 2 tier architecture..."

Yes - but perhaps worth it in order to avoid compromising ability to support the production environment. What if you need to implement an emergency fix to production, but are unable to do so because a project in progress has made a change in the development environment to the object that needs fixing? 

This is all about managing risk. If changes to the solution impinge on the current functionality and the production environment is subject to a high volume of change or service requests, then a fully fledged Release Management approach should be considered as a way of minimising the risk to the supportability of the Production environment.

"...And it's expensive to run a Release Management team"

True, however there are also economies of scale - certain project activities are managed for the release as a whole rather than at the individual project level - e.g. Training and Change Management, UAT and Regression testing, Transport / Configuration Management and Cutover. Only one role is thus required for the release, rather than one for each project or work package.

In particular, Transport co-ordination and sequencing across the whole environment rather than at project level simplifies the management of potentially large volumes of transports and reduces the risk of transport errors and resulting business process failures.

A co-ordinated approach to UAT and Training across all work packages ensures that users time can be optimised rather than receiving duplicate training or having to test similar functionality multiple times.

"But I won't get my new functionality as quickly...."

True, however it is usually the case that many business users will be impacted by the new functionality. The release provides a mechanism for an overall view of functionality to be implemented on a particular date - this facilitates business communications and change management. Once a release 'calendar' is established, there is visibility within the business as to when production functionality drops are planned to take place. 

"Isn't it much easier to deal with changes as they arise than packaging them for delivery as part of a release...?"

From a technical perspective this may be the case, however an ad hoc approach in releasing functionality risks changes getting made without full approval of the business. 

Additionally, testing of all work packages together in a single environment reduces the risk of errors in production - thus reducing the cost of re-work in production.

"Isn't difficult to control the Release timeline due to late scope additions or large projects within the release slipping?"

This risk is minimised by controlling the scope of the release and avoiding scope creep, and planning realistically for all work packages / projects in the release - especially the larger projects that will be on the critical path.

To sum up, Release Management is not for all organisations. Companies with stable SAP implementations (i.e. few change or service requests) who plan to implement occasional additions to functionality that does not touch the existing solution are not placing a great deal of risk on their production systems.  Release Management is not for these types of organisations. 

It is critical however for those organisations for whom change and service requests are frequent and who plan to implement extensive areas of new functionality that is closely associated with that already existing in the production environment.