|
|
As well as managing the Change processes and procedures, Change Management has a responsibility for managing the interfaces between itself and the other business and IT functions. A sample process model of best practice in Change Management is encapsulated in this guidance. However, it should be apparent that certain processes are mandatory for best practice - for example, Change logging, Configuration Management updating, and impact analysis.
The way in which an organisation decides to implement the Change Management process is however, to a large extent driven by the resources available (time, priorities, people and, above all, money).
Change Management should plan the implementation of operational procedures for the activities described in this section, or amend any existing procedures to best conform to these guidelines. Figure 8.3 provides a flowchart of these procedures.
As mentioned in Paragraph 8.3.4, process models provide a richer picture than a flowchart but require greater understanding and are therefore discussed later in this guide in a case study.
Procedures for documenting RFCs, using standard forms, email forms or intranet screens, should be decided. Where a computer-based support tool is used, the tool may dictate the format. Where no standard is imposed by a support tool, or if a paper-based system has to be used, it is recommended that the items shown in Paragraph 8.3.1 be included on the RFC form.
It is further recommended that all members of the organisation be authorised to request Changes. Otherwise, innovation might be stifled or important concerns may go unreported. Even so, where there are large numbers of Users, it is suggested that User requests should require signature by a senior User manager prior to submission. This will filter out any requests that do not have the support of the wider User community, or are impractical, and help collate similar or identical requests, thus reducing request volumes. However, User managers should also be careful not to stifle innovation or discourage staff from proposing Changes.
All RFCs received should be logged and allocated an identification number (in chronological sequence). Where Change requests are submitted as a resolution to a Problem record (PR), it is important that the original PR number is retained so that the link between the Problem and its resolution is readily apparent.
It is recommended that the logging of RFCs is done by means of an integrated Service Management tool, capable of storing both the data on all CIs and also, importantly, the relationships between them. This will greatly assist when assessing the likely impact of a Change to one component of the system on all other components. All actions should be recorded, as they are carried out, within the Change Management log. If this is not possible for any reason, then they should be manually recorded for inclusion at the next possible opportunity.
Procedures need to specify who has access to the logging system and what the levels of access will be. Normally, the system is open to any authorised personnel to create, or add reports of progress to an RFC (though the support tool should keep Change Management aware of such actions). However, only Change Management staff, or Configuration Management support staff if Change Management is an integral part of a Configuration Management system, should be allowed to close an RFC.
The procedures should stipulate that, as Changes are logged, Change Management should briefly consider each request and filter out any that are totally impractical. These should be returned to the initiator, together with brief details of the reason for the rejection, and the log should record this fact. A right of appeal against rejection should exist, via normal management channels, and should be incorporated within the procedures.
Every RFC should be allocated a priority that is based on the impact of the Problem and the urgency for the remedy. This priority rating is used to decide which Changes should be discussed and assessed first, either by Change Management or by the CAB if necessary. Change Management should be responsible for assigning this priority. The priority of RFCs ideally should be decided in collaboration with the initiator and, if necessary, with the CAB; but it should not be left to the initiator alone, as a higher priority than is really justified may result. Risk assessment is of crucial importance at this stage. The CAB will need information on business consequences in order to assess effectively the risk of implementing or denying the change.
The following priority ratings are provided as examples only. Many software tools allow a wide range of priority ratings to be set.
RFCs will have already been annotated with the priority defined and agreed within the organisation, which is a function of the impact and urgency of the Problem, to indicate the order in which they should be 'fixed'. This 'severity code' should be reviewed and (unless there is a good reason why not) should be used as a basis for the Change priority. Timeframes for each priority level should be predetermined and escalation processes defined.
The issue of risk to the business of any Change should also be considered prior to the approval of any Change. Change Management should examine each RFC and decide how to proceed based on the (predefined) category into which the RFC falls. The categorisation process examines the impact of the approved Change on the organisation in terms of the resources needed to effect the Change. Note that the structure and complexity of these categories will very much depend on the needs of the business, including the range of priority ratings identified (see Paragraph 8.5.3).
The prioritisation process above is used to establish the order in which Changes put forward should be considered. Any of the example priorities given might apply to a Change that falls into any of the example impact-assessment categories below. Where minor Changes are involved, Change Management can delegate the authority to approved specific parties, such as Service Desk personnel. However, adequate reporting structures should be put in place; while authority can be delegated, accountability cannot.
Example categories are set out below. It is expected that the majority of RFCs will fall into the first two example categories.
Change Management should have delegated authority to authorise and schedule such Changes, but these should be logged so that:
Recording every Change in summary helps to deliver an effective and efficient service to the Customer by allowing wastefully repetitive tasks to be spotted and eliminated. If Change Management has any doubts about authorising any such Change, the Change can be referred informally to members of the CAB for a wider assessment.
Depending on the urgency of the Change to be made, Change Management should decide whether to talk to members of the CAB or to convene a CAB/EC. Prior to any meeting all documentation should be circulated for impact and resource assessment.
Where a major Change pertains directly to IT, the RFC should be referred to the organisation's top Management Board or other appropriate body for discussion and a policy decision. Such Changes, once approved should be passed back, perhaps via the CAB, for scheduling and implementation.
It should not be necessary to insist on face-to-face meetings; much of the assessment referral process can be handled electronically via support tools or email. Only in very complex, high-risk or high-impact cases will a formal CAB meeting be necessary. It is, however, a good idea to schedule a regular meeting - say every six months, or when major projects are due to deliver products. The meetings can then be used to provide a formal review and sign-off of approved Changes, a review of outstanding Changes, and, of course, to discuss any impending major Changes. Where meetings are appropriate, they should have a standard agenda.
A standard CAB agenda should include a review of:
|
CAB meetings represent a potentially large overhead on the time of members. Therefore all RFCs, together with the FSC and the PSA, should be circulated in advance, and flexibility allowed to CAB members on whether to attend in person, to send a deputy, or to send any comments via Change Management. Relevant papers should be circulated in advance to allow CAB members (and others who are required by Change Management or CAB members) to conduct impact and resource assessments.
In some circumstances it will be desirable to table RFCs at one CAB meeting for more detailed explanation or clarification before CAB members take the papers away for consideration, in time for the next meeting.
Change reviews are discussed further in Paragraph 8.5.12.
When conducting the impact and resource assessment for RFCs referred to them, Change Management, CAB, CAB/EC or any others (nominated by Change Management or CAB members) who are involved in this process, should consider the following items:
Certain Changes that do not affect the specification of CIs - for example, a hardware repair - may not need to be assessed for impact in advance. However, it is recommended that Changes intended to correct software errors should be subject to formal RFCs and impact assessment.
Based upon these assessments, and the potential benefits of the Change, each of the assessors should indicate whether they support approval of the Change. CAB members should also decide whether they are content with the priority allocated by Change Management and be prepared to argue for any alterations that they see as necessary.
CAB members should come to meetings prepared to make decisions on which Changes should go ahead, based on the priority assessment of the Changes. The CAB should be informed of any Changes that have been implemented as a Work-around to Incidents and should be given the opportunity to recommend follow-up action to these.
Note that the CAB is an advisory body only. If the CAB cannot agree to a recommendation, the final decision on whether to authorise Changes, and commit to the expense involved, is the responsibility of management (normally the Director of IT or the Service Manager, or the Change Manager as their delegated representative). The Change Management procedures should specifically name the person(s) authorised to sign off RFCs. Depending on the nature of the Change, references to Service Level Agreements may be required. In any event, Customer sign-off will be required at some point
The culture of the organisation in which you work will, to a large extent, dictate the manner in which Changes are approved. Hierarchical structures may well impose many levels of Change approval, while flatter structures may allow a more streamlined approach.
Formal approval should be obtained for each Change from the Change authority. The Change authority may be Change Management, the Service Manager, or some other nominated person or group. For low risk Changes, the Change authority may choose to be informed of Changes authorised, rather than be involved in authorising each Change individually. The levels of approval for a Change should be judged by the size or risk of the Change. For example, Changes in a large enterprise that affect several distributed groups may need to be approved by a higher-level Change authority.
There are three principal approval processes that should be in place in the Change Management process: financial approval, technical approval, and business approval. Financial approval indicates that the cost of a Change has been assessed and that it is either within approved budgetary limits or meets cost - benefit criteria that may have been set for Change approval. The technical approval stage is an assurance that the Change is feasible, sensible and can be performed without inappropriate detriment to the services provided to the business. If the technical experts are required to provide cost estimates (as is the case in many organisations), then this phase needs to precede financial approval. Customer approval is necessary to ensure that the business managers are content with the Change proposals and the impact on their business requirements.
Although it may be better (or advisable) to implement one Change at a time - for example, in order to simplify diagnosis should an error occur - this is not usually practical. For instance, a hardware Change may require an operating system Change to support it; applications software may need to be changed so rapidly that a policy of 'one Change at a time' is impracticably slow; or a simple software Change may require simultaneous introduction of new documentation, procedures and training.
Consider also, as a further example, the number of concurrent Changes inherent in the introduction of a new standard desktop configuration. Where concurrent Changes occur, they should still be packaged into a Release so that the whole thing can be backed out from if problems occur. A packaged Release should be considered as a single Change from this point of view, even though it may contain many individual Changes, because it will either be implemented or backed-out as a single Change unit.
Wherever possible, Change Management should schedule approved Changes into target Releases and recommend the allocation of resources accordingly. There is clear continuity between the Change Management and Release Management processes. Release Management processes impact upon the Change Management process and, in particular, have a role in developing and maintaining standard Changes that introduce new or revised software and hardware into the infrastructure. As Releases are the manifestation of Changes, the Change process initiates the Releases under the agreed, documented and maintained Release process.
Wherever possible, software Changes should be implemented in the form of packaged Releases. It is very important to have a clearly defined software product Release strategy that interfaces to the Change Management system. For further information on this, see Chapter 9, Release Management.
It is also important to limit the size of a Release to manageable proportions, especially as it is unlikely that any Release will be completely fault-free. It follows that the larger the Release, the more effort will be required to identify and address any new errors. It also follows that there will be a correspondingly larger effort required in support activities, such as Service Desk calls, following a new Release.
It is recommended that Change Management issue FSCs. FSCs should include details of all Changes that have been authorised for implementation over a previously agreed (with the business) period, and the Release(s) that they have been allocated to. Note that some organisations will have clear plans for the short term and less detailed plans in the longer term, all of which need to be included in the FSC. Brief details of (probably major) Changes planned for the next two years should also be included. The FSC should be distributed to all Customers and Users or their representatives, application developers, service staff including the Service Desk, and any other interested parties. Distribution of FSCs outside Service Management should be done via the Service Desk or Customer liaison process.
Change schedules should be widely distributed since the proposed Changes and their timing will affect planning and practices in many areas, both within and outside Service Management. Promulgation outside Service Management will usually be through the Service Desk and the Service Level Management and Customer Relationship Management. Within Service Management, access to the schedule should be provided to all processes. Change Management should reinforce this information with a proactive awareness programme where specific impact can be detected; such as anticipated impacts upon Capacity Management, Availability Management or other processes.
It is most important to take into consideration the business needs of the organisation in the construction of any schedule, bearing in mind both the needs of the Customer and the needs of the end User.
Authorised RFCs should be passed to the relevant technical groups for building of the Changes. This might involve:
Change Management has a coordination role, supported by Release Management and normal line management controls, to ensure that these activities are both resourced and also completed to schedule. Release Management has a more important role in smaller Changes, such as when applications software development teams provide Configuration Management installation and back-out instructions/files.
It is important to ensure that the same standards and methods that were used for an original component are again used for the Change. Back-out procedures should be prepared and documented in advance, for each authorised Change, so that if errors occur after implementation, these procedures can be quickly activated with minimum impact on service quality.
To prevent Changes from adversely impacting on service quality, it is strongly recommended that Changes be thoroughly tested in advance (including back-out procedures where possible). Testing should include aspects of the change such as:
This advice is particularly relevant to the desktop environment, where constant technology updates take place. In many cases, this will require a separate 'test environment'. It is recognised that it is not always possible or justifiable to fully test all Changes in advance; it may be possible in some instances, though, to use modelling techniques to assess the likely impact of a Change instead of, or in addition to, ordinary testing.
Change Management has an overseeing role to ensure that all Changes that can be, are thoroughly tested. In all cases involving Changes that have not been fully tested, special care needs to be taken during implementation. Change Management should assess the risk to the business of any Change that is to be installed without complete testing having taken place. Testing should also include adequate regression testing to ensure that other areas of the infrastructure are not adversely affected by the Change.
Remember that testing does not have to stop merely because a Change or product has gone live. Normal operation and service use will be tested first and invoked in live use first. It is therefore still relevant to test performance and behaviour of Changes in unusual, unexpected or future situations so that further correcting action can be taken before any detected errors become manifest in live operation.
The implementation of such Changes should be scheduled when the least impact on live services is likely. Support staff should be on hand to deal quickly with any Incidents that might arise. Where it is possible to introduce such Changes into a limited environment - for instance for a pilot group of Users - this approach should be considered.
Change Management has responsibility for ensuring that Changes are implemented as scheduled, though this will be largely a coordination role as the actual implementation will be the responsibility of others (e.g. engineers will implement hardware Changes).
The number of urgent proposed Changes should be kept to an absolute minimum, because they are generally more disruptive and prone to failure. All Changes likely to be required should, in general, be foreseen and planned, bearing in mind the availability of resources to build and test the Changes.
Nevertheless, occasions will occur when urgent Changes are essential and so procedures should be devised to deal with them quickly, without sacrificing normal management controls. Such procedures are shown in Figure 8.5, and described in the following paragraphs.
Figure 8.5 - Procedure for implementing an urgent Change.
Incident control staff, computer operations and network management staff may have delegated authority to circumvent certain types of Incident (e.g. hardware failure) without prior authorisation by Change Management. Such circumventions should be limited to actions that do not Change the specification of CIs and that do not attempt to correct software errors. The preferred route for circumventing Incidents caused by software errors should be to revert to the previous trusted state or version, as relevant, rather than attempting an unplanned and potentially dangerous Change. Change approval is still a prerequisite!
Approved Changes should be allocated to the relevant technical group for building. Where timescales demand it, Change Management, in collaboration with the appropriate technical manager, should ensure that sufficient staff and resources (machine time etc) are available to do this work, even if this means calling staff in from home. Procedures and agreements - approved and supported by management - should be in place so as to allow for this. The cost of emergency call-outs should be covered somewhere in the approved running costs of Service Management. Back-out plans should still be devised despite the urgency of the Change.
As much testing of the urgent Change as is possible should be carried out. Completely untested Changes should not be implemented if at all avoidable. Experience has shown that when Changes go wrong, the cost is usually greater than that of adequate testing. Again, remember that there is still merit in testing even after a Change has gone live.
Change Management should give as much advance warning as possible to Customers and Users about any imminent Change. This should be done via the Service Desk or other help desk, as available. When any urgent Changes are implemented, particularly those that have not been adequately tested, Change Management should ensure that an adequate technical presence is available, to tackle any Incidents that may occur.
If a Change, once implemented, fails to rectify the urgent outstanding Problem, there may need to be iterative attempts at fixes. Change Management should take responsibility at this point to ensure that business needs remain the primary concern. It is important that each iteration is controlled in the manner described in this section. Change Management should ensure abortive Changes are swiftly backed out from.
If too many attempts at an urgent Change are abortive, there are three questions that need addressing:
In such circumstances, it may be better to provide a partial service, with some User facilities withdrawn, in order to allow the Change to be thoroughly tested, to suspend the service temporarily and then implement the Change.
It may not be possible to update all Change Management records at the time that urgent actions are being completed (e.g. during overnight or weekend working). It is, however, essential that manual records are made during such periods, and it is the responsibility of Change Management to ensure that all records are completed retrospectively, at the earliest possible opportunity. This is vital to ensure valuable management information is not lost. An example could be the updating of an attribute defining 'success', 'failure' or perhaps 'partial failure' of a Change. The updating should be carried out by the person responsible for applying the Change, and should happen no later than the
Post Implementation Review - and perhaps with the cooperation of the project team, Release or applications software development manager.
Change Management must review all implemented Changes after a predefined period has elapsed. This process may still involve CAB members; Change Management may look to them for assistance in the review process.
Change reviews may be tabled at CAB meetings, for CAB members' information and to agree any follow-up action that may be needed. The purpose of such reviews is to establish that:
Any problems and discrepancies should be fed back to CAB members (where they have been consulted or where a committee was convened), impact assessors, product authorities and Release authorities, so as to improve the estimating processes for the future.
Where a Change has not achieved its objectives, Change Management (or the CAB) should decide what follow-up action is required, which could involve raising a revised RFC. If the review is satisfactory or the original Change is abandoned, the RFC should be formally closed in the logging system.
Change Management should instigate follow-up actions to correct any problems or inefficiencies arising in the Change Management system itself as a result of ineffective Changes. For example, a large Change backlog may indicate that Change Management is under-resourced; a high incidence of unsuccessful Changes indicates that Change assessment or Change building is not working satisfactorily. Change record reviews may also show up problems in other processes, such as Problem Management, in the reliability of system components, or in staff's or Users' procedures and/or training. These problems should be reported to the managers concerned and highlighted in the Change Management reports to management.
It is also recommended that Service Management review the Change Management process periodically for efficiency and effectiveness. Such a review should be carried out shortly after the Change Management process is implemented, to ensure that the plans were carried out correctly and that the process is functioning as intended. Any problems should be traced back to source and corrected as soon as possible. Thereafter, regular formal reviews of the Change Management process should take place - at least every six months. The Change Manager should also continually assess the efficiency and effectiveness of the Change Management process.
It should be noted, with respect to any review, that a high number of RFCs does not necessarily indicate a problem with the Change Management process - it may just reflect volatile systems. Any attempt to reduce the number of RFCs may stifle innovation. The prime indicator of an effective Change Management process is that the right 'mix' of RFCs is maintained, not that the number of RFCs has been reduced over time.
Other indicators of an effective Change Management process include:
These items can be used as metrics for measuring the effectiveness and, to an extent, the efficiency of the Change Management process. In measuring that efficiency, it is necessary to consider, the amount of Change successfully implemented per unit of staff costs, including, for example, the costs of assessors, builders, and testers. This may be difficult to assess in absolute terms, but it should generally be possible to observe an increase in efficiency over time, especially in the early days of the Change Management process when the learning curve is steepest.
Clearly, the Change Management role should be filled, with defined responsibilities, for the Change Management process to work effectively. A suggested list of responsibilities for the Change Management roles is outlined below:
Change ManagerThe main duties of the Change Manager, some of which may be delegated, are listed below.
|
If a CAB is established, it needs to have appropriate terms of reference (e.g. meeting regularity, scope of influence, links to program management). To ensure proper representation, members of this Board should include representatives from the following areas:
The Change Manager should act as Chair of this Board. Change Management, or Configuration Management, support staff, can act as secretary.
Change Advisory Board (CAB)The main duties of a CAB member are listed below:
|
|
|
