How Metrics Can Help you
By Matthew J. Morgan
As a business architect or process excellence champion, metrics can be both an important dimension of your responsibilities and an entry-point into executive sponsorship. Senior managers often have an interest in key performance indicators to help them understand and manage their business. The popularity of certain business sayings (such as “What gets measured gets done” and “If you can’t measure it, you can’t manage it”) attests to the widespread acceptance of and interest in metrics among business leaders. Expertise in business architecture could make business architects likely targets of an executive’s question: “How can metrics help me manage my business?”
In this article, I will address how to respond when executives want advice on metrics and how to harness this executive engagement to drive business transformation. The article will review approaches to the following key questions that can help you formulate advice for executives interested in metrics:
- How can metrics help our organization?
- How can our metrics be improved?
- What do internal management reports look like and how should they be used?
- What is the process if the metrics highlight an issue in a department?
- With regard to these metrics, how do you frame what you need from IT?
Before moving into the main discussion, I would like to define the terms of reference. Metrics are used here as a general term for quantifiable indicators to show functional or process performance. Performance indicators (PIs), results indicators (RIs), key performance indicators (KPIs), and key results indicators (KRIs) are different variations of metrics, with KPIs being the most popular term in business usage in my experience. There is also a framework which defines measurements or measures as inputs to metrics, which are aggregated into KPIs. This article is not intended to highlight differences between different types of metrics (metrics in any more specific sense, measures/measurements, PIs, RIs, KPIs, and KRIs), but I would suggest David Parmenter’s Key Performance Indicators for a good discussion on this topic.
How can metrics help our organization?
There are two keys ways in which I would use metrics, and an executive leader’s interest in metrics, to help an organization. I will elaborate on both of these ways further in the other questions below, but to summarize:
- The first and simplest way in which I would use the metrics to help is to drive improvements (see the topic below “What is the process if the metrics highlight an issue…?”). There is a saying in my “former life” in Army intelligence: “From intelligence, action!” If nothing is done with the metrics, it is almost worse than not collecting metrics because there is a cost to measure that is receiving no return-on-investment. In addition, a culture of cynicism can arise as stakeholders see performance problems in metrics that result in no changes.
- The second and more complex way in which I would use the metrics to help an organization is to use them as a basis for a process-driven business transformation. The metrics are valuable in two ways: (1) they are evidence of a managerial commitment to performance improvement and data-driven management and (2) they can be the beginnings of process-driven management. Initially developing metrics, even if they are actively measured…and even if they lead to improvements (per the bullet above)…are only a partial realization of the potential they represent. They are a sign that the organization can create a more sustainable and efficient operating model, on which I will elaborate in the following section.
An effective metrics program consists of implementing a performance management capability that adheres to best practice standards to (1) plan for measurement, (2) collect data, (3) analyze the data, and (4) report findings to management and provide transparency across the organization for better decision-making and operational effectiveness.
How can our metrics be improved?
Metrics should represent an exhaustive look at the business, be specific and quantifiable, and – perhaps most importantly – be developed with top management engagement. A critical success factor (or significant pitfall) of business transformation efforts is the active and engaged sponsorship of top management. So, if a senior executive is engaging you about metrics, take reassurance. All of that being said, there are other important dimensions to consider as an organization’s process measurement capability matures. I would like to focus narrowly on what I consider the biggest pitfall for metrics – business relevance (or “so what?”) – and then look more holistically at a how an engagement with metrics can lead to transforming and organization’s operating model.
Business relevance involves avoiding metrics that are too often “counting” without context. Metrics (which could rely on data inputs that would be “counts”) should clearly drive business decisions or actions. Four methods can help drive business relevance in metrics:
- First, a technique in developing metrics is called G-Q-I-M, meaning Goal-Question-Indicator-Metric. First a business Goal is articulated, then a Question is developed that would show whether the goal is being met. Indicators are then defined that would show the answer to the question. Finally, those indicators are quantified as calculable Metrics. Traceability to the goal is achieved through systematic adherence to a discipline such as G-Q-I-M. For example, a corporate finance function using “timeliness of budget preparation” as their key performance indicator could be missing the point. A goal-focused approach would remind us that the purpose of a corporate finance function is financial stability or profitability. While timeliness is a normative metric, it still is not aligned to the goal of why the company would have a budget. The key budget metric in this case would be whether the budget is aligned to business priorities and whether actual spend is within the limits set by the budget.
- In addition, metrics development can leverage frameworks such as the Balanced Scorecard, which is a leading model that consists of four components: Financial Performance, Customer Satisfaction, Internal Business Processes, and Learning and Growth (i.e., human capital and innovation). The SQDCME model developed by the Ford Production System is another useful framework in that it also provides a prioritized exhaustive, cross-functional inventory of metrics. SQDCME stands for Safety-Quality-Delivery-Cost-Morale-Environment. In industries that are less manufacturing-intensive, Safety could better be understood as Risk or Security. Morale generally means human capital considerations, and Environment refers to ecological concerns or, perhaps more broadly, social responsibility. Such cross-functional frameworks can ensure reporting across dimensions of interest to managers and, when relevant, establish a rough prioritization.
- When publishing a list of metrics, a helpful discipline involves describing a purpose and/or context for each metric. This will both help the author ensure s/he is developing something useful for audiences and help audiences understand how a particular measure could be used.
- Generally, I would expect a target state for each metric and an acceptability threshold.
- If a customer satisfaction rating exceeded some target state (such as 95%, 98%, or whatever makes sense for that business context), we could be at a comfortable level (perhaps represented by a “green” on a Red/Amber/Green color-coding).
- If the metric fell below that level, it would enter an “amber” zone.
- Below another level (perhaps 90% on the customer satisfaction example, but the exact thresholds would depend on how the metric is calculated and what is the business context), it would be in a “red” zone, indicating it is below the acceptability threshold and requiring urgent corrective action.
Many metrics in my professional experience begin with “number of” (e.g., number of trades, number of accounts, number of routine reports, etc.). The normative context, target levels, or implied managerial actions are not immediately apparent. Another similar example is an HR metric “total staffing by department/level (new positions, departures, new hires).” While there could be a normative connection (“timely recruiting to meet the staffing needs of each business unit”), I would prefer to see clearer normative quantifiable metrics such as “speed and quality of new hires (average time to fill an open role and average retention and/or performance evaluation of new hires after first 6-18 months).”
Transforming the Business
Second, and more holistically, a top-down approach to metrics may better ensure that the metrics are measuring outcomes that are important to meeting business goals. Traceability is an important concept that indicates any goal or metric should be able to support a higher-level goal or metric up to the purpose of the enterprise. Starting with a mission or vision statement at the enterprise level is critical.
The key point is traceability. Stating the goals at the enterprise level and cascading down using the principle of traceability will ensure business relevance of metrics. The goal statement should be quantified with KPIs and appropriate to enterprise’s essential purpose. Other functional goals and lower-level metrics should in some way support the top enterprise goal and the three to five enterprise KPIs.
As we consider a top-down approach, executive engagement with metrics presents an opportunity for the transformation of operations strategy into a process-driven approach. Too often, lists of departmental metrics can be indicative of a siloed approach to management in which each function is considered independently (with some metrics even more specifically focused on individual roles). The opportunity here is to better understand how metrics contribute to enterprise value and to other functions within the enterprise. The tool to do this is a business process architecture.
Here is an excerpt that explains this concept:
“A business process architecture is a hierarchical model of the business processes of an organization. It provides a powerful visualization and management tool. Organizations are traditionally managed via the template laid out by the organization chart. Yet not one of the entities shown on any organization chart can, by itself, deliver value to an external customer. The reality is that we create, accumulate, and deliver value through collaboration across the organization chart. We manage resources vertically using the organization chart. We create and deliver value horizontally across the organization, and the key management artifact should be the process architecture.” –Roger Tregear, Reimagining Management
In my approach to process improvement and operations strategy, I consider the process architecture as the key managerial artifact. I begin by understanding the value chain of the business. How does the enterprise provide value to customers? What is the high-level process? After understanding the conceptual sequence of the value chain, decomposing into sub-processes helps managers and stakeholders have a view of the organization. To illustrate what I mean, I am sharing below several reference architectures. Imagine these “placemat” sections each having relevant KPIs that successively build into higher-level goals. Those KPIs could create a heat map using the process architecture. In high-maturity environments, the heat map could indicate which areas have strong performance and which have weak performance, making it easy to also see dependencies and which other downstream business capabilities that could be affected by under-performing KPIs. In low maturity organizations, perhaps the heat map could indicate where metrics are actively collected and for which we do not yet have the capability to measure.
This process architecture approach forms the basis of process-driven management and could be a starting point to more effectively driving metrics that are connected to goals. For more on process-driven management, you could view Roger Tregear's forthcoming book, quoted above, or read my previous BPTrends article: http://www.bptrends.com/making-bpm-work/. To illustrate the concept, please refer to these three examples of enterprise-wide business process architectures:
Figure 1: Accenture Cross-Industry Reference Architecture
Figure 2: Microsoft Banking Industry Reference Architecture
Figure 3: American Productivity & Quality Center (APQC) Process Classification Framework (PCF)
What do internal management reports look like and how should they be used?
Internal management reports provide key metrics, including periodic trending over time with year-over-year comparisons, comparisons against similar business units, competitor or industry benchmarks, and target and acceptability thresholds. They should also include narrative interpretation to indicate the significance of the performance, trends, and comparisons.
The process architecture discussed in the previous question could give some insight into differences between top management reports and those designed for business units. Because the process architecture decomposes from the highest-level enterprise capabilities into more specific subcomponents, this decomposition could correspond to different levels of management. Top management would be a more appropriate audience for enterprise KPIs and one level below, while business units would be more focused on more specific metrics focused on functional capabilities.
Metrics would ideally feed standardized, or even automated, process improvement processes (for more, see the next section below). They can also be used by top management as a way to understand problems in the organization that may require leadership attention or intervention as well as learn about managers and functional leaders responsible for the performance of different capabilities.
What is the process if the metrics highlight an issue in a department? What do you do and how does it get resolved?
As this process management system develops, it will eventually reach a high-maturity state in which the ongoing measurement of performance triggers process improvement processes and activities in an automated way. In lower-maturity environments as we just begin to build out this capability, underperforming metrics require more ad hoc follow up. There are several methodologies for process improvement, from the simple Kaizen approach, which involves team-based improvement efforts with short scopes (three to five days) to make small, incremental improvements. The advantages to this approach are that it ensures buy-in and ownership, it builds capability among front-line employees, and – because of its short time horizon and humble aspirations for small improvements – we can be relatively confident that something will actually get done. However, it is a “rinse and repeat” method in that we must continue to deliver more improvement projects to have significant impact. An alternative method is Six Sigma, which involves a longer and more robust analysis using statistical methods. The advantages to this method are that it is better aligned to larger and more complex business problems, but it requires more technical skills, is less transferable to the front-line, and requires more time to complete projects. I would assess the nature of the specific problem raised and the organizational capability and choose one of these or another methodology. I plan to contribute a future article to BPTrends to share ideas on change management, or how to ensure effective implementation and buy-in for the process improvement.
With regard to these metrics, how do you frame what you need from IT?
There could be two different approaches to IT enablement of metrics reporting: build or buy. In both cases, clear articulation of requirements is essential. The first alternative would depend on whether the application development capability and capacity of the IT department are sufficient to tailor a custom solution and whether a custom solution would be preferable for the organization (because commercial-out-of-the-box solutions can often be more economical, more effective, and easier to maintain). If we decide to buy a solution, which seems to be the more likely option, there is much literature available comparing different technologies in business intelligence. Gartner's Magic Quadrant and The Forrester Wave are two of the most respected and well-known reports. I would still partner with IT to develop business requirements as developing requirements first is the best way to ensure the right solution is chosen in an IT procurement process.
Metrics are a popular, and sometimes controversial, topic. Business architecture and transformation professionals can serve their organizations by thinking through the relevant issues with respect to metrics. Ultimately, effective metrics – like other parts of a business – depend on an effective process: (1) plan for measurement, (2) collect data, (3) analyze the data, and (4) report findings. Understanding that process, particularly the first step, will help transformation professionals to build executive engagement and sponsorship to advance the maturity and capability.
 I would like to express gratitude to Sandeep Johal and Roger Tregear of Leonardo Consulting and Joanne Dong of JDStream Management Consulting for their input into this article. Any criticisms you might have of the article are likely due to my stubbornness in not making all the changes Sandeep, Roger, or Joanne suggested.
 A clarifying note on pronouns: The singular first person (“I”) is meant as me as the author speaking to “you” as the reader (whom I consider to be a business architecture or process excellence professional). The singular second person (“you”) is you as the reader, either my advice to “you” or in a hypothetical question from the hypothetical executive such as “How do you frame what you need from IT?”. The plural first person “our” or “we” (such as in “How can metrics help our organization?”) is intended to refer to the executive manager asking your advice, you, and generally the organization of which the notional “you” and the notional executive are members.