How do you select the key performance indicators for configuration management?

More importantly KPIs are a way to understand if the movement (trend) is in the right direction of planned strategy or simply aligned to the strategy

The KPls I select typically reflect operational stability and agility. It's about how quickly we can pivot without breaking stride, like responding to demands while maintaining uninterrupted service.

A KPI that is often used, is the cycle time of changes with the intent to reduce the cycle time. However this can trigger the wrong behavior. Cycle time of a change depends heavily on the size and complexity of the change. So if people start scoping changes to be smaller you have more changes, with a reduced cycle time. This results in getting results slower as every change has some overhead, even if it is a little overhead. It is better to have KPIs on planned versus actual with respect to the scope, cost (includes business case), and required resources (this includes time and people) of a change.

A way to tell something about the overall effectiveness of your configuration management practices, is the number of non-conformances that are reported. You can use different perspectives here: - # non-conformances / # products - # non-conformances per product - # non-conformances / # FTE You can add filters like severity of the non-conformance to see how the results are distributed. Due to the nature of this KPI, there is a risk that people would want to reduce the registration of non-conformances. However, when you do not use this KPI as a stick, but just to create awareness, you can mitigate this. You are not measuring the performance of a specific task but the result of an entire delivery system.

A KPI I used to measure is the quality of baselines in relation to change management (consistency between change management systems and application/product lifecycle management systems_ Think of: are all issues/tickets (changes requests, bugs, features) for a release traceable to code/documents etc, but also the other way around: can all changed configuration items be related to issues/tickets in your change management system.

For change mgmt, I suggest the qty of configuration items (CI) in your product or end item baseline (or a similar size metric) can be used to identify similar products and normalize metrics for non-similar products e.g. changes, errors or change effort per CI. Of course classifying reason for change and capturing error codes will expose negative trends needing attention For Configuration Status Accounting I suggest report execution dialogs that capture requestor/dept data plus optional satisfaction data to see how frequently reports are used, by who and how well they meet stakeholder needs

-For Configuration Control - review turn-around-time by anyone and anystep in the change process. Be careful on creating KPIs for yield that may drive the wrong behavior. e.g. zero rejection targets.

KPI for CM should go hand in hand with additional KPIs, such as network KPIs. These are particularly important for before and after changes in firewalls, routers, etc. There are also some very fuzzy KPI's which should not be ignored, such as end user satisfaction. These can be difficult to put into usable numbers, but attempts should be made.

When you are inexperienced, you tend to define many KPIs for the processes you want to continuously improve. At the end of the day, you realize that selecting too many metrics or defining too many KPIs does not make sense, and only a few KPIs actually guide you. As your experience grows, these KPIs become like your alphabet. However, a new era is beginning, and everything that previously seemed meaningless is starting to make sense thanks to disciplines like artificial intelligence and data science. Companies no longer want to rely solely on lessons from the past but rather want to decide how to move forward in the future based on current processes and data. With this era, I believe that CSA will become much more valuable.

Don't select a KPI that no one can take action on. Ideally it will be CM taking action on a CM KPI but not always since CM touches all orgs and usually owns the status accounting db

KPIs should also find its way into the CM Plan describing what you try to measure and with which intention. As many aspects related to Configuration Management, KPIs should be reviewed on a regular base. A developing and learning system should replace KPIs if needed, in case they are not delivering insights as expected - or in case new needs arise. Better have few, but meaningful Config KPIs.

Looking at some of the examples given, I think one should distinguish between CM KPIs and KPIs that can be derived from the CM systems. The cycle times of changes for example can be derived perfectly from the Change Management system, but as configuration manager you typically can't influence this. Guarding consistency between change management and the CMDB on the other is (imho) a core competence/responsibility of the configuration manager, so this is a KPI the configuration manager can influence.