Management Information Reporting (MIR) Part 2

Art 4.1 Change Pt2

Management Information Reporting (MIR) - Change (Part 2 - Putting the Theory into Practice)

In this second part of the article (first part is here) we will look at having reached the stage where we know that we are going to proceed with a service or change request (using the ITIL Change Management processes for Request For Change [RFC]) we shall now look at the stages and will discuss how the related Management Information Reporting (MIR) from them helps us with the understanding, management and control at the Strategic, Tactical and Operational levels, as described in part 1.

Configuration Management data and its relationship information between Configuration Items (CIs) enables a two way process - if we know which service needs to be changed then we have a means of identifying the component(s) involved and conversely if we know a specific component requires changing we can also ascertain which service or services will be affected. With a one-to-many relationship for a majority of items of infrastructure we must never forget that we are looking to protect the other existing services at the same time that we are affecting the change.

It is through the MIR on the Configuration Management processes that we can start to have confidence in the data. Suggested MIR and what value it adds is discussed in the Configuration Management article.

Change Management MIR

Note: I would expect at this point that most mature change management processes will have set parameters for categories of change. These categories are usually set to make the working processes, reporting and work planning easier. The governance requirements within ITIL Change Management of a 'standard routine' change will be different to that of a 'major' change. The precise terminology and definitions will be dependant on how the adapt part of ITIL's adopt and adapt has been applied.

Use of the Change Record Status and Date fields will give a large percentage of the Management Information Reporting detail generated from Change Management.

First question : How many new requests for change?

Metrics:- For the reporting period, the items below will generate the important information

• the number of changes/requests opened during the reporting period
• the category of those Change Requests
• the area that initiated the Request for Change (the business area, IS.. etc)
• The Configuration Item(s) (CI's) to be changed
• The Service(s) that will be affected
• Number of RFCs rejected and the reason for rejection
• The numbers of requests that have been returned to instigators should be reported on together with the reason for the return (e.g. documentation incomplete, the idea is too off the wall, more information required.. etc)

At the Strategic level the MIR listed above may indicate:

•  Workloads - the levels of project and programme activity, suppliers activity (internal and external) also the overview of workloads for forthcoming Impact Assessments (IA)
• Customer satisfaction, business perception of the services - a high level of RFCs may mean the business think the service is wonderful and want more (that would be good news) or that what they have is not performing to their requirements (not such good news) - at this level the Service Level Manager should have taken the business view from the service review meetings and added it to this MIR in conjunction with the MIR from Incident, Problem and Availability Management for an accurate and validated view.
•  Potential savings

Note: This is not a definitive list, at this stage it is indicative of what MIR can provide at this level of audience.

The usual reporting period for MIR to be published for Strategic level consideration would be monthly.

At the Tactical Level the MIR may be scrutinised for or indicate:

• Patching and updates that keep services at a level that keeps them 'in support' from suppliers
• Security patches and updates - essential to reduce risk to the organisation and essentially aligned and governed by the organisation's Security policy (this could be seen as strategic, tactical and operational!!)
• Support changes in response to business requirements - it may be a tactical decision to change to greater or lesser levels of support to reflect the business's tactical requirements or initiatives
• Is there a profile, within Change Management, that displays peaks and troughs that can be projected forward and planned for

The usual reporting period for MIR to be published for Tactical level consideration would be fortnightly.

At the Operational Level:

• Workload: for the individual teams especially the Change Management section, if the workload is too high you can always use your Service Level Manager (s) to approach the business to confirm their priorities.
• Impact Assessment (IA) workload: support teams, may be supplier or internal and assurance teams (Solutions and/or Technical Architects)
• There may be Service Levels or contractual requirements on turn round, or just the highlighting of inefficiencies or bottlenecks
• Profile of initial rejections: if from a specific business area it may indicate that the Service Level Manager who has been sponsoring the changes requires some additional focus on the Change Management Process itself. If however the rejections come from across the range of business areas then it is likely that the work instructions may require update or improvement

The usual reporting period for MIR to be published for Operational level consideration would be weekly

Efficiencies, Effectiveness, Cost and Sustainability

Efficiencies: At this stage in terms of pure numbers it is likely to be true that a very high number of changes is less likely to be efficient, and with that will carry a relatively higher risk to availability, this is why we will batch changes where we can, as part of release management in Service Transition.

Effectiveness: All that numbers indicate at this stage is whether the process for registering the request is a good one, the number of initial rejections will require further detailed review. See comment above/below

Cost: At this stage the Change Management Process costs that are identifiable will be a proportion of the ITSM Toolset costs, equipment and software, the Service Desk staff costs if initial registration is processed through them, the Change Management staff (a proportion of their time - it will spread over each of the Change Management process stages) the Service Level Managers time, in helping their business customers to define their requirements, this will usually both function and Service Level Requirements (SLRs).

Sustainability: If the initial stage is causing a resource problem you can practically guarantee that the next stages will definitely struggle to deliver.

Assumptions:

It is assumed that for major changes there will already be a budget allocation, usually held and managed through the 'Project' or 'Programme' - the amount of budget may be further refined as the changes are Impact Assessed and more detail is amassed.

Please note: It is important that project planners and managers remember that the Service Level Requirements (SLRs) materially affect the cost of a change and its on-going support and management, if the SLR's are not fully considered it will not be possible to accurately manage the customers' expectations. You may well be starting down the slippery slope of scope or budget changes during the project or post implementation in order to meet them.

Second Question : How many changes are there at each stage of the process?

Metrics:- For the reporting period and split by each process stage (CR Status) and broken down into categories (major, significant, standard... etc):

• Number of changes brought forward from previous reporting period (existing in this stage)
• Numbers of changes moving to this stage during reporting period (new to this stage)
• Numbers of changes moving out of this stage (leavers)
• Numbers of changes carried forward (this will be the first bullet for the next reporting period)
• It would be of value to have the carried forward changes report further split to show their age, thus highlighting those that have lost momentum

At the Strategic level this MIR may be interpreted into

• Change Profile: numbers in each stage gives a total picture of the IS Change profile for the organisation and the volumes in each stage, it would probably be usual for there to be high numbers in the 'Build and Test' stage. This is a stage that a change may be in for a considerable time. As you would expect the length of time will be dependent on the complexity of the change and the focus it is given. Usually this focus will be provided through a project mechanism, which will also manage its specific funding and resources.
• Pressure points: At this level the information may be pointing to areas feeling the stress of high volumes of work. This may have contract impact and require strategic level priority settin.

Note: To a large extent the Programme Management Office (PMO) will be providing its' MIR on the Major and Significant projects that are being run through them from their perspective.

At the Tactical Level this MIR may be scrutinised for:

• Implementation pressures: changes planned to come out of build and test and the updating of the Forward Schedule of Change will affect tactical deployment of resources. In the later stages of testing this will probably include the Business for User Acceptance Testing (UAT), will definitely include your suppliers (internal or external) for Operational Acceptance Testing (OAT).
• The Forward Schedule of Change (FSC): do not forget that this is one of the most important reporting tool's for the organisation, and within IT is essential for both planning, forecasting, budgeting and diagnosis. It will contain changes that originate from across the organisation e.g. Business initiated requests, Facilities Management for Electrical and environmental changes, Infrastructure Suppliers for patching, Business and IS Continuity planners who want to run a test etc etc..

Note: The Forward Schedule of Change as an important Management Information Reporting is discussed in further detail in the last section of this article.

Fact: The greater the warning period of possible contention between changes the easier it is to manage and resolve in advance - proactive management. Hassle, angst and the potential for grey hairs (or a complete lack of hair!) rises exponentially the closer to the implementation date you are if something goes wrong or needs to be re-arranged, to mitigate against this - we plan.

At the Operational Level this MIR may be scrutinised for:

• Workload and Activities: we and our suppliers should be taking part in the Operational Acceptance Testing, we are looking for the service and support detail through the project teams, knowledge transfer should be being prepared and reviewed for acceptance - all these activities require resource and therefore planning.
• Forward Schedule of Change: we and our suppliers are looking at the activities we need to be actively involved in or will affect our working, this can be as simply as a contractor requiring access and to be accompanied into the data centre, but failure to recognise the need to act could mean delay or a window of opportunity missed.

Efficiencies, Effectiveness, Cost and Sustainability

Efficiencies & Effectiveness: Not unusually we are looking for a degree of balance, both of the targets efficiency and effectiveness will be adversely affected if there are bottlenecks. If there are, they will usually be symptoms of other management issues, resourcing, contractual etc. In the short term all you can do is prioritise, in the longer term use all of your MIR to identify the root cause.

Cost & sustainability: Inefficiency costs and late changes to implementation (resource re-scheduling, re-arrangement of business support etc) will certainly carry additional cost and will also probably make the revised implementations less efficient, it is not a sustainable way of working (although I am sure we all know organisations that appear to be practised at it!).

KPIs

Key Performance Indicators at this stage may be the numbers in each stage and the numbers of movements between stages (volumes). The time taken between initial submission and Impact Assessments (IAs) being requested, the time between IAs being requested and the appearance on the CAB agenda

Note: It must be understood that what ever the Service Level targets set for the Change Management team there may be changes that are too complex for the targets and measures to be realistic, these at the IA stage would usually be covered by a 'feasibility project or study'.

CSFs

Critical Success Factors at this stage may be around the numbers of rejections or requests for further information as both these may be indicative of the process, education, forms or templates, help available requiring attention or improvement (quality).

Third question : How many changes have been implemented? Or had implementations that have failed?

Metric:- For the reporting period the number of changes that have been successfully implemented, broken down into categories (major, significant, standard...etc):

Reporting the number of implementations, split by categories, although for organisations with a high maturity level in Change Management it is worth including risk information also in this section.

• Number of Major implementations successfully completed
• Number implemented at risk
• Number of Major implementations that have failed or been backed out.
• Number of Significant implementations successfully completed
• Number implemented at risk
• Number of Significant implementations that have failed or been backed out.
• Number of standard implementations successfully completed
• Number implemented at risk
• Number of Standard implementations that have failed or been backed out.

The mature organisations will have pre-defined levels of risks and by reporting on these trends will be come apparent.

At the Strategic level this MIR may be interpreted into

The overall levels of implementations that are being introduced into the business, remember that Major implementations will be demanding on business resources as well as IS. Training and familiarisation will detract from the business doing their day job (quite literally Business as Usual - BAU).

The levels of risk and how they are managed may at this level be seen as reflective of the business culture, but there could also be the risk that the business is moving into an area where it doesn't really want to be. A number of medium to high risks that occur close to simultaneously can mean effects that are cumulative.

At the Tactical Level this MIR may be scrutinised for:

Here the Management Information Reporting (MIR) will be showing the shorter term resource demands having a direct and immediate effect, you may be seeing excessive overtime becoming the norm. The time for optimising and get the best effect from a change being affected by having to move too quickly to the next change, and this can affect both the business and IS.

At the Operational Level this MIR may be scrutinised for:

Here the potential overtime culture is likely to be affecting smaller technical teams who are actually doing the implementations, it is important to watch for potential burn out, if you have a large programme of change then you need to nurture your 'techies'

Efficiencies, Effectiveness, Cost and Sustainability

Efficiencies and Effectiveness: Implementations will invariably arrive with a degree of pressure from the business, don't let it drive you away from good practise. The value of planning releases to make the most of resources and potential down time will pay you back enormously.

Cost: Release planning as mentioned above will help with the cost of change. Major and Significant changes should come with their own implementation budget, but be wary, it is not unknown for a project that over spends during Build and Test to try to squeeze the implementation costs.

Sustainability: Truly important that we consider both the sustainability of the Change process in delivering the implementations and also the sustainability of the services that have been implemented.

A new or changed service that has been implemented must be managed delivered and supported, the service introduction processes are absolutely critical.

A horror moment - following months of project work the new service (it has been called Albert) is implemented and our excited user can't get access!! Worse follows - he phones the Service Desk and hears 'Albert, we have never heard of a service called Albert'. You only get one chance for a first impression - what do you think the user will think of IS? I know how I would feel.

A single aim for the end users, the Service Management, the Service Desk, the Support Teams should be 'No Surprises' and that means ensuring that there is real communication in the Change Process and that implementation teams are fully involved in documentation and where necessary also in training.

Fourth Question: Have we learnt from what we have done?

Here we are looking at the MIR that is looking at the final results, projects and the larger implementations. Post Implementation Reviews (PIRs) are there to review both the process and effects, it is usual to have pre-defined levels

How many implemented RFCs and the PIR is rating

It is probably worth considering grading levels for implementations, I would expect the granularity to vary by organisation but the information is useful in viewing how the service is performing

Some ideas:

Good: considered a success (the success criteria again will vary between organisations and their focus, e.g. a SIAM organisation may focussed slightly differently to a specific tower supplier)

OK : By and large successful but some important Lessons Learned too

Alright: We made it, but we had severe moments of doubt during the process

Car Crash: We will not do that again

The primary value of grading the implementations is the feel for the relative areas of good and not so good performance over the whole function.

Configuration Management MIR