Alignment & Cascading. Which are your choices?
Mihai Ionescu - Senior Strategy Consultant, Owner Balanced Scorecard Romania, Author
When it comes to setting up the model for aligning or cascading objectives and KPIs for the business units of an organization, things are never easy. It's not that defining goals, strategic gaps, objectives, cause-effect relations, KPIs, targets or initiatives for the whole organization would have been easy, but the alignment & cascading have to overcome two opposing requirements: (a) to ensure sufficient consistency and accuracy in deconstructing the top-level objectives and aggregating the results bottom-up and (b) to give to business units at all levels of the organization sufficient freedom to adapt the top-level objectives and KPIs to the specifics of the processes they manage and changes that they have to be make, in order to contribute to the success in achieving the top-level objectives.
To make things more complicated, we often encounter two schools of thought on this. One is based on the wide-spread operational performance management, sometimes driven by the focus on employees’ performance evaluation. The other one is focused on strategic management and on the contribution that each business has to the execution of the Strategy. In the former case, the dominating concepts are Cascading & Aggregation, mostly related to KPIs. In the latter, it's Alignment, with a predominant focus on objectives, more than on KPIs.
When it comes to Alignment or Cascading, we often hear questions that rapidly build-up to major conceptual issues, like:
Do we calculate the status of each parent business unit objective based on its KPIs, or based on the aggregation of the cascaded objectives' statuses from the child business units (at the level below)?
How do we cascade an Objective with KPIs that cannot be measured at the child business units level (e.g. '# Net Promoter Score', '$ EBITDA', or '% Brand Awareness')?
If we aggregate objectives from our child business units, what do we show under the objective in the parent scorecard: the child KPIs, a selection of them, the parent KPIs, or both?
How do we aggregate a KPI if it is measured for an objective of a child business unit, but isn't measured for the corresponding objective of the parent business unit?
Do we have to cascade an objective or KPI down to the lowest level in the company (e.g. sub-departments) or we stop the cascading at a certain level? At which one? Is this valid for all objectives?
How do we do aggregation if an objective has KPIs that we cascade to child business units, but also KPIs that we don't cascade? What will we aggregate then - child objectives or child KPIs?
If we are using weighted aggregation, do we use the same weights for both child objectives aggregation and for child KPIs aggregation?
These are questions that you might have encountered yourself in your organization. Before answering them (in the next article), let's clarify first which are the model choices that we have for setting-up the alignment and cascading of objectives and KPIs. We'll use some illustrating diagrams, where we've simplified the cases for how we align/cascade an objective from the top of the organization (Level 0) to the next two hierarchical levels (Level 1 and Level 2) and then calculate the objective statuses. I'm sure that you can extrapolate further to more levels, as required.
Let's start with the first choice we have, or model case, as we're calling it. The diagrams illustrate the case for one objective. We have this objective at the top organization (Level 0 - Business Unit A - we call it a Business Unit for consistency, but it's the company/top-organization) and at two business units at the next hierarchical level (Level 1 - Business Unit B and C), each of them having two business units below them (Level 2 - Business Units D and E, which report to Business Unit B and then F and G, which report to Business Unit C).
The KPIs where data is entered (actual measured values) are marked by a red arrow to their right side. The arrows linking objectives and KPIs are the alignment/cascading links, but the arrows point upwards, to show how we are aggregating values, which are either statuses (objectives) or actual measured values (KPIs). Inside each objective we show their KPIs (1), (2) and (3). When we calculate the status of the objective based on its KPIs' statuses (usually by weighted average) there are arrows pointing from the KPIs to their objective. When the status of the objectives is calculated otherwise, there are no arrows between it and its KPIs, but we show what KPIs are listed under that objective.
The case above is typical for operational performance management, but also for organizations where little or no freedom is given to business units in setting other objectives or KPIs than those of the top-organization. Or it might just be the case that child business units manage exactly the same operational processes, like the nearly-identical stores of a supermarket chain. This case is also encountered in strategic management, for what we call Identical Alignment, where an objective is mandatory to be included in all child business units' scorecards, usually with the same KPIs (take Cost reduction, Attrition rate, Succession planning, etc. as typical examples).
In order to allow for a full and accurate aggregation of objectives' statuses, the data (actual measured values) is entered for the same KPIs, at each bottom business unit (Level 2, in our diagram), then rolled-up, either as sum, or as weighted average, to the parent organization and so on, until the values are added-up to the top organization (Business unit A, in our diagram). The status of each objective is calculated based on its KPIs, using either data entry values (bottom child business units - Level 2) or the aggregated values (business units at levels 1 and 0).
Let's go to the next choice, or model case, which is widely used in strategic management.
We can say that we are on the opposite side from the previous case.
The case above is typical, more precisely, for what we call Contributory Alignment. The child business units have full freedom to define the KPIs that are as specific as possible to the operational processes they manage and to the changes they have to make in those processes, in order to bring their contribution to the achievement of the respective objective, at the top level.
The objectives' statuses are calculated based on their KPIs and measured values are entered into the KPIs at each business unit. But then, how do aggregate? Well, we don't - or to be more precise, we replace the aggregation with the proper setting of the contributory model, based on the Contribution Analysis that we make when deciding which business units will participate in achieving the top-objective and how, including what has to be measured at each level and for each unit, in order to quantify the success in achieving each aligned objective.
So, we no longer have a KPI aggregation like KPI A = KPI B + KPI C, KPI B = KPI D + KPI E, etc., but we know that if the aligned objectives of business units D and E will be accomplished (as quantified by their KPIs), then the objective of their parent business unit B will be accomplished, as well, and we validate that by calculating unit B's objective status based on its separate KPIs.
One of the drawback of this model case is that the results may decouple the performance between business units at lower levels and those on the top levels, in case the Contribution Analysis has not been performed accurately and completely. This may result, for example, in lower levels business units accomplishing their objectives, while the whole organization is not.
Strategic management is part Art and part Science, or in other words, you need a lot of practical experience and possibly multiple iterations, in order to correctly define the aligned objectives for each child business unit and the most appropriate KPI measures. In some cases it's easy, in others is difficult, but the benefits in flexibility and adaptability of using this model are tremendous.
The case above is where the two previous cases meet, as we use objectives alignment(instead of KPIs cascading) and aggregation, which is performed this time at objectives level - we aggregate the statuses of child objectives, in order to get the status of their parent objective. One of the typical cases when we use this model is for what we call Heterogeneous Objectives, where the KPIs at each child business unit are measuring significantly different things, for the same objective. This is very much used in holding companies, where the business units run different business/product/service lines.
Take, for example, a company which has one business unit which produces a raw product and sells it in bulk (trading), another one that takes the raw product, refines it, packages it and sells it as finite product to consumers (retail) and a third business unit that provides services to the suppliers of the materials from which the raw product is manufactured. If the objective in case id 'F2 Increase sales volumes', we cannot add the KPIs of F2.1 Tons of raw product from the first business unit with F2.1 Number of finite product packages sold by the second business unit and with the F2.1 Days of service sold by the third business unit.
You may observe that, in this model case, the KPIs are defined only for the bottom child business units (Level 2, in our diagram), where the measured values data is entered. These KPIs are used to calculate the statuses of the respective child objectives. Anywhere above the bottom level, the objectives statuses are calculated by aggregating the objective statuses from the child business units one level below. It's important to notice that at all levels above the bottom one there are no new KPIs used, but we are listing the KPIs from their child objectives.
The benefit of aggregation works flawlessly, but the drawback is that under each parent business unit objective the KPIs listed are piling-up, ending at the top level objectives with possibly long lists of KPIs, most of which are irrelevant for the majority of the child business units. For this reason, this model case is seldom used in practice, being replaced by the next one.
The main difference in the model case above, compared to the previous one, is that for each parent objective we make a selection of the child business units' KPIs that are listed under the objective, picking only the most significant ones. So, we retain the benefits of the model, but we overcome the main drawback of the previous case.
The only disadvantage is that the KPIs listed under each parent objective don't 'tell the whole story' of how the respective child objective's status was calculated. But this can addressed through the practice of selection and through iterations, during the use of the model.
The last model case is probably the most complex one, but it harvests the majority of the advantages of previous models, with significantly reduced drawbacks. However, be advised that this model requires a lot of experience in order to be used, so don't use it on your own, if that's for the first time. Ask for help and you'll be able to set it up correctly, with highly-rewarding benefits.
This model case is illustrated by two diagrams, for capturing the various cases of mixed alignment, cascading and aggregation.
We can observe in the diagram above several similarities with the models presented so far. First of all, we are using both KPI cascading & aggregation AND objectives alignment and objectives status aggregation. Then, we are entering measured values data for KPIs in all business units, with the exception of the top-organization (the Business Unit at Level 0, in our diagram). This means that we give child business units the freedom to adapt their KPIs set to the specifics of the operational processes they are managing and of the changes that they have to make, in order to accomplish their objective.
It is important to mention that the model offers the choices to (a) cascade a KPI to the child objective, or not and (b) to aggregate all or only a part of the KPIs of a child objective to the parent objective.
You have probably noticed in the first model case presented that if we would aggregate the objectives by rolling-up their statuses from child objectives to parent objectives, we would always get the same result as the one produced through the aggregation of the KPIs. The explanation is that, in that case, the set of KPIs is identical for all the aligned objectives (in the child business units linked to a certain parent business unit). That's not the case in this last model. The reason for that is that not all the KPIs in a child objective are aggregated to the KPIs of the parent objective. But this is normal in practice, because a child business unit might require a finer granularity in their KPIs set, which make some of their KPIs insufficiently significant for the objective of their parent business unit.
One more observation about why the top-organization's objective doesn't have its own KPIs (not aggregated from the child business units). The reason is that the purpose of the specific KPIs, which are not cascaded & aggregated, is to allow for a customization of the KPI set for each business unit's objective. But that's not the case of the top-organization at Level 0 (Business Unit A, in our diagram), because its objective's KPIs do not need to be customized - on the contrary - they have to retain a general coverage for all the objectives in the other child business units.
So, let's discuss at least one of the three use cases that are illustrated in this first of the two diagrams for this model case. First of all, the top-unit (A) is cascading two KPIs, A and A to both its child business units. But in both business units B and C, the respective child objectives also use other KPIs, complementing those cascaded from their parent business unit. In the case of B, there are two KPIs (B and B) that are cascaded/aggregated with its two child business units (D and E), which are not further aggregated to the parent objective in business unit A.
The KPIs B and B are finishing their cascading here, because their actual measured values are entered at this level, not at the Level 2. Although we try to enter data at the lowest possible level of the alignment model, we may encounter cases like this, when the data cannot be entered below a level which is not the bottom one.
Let's take an example, to better understand this. Assume that our objective is "C3 Increase brand awareness & recognition" and the two KPIs (A and A) are "C3.1 # Brand awareness ranking (survey)" and "C3.2 % Brand recognition level". We can align this objective down to the bottom Level 2 (e.g. sub-departments), but the C3.1 and C3.2 KPIs don't have enough granularity to cascade them below the level L1 (e.g. departments, responsible for different product lines). So, the cascading of these KPIs stops at Level 1, the lowest level where we can enter actual measurement data for them.
So, now we need other KPIs to cascade further to Level 2, in order to perform the alignment from the Level 1 (business unit B) to the Level 2 (business units D and E). Assuming that these are sub-departments that can contribute to the achievement of the objective with initiatives like fairs & public events participation, as well as publishing articles and newsletters about the product line managed by their parent business unit (B), we cascade to them some relevant KPIs (B and B, in our diagram), like "C3.3 # fairs & events participation" and "C3.4 # articles published in specialized magazines".
We now reach an important point that has to be made. Because C3.3 and C.4 are too granular for the top-level (Level 0) for being linked there to our C3 objective, but - on the other hand - we use both of them to calculate the C3 status for the business unit B (at Level 1), it means that we cannot correctly and fully determine the status of C3 at business unit A by using KPIs aggregation, as the units A and B share only the C3.1 and C3.2 KPIs. Therefore, we need to aggregate the objective's status from the Level 1 (units B and C) to the Level 0 (top-unit A), in order to correctly and fully calculate C3's status for A.
Similar examples can be given as well for the other two use cases in the diagram above, but I'd rather let you study it and ask questions about the aspects or details that are not clear. And in order to provide you three more use cases to explore, here is the second diagram of the "Mixed Alignment & Cascading" model case.
I think that this is more than enough for this article. Take a look again at the diagrams, see/download them eventually from Issuu (http://issuu.com/mihaiionescu7/docs/alignment_and_cascading), or ask for a PDF copy by e-mail at firstname.lastname@example.org. Then don't hesitate to ask any questions you might have, or make any observations you think are appropriate on this subject, and then we'll move forward to a second part of this article (coming soon), where we'll attempt some answers to the questions you have seen at the beginning and maybe to those received in the mean time. See the Document: ALIGNMENT & CASCADING - THE USE CASES: YOUTUBE (VIDEO): http://youtu.be/5dntCQx3kwQ SLIDESHARE (SLIDE-PACK) http://www.slideshare.net/mihaione/alignment-and-cascadingslideshare ISSUU (PDF): http://issuu.com/mihaiionescu7/docs/alignment_and_cascading_use_cases