8.7 Metrics and management reporting

Regular summaries of Changes should be provided to service, Customer and User management. Different management levels are likely to require different levels of information, ranging from the Service Manager, who may require a detailed weekly report, to the senior management committees that are likely only to require a quarterly management summary.

Consider including the following facts and statistics in management reports:

• the number of Changes implemented in the period, in total and by CI, configuration type, service, etc
• a breakdown of the reasons for Change (User requests, enhancements, business requirements, service call/Incident/Problem fixes, procedures/training improvement, etc)
• the number of Changes successful
• the number of Changes backed-out, together with the reasons (e.g. incorrect assessment, bad build)
• the number of Incidents traced to Changes (broken down into problem-severity levels) and the reasons (e.g. incorrect assessment, bad build)
• the number of RFCs (and any trends in origination)
• the number of implemented Changes reviewed, and the size of review backlogs (broken down over time)
• high incidences of RFCs/PRs relating to one CI (these are worthy of special attention), giving the reasons (e.g. volatile User requirement, fragile component, bad build)
• figures from previous periods (last period, last year) for comparison
• the number of RFCs rejected
• the proportion of implemented Changes that are not successful (in total and broken down by CI)
• Change backlogs, broken down by CI and by stage in the Change Management process.

Consideration needs to be given, in consultation with the Customer, to the manner in which the management information is presented. In many cases, percentages, and graphical or pictorial representations, are more meaningful than bare numerical data.

The information can be used as a basis for assessing the efficiency and effectiveness of the Change Management process. For this, it is necessary to filter out effects that are outside the direct control of Change Management. For example, frequent Changes affecting a particular CI may be a result of fragility of that item, and should not reflect badly on Change Management as might at first be inferred. Similarly, frequent Changes in User facilities may reflect a rapidly changing User requirement.

8.7.1 Auditing for compliance

This paragraph is a checklist for organisations that wish to audit their Change Management process (using the organisations' computer audit group, which is independent of the Service Team), for compliance to the procedures and advice in this chapter. It is recommended that such an audit is completed at least annually, and may be required more often, initially or where particular problems are evident.

The audit should include an examination of the following items:

• randomly selected RFCs - normal, urgent and standard Changes
• Change records
• CAB minutes
• FSC
• review records for random RFCs and implemented Changes.

Checks must be made to ensure that:

• all RFCs have been correctly logged, assessed and actioned
• FSC have been adhered to, or there is a good reason why not
• all items raised at CAB meetings have been followed up and resolved
• all Change reviews have been carried out on time
• all documentation is accurate, up-to-date and complete.