|
|
Change Management is responsible for managing Change processes involving:
This means that changes to any components that are under the control of an applications development project - for example, applications software, documentation or procedures - do not come under Change Management but would be subject to project Change Management procedures. The Change Management team will, however, be expected to liaise closely with Application Management project managers to ensure smooth implementation and consistency within the changing management environments.
It is the Change Management process that produces approval (or otherwise), for any proposed Change. While Change Management makes the process happen, the decision authority is the Change Advisory Board (CAB), which is made up for the most part of people from other functions within the organisation. Note also that it is Configuration Management who is responsible for ensuring that information regarding the possible implications of a proposed Change is made available, and that these possible impacts are detected and presented appropriately.
There will be occasions when a proposed infrastructure Change will potentially have a wider impact upon other parts of the organisation (e.g. applications development projects or business operations), or vice versa. To mitigate possible negative impacts from either direction, it is imperative that the infrastructure and other Change Management systems are appropriately interfaced (see Figure 8.1).
Inputs to the Change Management process will comprise:
Activities undertaken will involve:
Outputs from the process will be:
Change Management is not responsible for identifying components affected by Change or updating Change records (the domain of Configuration Management), nor is it responsible for the Release of new of changed components (the domain of Release Management). The relationships between Capacity Management, Change Management, Configuration Management, and Release Management are illustrated in Figure 8.2.
Figure 8.2 - Relationship between Capacity Management, Change Management, Configuration Management and Release Management.
As an example of scoping, the following is extracted from 'A Code of Practice for IT Service Management - PD0005 - from BSI: Change Management comprises:
Emergency Changes are sometimes required and enterprises should plan for these carefully. They usually follow the Change process but some details may be documented retrospectively. Change records should be reviewed regularly to identify trends and assist the organisation to improve the service by identifying high-risk components. |
'Change' has many erudite definitions but possibly the most apt is the simplest:
Change is the process of moving from one defined state to another.
Everything changes and, in business, where life is sufficiently complex already, the reliance on information systems and technology causes management to spend an astonishing amount of time
Managing Change has become a full time occupation.
If Changes can be managed to optimise risk exposure, severity of impact and disruption, and of course to be successful at the first attempt, the bottom line for the business is the early realisation of benefits (or removal of risk), with a saving of money and time.
Although focused at the mid-range mark in the scale of things, the guidance in this chapter is adaptable - after all, planning, controlling, managing risk, minimising disruption, communicating, implementing and measuring are hardly exclusive to any one kind or size of organisation or infrastructure.
This chapter provides guidance on managing Changes that is scaleable for:
Chapter 5 of this book discusses the Incident life-cycle and in conjunction with Chapter 6, Problem Management, sets the scene for the inclusion of Change Management in these processes. Nevertheless, it is worthwhile considering the boundaries between Incident resolution and Change. An Incident is not a Change and a Problem may not lead to a Change. A Change in infrastructure management terms is the result of Problem fixing where there is 'a state different from a previously defined condition'. This may be manifested in a number of ways, both visible and invisible to the naked eye.
Here is an example: A PC breaks down and so is taken away and replaced with a new one. Infrastructure management demands that, following the service call and Incident logging, resolution and fixing, Configuration Management records have been properly updated. Service Desk procedures will ensure that the person who reported the Incident in the first place knows that the new PC, and any training and ancillary items that may need to go with it, have been ordered, and when they can be expected.
It is important to know the distinction between a Change request and a service request. Many organisations mis-classify service requests, such as the desire to change a password or perhaps to extend service hours, as Change requests; this results in a swamped Change Management process. The examples given are Changes, but Changes that can be filtered and managed more efficiently than using all of the processes described in this book.
One area that until relatively recently even infrastructure management neglected was regression or back-out strategy. The original guides certainly mentioned the issue of backing out from 'problem' Changes, but it is more and more important to think about back-out well before implementation. Very often, back-out is the last thing to be considered; risks may be assessed, mitigation plans cast in stone, but how to get back to the original start point is often ignored or considered only when regression is the last remaining option. The Change Management process should ensure that any Change plans include plans for back-out in the event of serious unforeseen problems.
If you merely inform applications developers and systems analysts that all Change is now under the control of a single Change Management process, you are unlikely to receive enthusiastic support. There are many good reasons for such a single Change Management process. However, the dynamics of Change to systems designs and to programs makes it well nigh impossible to take control of the Changes to the software at any time until systems-tested versions of unique programs, and sometimes suites of programs, are in the Customer acceptance testing phase.
In terms of progress of program development, it makes sense for Change Management to know what is going on, but day-to-day version control and so on is more sensibly left to the applications development team, with emphasis on good and rapid communications. The funding of Change Management and Configuration Management in applications software development may arise from program/project budgets (indeed, it is considered best practice in many organisations). Release of products to the operational environment is also better funded this way, in order to extend the scope of the processes without ballooning the budget of Service Management. For more information, see Chapter 9, Release Management.
Consider the implications for Configuration Management. Very few infrastructure management software tools are designed for controlling applications software development. In any medium-sized to large organisation, there could be a significant number of people writing new applications. At what level do you want to start with Configuration Management? Some options might include:
Hard-and-fast recommendations are not appropriate. You should decide for yourself in the light of knowledge of your business drivers, systems and resources. An organisation needs to make sensible decisions based on business drivers, risk, manpower, tools capability, organisational competence and the cost-benefit equation at the micro-level of Change Management and Configuration Management. If the decision is taken to control all Changes centrally, there will need to be a major investment in appropriate software tools and training. Please refer to Section 8.8 for more information.
The scale of the Configuration Management problem is clear; the scale of the Change Management problem is perhaps even worse, since the impact of business change should also be taken into account where it will eventually filter down to operational Change Management.
The Change Management process manages Changes to the day to day operation of the business. It is no substitute for the organisation-wide use of methods such as PRINCE2 to manage and control projects.
In later sections of this Chapter, you will read about CABs and their occasional role in assessing the need for Change, and the timescale and importance of Changes. Where appropriate, the CAB should be involved with program and project management teams to ensure that Change issues, aims, impacts and developments are cascaded throughout the organisation. One way in which Change Management can help Change planners is by building models of Changes and liaising with capacity planners to assess the impact of the models.
|
|
