IT Governance Metrics Measurement and Benchmarking Best Practice Workbook Roadmap, Implementation and Management - Ready to…

1. 1Name the motive behind your current reporting. If you monitor and report at component level mainly to protect yourself or point the blame elsewhere, say so. The passages treat that as the failure this construct corrects: service measurement is about a meaningful view of the IT service as the customer experiences it.
2. 2Start with business processes (Step 1). List them and mark which are critical to delivering value to the business. Confirm that IT goals and objectives support the business goals and objectives. Only the marked services get an end-to-end measure.
3. 3Define success before choosing metrics. Write down what you are trying to achieve and how you will know you have achieved it. The passages call this 'Origins: defining what success looks like'.
4. 4Sort your existing metrics into three tiers: technology (component and application metrics such as performance and availability), process (CSFs, KPIs, activity metrics), and service (results of the end-to-end IT service). Label the service tier as the one you report to the customer.
5. 5Build each service metric from its component metrics. The passages say component metrics are used to compute service metrics, so keep monitoring components but stop presenting them alone. Use the 'Availability Reporting' approach: measure at different levels of systems and components to produce one true service measurement.
6. 6Measure results, not efforts. For each service, state the organizational output and the contribution it makes, then derive goals and metrics for each role in the process from the process goals and the service's quality attributes.
7. 7Write the KPI as a CSF, KPI, required metrics and measurements chain. For a qualitative goal: CSF = improve IT service quality; KPI = 10% rise in customer satisfaction for incident handling over 6 months; metrics = starting and ending satisfaction score; measurements = survey score and number of scores.
8. 8Add tension metrics so no single element dominates. If you push only for on-time delivery, resources and service features get flexed, which leads to budget increases or lower quality. Review every KPI critically against the framework's limitations before you implement it.
9. 9Make the output usable for decisions. Check that the report lets someone make an operational, tactical or strategic decision, and that it looks forward as well as back.

The passages give a customer-facing measure: CSF = improving IT service quality, KPI = a 10% increase in the customer satisfaction rating for handling incidents over the next 6 months. You capture the original customer satisfaction score for incident handling and the ending score, using the incident handling survey score and the number of survey scores as measurements. The KPI rests on what the customer rates, not on how fast any one team closed its tickets. In parallel you keep component metrics such as availability and performance, but use them as inputs that compute the service metric rather than as the report. A team that once reported 'our server was up' now reports the service level the customer actually experienced. Pairing this with a cost KPI, such as a 10% reduction in the cost of handling printer incidents, acts as a tension metric: satisfaction cannot be bought without regard to cost, and cost cannot be cut without watching satisfaction.

• If a report shows only a component, system or application result, then add or substitute the service level as the customer experiences it before it goes out.
• If a metric describes effort (hours, tickets touched) rather than output, then rewrite it around the result and contribution, or drop it.
• If the reason for a measure is to show it wasn't your component's fault, then stop reporting it externally. Keep it as an internal input to the service metric.
• If a goal is driven by one element, such as on-time delivery, then add a tension metric on the others (budget, quality) so it cannot be hit by flexing them.
• If you cannot name the business process and decision a service metric supports, then it is not tied to business value; leave it out.

• Component reporting passed off as service reporting: the tell is green dashboards for each system while customers still complain.
• Blame-driven monitoring: the tell is reports built to show another team's component failed, and disputes about whose number is right rather than what the customer saw.
• Measuring effort instead of results: the tell is metrics that show activity volume with no stated output or contribution.
• Single-factor targets: the tell is on-time delivery met while the budget grows or quality falls.
• Metrics chosen without a defined success picture: the tell is nobody can say what you were trying to achieve or how you would know you had achieved it.

• ▸Service and critical business process: name the service and the business process it supports (Step 1).
• ▸Definition of success: what are we trying to achieve and how will we know we have achieved it?
• ▸Customer-experienced measure: the service-level result the customer actually sees (e.g. incident handling satisfaction score).
• ▸Component inputs: the technology metrics (availability, performance) used to compute the service metric.
• ▸CSF and KPI: the critical success factor and the target change with a time frame.
• ▸Metrics and measurements required: starting and ending values, and the raw data that produces them.
• ▸Tension metric: the competing element (cost, quality, time) that stops one factor dominating.
• ▸Role-level goals: the goal and metric for each role, based on process goals and service quality attributes.
• ▸Decision supported: the operational, tactical or strategic decision this report enables.

1. 1Tie each improvement effort to a Critical Success Factor before choosing any number. Write the CSF in one line (for example, 'Improving IT service quality'), then derive the KPI from it. The KPI must be measurable and time-boxed, for example '10% increase in customer satisfaction rating for handling incidents over the next 6 months.'
2. 2List the metrics the KPI needs, including the baseline. For the incident example, that means the original customer satisfaction score for handling incidents and the ending score. Without a captured starting score, you cannot show improvement later.
3. 3Define the underlying measurements and how you collect them: the incident handling survey score and the number of survey scores. Metrics define what is measured. Measurements are the raw data that feed them.
4. 4Sort every metric into one of three types: technology (component and application, such as performance and availability), process (CSFs, KPIs, activity metrics), or service (end-to-end results computed from component metrics). Use process metrics to find improvement opportunities. Use service metrics to judge what the business receives.
5. 5Test each KPI against the four questions KPIs can answer: quality, performance, value, and compliance. Review your indicators critically against these questions before you implement them, so you know the limits of your measurement framework.
6. 6Measure results, not effort. Focus on organizational output and the contribution it makes. Then define goals and metrics for each role in the process, based on the process goals and the service's quality attributes.
7. 7Add tension metrics so cost, quality, and delivery stay balanced. If a team is pushed only toward on-time delivery, the manager flexes resources and features to hit the schedule, and the result is a budget increase or lower quality. Pair each delivery metric with a cost metric and a quality metric.
8. 8Run improvement as a cycle. Create and manage a Service Improvement Plan (Plan, Do, Check, Act), implement the improvements, and keep auditing. Partial audits at least once a year keep the focus on process control so it does not slack off. For deeper projects, use Six Sigma's define-measure-analyze-improve-control (DMAIC), starting from customer requirements and the process that delivers them.

The source passages give a qualitative case. The CSF is 'Improving IT service quality.' The KPI is a 10% increase in customer satisfaction rating for handling incidents over the next 6 months. You first record the original customer satisfaction score for handling incidents. The measurements are the incident handling survey score and the number of survey scores collected. At month six you take the ending score and compare it with the baseline. A tension metric stops the target being met by cutting corners elsewhere. If the team hits a delivery or response target by flexing resources and features, the passages warn that the budget rises or quality falls. So you also track cost, such as time spent on Problem Management activities and the cost of calls to third-party vendors, alongside the satisfaction score. The improvement counts only if satisfaction rises and cost and quality hold. The measure is the result, not the number of surveys sent.

• If a proposed metric counts activity (hours worked, tickets touched) rather than output or contribution, then redefine it around results before adopting it.
• If a delivery, cost, or quality goal is set alone, then add tension metrics for the other two so the team cannot meet one by flexing the others.
• If you cannot state a baseline and an end value for a KPI, then it is not ready; capture the starting score before work begins.
• If a metric is specialized to one subject area, then do not benchmark or compare it outside that domain; only generic metrics can be aggregated across units.
• If a surveillance audit finds a major non-conformance, then rectify it; if the finding is minor, then expect a possible follow-up audit rather than assuming it closes itself.

• Measuring effort instead of results. The tell: dashboards report volumes of activity but no one can name the output or contribution they represent.
• Single-driver management. The tell: delivery dates are met, then the budget climbs or quality drops, as the tension-metrics passage predicts.
• Goals with no baseline. The tell: a KPI says 'improve satisfaction' with no original score, so the end of the period offers nothing to compare against.
• Comparing specialized metrics across domains. The tell: a metric valid only in one subject area is aggregated or benchmarked against another business unit's numbers.
• Improvement that fades after certification or launch. The tell: audits are skipped between cycles and process management control slackens, instead of partial audits at least yearly and a maintained Plan-Do-Check-Act improvement plan.

• ▸Critical Success Factor: state the outcome in one line (e.g., improving IT service quality).
• ▸KPI statement: write the measurable target and time frame (e.g., +10% in 6 months).
• ▸Metric type: mark technology, process, or service.
• ▸Baseline metric: record the original value and the date it was captured.
• ▸Measurements and source: list the raw data and how it is collected (e.g., survey score, number of scores).
• ▸KPI question answered: mark quality, performance, value, or compliance.
• ▸Result or effort check: confirm the metric measures output or contribution, not activity.
• ▸Tension metrics: name the cost metric and the quality or delivery metric that balance this KPI.
• ▸Review date and owner: set when the end value is compared with baseline, and who acts on the gap.

1. 1Anchor each improvement to a Critical Success Factor, then derive the KPI from it. The workbook's pattern is CSF (e.g., reducing IT costs) leading to a KPI (e.g., 10% reduction in the cost of handling printer incidents). Write the CSF and KPI as one pair before you collect any data.
2. 2List the metrics the KPI requires, then the raw measurements behind each. For the printer KPI the metrics are original handling cost, final handling cost, and cost of the improvement effort. The measurements are 1st and 2nd level time on the incident, average salary, Problem Management time, training time for 1st level on the workaround, and 3rd party vendor call costs.
3. 3Classify every measure as a technology metric (component or application availability and performance), a process metric (CSF, KPI, activity metrics) or a service metric (end-to-end result). Compute service metrics from component metrics so availability and reliability reflect what the customer experiences.
4. 4Set a target for every measure, drawn from the SLA or OLA agreed internally within IT, and write it as a SMART target. Assign roles for who defines measures and targets, who monitors and measures, who gathers data, who processes and analyzes it, who prepares reports, and who presents them.
5. 5Test each measure before go-live against the workbook's criteria. It must be accurate and reliable, well defined, relevant to the objectives, free of negative behavior, and capable of leading to improvement opportunities. Drop or rewrite any measure that fails.
6. 6Pair each primary metric with a tension metric. Where on-time delivery drives an initiative, add metrics on budget and quality so the team cannot hit the date by flexing resources and features and silently raising cost or lowering quality.
7. 7Benchmark against internal baselines, the customer's view and competitors. Use the gaps in processes, technology, staffing levels and skills as the starting list of improvement targets, rather than relying on internal audit or self-assessment alone.
8. 8Define the criteria for continual improvement initiatives and decide in advance when targets should be raised. For defect-type measures, express capability in Six Sigma terms: a defect is anything outside customer expectations, and the 3.4 defects per million opportunities (99.99966% error-free) benchmark is the ceiling, not the starting target.

Take the workbook's quantitative example. The CSF is reducing IT costs, and the KPI is a 10% reduction in the cost of handling printer incidents. You need three metrics: the original cost per printer incident, the final cost per printer incident, and the cost of the improvement effort. The measurements feeding them are time spent by 1st and 2nd level operatives multiplied by their average salary, time spent on Problem Management activities, time spent training 1st level on a workaround, and the cost of calls to a 3rd party vendor. You baseline those inputs first, which yields the original cost. After the change, you re-measure the same inputs for the final cost. The KPI is met only if the final cost sits at least 10% below the original, and the improvement-effort cost is counted so the saving is net. The workbook's qualitative counterpart tracks an incident handling survey score, so you also record the starting and ending customer satisfaction score and the number of survey scores. That check shows cost fell without service quality falling.

• If a proposed measure cannot be tied to a CSF, then do not adopt it; it produces data without an improvement decision.
• If a target is being hit but customer satisfaction or quality is flat or falling, then add or tighten a tension metric, because the team is likely trading one element for another.
• If your measures are specific to one subject area, then do not benchmark them directly against other domains; use generic metrics when you need to aggregate across business units.
• If the target is the SLA or OLA figure and it is met consistently, then use your pre-agreed criteria to decide whether to raise the target, instead of leaving it static.
• If processes are at inconsistent maturity levels, then assess maturity (e.g., against CMMI levels) before committing to a certification or formal improvement program.

• Measuring components, not services: dashboards show server or application availability green while customers report outages. The tell is service metrics that are not computed from component metrics.
• Single-metric optimization: one target is hit at the expense of budget or quality. The tell is a rising cost or defect count alongside a hit delivery date, with no tension metric in place.
• No baseline or cost of effort: the saving is claimed without the original cost or the improvement cost. The tell is a KPI result that cannot be reproduced from stated metrics and measurements.
• Unowned measurement: nobody is named for gathering, analyzing or presenting data, so reports lapse or disagree. The tell is the 'who' questions going unanswered.
• Self-assessment only: performance is judged through internal audit with no external or competitor benchmark. The tell is that no gaps in processes, technology, staffing or skills are ever identified.

• ▸Critical Success Factor: state the outcome, e.g., reducing IT costs.
• ▸KPI and target: state the numeric goal in SMART form and its SLA/OLA source, e.g., 10% reduction in printer incident handling cost.
• ▸Metric type: mark technology, process or service, and the component metrics feeding any service metric.
• ▸Metrics required: list original value, final value, and cost of the improvement effort.
• ▸Measurements and data source: list raw inputs (time spent, salary, vendor call cost, survey score) and the tool or owner for each.
• ▸Roles: name who defines, monitors, gathers, analyzes, prepares and presents.
• ▸Tension metric: name the paired quality, budget or schedule measure that guards against imbalance.
• ▸Benchmark gap: record the internal, customer-view and competitor comparison and the gap found.
• ▸Review rule: state the criteria for closing the initiative and when the target is raised.

1. 1Open with the pressure the passages name: IT must keep proving compliance through successful independent external audits, and must also do more with less while creating additional value from existing resources. Write both as the two claims your evidence has to support.
2. 2Pick one Critical Success Factor per business objective. The passages pair CSF 'Improving IT service quality' with a satisfaction KPI, and CSF 'Reducing IT costs' with a cost KPI. Name the objective first, then the CSF.
3. 3Write each KPI as a measurable change over a stated period, as in '10% increase in customer satisfaction rating for handling incidents over the next 6 months' or '10% reduction in the costs of handling printer incidents'. Check that each KPI answers one of the four questions the passages give for KPIs: quality, performance, value or compliance.
4. 4Set the baseline before any change. The glossary defines a baseline as the base level of previous or current performance used to set goals and assess progress. For the cost case, record the original cost of handling a printer incident. For the quality case, record the original customer satisfaction score.
5. 5List the raw measurements behind each metric. For the printer cost case: time spent on the incident by 1st and 2nd level operatives and their average salary, time on Problem Management activities, time spent training 1st level operatives on the workaround, and cost of calls to the 3rd party vendor.
6. 6Record the cost of the improvement effort next to the benefit. The quantitative example lists 'Costs of the improvement effort' as a required metric, so ROI is computed against it. Run the figures through the workbook's ROI Calculator.
7. 7Add tension metrics so the value claim cannot be bought by sacrificing another factor. The passages warn that driving only on-time delivery leads to a budget increase or lower product quality. Pair every value KPI with a counter-measure covering time, budget or quality.
8. 8Add a benchmark: compare your result against best-in-class or best-practice examples to show competitive standing. Only compare generic metrics across units. The passages state that domain-specific metrics cannot be directly benchmarked outside their domain.
9. 9Package the result for management with the ROI presentation and the example KPI documents for the value of service management and high-level goals. The workbook says these presentations can serve as the basis for a formal business case.

The passages give two paired examples. Quantitative: CSF = reducing IT costs; KPI = 10% reduction in the cost of handling printer incidents. The required metrics are the original cost per printer incident, the final cost per printer incident, and the cost of the improvement effort. The measurements feeding them are 1st and 2nd level operative time times average salary, time spent on Problem Management, time spent training 1st level staff on the workaround, and cost of calls to the 3rd party vendor. Qualitative: CSF = improving IT service quality; KPI = 10% increase in customer satisfaction for incident handling over 6 months. The metrics are the original and ending satisfaction scores, measured by the incident handling survey score and the number of survey scores. Together they let IT say 'cost per incident fell by X against an improvement cost of Y, and satisfaction rose', which is a business case tied to stated objectives. No figures beyond the 10% targets are given in the source, so the actual results come from your baseline.

• If you have no baseline for a metric, then do not state a benefit. Measure current performance first, because improvement is judged against it.
• If a KPI cannot be tied to quality, performance, value or compliance, then drop it or rewrite it. It does not support the business case.
• If a value KPI optimises one element such as delivery time, then add a tension metric on budget or quality before reporting it.
• If the improvement cost is not in the calculation, then the figure is not an ROI. Add the effort cost to the metrics required.
• If a metric is specific to one domain, then do not benchmark it against other domains. Use generic metrics for cross-unit or external comparison.

• Reporting activity or technology metrics (availability, component performance) as business value. The tell: the report never names a business objective or a CSF.
• Claiming a cost reduction without the improvement effort cost. The tell: the 'saving' has no matching investment line.
• Starting measurement after the change. The tell: you cannot state the original score or cost, so the percentage change is unverifiable.
• Single-factor optimisation. The tell: the delivery target is met while budget rises or quality drops, which is the imbalance tension metrics are meant to prevent.
• Presenting compliance as a one-off. The tell: no evidence of repeated successful independent external audits, although the passages say IT must continually demonstrate compliance.

• ▸Business objective: state the objective IT improvement is meant to serve.
• ▸CSF: one success factor linked to that objective (e.g. reducing IT costs).
• ▸KPI statement: a measurable % change with a time frame, and which of quality/performance/value/compliance it answers.
• ▸Baseline: the original cost or score and the date it was measured.
• ▸Raw measurements: list the data sources (staff time x salary, vendor call costs, survey scores and count).
• ▸Improvement effort cost: total cost of the initiative, entered into the ROI calculator.
• ▸Result vs baseline: the final cost or score and the % change achieved.
• ▸Tension metric: the time, budget or quality counter-measure and its current reading.
• ▸Compliance evidence: the latest independent audit result and date.
• ▸Benchmark reference: best-in-class or best-practice comparison, using generic metrics only.

1. 1Sort every candidate measure into one of three layers before you define it: technology (component and application metrics such as performance and availability), process (CSFs, KPIs and activity metrics for service management processes), or service (end-to-end results computed from component metrics). A measure with no layer has no owner and no place in the roll-up.
2. 2Start from the objective, not the data you already collect. Write the objective broadly, then derive one Critical Success Factor, then one KPI. The source's chain: CSF = improving IT service quality; KPI = 10% increase in customer satisfaction rating for handling incidents over the next 6 months.
3. 3List the underlying metrics each KPI needs, including baseline and end-point. For the incident KPI these are the original customer satisfaction score for handling incidents and the ending score. If you cannot name the baseline source, the KPI is not yet measurable.
4. 4Define each metric precisely: what is measured, the quantitative assessment method, and the process that carries out the measurement. Metrics define what is to be measured. Record the data source, who captures it, and when.
5. 5Check scope of validity. Specialized metrics are valid only within their domain and cannot be benchmarked outside it. Generic metrics can be aggregated across business units. Tag each metric as specialized or generic before you compare or roll up.
6. 6Test each process KPI against the four questions KPIs should answer: quality, performance, value and compliance. A KPI that answers none is activity noise. Rebuild or drop it.
7. 7Compute service metrics from component metrics, then check that they reflect what the customer experiences. For availability, use the supporting 'Example: Availability Reporting' as a template. Define a defect the Six Sigma way: anything outside customer expectations.
8. 8Route results into improvement. Process metrics are the input for identifying improvement opportunities. Assign a named action for each out-of-range reading, and review whether the metric itself still serves the objective. Check for perverse effects before you adopt it.

The source's qualitative example runs as follows. The objective is better IT service quality, so the CSF is 'Improving IT service quality.' The KPI is 'a 10% increase in customer satisfaction rating for handling incidents over the next 6 months.' The metrics required are the original customer satisfaction score for handling incidents and the ending score at six months. You measure the baseline now, from the same survey and the same incident population you will use at the end. You set the target as baseline × 1.10 and fix the six-month date. You tag the metric as a process metric, since it tells you about the incident process. It answers the quality question. At month six you compare the two scores. A shortfall becomes an improvement opportunity for the incident process, and a hit prompts the question of whether the target was set too low. The source gives no scores, so the numbers stay as blanks in the tool below.

• If a metric cannot be traced to a CSF and an objective, then drop it, however easy the data is to collect.
• If a KPI lacks a stated baseline and end-point, then it is not yet a metric. Capture the baseline before you set any target.
• If you intend to benchmark a metric across units or against outside organizations, then confirm it is generic. A specialized metric is valid only inside its domain.
• If a service metric moves and you cannot decompose it into component metrics, then the measurement design is broken. Rebuild the link from technology to process to service.
• If a KPI answers none of quality, performance, value or compliance, then retire it. If it is the only KPI for a process, replace it rather than leave the process unmeasured.

• Measuring technology only: availability and performance stay green while customers are unhappy. The tell is a healthy component dashboard alongside rising complaints or falling satisfaction.
• Targets with no baseline: 'improve satisfaction' appears without a starting score or a date. The tell is that nobody can say at review time whether the target was met.
• Benchmarking specialized metrics across domains: you compare numbers that were never comparable. The tell is a league table whose definitions differ between units.
• Short-horizon ROI-style metrics: the measure either meets a numerical criterion or it doesn't, which looks self-evident, but it ignores differing business impact and the difficulty of quantifying implementation complexity. The tell is a metric that passes while the benefit is unclear.
• Reporting without action: metrics are collected but not used to find improvement opportunities. The tell is a report with no owner, no follow-up item and the same red status next period.

• ▸Objective: state the business or service objective in one broad sentence.
• ▸Critical Success Factor: the single factor that must go right to meet the objective.
• ▸KPI statement: the measurable target with a value and a time frame.
• ▸Metric layer: technology, process or service. Name the owning role.
• ▸Metric type: specialized (domain-bound) or generic (can be aggregated or benchmarked).
• ▸Measurement method: what is measured, data source, who captures it, how often.
• ▸Baseline value and date: the starting figure measured before the target is set.
• ▸End-point value and date: the figure at review, and the comparison against the target.
• ▸KPI question answered: quality, performance, value or compliance. Add a perverse-behaviour check and the improvement action triggered if the target is missed.

1. 1Start from the business side. Write down the organization's strategic goals, mission and critical success factors before you pick any IT measure. The Excellence Implementation Framework opens with exactly these: strategic goals, mission, CSFs and key processes define the strategic direction.
2. 2Baseline the current position. Use self-assessment against the Excellence Model and product/service assessments to answer 'where are we now?' Then run a gap analysis. The gaps are your strategic improvement opportunities, and they decide which IT processes get measured.
3. 3Express each IT goal as a CSF tied to a business goal. Example CSFs from the source: 'Improving IT service quality' and 'Reducing IT costs'. If you cannot name the business goal a CSF serves, drop the CSF.
4. 4Attach a KPI with a magnitude and a time frame to each CSF. The source models this as '10% increase in customer satisfaction rating for handling incidents over the next 6 months' and '10% reduction in the costs of handling printer incidents'. A KPI that lacks a target and a period cannot show progress toward the goal.
5. 5List the metrics each KPI requires, then the raw measurements behind those metrics. For the cost KPI the metrics are original cost per printer incident, final cost per printer incident and cost of the improvement effort. The measurements are 1st and 2nd level time and average salary, Problem Management time, training time and 3rd-party call cost.
6. 6Check KPI coverage against the four questions KPIs help answer: quality, performance, value and compliance. Use these to confirm the set shows business value and is not purely technical.
7. 7Verify alignment at three levels: organization, key process and work unit. The Alignment definition requires complementary measures and a common understanding of goals at all three, so trace every work-unit measurement up to an organization-level goal.
8. 8Use component metrics to compute service metrics, and report the end-to-end service result. Then feed the results into improvement-opportunity decisions, prioritizing process analysis and Six Sigma-style projects for the gaps that carry bottom-line benefit.

The source gives a two-line trace from business goal to measurement. Take the business goal of reducing IT costs. The CSF is 'Reducing IT costs'. The KPI is a 10% reduction in the costs of handling printer incidents. The metrics required are the original cost of handling a printer incident, the final cost, and the cost of the improvement effort. The measurements feeding those metrics are time spent on the incident by 1st and 2nd level operatives and their average salary, time spent on Problem Management activities, time spent training 1st level operatives on the workaround, and the cost of calls to a 3rd-party vendor. Including the improvement effort's cost keeps the result honest, because the saving is judged net of what it took to achieve it. The qualitative twin runs the same chain from 'Improving IT service quality' to a 10% rise in incident-handling satisfaction over 6 months, measured by the starting and ending survey scores and the number of scores collected. In both chains, every measurement can be traced upward to a business-level goal.

• If a proposed KPI cannot be traced through a CSF to a stated business goal, then drop it or re-derive it. Do not report it.
• If a KPI lacks a numeric target or a time frame, then add both before collecting data. The source examples always carry a percentage and a period.
• If a metric is specialized to one subject area, then do not benchmark or compare it outside that domain. Use generic metrics when you need to aggregate across business units.
• If the gap analysis does not flag a process as a strategic improvement opportunity, then do not make it a priority for measurement or improvement effort.
• If measures at the work-unit level do not roll up to key-process and organization-level measures, then treat the organization as misaligned and fix the measures before adding new ones.

• Starting from available data instead of business goals. The tell: the dashboard is full of metrics, but no one can name the business goal each serves.
• Writing KPIs with no target or period, such as 'improve satisfaction'. The tell: nobody can say whether the KPI was met.
• Counting benefit but ignoring cost. The tell: the savings figure omits the cost of the improvement effort, which the source lists as a required metric.
• Treating individual facts and data as a basis for action. The tell: reports list numbers but no cause/effect analysis. The source states that actions depend on understanding cause/effect relationships.
• Aligning at only one level. The tell: organization-level goals exist, but process and work-unit measures use different, uncoordinated definitions.

• ▸Business goal: state the strategic goal in the organization's own words.
• ▸Gap-analysis evidence: record the baseline finding that makes this goal an improvement opportunity.
• ▸IT CSF: name the critical success factor that supports the business goal.
• ▸KPI (target + period): write the percentage change and the time frame.
• ▸KPI question answered: mark quality, performance, value or compliance.
• ▸Metrics required: list the starting value, ending value and improvement-effort cost.
• ▸Measurements: list the raw data items, their sources and who collects them.
• ▸Three-level alignment check: record the organization, key process and work unit measure for this goal.
• ▸Owner and review date: name the accountable person and when the result is judged.

1. 1Set the internal baseline first. The workbook defines a baseline as the base level of previous or current performance, used to set improvement goals and judge later progress. Record the current value of each metric before you contact any outside party. Without it, an external gap has nothing to be measured against.
2. 2Choose the subject and split it across the four things the construct compares: process, technology, staffing and performance. Give each metric one of the Balanced ScoreCard lenses (financial, customer, internal, learning and growth). This keeps you from benchmarking only cost. The workbook's balanced-performance logic says managing one force is easy, two is harder, and balancing customers, employees and operational/financial results is difficult but necessary.
3. 3Fix the unit of data collection before collecting. The workbook notes that data collection for process transactions differs from data collection for a function. Decide whether you are benchmarking a transaction-level process or a whole function, and define each metric the same way for every party you compare.
4. 4Budget the three costs the workbook names. Visit costs are travel and accommodation. Time costs arise because team members spend part of each day researching problems, finding exceptional companies, visiting and implementing, so additional staff may be needed to backfill. Database costs apply if you institutionalize benchmarking with a maintained database of best practices and the companies behind each one.
5. 5Select benchmarking partners. These are the other organizations you compare against to find best practices to adopt. Use three reference classes: your own prior performance, industry norms, and named competitors or exceptional companies. Record which class each comparison number comes from.
6. 6Compute the gap per metric as your baseline versus each reference value. Before accepting an external figure, check how it was produced. The workbook notes that the Six Sigma savings claims from ABB, Allied Signal and GE are debated. Treat any published figure as a claim to verify, not as a target.
7. 7Attribute results with one of the workbook's three techniques after you act. Forecast analysis projects a trend line as if the program had not happened. Impact analysis uses estimates from managers, independent experts and external assessments when data is missing or inconsistent. A control group runs a pilot in one geography, delivery centre or branch and compares it with a similar unaffected one. Use the strongest technique your data supports.
8. 8Store the findings in the benchmarking database: metric, partner, value, date and adopted practice. Re-run the comparison on a fixed cycle against the updated baseline, so the next gap is measured from what you achieved.

The workbook cites a Six Sigma staffing norm: Harry & Schroeder suggest one black belt for every $10M of revenue, and the claim that an average black belt project saves $175K. Treat these as external benchmark claims. Step one is your baseline. Count your current trained improvement leads and the revenue they cover, and record completed-project savings. As a hypothetical for illustration only, a firm with $50M revenue would compare its actual count against 5 black belts. Step two is the gap: if it has 1, the staffing gap is 4. Step three is the cost test: the workbook says black belt training is a massive investment (about four weeks of quality-tools training per black belt), so you price that against the claimed $175K per project. The workbook warns that the large corporate savings figures (GE at 5.5% of sales, for example) are debated. So you do not adopt the ratio blindly. You pilot it with a control group in one delivery centre, compare it with a similar centre without black belts, and decide on measured savings.

• If you have no internal baseline for a metric, then measure it first and delay external comparison, because a gap cannot be computed without a base level.
• If historical data is missing or inconsistent, then use impact analysis (expert and stakeholder estimates). If you have a clean trend, then use forecast analysis. If you can pilot in a subset, then prefer a control group.
• If a benchmark claim is publicly debated, as the Six Sigma savings claims are, then treat it as a hypothesis and verify it with a pilot before you set a target from it.
• If benchmarking is a one-off exercise, then budget only visit and time costs. If you plan to repeat it, then also budget for a best-practice database.
• If your scorecard is dominated by one lens (e.g. financial), then add customer, internal and learning-and-growth measures before you act on the gaps.

• Comparing against others without a baseline. The tell: the report lists competitor numbers but no 'our value, before' column, so improvement can't be verified later.
• Underestimating time costs. The tell: team members are pulled from regular duties for research and visits, and day-to-day work slips because no backfill was approved.
• Adopting published best-practice or savings figures as targets without checking them. The tell: targets cite a famous company's savings but you have no evidence the method works in your context.
• Mixing data definitions between a process and a function. The tell: your metric and the partner's are the same label but come from different collection methods, so the gap is inconsistent.
• Taking credit for improvement without attribution. The tell: results are reported with no forecast line, estimate source or control group, so business leaders question the value, a risk the workbook says arises without clearly defined financial objectives.

• ▸Metric and lens: name the metric and tag it financial, customer, internal, or learning and growth.
• ▸Subject type: process, technology, staffing, or performance; and whether data is process-transaction or function level.
• ▸Internal baseline (value and date): the current or previous performance before any change.
• ▸Reference class and partner: internal history, industry norm, or named competitor/exceptional company.
• ▸Partner value and source: the comparison figure and how it was obtained or verified; mark it 'debated' if so.
• ▸Gap: partner value minus baseline, with direction of improvement.
• ▸Cost to close: visit, time (backfill) and database costs, plus any training cost.
• ▸Attribution method: forecast analysis, impact analysis, or control group; name the data source or pilot unit.
• ▸Database entry and re-measure date: where the finding is stored and when the metric is next compared.

1. 1Start with the customer, not the process. Write down what the customer expects from the service. The source calls defining what to measure 'perhaps the hardest element' and says it must involve the customer. Use the Six Sigma Defining Requirements document in the workbook as the template.
2. 2Define phase: write the scope and goals of the improvement project in terms of customer requirements and the process that delivers them. Describe the process by its inputs, outputs, controls and resources. A process with no stated customer requirement has no defect definition.
3. 3Set the defect definition before collecting data: a defect is anything outside customer expectations. Count opportunities for a defect per unit of work, so you can express performance as defects per million opportunities (DPMO). The Six Sigma goal is no more than 3.4 DPMO, which is 99.99966% error-free.
4. 4Measure phase: take a baseline of how the process performs now. The source warns that most service areas 'don't have a clue' how well they are doing. Measure results as the customer experiences them, not effort and not isolated component statistics. Roll component data up into an end-to-end service view, as the Availability Reporting example does.
5. 5Analyze phase: use rigorous data gathering and statistical analysis to find the sources of variation. The focus is on reducing variability, not on hitting an average.
6. 6Improve phase: act on the identified sources of variation. Cut costs that add no value to the customer, and keep or improve customer value while you do it. Six Sigma is not simple cost cutting.
7. 7Control phase: write process control plans that reflect the new targets. Train operators in statistical process control (SPC) charting. The objective is to keep the variables on target and within acceptable ranges.
8. 8Staff by belt role. Green Belts are trained team members who apply the tools in their existing work. Black Belts are the process/project subject matter experts who lead improvement teams. Master Black Belts review and mentor Black Belts, are chosen for quantitative skill and teaching ability, and are generally full time in larger organisations. Use the Starter Kit and Short Overview documents as your working templates.

The source supplies no project data, so this walks its logic through a hypothetical IT service and invents no figures. A team reports component uptime for servers, networks and applications. The reports show the components healthy, yet customers complain. The source describes the cause: organisations often report on components to protect themselves or point blame elsewhere, rather than showing the service level the customer experiences. In Define, the team states the customer's requirement for the service and maps the process by its inputs, outputs, controls and resources. A defect becomes any service outcome outside what the customer expects, whatever the component dashboards say. In Measure, the team rolls component data up into an end-to-end service measure, following the Availability Reporting approach, and counts defects per opportunity as DPMO against the 3.4-per-million goal. In Analyze, it uses statistical analysis to find where variation enters the service. In Improve, it removes the sources of variation and cuts any activity that adds no customer value. In Control, it writes a control plan with the new targets and trains operators to read SPC charts so the variables stay within range. A Black Belt leads the team, Green Belts apply the tools in their own roles, and a Master Black Belt reviews the Black Belt's work.

• If you cannot state what the customer expects from the process, stop at Define. Without that you cannot define a defect, and the source says the customer must be involved in deciding what is measured.
• If a measure reports a component rather than the service as the customer experiences it, then roll it up to an end-to-end service view or discard it. Component reporting alone invites blame-shifting.
• If someone says Six Sigma only works in manufacturing, then point to the source: it started in Motorola's manufacturing, but any 'process' can be measured and improved with SPC. Service processes qualify, and the source expects productivity gains and direct cost savings.
• If a proposed improvement cuts cost but lowers customer value, then reject it. Six Sigma removes only costs that add no value to the customer.
• If the project is in Control, then do not close it until a control plan with the new targets exists and operators are trained on SPC charting.
• If the organisation is large, then plan a full-time Master Black Belt to review and mentor Black Belts. Choose for quantitative skill and teaching ability.

• Defining defects internally. Teams count what is easy to count, such as component uptime, not what falls outside customer expectations. The tell: green dashboards alongside customer complaints, and no customer input in the requirements.
• Measuring effort instead of results. The reports show activity, such as tickets handled or hours worked, but not outcomes. The tell: you cannot say what the output contributes.
• Skipping the baseline. The team jumps to fixes without knowing current performance, as in the service areas that 'don't have a clue'. The tell: no before-and-after DPMO or process data to show improvement.
• Treating Six Sigma as cost cutting. Savings are taken without checking customer value. The tell: costs fall while customer satisfaction or service quality slips.
• Stopping at Improve. No control plan, no SPC training, and the gains drift back. The tell: the variables wander outside acceptable ranges after the project team disbands.
• Dismissing the method as manufacturing-only. Service processes go unmeasured. The tell: the word 'process' is used, but no SPC or variation data exists.

• ▸Process and customer: name the process and the customer who receives its output.
• ▸Customer requirement: state in the customer's terms what they expect. This sets the defect definition.
• ▸Scope and goal: state the improvement goal and the boundaries of the project.
• ▸Process definition: list the process inputs, outputs, controls and resources.
• ▸Defect and opportunity definition: define what counts as a defect (anything outside customer expectations) and what counts as an opportunity.
• ▸Baseline: record current DPMO and the end-to-end service measure, set against the 3.4 DPMO goal.
• ▸Sources of variation: record what the statistical analysis found and the data behind it.
• ▸Improvement actions: list each action and confirm it removes non-value-adding cost without lowering customer value.
• ▸Control plan: set the new targets and acceptable ranges, the SPC charts used, and the operators trained.
• ▸Belt roles: name the Black Belt lead, the Green Belt team members, and the Master Black Belt reviewer.

1. 1Open with an executive workshop, not an overview. In it, set goals, draft the deployment plan, define roles, select the key people for those roles, and list areas for improvement. Management learns its own role here.
2. 2Link the initiative to the organization's strategic objectives and key performance measures. Name the critical business problems it will solve, and confirm it will be integrated across the organization rather than run as a side program.
3. 3Provide the resources visibly and early. The sources describe commitment as evident in leaders' behavior, drive, energy, and willingness to provide the necessary resources. Treat the program as a major investment that must deliver bottom-line results.
4. 4Appoint Champions and train them for their role: selecting and chartering projects, guiding Black Belts, and reviewing projects. Each Black Belt arrives at training with a chartered project that addresses a key issue from the executive workshop.
5. 5Review every project during each week of training and keep successful project completion as the number one agenda item. Understanding the method matters, but it never outranks finished projects.
6. 6Build a cadre of change leaders and make improvement training part of the promotion path. At GE, managers and aspiring managers complete the equivalent of black belt training to qualify for promotion.
7. 7Reinforce continuously. Design incentives that drive the desired behaviors, and put competency and experience in the method into the appraisal process for all staff, including executives.
8. 8Pair the leader's drive with real concern for the people being transformed. The sources warn that the hard 'edge' model is not a unified theory of leadership, and sustained success needs both qualities.

GE, Allied Signal and Motorola are the sources' examples of committed leadership. Jack Welch (GE), Larry Bossidy (Allied Signal) and Bob Galvin (Motorola) showed their commitment through behavior, drive, energy and provision of resources. At GE, Six Sigma is applied across the business, including product development, R&D, order fulfillment and back-office operations, to align resources to critical business problems and deliver strategic objectives. GE makes managers and aspiring managers complete the equivalent of black belt training to qualify for promotion. It has produced more than 70,000 part-time improvement team leaders, which the source says sends a powerful message about long-term commitment. It also includes Six Sigma competency and experience in the appraisal of all staff, including executives. The pattern is that leadership commitment shows up in promotion rules, appraisals and resourcing, not in announcements.

• If the leadership session is billed as an 'overview', then redesign it as an executive workshop that produces goals, a deployment plan, roles and named people.
• If a Black Belt arrives without a chartered project tied to an executive-identified issue, then stop the training until a Champion charters one.
• If the initiative cannot be tied to strategic objectives and key performance measures, then do not launch it; fix the alignment first.
• If incentives and appraisals do not reward the desired behaviors, then expect commitment to fade; add competency in the method to appraisals, executives included.
• If implementation is failing (the sources cite failure rates of 50% to 75% for strategic plans), then do not assume lack of management commitment is the only cause; also check complexity and the lack of an enabling structure.

• Treating executive training as an awareness overview. The tell: leaders finish with no goals, no deployment plan and no assigned roles.
• Commitment by rhetoric only. The tell: no resources, no promotion criteria and no appraisal links, so the program reads as 'one initiative too many'.
• Applying the 'edge' model of leadership alone. The tell: tough decisions are made with no concern for the people being transformed, which undermines sustained success.
• Running improvement as a side program disconnected from strategy. The tell: projects cannot be linked to strategic objectives or key performance measures.
• Blaming leadership alone for failed implementation. The tell: the plan is too broad and has no enabling structure, so leadership attention alone does not rescue it.

• ▸Strategic objectives and key performance measures supported: list the ones the initiative serves.
• ▸Executive workshop held (date, attendees): confirm goals, deployment plan, roles and key personnel were produced.
• ▸Named Champions and their project-chartering responsibilities: list each Champion and the projects they charter.
• ▸Resources committed (people, time, budget) and approving executive: state what is provided and who signed off.
• ▸Chartered projects linked to executive-identified issues: list each project and the issue it addresses.
• ▸Project review cadence: state when projects are reviewed, e.g. weekly during training.
• ▸Promotion and appraisal links: state how method competency enters promotion and appraisal, executives included.
• ▸Incentives and recognition aligned to desired behaviors: describe the reward for leaders and improvement teams.
• ▸People-concern actions: list how those affected by the change are supported.