9.4 Benefits and possible problems

9.4.1 Benefits

As organisations become more dependent on IT, the effective control and security of their computer systems assumes greater importance. Organisations should be able to cope with a high frequency of software and hardware Releases across the organisation without sacrificing IT service quality. The controls and mechanisms within Release Management help support this requirement in an efficient and economic manner.

The principal benefits of Release Management, when combined with effective Configuration Management, Change Management and operational testing functions are:

• a greater success rate in the Release of hardware and software and therefore an improved quality of service delivered to the business
• consistency in the Release processes of the hardware platforms or software environments
• minimisation of the disruption of the service to the business through synchronisation of Releases within packages involving hardware and software components from different platforms and environments
• assurance that the hardware and software in live use is of good (or known) quality, because the Releases are built properly, from hardware and software components that have been subject to quality control and effective testing, and have been constructed under Change Management
• stable test and live environments, because Changes are normally combined into Releases and so there should be fewer individual implementations
• better use of User resources because of combined efforts when testing new Releases - this also means that it will be easier to justify the cost of system-wide regression testing
• minimisation of regression-testing requirements, offering greater coverage than is possible with small Changes that occur frequently or too close together
• better expectation setting within the organisation on publication of a Release schedule in advance
• error reduction through the controlled Release of hardware and software to the live environment, e.g. avoiding incorporating an incorrect version into the Release
• a complete record (or audit trail) of Changes to the live environment is maintained, both of software distributions and of hardware Changes
• proper control and safeguarding of hardware and software assets, upon which an organisation may be heavily dependent
• an ability to absorb high rates of Change to the live systems, effectively and without adversely affecting IT service quality - this is achieved by releasing a large number of Changes together as a single, controlled and well-understood Release
• the ability to build and control the software used at remote sites from a central location
• savings in support costs through the ability to maintain consistent software over a large number of locations
• reduced likelihood of there being illegal copies of software in use at any location
• easier detection of wrong versions and unauthorised copies of software
• reduced risk of unnoticed introduction of viruses or other malicious software
• reduced time to Release and fewer delays
• fewer Releases to be rolled out to Customers
• smoother transitions of Releases from the development activities (projects) to the Customer's business environment.

As the efficiency and effectiveness of Release Management grows, the productivity of IT services staff is likely to increase. More importantly, productivity benefits are likely to be realised amongst end Users, as Releases should be fewer and better planned, with appropriate training and documentation of higher quality.

9.4.2 Possible problems

The potential problems in implementing Release Management are:

• There may be some initial resistance from staff who are familiar with the old procedures and who may not welcome change. To overcome this, the benefits of the new procedures should be carefully explained during an awareness campaign, and there should be a close working relationship with the team implementing the Changes.
• Experience has shown that those teams that are in most need of help with Release Management often have the least time to adopt it. One way round this is to look for minimal-impact ways to gain a foothold and to provide them with some hands-on assistance at the beginning.
• Circumvention of the Release Management procedures may be attempted. This needs to be dealt with firmly, particularly if it involves the installation of unauthorised software, as this is the most likely cause of viruses or untested software that make support very difficult and costly.
• Staff may also be tempted to bypass the standard procedures to install an emergency fix. This should be banned, and disallowed by software security rules as far as possible.
• There may be some reluctance to carry out a controlled build in the test environment, relying instead on copying over software from the development environment.
• In a distributed system, difficulties may arise if new versions of software or hardware are not installed and activated on time at remote locations. The use of software distribution tools, backed up by regular audits, can help avoid this problem.
• Some people (including IT management) may view the Release Management procedures as cumbersome and expensive. Nevertheless, they are almost invariably necessary to cope efficiently and effectively with software Changes.
• Unclear ownership and responsibilities between operational groups and development teams (project teams) may exist - for instance, there may be a lack of understanding about who is responsible for managing components of a Release at different points in the Release cycle.
• Insufficient resources available for adequate testing will reduce the effectiveness of these procedures, or a high number of variants in the live environment may limit complete testing.
• If sufficient machine and network resources are not available, then it may be impossible to build and test new Releases and equipment adequately, or in a timely fashion. Time needs to be allowed in testing for a Release to fail the first time and be reworked. Similarly, back-out procedures should be proven in a controlled test environment.
• A lack of understanding of the Release contents, build and installation components, can lead to mistakes.
• Testing in one area may be acceptable but may fail in another area - e.g. different infrastructure or parameters not set to the same values.
• Staff may be reluctant to back out from a Release, and there may be pressure to transfer inadequately tested software and hardware into the live environment.
• Poor, restricted or non-representative testing environments and procedures may exist.

In all cases, the Release Management plan and the principles and policies on which it is based may be subject to a publicity campaign at the outset and periodically thereafter in order to set expectations and goals.