Implementing a Lead Time Framework for the Handling of Requests for Change

Transcription

1 Article Paper Implementing a Lead Time Framework for the Handling of Requests for Change Submitted by: Mark Sykes Principal Consultant Office: +44 (0) mark.sykes@foxit.com Head Office Sentinel House Harvest Crescent, Fleet, Hants. GU51 2UZ Registered Address Fox IT SM Limited 1 Vincent Square London SW1P 2PN Tel :+44 (0) Fax :+44 (0) sales@foxit.com Company Registration Number Company VAT Number GB

2 Introduction When someone raises a request for change (RFC), how far in advance of a change advisory board (CAB) meeting or its implementation should it be raised? How do you ensure that you have the most appropriate lead times in force that best support business requirements and which further supports the necessity to make certain full due diligence is performed on a change prior to its implementation? How does a specific change type, category or lead time influence, determine and dictate the levels of governance that need to be exercised? For example, how does this affect the approvals necessary (who and when) or any associated workflows? This paper is intended to provide you with guidance on some of the key factors that need to be considered when implementing a lead time framework; a framework that can be utilised to drive some key elements of good practice across an IT organisation (such as better planning, control and governance of forthcoming changes). Change Types and Categories Before we take a look at lead times, it is important for any organisation that they have a categorisation and classification structure in place that best fits their needs. This should support not only the progression of changes through the Change Management process, but also provide the right level of granularity for any management reporting that is required. In turn, this structure can also be utilised (in part) for determining the lead time that a change requester must adhere to. The normal convention of frameworks such as ITIL 1 identifies three typical change types: Type Standard Normal Emergency (or Urgent) Definition A change where all steps required in achieving it are well known and documented (e.g. as a set of work instructions). Such a change is typically one which: follows a well-known and defined path is relatively common is the accepted solution to a specific requirement (e.g. new account, leaver or a known operational issue such as restarting a database server) has tasks that are well-known and proven is often pre-approved A change which is not a standard change and will likely require some level of approval before being able to be implemented; or at a minimum the Change Manager will need to review it to decide the path it needs to follow (or to perform quality assurance before presenting to a CAB). Requirement for a change of this type can be triggered, for example, by forthcoming scheduled maintenance, project or BAU activities, etc. A change which needs to utilise a fast-track path in order that it can be implemented as soon as possible, such as to resolve a major incident or serious problem. An emergency change can only be implemented provided an emergency change authority (i.e. ECAB typically a senior manager or service owner, his nominated representative or an on-call duty manager, etc.) has approved it. 1 ITIL is a registered trademark of AXELOS Limited Fox IT SM Ltd 1

3 Change categories follow a similar principle and are normally used to help identify the expected level of impact from a change. Below is a typical example category matrix: Category Major Significant Minor Definition A change which has a potential major impact on the business and so a higher level of management requires being involved. For example, a management board, steering group, governance committee, etc. A change which has a potential for significant impact on the business and so a CAB or Emergency CAB (ECAB) requires being involved. A change which has little potential impact on the business and so where authority can be delegated. For example: a Change Manager can authorise & schedule the change and then report subsequent results to the CAB; or authority may be delegated to approved parties (such as a team manager or service owner). Standard changes often fit into this category. It is essential to ensure adequate reporting and logging is in place. Lead Times What are lead times? Now that we have a clear understanding of change types and categories, how do these translate into ensuring that RFCs are raised in accordance with rules on how far in advance they need to submitted, i.e. the lead time. A lead time is usually expressed in days or hours, and may or may not have to take into consideration weekends, public holidays, etc. depending on organisational requirements. The intention of having lead times is to ensure that a requester provides sufficient advance notice of a change such that subsequent process activities (not only Change Management but related processes where applicable, such as Service Validation & Testing, Release & Deployment Management, etc.) can be undertaken prior to its scheduled implementation date/time. Activities such as review and quality assurance by a Change Manager, schedule conflict analysis, review and approval by a CAB, remediation of any issues identified during review, etc. Lead times are also a way of helping to ensure that changes are not rushed through the Change Management process. Rushing things can often lead to mistakes or activities not being fully executed (or executed at all!); which in turn increases the potential risk to the business, customers and users particularly if a change is potentially service-impacting. Additionally, certain business conditions may affect the minimum lead time applicable to a particular change, for example at the end of the month or end of a financial year. These situations will typically cause a lead time to be extended beyond the norm, and indeed may even dictate that a standard change be treated as a normal change during the noted period. These scenarios may also cause changes normally handled within scheduled lead times to be treated as an emergency change if the temporary timeframes cannot be met for any reason. Standard changes A standard change is typically categorised as minor, indicating that it is not only deemed low impact but also low risk, as well as having a proven set of implementation and back-out instructions. Often the majority, if not all, standard changes in an organisation are pre-approved, meaning that they do not have to be presented to the CAB prior to their implementation perhaps they are just peer reviewed by a Team Manager. It should be noted here though that the results of standard change implementations should be reviewed at subsequent CAB meetings to ensure that they remain suitable for continuing as that type. Fox IT SM Ltd 2

4 Individual standard changes should have a pre-configured workflow a set of repeatable and trusted actions and tasks that are to be carried out each time that change takes place. Depending on the change and its workflow, lead times may be the same across all standard changes, they may differ depending on the configuration items (CIs) that are affected, or indeed in certain circumstances a lead time may not be necessary. It should be the case that if a requester fails to meet any required lead time of a standard change then it defaults to become a normal change and hence subject to additional checks (and likely some form of CAB or Change Manager approval). Normal changes Whilst normal changes may also have pre-configured workflows (particularly for common, often repeated, changes), stipulated lead times help to ensure that relevant changes are submitted to the Change Manager or CAB in a timely manner. As already mentioned above, there are good reasons why lead times exist and the failure to adhere to a set timeframe may cause a change to be rejected, or treated as an emergency and hence subject to an even higher threshold for approval. In the experience of Fox IT 2, certain organisations that we work with choose to clearly distinguish between normal changes that adhere to the accorded lead time and those that don t, and hence split normal into two distinct types, such as normal planned and normal unplanned (other example names include out-of-cycle/off-cycle). In this latter case, special justification would need to be provided illustrating the reasons why nominated lead times should be bypassed. The bullet points below represent the first few steps of a typical Change Management process that supports this methodology: Create the RFC record Enter the implementation date Based on the scheduled implementation date and current date, is required lead time met? o Lead time met handled as a normal planned change o Lead time not met handled as a normal unplanned change An advantage of utilising this type of mechanism is that emergency changes remain genuinely that, changes that cannot wait for normal scheduled lead times, and need to be kept, and reported, separate. One of the tasks of a Change Manager, or CAB, would be to review each normal unplanned change to determine if the justification provided is sufficient to warrant the usual lead times not be adhered to. If the justification is found wanting, then the change should be rejected and the requester instructed to re-submit it as a normal planned change (i.e. with a revised implementation date/time). It should be recognised that even normal unplanned changes will have lead times applicable to them, just shorter ones than for normal planned changes. Only if circumstances dictate, and specific criteria are met, should it be handled as an emergency change. Emergency changes Emergency changes, due to their specific nature, often do not have any set lead times. These types of changes are typically in response to an incident (e.g. a major incident) or an urgent problem, and hence need to be fast-tracked through the Change Management process. Global organisations Organisations that operate on a 24x7 basis, and even more so those operating across multiple continents and time zones, should consider more complex lead time scenarios. For example, is there a need for regional and global CABs, hence lead times with perhaps two timeframe elements for those changes that must be presented at both? Perhaps also needing consideration is how are public holidays in one region but not another catered for? These questions, and others, will need to be answered. This level of complexity requires a detailed mapping exercise to be carried out so that all factors can be clearly understood and the various scenarios explicitly documented. It is also important for an organisation to produce an example set of use cases and to see how each one can be managed given 2 Fox IT is a registered trademark of Fox IT SM Limited Fox IT SM Ltd 3

5 the various lead time situations that are needed. This can be a crucial exercise in validating that there is a correct set-up in place that caters for a multitude of different requirements. Example lead time matrices Below are two examples of how a lead time framework may look. Once all of the factors mentioned above have been taken into consideration, an organisation should build a matrix that best fits the needs and requirements of both IT and the business. Category Lead Time CAB Major 14 days Formal CAB Significant (core service) 7 days Formal CAB Significant (noncore service) 3 days Virtual CAB (multi-team approval) Minor 1 day Virtual CAB (single team approval) Impact Level 5 Level 4 Level 3 Level 2 Level 1 Level 5 7 days 7 days 5 days 5 days 5 days Level 4 7 days 5 days 5 days 5 days 5 days Risk Level 3 5 days 5 days 5 days 3 days 3 days Level 2 5 days 3 days 3 days 3 days 3 days Level 1 5 days 3 days 3 days 3 days 3 days Ideally, lead times should then be configured within the ITSM toolset so that they can be enforced with built-in automation. For example, a requester trying to submit a normal planned change but with a scheduled implementation date only 2 days away, will have it automatically amended to normal unplanned by the toolset. That way the requester has no mechanism for forcing it through on the quiet! This is one way that an ITSM toolset can help to enforce process compliance. Where applicable, lead times should also be integrated within relevant service level agreements and operational level agreements. Approvals All changes need to be approved, even standard changes at some point (such as at a CAB meeting that provides the initial declaration that subsequent changes of that type will be classified as standard). Whilst many, if not all, standard changes may be pre-approved, they will likely still need some level of peer review prior to their implementation. The approvals that are configured for normal unplanned changes may be the same as those for normal planned, but if so organisations should consider increasing the level of review and approval for those fitting into the unplanned type. Normal unplanned changes are usually subject to additional approval, such as by a Change Manager before presentation to the CAB or perhaps formal presentation to a CAB meeting rather than a typical virtual approval activity (e.g. via an IT Service Management (ITSM) toolset). Fox IT SM Ltd 4

6 Summary Allocating a lead time to a type or category of change is a way of enforcing good practice within any IT organisation. Teams responsible for maintaining and upgrading/updating configuration items (CIs), be that hardware, software, documentation, etc., need to ensure that due consideration is given to any forthcoming change to a CI. This can only be done effectively if sufficient notice of change is provided so that a full assessment of the potential consequences of it can be determined and that its build, test and implementation can be planned accordingly. Enforcing lead times is one way of encouraging all personnel (e.g. project, application support, operations, etc.) responsible for raising change requests to be more proactive in their planning of changes, rather than always leaving things to the last minute before raising a request for change and then expecting it to be approved just a short while later. This should be the exception (e.g. raising a normal unplanned or emergency change) rather than the norm. Yes, producing management reports that name and shame these teams is one way of enforcing good practice, but it s so much better to tackle the issue at the start of the Change Management process rather than at the end of it. When introducing formal lead times for the first time, remember that it will be important to educate all process practitioners (e.g. change requesters, approvers, implementers) in the new practices and to provide appropriate guidance and procedures in the correct use of those lead times. It is important that they recognise the reasons for doing something like this; it s not just throwing more hurdles in their way, it s about protecting the business from, and reducing the risk of, failed changes, and for making the whole management of changes to be more effective and efficient. Mark Sykes Principal Consultant at Fox IT About Fox IT Fox IT has been a leading Information Technology Service Management (ITSM) and governance business for over 30 years. We provide a range of practical and effective consultancy solutions designed to create agile, proactive, responsive IT organisations providing excellent IT services in alignment with our clients goals to support and drive continuous business innovation. We achieve this by empowering your people with best practice training, developing and implementing the right operational processes and using properly configured and integrated tools to enable IT Services transformation. To discuss how we can assist you in transforming your IT services or in obtaining ISO/IEC certification please call us now on +44 (0) Please come and join in the latest ITSM conversations on our social media pages: Facebook: LinkedIn Company Page: LinkedIn Group: Fox IT SM Ltd 5