Performance Dashboards Measuring, Monitoring, and Managing Your Business

1. 1Anchor each decision to the MAD sequence (Monitor, Analyze, Drill to Detail). For every recurring decision, name the metric that triggers it, the predefined target it is compared against, and the alert that fires when performance falls below that target.
2. 2Replace anecdote with exception conditions. When a metric trips an alert, the first question in the meeting is 'what does the analysis layer show as the root cause?' Do not discuss remedies until someone has explored the data across dimensions and hierarchies (OLAP, parameterized or ad hoc reporting).
3. 3Peel the layers before concluding. Use the three layers of information like an onion: start with the summary indicator, then go to deeper views and perspectives until the cause is identified. Record which layer the decision rested on.
4. 4Move reviews onto the dashboard. Run executive strategy meetings and manager-subordinate performance reviews from the dashboard pages, not from slide decks or memory. Have subordinates annotate the chart to explain the discrepancy and list action steps, and have the executive review, comment on and approve the plan in the tool.
5. 5Close the loop with workflow. Convert each decision into an action item kicked off from the dashboard (threaded discussion or workflow) so follow-through is traceable. This is the Act and Adjust step, which the source calls the most critical part of performance management.
6. 6Make fine-tuned course corrections instead of reversals. Use the dashboard as a steering wheel: respond to trends with a series of small adjustments rather than dramatic swings triggered by internal issues or industry events.
7. 7Remove the data-quality excuses that let intuition win. Automate data collection so analysts analyze instead of massage, source from multiple systems for an enterprise view, and use consistent definitions for common entities. Decision makers abandon dashboards they cannot trust or drill into.
8. 8Track usage and trouble tickets through IT administration features. Low usage of a dashboard in a given group signals decisions are still being made elsewhere.

The source describes an online travel site that uses an operational dashboard to alert managers when surges in demand require expanding its inventory of airline seats and hotel rooms. Under a fact-based approach, the trigger is a metric against a predefined target, not a manager's hunch that 'things feel busy.' The alert fires, the manager drills into the data to confirm where demand is surging, and then acts to expand inventory. The source also notes that for well-known processes, intelligent alerts can recommend action or execute tasks, sometimes without human intervention, which removes opinion from the loop entirely. A second example from the source is the equipment manufacturer that reforecasts sales eight times a quarter and financials once a quarter, creating plans 90 percent faster using half the staff. Frequent data-driven reforecasting replaces the annual budget ritual, which the source calls a 'corporate rain dance' that is out of date before it is finished. In both cases the decision rests on current measured data and a defined response, not on influence or anecdote.

• If a metric falls below its predefined target, then drill to the root cause through the analysis layer before assigning blame or choosing a fix.
• If the metrics show something is wrong and users immediately ask for more information, then the dashboard lacks drill-down depth; add analytical layers rather than more top-level metrics.
• If the response to a condition is well known and repeatable, then automate it with an intelligent alert that recommends or executes the action; reserve human debate for novel cases.
• If analysts spend days each week collecting and massaging data, then fix automation before demanding more data-driven decisions; manual updating stalls the culture shift.
• If a position is argued from experience or personality alone, then ask for the dashboard view that supports it; if none exists, treat it as a hypothesis to test, not a decision.

• Glitzy front end, no foundation: the dashboard looks impressive but is built in Excel or PowerPoint with no data or analytical capability to explore root cause. Tell: users see a red indicator and cannot find out why, so they revert to opinion.
• Manual upkeep: skilled analysts spend several days a week collecting data. Tell: dashboard numbers are stale at meeting time and debates start with 'my numbers are different.'
• Isolated or parochial dashboards: data comes from a single system or serves a small audience, with metrics that do not align to the rest of the organization. Tell: conflicting definitions of common entities and confusion across departments.
• Reports without alignment: too many reports measuring too many things of too little importance. Tell: meetings cite many figures but no one can say which objective they serve.
• Metrics without action: data is reviewed but never converted into follow-through. Tell: performance discrepancies are noted repeatedly with no annotated explanation, action steps or approval trail.

• ▸Decision: state the decision being made in one sentence.
• ▸Trigger metric and target: name the metric, its predefined target and the current value that fired the alert.
• ▸Root-cause drill path: list the dimensions, hierarchies and layers explored to find the cause.
• ▸Evidence summary: record what the data showed, with the dashboard page or report referenced.
• ▸Intuition or anecdote offered: note any non-data input and whether the data confirmed or contradicted it.
• ▸Action steps and owner: list each action, who owns it and the due date.
• ▸Approval: record who reviewed, commented and approved the plan in the dashboard.
• ▸Follow-up check: name the metric and date that will show whether the action worked.
• ▸Data trust issues: log any definition, freshness or integration problems that weakened the evidence.

1. 1Start from the strategy, not the departments. Write the few strategic objectives that matter and list which departments touch each one. The passages describe an 'organizational magnifying glass' that focuses everyone's energy on a clear, unambiguous set of goals. Without that focus, each unit spins off in its own direction.
2. 2Fix one definition per metric before you publish anything. Consolidate and integrate the data using common definitions, rules, and metrics, so there is a single version of business information. Write each shared metric's definition, calculation rule, and source once, and have every department's dashboard use it. This removes arguments about whose version of the data is 'right.'
3. 3Build role-tailored views on that single data layer. Executives communicate strategy and expectations to managers and staff through dashboards and scorecards tailored to individual roles. Each person logging in should see the organization's strategic objectives and what they need to do in their own area to reach them.
4. 4Match the display type to the work. Use dashboards for operational processes such as sales, shipping, or manufacturing. Use scorecards for strategic goals. Both draw on the same metrics, so operational departments and strategy owners are looking at the same numbers.
5. 5Publish performance data broadly across departments, not only up the chain. Broad publication is the mechanism that pushes staff from different departments to work more closely together. It also starts dialogue between managers and staff about how to improve performance. Give peer departments visibility into each other's results.
6. 6Turn on the management-layer functions, not just monitoring. The passages list strategy maps, initiative management, collaboration annotation, workflow, and usage monitoring as the components that improve alignment, coordination, and collaboration. Use annotation and workflow so a flagged exception moves between units on the dashboard rather than by side email.
7. 7Support exchange across levels with drill-to-detail and alerts. When a metric breaches, the owning department analyzes the exception and drills to detail, and the affected departments see the same alert and data. Managers can then exchange ideas and information between organizational levels, business units, departments, and workgroups.
8. 8Keep the system enterprise-wide and automated. Source data from more than one system and serve more than a small audience. A dashboard fed by a single system or aimed at a narrow group gives a parochial view, and its metrics may not align with the rest of the organization. Automate collection and delivery so analysts spend their time analyzing rather than massaging data. Name a central point of control or coordination so dashboards don't multiply into a haphazard, nonintegrated jumble.

The passages give no named case of cross-department coordination, so this example is illustrative and uses only the mechanisms and process names they describe. Take three operational processes the source names: sales, shipping, and manufacturing. Each department tracks its own report, with its own definition of a shared figure, and managers argue over whose version is 'right.' Step one is a single metric definition, with common rules, used by all three. Step two is a role-tailored dashboard for each department built on that same data, plus a scorecard that shows the strategic goal all three serve. Step three is publishing all three departments' results to one another, which the source says encourages staff to work more closely together and prompts manager-to-staff dialogue about improvement. When an alert fires on one department's metric, the other two see it, annotate it, and route it through workflow instead of discovering it later. The tell that coordination is working: meetings shift from reconciling numbers to deciding actions on numbers everyone already accepts.

• If two departments report different values for the same metric, then stop adding dashboards and settle one common definition, rule, and source first. Until you do, publishing more data only spreads the conflict.
• If a dashboard draws on a single system or serves a very small audience, then treat it as parochial. Widen the sources and audience, or align its metrics to the enterprise set, before you count it as coordination.
• If staff can see only their own department's results, then add broad publication of peer-group results. Visibility across departments is what prompts collaboration, and it also creates the friendly competition the source describes.
• If an exception crosses department lines, then route it through collaboration annotation and workflow on the dashboard rather than ad hoc channels, so ownership and follow-up stay visible.
• If dashboards are being built independently by different units with no central control, then establish coordination first. The source warns that organizations without central control deploy a haphazard jumble of nonintegrated dashboards, and that results are only as good as the organization measured.

• Metric definitions differ by department. The tell is meetings spent debating whose numbers are right, and analysts building competing reconciliations.
• A narrow, single-system dashboard is called 'integrated.' The tell is that its metrics don't match the rest of the organization, causing confusion, and other departments don't use it.
• Monitoring is built but the management layer is skipped. The tell is that everyone can see the alert but nobody owns the cross-unit response, and there is no annotation, workflow, or initiative tracking.
• Manual data updates consume the analysts. The tell is skilled analysts spending several days a week collecting and massaging data, so refreshes lag and departments drift back to their own sources.
• Data is kept inside each silo, or silos are left running alongside the dashboard. The tell is that spreadmarts, data marts, and separate reporting systems persist, undermining the single version of business information.

• ▸Strategic objective: state the goal in one sentence, taken from the corporate strategy.
• ▸Departments involved: list every department or business unit whose work affects this objective.
• ▸Shared metric and common definition: write the one agreed definition, calculation rule, and data source used by all departments.
• ▸Display type per department: mark each as dashboard (operational) or scorecard (strategic) and name the role-tailored view.
• ▸What each role must do: one line per role on the action it takes in its area to advance the objective.
• ▸Publication scope: state who sees each department's results, confirming peers see them and not only executives.
• ▸Exception and alert path: name the alert condition, the owner who drills to detail, and the departments notified.
• ▸Collaboration mechanism: record where annotation, workflow, or initiative management handles cross-unit follow-up.
• ▸Data sourcing and automation: list the systems feeding the metric and confirm collection and delivery are automated.
• ▸Central coordination owner: name who controls dashboard consistency and retires redundant reports.

1. 1Name the gap before you fix it. Check whether the strategy has been handed down the way the source describes: executives spend days or weeks crafting it, throw it over the wall, and 'usually nothing much happens.' If staff cannot say what the strategy asks of them, you have a translation problem, not a planning problem.
2. 2Confirm the readiness conditions first. Chapter 3 lists a clearly defined strategy, strong committed sponsorship, a clear and urgent need, mid-level manager support, and a culture of measurement. If the strategy is not defined clearly enough to measure, stop and fix that before building anything.
3. 3Decompose the strategy into explicit objectives and themes. Use the balanced scorecard method and a strategy map (Exhibit 6.8, Exhibit 9.8) so each objective is a named, individually viewable item (Exhibit 9.9), not a paragraph in a plan.
4. 4Attach metrics to every objective. The source calls metrics the linchpin between business and technical architecture. Use leading, lagging, and diagnostic measures, and set a target for each metric. Take 'great care' choosing metrics and targets, because the metrics embody the strategy.
5. 5Standardize semantics before you build. Agree on the corporate vocabulary and metric definitions with stakeholders. Semantics are named as the biggest stumbling block, and consistent definitions are what let multiple dashboards integrate.
6. 6Cascade the scorecard to every level. Performance management monitors progress toward strategic objectives 'at every level of the organization.' Give each department a strategic dashboard that shares metric definitions, data, and infrastructure with the corporate one.
7. 7Link strategy to the lower dashboard types. Strategic dashboards emphasize management. Connect them to tactical dashboards (analysis of departmental processes and projects) and operational dashboards (monitoring of core processes) so a missed objective can be traced to the process that caused it.
8. 8Put it into a review rhythm. Executives use strategic dashboards to communicate strategy and review performance at monthly strategy or operational review meetings. Make course corrections in those meetings, and plan end-user adoption and organizational change deliberately.

The source describes the failure and the mechanism but gives no step-by-step case with figures. Cisco and the Kingdom of Bahrain's Ministry of Works are cited as strategic dashboard cases (Chapter 9), with exhibits such as Cisco's functional balanced scorecard, a strategy map, and individual-objective views. What follows is the source's own logic applied in sequence, not a report of what those organizations did. Start: executives write a strategy and pass it down, and the organization stays 'deaf' to it. Intervention: express the strategy as objectives on a strategy map, give each objective leading, lagging, and diagnostic metrics with targets, and agree the definitions of those metrics up front. Then publish a scorecard view and a view of each individual objective, and build departmental scorecards that share those definitions. Finally, hold the monthly strategy review off the dashboard. When an objective goes off target, drill into the tactical and operational dashboards beneath it to find the process responsible, and correct course there. The test of success is that the strategy now generates measurable, reviewed actions at every level, where before it generated nothing.

• If people cannot state the strategy in terms of objectives they can influence, then rebuild the strategy map and objectives before adding any metrics or software.
• If two departments report the same metric with different numbers, then stop building and resolve the semantics; shared definitions come before integration.
• If an objective is off target and you cannot see why, then the dashboard lacks a tactical or operational drill path; add diagnostic metrics and linked dashboards rather than more strategy slides.
• If sponsorship, mid-level manager support, or a culture of measurement is weak, then treat adoption and change management as the project, because the source ranks sponsorship and adoption planning among the four macro success factors.
• If departments are building their own dashboards with unique metrics and tools, then expect 'information chaos' and enforce a common metric set and shared BI/DW infrastructure.

• Throw-it-over-the-wall strategy: executives publish the plan and wait. The tell is no change in departmental behavior and managers who cannot link their work to an objective.
• Lagging-only metrics: scorecards report only results after the fact. The tell is that you learn about misses too late to act, because there are no leading or diagnostic measures.
• Semantic disputes: the same term means different things across groups. The tell is meetings spent arguing about whose number is right instead of what to do.
• Rogue, siloed dashboards: each department builds its own with unique metrics, rules, and data. The tell is local value but contradictory enterprise views.
• Reliance on budgets as the execution mechanism: the source says traditional plans and budgets are out of date before completion and are seen as a 'corporate rain dance.' The tell is staff who treat the budget as a hoop and ignore it when deciding what to do.

• ▸Strategic objective: state it in one sentence, as it appears on the strategy map.
• ▸Theme / strategy map position: record which theme it belongs to and which objectives it drives or depends on.
• ▸Executive owner: name the single accountable person.
• ▸Leading metric(s): list measures that predict progress, with the agreed definition of each.
• ▸Lagging metric(s): list outcome measures that confirm results, with the agreed definition of each.
• ▸Diagnostic metric(s): list measures that explain why performance moved.
• ▸Target and threshold: state the target value and the level that triggers review.
• ▸Linked tactical/operational dashboards: identify where you drill to find the responsible process or project.
• ▸Review forum and cadence: specify the monthly strategy or operational review where this objective is discussed and corrected.
• ▸Corrective action log: record the date, the variance, the action taken, and the owner.

1. 1Write the superordinate goals first, as a short list every unit can see. The readiness checklist in the source starts with "a clearly defined strategy," and the book says metrics must be "aligned with corporate strategy." If you can't state the goals in a few lines, stop and fix that before building anything.
2. 2Name one executive sponsor who will act as an "agent of organizational change." The source says every dashboard initiative needs strong sponsorship. The foreword tells executives to read at least Chapter 1 and Chapter 5 and to set a clear direction. Get the sponsor to state the goals in their own voice.
3. 3Build a strategy map: strategic objectives linked to the metrics that measure them. The source lists strategy maps, initiative management and collaboration as the "management" application, whose stated purpose is to "improve alignment, coordination, and collaboration." Every objective gets at least one metric and one owner.
4. 4Match each unit to the right dashboard type. Operational dashboards monitor core processes such as sales, shipping or manufacturing. Tactical dashboards serve departmental analysis. Strategic dashboards and scorecards track progress against goals. Do not give every group the same view. Give each the view that connects to the superordinate goals at its own level.
5. 5Cascade metrics from the top down. The book treats scorecard cascading, dashboard cascading and data roll-ups as the mechanisms for integration. Each lower-level metric should roll up to a higher-level one. Test every departmental metric with one question: which strategic objective does it feed?
6. 6Align business and IT as a deliberate workstream. The source calls tight business-IT alignment "the key to the success of any performance dashboard initiative." The Chapter 5 tactics include a BI portfolio road map, mapping applications to subject areas, and a business-driven architecture. Sequence the build by business priority, not by technical convenience.
7. 7Use the management layer to resolve conflicts in the open. Annotation, workflow and initiative management let units record why a metric moved and who is acting on it. Cross-unit conflicts then surface on the dashboard, not in side meetings.
8. 8Govern and monitor adoption. The book lists dashboard governance and usage monitoring as components. Review who uses which dashboards and whether managers use the metrics "to drive change in a positive direction." Re-run the cascade check whenever strategy changes.

The passages name real cases (Cisco's metrics-driven organization with a functional balanced scorecard and strategy map, NetApp's centralized top-down MAD dashboards, Rohm and Haas's dashboard framework) but give no figures. The example below is therefore an illustration built on the book's own structure, not a reported result. Suppose a company sets one superordinate goal: raise customer loyalty. The sponsor states it and a strategy map ties it to a customer-satisfaction objective, as in Cisco's customer satisfaction dashboard. The executive scorecard tracks that objective. A tactical dashboard for the account-management group drills into satisfaction by account. An operational dashboard for support monitors daily process metrics that roll up into the satisfaction objective. IT builds the data for these subject areas in the order the business ranks them. Support is then tempted to optimize call speed alone. The cascade makes that visible, because the metric's parent objective is satisfaction, and the unit owner annotates the trade-off. Alignment here means each team can trace its numbers to the same goal.

• If a departmental metric cannot be traced up to a strategic objective, drop it or rewrite it. Do not add a dashboard to carry it.
• If two units' metrics pull against each other, bring them to the sponsor and settle which superordinate goal takes priority. Do not average them or let IT arbitrate.
• If the strategy is not clearly defined or the sponsor is weak, delay the rollout. The book lists both as readiness conditions, and more dashboards will not compensate.
• If a unit's data is not available or trustworthy, build the metric manually or defer it. Do not publish a misaligned proxy. The source notes strategic measures often have no ready data source.
• If usage monitoring shows a unit not using its dashboard, treat it as an alignment signal. Check mid-level manager support and whether the metrics matter to that unit's work.

• Metrics are chosen unit by unit and never linked to strategy. The tell: dashboards look healthy while the strategic scorecard stalls, and no one can name the objective a given metric serves.
• IT builds on technical convenience, not business priority. The tell: pitched battles over requirements, and delivered subject areas that don't match the BI road map.
• The sponsor endorses the project but does not set direction. The tell: executives disagree on what the goals are, and each unit invents its own version.
• Mid-level managers are left out and the cascade stops at the top. The tell: executives use the scorecard while front-line teams ignore the operational dashboards.
• Goals change but the cascade is not updated. The tell: units hit their dashboard targets while the leadership's current priorities go unmet, and governance has no process for revising metrics.

• ▸Superordinate goal: write the strategic goal in one sentence, as the sponsor would say it.
• ▸Executive sponsor: name the person who owns the goal and will communicate it.
• ▸Strategic objective: the specific objective on the strategy map that serves this goal.
• ▸Unit and owner: the department or team and the named person accountable.
• ▸Unit metric: the metric the unit tracks, and its dashboard type (operational, tactical or strategic).
• ▸Roll-up link: the higher-level metric or objective this metric feeds, and how it rolls up.
• ▸Conflict check: any other unit's metric that could pull against this one, and who resolves it.
• ▸Data and IT dependency: the subject area and data source needed, and its status (available, partial, missing).
• ▸Usage and review: how adoption is monitored, who reviews it, and when the mapping is next re-checked against strategy.

1. 1Fix the outcome list before build. Pick the few business outcomes the dashboard must move from the construct: profitability, revenue growth, cost reduction, efficiency, customer satisfaction. Tie each to the strategy the dashboard serves. The source's readiness test starts with 'a clearly defined strategy', so an outcome with no strategic link gets dropped.
2. 2Capture a baseline before go-live. Record each chosen outcome's current value, plus the effort cost of the current process: analyst hours spent collecting and integrating data, and time executive meetings spend arguing over whose numbers are right. The source names both as the hidden bleed of spreadmarts, and neither can be shown as improved without a 'before'.
3. 3Split outcomes into two tiers. Near-term efficiency gains (time to produce information, fewer reconciliation fights) are what sponsors fund. Business-result outcomes (revenue, cost, satisfaction) arrive later. The source notes sponsors now fund short tactical projects with rapid ROI, not multi-year infrastructure, so name which tier each project phase must prove.
4. 4Scope the first release to one or two well-known data sources and one application. This yields a measurable benefit fast enough to keep funding, even if sponsors do not get the full application first. Set the first measurement date to this release.
5. 5Link each outcome to a specific dashboard metric and a named owner who acts on it. A dashboard changes results only when users alter how they consume information and decide, which the source calls an exercise in change management. If no one's decision changes, no outcome moves.
6. 6Retire competing sources at go-live. Track the spreadmarts the dashboard replaces and record when each is switched off. Users who cling to spreadmarts leave you without a single version of truth, and your outcome data will be contested.
7. 7Re-measure on a fixed cadence against the baseline and report the result to the sponsor. Use the same definitions each time. Compare against the TDWI-style question in Exhibit 1.4, 'To what degree has your dashboard had a positive impact on business results?', and answer it with your own evidence rather than opinion.
8. 8Log external shocks beside the results. The source says mergers, acquisitions, new executive leadership, and changing economic or regulatory circumstances can push a program backward a stage. Annotate the outcome trend so a drop from outside forces is not read as dashboard failure.

The source supplies no quantified outcome figures, so this example applies its spreadmart scenario with placeholders; fill in your own numbers. An organization runs on spreadmarts: analysts act as 'human data warehouses', and executive meetings 'dissolve into chaos' as managers argue about whose data are right. Before launch, you record the baseline: analyst hours per reporting cycle spent collecting and integrating data (H0), and meeting time lost to data disputes (M0). You scope release one to one or two well-known sources, as the source advises, and publish centrally defined metrics. After the first cycle you re-measure H1 and M1 and list which spreadmarts were switched off. The efficiency claim is H0 minus H1 and M0 minus M1, which is credible because you captured the baseline. You then assign owners to the customer-satisfaction or cost metrics, the kind of outcome Cisco's customer satisfaction dashboard and Drivers of Loyalty exhibit address, and track those on a longer cadence. Annotate any reorganization or acquisition, since the source says these can regress a program.

• If you have no baseline for an outcome, then do not claim improvement on it. Record the baseline first, or state that the outcome is unproven.
• If the sponsor wants rapid ROI, then prove efficiency outcomes in the first release and defer revenue or profit claims to later phases.
• If a metric has no named owner who changes a decision based on it, then drop it from the outcome case, because the source treats BI as change management and unused information changes nothing.
• If spreadmarts still circulate beside the dashboard, then treat outcome data as contested. Retire them or reconcile them before reporting results.
• If results dip after a merger, leadership change, or regulatory shift, then annotate the external cause and re-baseline rather than concluding the dashboard failed.

• Claiming bottom-line impact without a pre-launch baseline. The tell: the sponsor asks 'compared to what?' and you have only anecdotes.
• Reporting dashboard usage (logins, reports viewed) as organizational performance. The tell: your metrics measure activity of the tool, not profitability, cost, revenue, efficiency, or satisfaction.
• Promising enterprise-scale outcomes from a first release. The tell: scope covers many sources, and the funded window closes before any benefit appears, so the sponsor stops funding.
• Letting spreadmarts persist so numbers conflict. The tell: meetings still argue about whose data are right, and two versions of the same outcome circulate.
• Ignoring external events when reading results. The tell: a post-merger or post-reorganization dip is blamed on the dashboard, or a gain is credited to it, with no annotation.

• ▸Business outcome: name one of profitability, revenue growth, cost reduction, efficiency, or customer satisfaction.
• ▸Strategic link: the stated strategy goal this outcome serves.
• ▸Dashboard metric(s): the exact metric(s) expected to move this outcome, with the definition used.
• ▸Decision owner: the named person whose decision changes based on the metric.
• ▸Baseline value and date: the pre-launch measurement and when it was taken.
• ▸Current value and date: the latest measurement, using the same definition as the baseline.
• ▸Effort-cost baseline: analyst hours and meeting time spent on data collection and disputes before launch, and after.
• ▸Spreadmarts retired: which competing sources were switched off and when.
• ▸External events log: mergers, leadership changes, economic or regulatory shifts that may affect the trend.

1. 1Score the ten readiness factors from Chapter 3 one by one: clearly defined strategy, strong committed sponsorship, clear and urgent need, support of mid-level managers, appropriate scale and scope, strong team and available resources, culture of measurement, business-IT alignment, trustworthy and available data, solid technical infrastructure. Use a simple Red/Amber/Green and write one line of evidence per factor. A rating without evidence is an opinion.
2. 2Treat the first three factors as gates: strategy, sponsorship, and urgent need. The source names 'proper sponsorship and resources' as the first macro-level success factor. A Red on any gate stops the launch decision until it is fixed. A Red elsewhere becomes a work item.
3. 3Probe the five dimensions the source's 2003 TDWI study (Eckerson) used to separate more from less successful BI efforts: business team capabilities, technical team capabilities, level of information sharing, business-IT alignment, and executives' view of data as a corporate asset. Ask each as a direct question of the people who would own the dashboard, not of the project sponsor alone.
4. 4Interview three layers separately: the executive sponsor, mid-level managers, and IT. Mid-level managers are a named factor because they run the processes the dashboard measures. Compare their answers on the need and the strategy. Divergence between layers is itself a readiness finding.
5. 5Keep organizational readiness apart from technical readiness. The source splits them into Chapter 3 and Chapter 4 (BI Maturity Model). Score the infrastructure factor here only as a yes/no gate and take the detail to the Chapter 4 assessment, so a strong tool stack cannot mask weak sponsorship or culture.
6. 6Narrow the scope to fit the readiness you actually have. The source's organizing image is a magnifying glass: focused light burns, scattered light does nothing. Pick one dashboard type (operational, tactical, or strategic) and one business problem. Plan to add more versions later, integrated through consistent metric definitions, shared data, and a common infrastructure.
7. 7Write a remediation plan for every Amber and Red: an owner, an action, and a date. If business-IT alignment is weak, route it to the Chapter 5 tactics. Executives are advised to read Chapters 1 and 5 and to act as an 'agent of organizational change.'
8. 8Re-run the assessment at project checkpoints and after launch. Readiness has to be sustained, not only established once.

The passages give the ten Chapter 3 headings and the exhibit titles, but not the scored detail of any case, so this example combines the source's one concrete story with a hypothetical scoring. The source's story is the author's son Henry and his friend Jake, who focus sunlight through magnifying glasses to ignite dry grass. The lesson the author draws is 'the power of focus': the same light, spread out, does nothing. Apply it to a hypothetical manager who wants a dashboard for every department at once. Scoring shows strategy Amber (objectives exist but are not agreed), sponsorship Green, urgent need Amber, mid-level managers Red (never consulted), and scope Red (all departments). Under the focus principle, the sponsor narrows the first release to one department's tactical dashboard, where the need is sharpest. The manager's remediation plan for the Red on mid-level managers is to bring that department's managers into metric definition before build. Re-scoring after those two moves shows scope Green and managers Amber, and the launch decision can proceed.

• If sponsorship, strategy, or urgent need is Red, then pause the build and fix it first. The source lists sponsorship and resources as the first macro success factor, and the other factors cannot compensate for its absence.
• If business and IT answer the alignment questions differently, then work through the Chapter 5 alignment tactics before choosing tools or architecture.
• If you cannot name one business problem and one dashboard type (operational, tactical, or strategic), then your scope is too broad. Narrow it before scoring the remaining factors.
• If mid-level managers are Red but the sponsor is Green, then involve those managers in defining the metrics before launch. They own the processes being measured and decide whether the dashboard is used.
• If the organizational factors are Green but data or infrastructure is Red, then take it to the Chapter 4 technical readiness assessment. Do not call the organization 'ready' on the strength of the first set alone.

• Scoring from impressions. Tell: every factor is Green and no one can cite a conversation, document, or fact behind any rating.
• Treating readiness as a technology check. Tell: the assessment is run only by IT and focuses on tools and data, with no interviews of business managers or executives.
• Sponsorship in name only. Tell: the sponsor approves the budget but does not attend reviews, set direction, or read the foundational chapters on alignment and change.
• Scope that scatters the focus. Tell: the kickoff deck lists many departments, many dashboard types, and no single problem the first release must solve.
• Skipping the mid-level managers. Tell: the metrics are agreed between executives and IT, and the managers first see them at rollout.

• ▸Initiative and dashboard type: name the business problem and whether the dashboard is operational, tactical, or strategic.
• ▸Strategy (gate): state the strategic objectives the dashboard will track, and rate Red/Amber/Green with the evidence.
• ▸Sponsorship (gate): name the sponsor, what they have committed in time and resources, and rate Red/Amber/Green.
• ▸Urgent need (gate): state the business pain in one sentence, who feels it, and what happens if nothing changes.
• ▸Mid-level manager support: list the managers whose processes are measured, record each one's stance, and rate Red/Amber/Green.
• ▸Scale and scope: define what is in and out of the first release, and rate whether the scope is narrow enough to focus.
• ▸Team and resources: record business and technical team capabilities and the funding or time that is actually available.
• ▸Culture of measurement, information sharing, and executive view of data: note the evidence on each of the three.
• ▸Business-IT alignment, data, and infrastructure: rate each as a gate and note whether the Chapter 4 technical assessment is needed.
• ▸Remediation plan: for every Amber or Red, give an owner, an action, a due date, and the checkpoint where you will re-score.

1. 1Define the scope first: a performance dashboard is three applications in one (monitoring, analysis, management) built on a BI and data integration infrastructure. Test the infrastructure against all three. A screen of graphics over a thin data layer is only a display mechanism, not a performance dashboard.
2. 2Place the BI environment on the BI Maturity Model (Chapter 4, Exhibit 4.1). Record the stage you are in today, not the one in the roadmap. The source material here does not list the stage names, so take them from the book's Exhibit 4.1 and write them into your assessment.
3. 3Read your stage against the model's four lenses: autonomy versus control (4.2), users and usage (4.3), business value and ROI (4.4), and insight to action (4.5). Write one sentence per lens describing what is true in your shop. A stage claim without those four sentences is an opinion.
4. 4Test data trustworthiness as its own item, separate from infrastructure (Chapter 3 treats 'Trustworthy and Available Data' and 'A Solid Technical Infrastructure' as separate readiness factors). For each metric the dashboard will show, name its source system and whether it passes through the data integration and warehousing foundation or is hand-assembled.
5. 5Map the planned applications to subject areas (Exhibit 5.3) and check each subject area against the warehouse or marts. Mark each as already integrated, partially integrated, or absent. Absent areas are your technical gaps.
6. 6Choose a display and data architecture that fits your current maturity. Chapter 13 compares eight options, including direct query, BI tool, mashboard, in-memory, data federation, data mart, and complex event processing. Pick the one your existing environment can support and write down what you give up by not choosing the others.
7. 7Score the technical team's capabilities, the level of information sharing, and executives' view of data as a corporate asset. The 2003 TDWI report compares each of these against degree of BI success (Exhibits 3.2, 3.3, 3.5). Weak scores signal technical risk even when the tooling looks adequate.
8. 8Plan incrementally. Build the BI architecture in stages (Exhibit 5.1) and sequence dashboard applications on a BI portfolio road map (Exhibit 5.2). Do not commit to a dashboard whose data foundation your road map does not deliver before launch.

Illustrative walkthrough built only from the book's structure; the source gives no specific company numbers. A team wants an operational dashboard. First, they place their BI environment on the maturity model and write four sentences for autonomy/control, users/usage, value/ROI, and insight-to-action. Second, they list the metrics the dashboard needs and map each to a subject area, in the manner of Exhibit 5.3. Two subject areas sit in the warehouse and one is spreadsheets maintained by hand. Third, they flag the spreadsheet-fed metric as untrustworthy, because it does not run through the data integration foundation. Fourth, they compare the architecture options in Chapter 13. A data mart or BI-tool architecture fits their existing warehouse better than complex event processing, which would require infrastructure they lack. Finally, they launch with the two integrated subject areas and put the third on the road map. The result is a dashboard sized to the infrastructure instead of one that exposes its gaps.

• If a dashboard metric's data does not come through your integration and warehousing foundation, then hold it out of the first release or label it provisional.
• If your maturity-model stage is early and your four-lens sentences describe isolated, individually owned reporting, then scope the dashboard to a single subject area rather than an enterprise one.
• If executives do not treat data as a corporate asset or information sharing is low, then treat technical readiness as amber even when the tools are in place.
• If a power-user population needs ad hoc views from predefined report elements, then consider the mashboard architecture, but only when a vendor BI tool already supplies those elements.
• If a needed subject area is absent from the warehouse, then place its build on the BI portfolio road map ahead of the dashboard application that depends on it.

• Treating the dashboard as a screen: the project budget is almost all graphics and little data integration. The tell is that metric definitions and sources are undocumented while mock-ups are polished.
• Self-rating the maturity stage aspirationally: the team claims the next stage because of tool purchases. The tell is that the four-lens sentences describe practices that don't exist yet.
• Assuming data is trustworthy because it is available: numbers are reachable but not reconciled. The tell is that two reports disagree and nobody can say which source is authoritative.
• Picking an architecture before assessing the foundation: a sophisticated option, such as in-memory or complex event processing, is chosen without the supporting data layer. The tell is that the architecture choice precedes the subject-area mapping.
• Ignoring the human side of technical readiness: weak technical team capability or low information sharing is not scored. The tell is a technology-only checklist with no entry for team skills or executives' attitude toward data.

• ▸Current BI Maturity Model stage: record the stage name from Exhibit 4.1 that you are in today.
• ▸Four-lens evidence: one sentence each for autonomy vs. control, users and usage, business value/ROI, and insight to action.
• ▸Metric-to-source map: list each planned metric, its source system, and whether it flows through the integration/warehouse foundation (Y/N).
• ▸Subject-area coverage: for each subject area, mark integrated, partial, or absent.
• ▸Data trust rating: red/amber/green for each metric, with the reason.
• ▸Technical team capability: score your team and note the gap against successful BI programs.
• ▸Information sharing and data-as-asset view: score information sharing and executives' attitude toward data as a corporate asset.
• ▸Chosen architecture and trade-off: name the option from Chapter 13 and what you give up by not choosing the others.
• ▸Road-map actions: list the gaps to close, in order, before each dashboard application launches.

1. 1Classify the dashboard first as operational, tactical or strategic, because the type decides data volume and architecture. The source notes that for strategic dashboards 'the quality of information is the key, not the quantity,' and that a few gigabytes can be enough. Write the type, the primary users and the application (monitoring, analysis or management) in one line before designing anything.
2. 2Start from the strategic objective, not from available data. Write each objective as a sentence, then derive metrics that 'embody strategic objectives and compare performance to plans.' A metric with no objective and no plan or target to compare against does not go on the dashboard.
3. 3Gather metric requirements from the business and IT together, using a structured request form and a culling pass (the Chapter 11 tools: approaches to gathering requirements, request form, culling performance metrics). Cull until each remaining metric maps to one objective and one accountable owner. Expect to revise the list, since 'strategy and plans are constantly changing.'
4. 4Design the display before building it. Fix the layout with proximity grouping (Gestalt), color-blind-friendly color, and preattentive attributes reserved for the few items that need attention. Choose each chart from the comparison it must show (the 'comparing comparisons' and graph-selection guidance). Test the draft against the poorly-designed-versus-well-designed airline dashboard contrast: can a user see what needs action at a glance?
5. 5Structure the layers to match the 'three threes': a graphical layer for monitoring, a dimensional layer for analysis, and a transactional layer for detail. Define the drill path from top-level metric to record. The Arizona State enrollment dashboard is the model: state, then county, then high school, then student record.
6. 6Select the architecture last, from the options the source lists: direct query, BI tool, mashboard, in-memory, data federation, data mart and complex event processing. Choose by data volume, latency and who maintains it. If the data is small and low-frequency, a manual feed is acceptable.
7. 7Plan scaling before launch. Decide centralized or distributed deployment, keep a dashboard inventory, and define how metrics cascade (scorecard cascading, dashboard cascading, data roll-ups) so lower-level dashboards roll up to the top-level objectives.
8. 8Instrument usage and review it on a schedule. Monitor which views are opened, and retire or rework metrics nobody uses.

The source describes a newly merged company whose strategy was to lower customer costs by integrating offerings from six operating companies. It charted the strategy with a handful of metrics: the number of contracts won containing integrated solutions involving two or more operating companies; percent of revenue from integrated projects; the number of integrated solutions created; and survey results of employee awareness and acceptance of the new cultural values. The company does a limited number of huge projects each year, so the data were hand-calculated and manually added to the strategic dashboard. No warehouse or heavy feed was needed. Each metric traces back to the single objective, and the cultural-values survey covers the behavioral side of the strategy. This is the quality-over-quantity principle in practice: because the dashboard focuses the organization on what is important, the volume of data is irrelevant. The design lesson is to size the architecture to the metric set, not the other way around.

• If a proposed metric cannot be tied to a stated strategic objective and a plan or target, then cut it, however easy the data is to get.
• If the dashboard is strategic and the data is low-volume or infrequent, then accept manual data entry and a light architecture rather than building a pipeline.
• If users need to move from summary to cause, then build a layered drill path (graphical, dimensional, transactional) before adding more top-level metrics.
• If strategy or plans change, then revisit the metric list with the business and IT jointly. Do not patch the display alone.
• If more than one team will build dashboards, then settle centralized versus distributed deployment and the cascading rules before the second dashboard ships.

• Data-driven metric selection: the dashboard shows what is easy to extract. The tell is metrics nobody can link to an objective or an owner.
• Volume mistaken for value: dozens of metrics and heavy infrastructure for a strategy that needs a few. The tell is that users cannot say what to do after viewing it.
• Visual clutter: attention-grabbing color and chart variety applied everywhere, ignoring proximity grouping, color-blind accessibility and preattentive attributes. The tell is that every item looks urgent, or users cannot find the problem item.
• Architecture picked first: a tool or architecture is chosen before the data volume, latency and users are known. The tell is rework when the first real dashboard does not fit.
• Static metrics: metrics are never revisited as strategy and plans change, and nobody checks usage. The tell is stale KPIs and falling logins.

• ▸Dashboard type: operational, tactical or strategic, with primary users.
• ▸Strategic objective: the one-sentence objective this metric serves.
• ▸Metric name and definition: the exact calculation, and the plan or target it is compared against.
• ▸Owner: the person accountable for the result, and the person responsible for the data.
• ▸Data source and refresh method: system or manual entry, and update frequency; justify manual entry if used.
• ▸Layer and drill path: graphical view, dimensional breakdown, and transactional detail it opens to.
• ▸Chart choice and visual treatment: the comparison shown, chart type, proximity grouping, color-blind check, and what gets the preattentive emphasis.
• ▸Architecture fit: which of the architecture options carries this metric and why.
• ▸Review trigger: the strategy or plan change, or the usage signal, that forces a re-evaluation or retirement.

1. 1Define adoption as three separate tests before launch: actively (users log in), correctly (they read and act on the metrics as defined), and consistently (they keep using it in routine work). Give each test a measure you can observe. Login counts alone cover only the first test.
2. 2Reconcile the dashboard's numbers with the old systems' numbers before go-live. The source says users must trust the data, and that requires the project team to reconcile new-system data with old-system data. Publish the reconciliation results. Do not publish metrics built on suspect source data (garbage in, garbage out).
3. 3Hand ownership to lower levels of the organization. Set up stewardship committees whose members define, update, and certify key metrics and data elements. People who own the definitions defend the numbers.
4. 4Expose functionality in stages by role. Show each user only the drill paths relevant to their role. When a user outgrows the predefined paths and asks for latitude, switch on right-click navigation or chart toolbars (sort, calculate, annotate, export, switch chart type) for that person only. Too many icons and options make users stop using the tool. The source's model is Google: one visible function.
5. 5Offer flexible training: more than one format and time, so users can learn when they need the tool. Train managers separately, specifically in using the dashboard to empower staff, not punish them.
6. 6Turn on usage tracking at launch and review it on a fixed cadence. Arizona State University's usage-monitoring exhibit (Exhibit 15.1) is the source's reference for this practice. Segment usage by audience group so you can see who is not using the dashboard.
7. 7Run regular end-user satisfaction surveys alongside the usage data. Usage shows who is using the tool, and the survey shows why the rest are not.
8. 8Delay incentives. Publicizing results so peers can compare, or tying bonuses to results, drives engagement. Do this only after the metrics are stable, reliable, and tamperproof, and after you have tested them for gaming.

This is an illustrative scenario built from the source's techniques; the source gives no adoption case with numbers. A team launches a tactical dashboard for call-center supervisors. Before go-live, an analyst reconciles the dashboard's calls-per-hour figure against the legacy report and documents each variance, so supervisors can see the old and new numbers agree. A stewardship committee of supervisors certifies the metric definitions, including a quality metric that balances the productivity one, since a productivity metric alone would push agents to rush customers. At launch, supervisors see only the drill paths for their role. Two weeks later, three power users ask for more freedom, and the administrator enables right-click navigation and chart toolbars for those three only. Usage tracking shows one team never logs in, and the satisfaction survey says why: their manager uses the numbers to rank and reprimand. The team lead then trains managers to use the dashboard to coach, and incentives stay off until the metrics have been tested for gaming.

• If dashboard numbers differ from the legacy reports and the gap is unexplained, then hold the rollout and reconcile first. Users who spot an unexplained discrepancy stop trusting the tool.
• If a user asks for more navigation or functions, then enable them for that user only. Do not widen the default view for everyone.
• If usage tracking shows a group not logging in, then check the satisfaction survey and the manager's behavior before adding more training. The cause may be fear of punishment or distrust of the data.
• If you are considering bonuses or public peer comparisons, then first confirm the metrics are stable, reliable, and tamperproof. If they are not, fix the metrics first.
• If a metric moves in a way that does not match reality, then assume gaming or a definition flaw. Audit it and revise the metric rather than urging users to try harder.

• Treating login counts as adoption. The tell: usage is high but decisions and meetings still run on spreadsheets, and users cannot explain what a metric means.
• Launching without reconciliation against old systems. The tell: users keep a shadow report and quote different numbers in meetings.
• Overwhelming a general audience with full functionality at once. The tell: usage peaks in week one and then drops, and users say the tool is cluttered or confusing.
• Managers use the dashboard to punish. The tell: staff avoid the tool, argue about the numbers, or take unexpected actions to boost a metric at the expense of other areas.
• Linking pay or rankings to unstable or gameable metrics. The tell: red lights turn green with no substantive change, and users hunt for loopholes.

• ▸Audience group: name the role or team this sheet covers.
• ▸Active-use measure: how you will track who logs in and how often (usage tracking).
• ▸Correct-use check: how you will confirm users read and act on metrics as defined (e.g., a spot check of metric definitions in their own words).
• ▸Consistency check: the routine meeting or decision where the dashboard should be used, and whether it is.
• ▸Reconciliation status: which metrics are reconciled with old systems, who signed off, and which variances remain open.
• ▸Metric stewards: names of the steward committee members who certify each key metric.
• ▸Training plan: the formats and times offered, and a separate session for managers on empowering, not punishing.
• ▸Functionality tier: the drill paths and functions this group sees by default, and the named users granted extras.
• ▸Survey findings and action: the latest satisfaction results, the top complaint, and the fix with its owner and date.

1. 1Check readiness first. 'A Clearly Defined Strategy' is the first organizational-readiness item in Chapter 3. If you can't state the strategy in a few sentences that executives agree on, stop. The dashboard concentrates whatever you point it at, so it can't supply a strategy.
2. 2Inventory the dispersion. List every business unit, division, and department with its own products, strategies, processes, applications, and systems. The source describes this as where organizations 'excel at losing focus and dissipating energy far and wide.' The list shows how many separate directions your light is currently radiating.
3. 3Pick the few activities that matter most. Use the BPM test: identify the key activities that contribute most to success and make sure they are done well. Everything that fails the test stays off the dashboard. Spreading energy 'far and wide' is the problem you are fixing.
4. 4Express the strategy as objectives. Use the strategic dashboard forms the book profiles at Cisco and the Bahrain Ministry of Works: themes and a strategy map, then a view of each individual objective, then a scorecard view. Each objective gets one plain-language statement that a non-executive can read.
5. 5Attach metrics to each objective, then cull. Chapter 11 covers designing metrics and gathering requirements, and its 'Culling Performance Metrics' exhibit exists because the first list is too long. Keep only the metrics that show progress on a stated objective.
6. 6Cascade to every level. Chapter 14 covers cascading metrics, and Cisco's functional balanced scorecard shows a function-level view. Give each group a view in which its own metrics visibly roll up to the objectives above it. This is what lets a person see how daily work contributes.
7. 7Match the dashboard type to the question. Strategic dashboards track objectives, tactical dashboards support analysis within a unit, and operational dashboards monitor daily activity. Link them so a person can move from an objective down to the activity beneath it.
8. 8Check understanding at several levels, from boardroom to shop floor. Ask people to name the objectives and their own contribution. The source says dashboards 'resonate' across the hierarchy, but it gives no test for this, so treat it as your own verification step.

The source's anchor example is the magnifying glass. In 2004 the author watched his son Henry and a friend, Jake, kneel in a driveway with magnifying glasses. Light normally radiates harmlessly in all directions. Focused on a single point, it ignites dry grass. The book's 'Organizational Magnifying Glass' (Exhibit 1.1) applies the same idea: most organizations have many units, each with its own products, strategies, processes, applications, and systems, so energy scatters like unfocused light. Applying it to your organization works in three moves. First, list the scattered activity by unit. Second, choose the few key activities that contribute most to the strategy. Third, build the strategy map, objectives, and cascaded metrics so every group sees those same points. The passages name Cisco's strategy map, individual-objective view, and functional scorecards as examples of this structure. They don't give the contents, so look to those case studies for detail rather than assuming it.

• If leaders can't state the strategy in a few agreed sentences, fix the strategy before building any dashboard, because a dashboard can't focus something undefined.
• If a proposed metric can't be tied to a named objective, cut it. Spreading effort across everything is the failure the dashboard exists to prevent.
• If a group can't see how its metrics roll up to an objective, cascade metrics to that level before launching its view.
• If your design has more objectives than people can recall, return to 'the key activities that contribute most' and cull again.
• If your design resembles a Balanced Scorecard but doesn't follow the methodology, treat it as a strategic dashboard, which the book defines as a distinct type.

• Dashboard built before strategy exists. The tell: executives disagree on which metrics matter, and the metric list grows by request rather than by objective.
• Reporting-portal sprawl. The source notes dashboards that look like reporting portals or briefing books. The tell: lots of data, no stated objectives, and no visible priorities.
• Top-only focus. The tell: executives see the strategy map, but frontline groups have no view linking their metrics upward, so they can't say how their work contributes.
• Unculled metric lists. The tell: every stakeholder request was accepted and no one can say which metrics drive the objectives.
• Treating the display as the focus. The tell: effort goes into screens and charts while the choice of what matters most is never made.

• ▸Strategy statement: write the strategy in two or three sentences that executives have agreed on.
• ▸Dispersed activities: list each unit, division, or department and its separate strategies, processes, and systems.
• ▸Key activities: name the few activities that contribute most to success, and the reason for each.
• ▸Objective: one plain-language statement per key activity, drawn from the strategy map.
• ▸Metric(s) per objective: the measures that show progress, plus the one you would drop if forced to cut.
• ▸Cascade path: which unit or function metrics roll up to this objective, and at which level each is shown.
• ▸Owner/audience: the group that sees this objective and the person accountable for it.
• ▸Dashboard type and drill path: strategic, tactical, or operational, and how a user moves from objective to underlying activity.
• ▸Understanding check: at which levels did you ask staff to name the objectives and their own contribution, and what did they answer?