Dashboard & Analytics

Chapter 2
Business Questions, Requirements and KPI Design

Diploma in Business Intelligence (Power BI)
Dashboard & Analytics   •   Diploma

Business Questions, Requirements and KPI Design

Introduction

Business intelligence does not begin with a chart. It begins with a decision that someone needs to make. A Power BI dashboard is valuable only when its data, measures and visual design help a defined audience understand performance and take appropriate action. Consequently, dashboard development is partly a technical activity and partly an analytical requirements activity.

Requirements work translates organisational priorities into a structured analytical specification. It identifies stakeholders, decisions, business questions, data needs, dimensions, measures, targets, key performance indicators (KPIs), definitions, ownership and success criteria. Poor requirements often produce dashboards that are visually attractive but operationally irrelevant. Strong requirements create a direct chain from strategy to measurement and from measurement to action.

This chapter presents a practical framework for eliciting stakeholder requirements, translating decisions into analytical questions, defining measures and KPIs, and applying SMART objectives, KPI trees and balanced scorecards. The discussion is designed for diploma-level learners preparing to design and implement Power BI solutions in professional settings.

Learning Objectives

By the end of this chapter, you should be able to:

  • identify dashboard stakeholders, decisions and information needs;
  • distinguish business questions, analytical questions, measures, metrics and KPIs;
  • define dimensions, measures, targets, thresholds and time horizons;
  • write objectives and KPIs using SMART criteria;
  • decompose strategic outcomes through KPI trees;
  • apply the balanced scorecard to organise performance measures;
  • specify KPI ownership, data sources, calculation rules and refresh requirements;
  • evaluate the quality, limitations and ethical implications of dashboard requirements; and
  • translate a requirements specification into a practical Power BI dashboard design.

1. From Business Decisions to Dashboard Requirements

A requirement is a documented statement of a need, capability or constraint. In dashboard development, a requirement explains what users need to know, why they need to know it, how the information will be measured and what action may follow.

The starting point should be the decision rather than the visual. For example, “the sales manager must decide which territories require intervention each week” is more useful than “the manager wants a map.” The decision leads to questions such as:

  • Which territories are below target?
  • Is the variance caused by lower volume, lower price or delayed orders?
  • Which products and customer segments contribute to the variance?
  • What intervention is available, and by when?

A useful requirements chain is:

Strategy → objective → decision → analytical question → measure/KPI → visual → action → outcome

If a proposed visual cannot be connected to a decision or action, it may be unnecessary. Conversely, if a critical decision cannot be supported by an existing visual, the dashboard is incomplete.

Stakeholder roles

Stakeholders may include executive sponsors, operational managers, analysts, data engineers, finance staff, frontline employees, customers and regulators. They do not have identical requirements. An executive may need a monthly view of enterprise performance, while an operations supervisor may need hourly alerts and transaction-level drill-through.

Requirements should distinguish at least four roles:

RoleMain concernTypical requirement
SponsorStrategic value and adoptionEvidence that the dashboard supports organisational priorities
Decision-makerTimely actionExceptions, trends, targets and recommended intervention
Data ownerDefinition and qualityAuthoritative source, validation and ownership
Dashboard consumerUsability and accessClear language, suitable detail and reliable availability

A person can occupy more than one role. A finance manager, for example, may be both a decision-maker and data owner for revenue measures.

2. Eliciting Requirements Professionally

Requirements elicitation is the systematic discovery and clarification of stakeholder needs. It should not rely on a single informal conversation. Different techniques reveal different kinds of information.

Interviews

Semi-structured interviews combine prepared questions with opportunities to explore unexpected issues. Useful prompts include:

  1. What decisions do you make, and how frequently?
  2. What information do you currently use?
  3. Which reports or spreadsheets are trusted, and why?
  4. What delays, inconsistencies or manual work occur?
  5. What would cause you to take action?
  6. How should performance be compared: against budget, prior period, forecast or benchmark?
  7. What level of detail is appropriate?
  8. What definitions or calculations are disputed?

The interviewer should distinguish stated preferences from genuine requirements. “I want a pie chart” is a design preference; “I need to compare product mix across regions” is an analytical need.

Workshops

A facilitated workshop brings stakeholders together to agree on objectives, terminology, decision processes and priorities. Workshops are particularly useful where departments use different definitions. For example, sales may define a customer as any account with an order, while finance may define an active customer as one with a settled invoice during a specified period.

Observation and document analysis

Observing work reveals information needs that users may not articulate. Reviewing existing reports, spreadsheets, policies, budgets, data dictionaries and regulatory requirements helps identify established definitions and constraints. A dashboard should not silently replace an approved financial definition.

Prototyping

A low-fidelity prototype can test structure before substantial development. It may contain labelled boxes, sample values and navigation paths rather than finished visuals. Users can then validate whether the proposed questions, filters and detail levels match their work.

Requirements register

A requirements register creates traceability. A compact example is shown below.

IDStakeholderDecisionQuestionPriorityAcceptance criterion
R01Sales directorAllocate supportWhich regions are below quarterly revenue target?HighRegional revenue and target are visible with variance
R02Sales managerInvestigate weak performanceWhich products explain the regional shortfall?HighProduct drill-down identifies contribution to variance
R03Finance controllerValidate reported revenueDoes dashboard revenue reconcile to the ledger?HighDifference is within agreed tolerance
R04Operations analystMonitor serviceWhich orders exceed the promised delivery date?MediumLate orders can be filtered by customer and carrier

A requirement should be testable. “The dashboard must be user-friendly” is vague. “A sales manager can identify regions below target in two selections or fewer” is more testable, although usability should still be evaluated with representative users.

3. Translating Decisions into Analytical Questions

A business question expresses a management concern in ordinary language. An analytical question makes the concern measurable and specifies the comparison, population, time period and level of detail.

For example:

  • Business question: “Are we retaining customers?”
  • Analytical question: “What proportion of customers who purchased in the previous quarter also purchased in the current quarter, by segment and region?”

The second question identifies a population, period, calculation and dimensions. It can therefore guide data modelling and measure design.

A well-formed analytical question commonly specifies:

  • Subject: sales, customers, inventory or service cases;
  • Measure: revenue, count, rate, margin or duration;
  • Population: all orders, active customers or closed cases;
  • Time: day, month, quarter, financial year or rolling period;
  • Dimensions: product, region, channel, customer segment or status;
  • Comparison: target, budget, prior period, forecast or benchmark; and
  • Action threshold: the condition requiring attention.

Descriptive, diagnostic, predictive and prescriptive questions

The question type should match the decision maturity of the organisation.

TypeMain questionExample
DescriptiveWhat happened?What was monthly revenue?
DiagnosticWhy did it happen?Which products caused the decline?
PredictiveWhat is likely to happen?What is expected revenue next month?
PrescriptiveWhat should be done?Which accounts should receive retention offers?

Power BI dashboards commonly begin with descriptive and diagnostic analysis. Predictive and prescriptive capabilities may require statistical models, machine learning, optimisation or additional governance. A dashboard should not imply predictive certainty when it merely reports historical observations.

4. Measures, Metrics, Dimensions and KPIs

The terms used in performance reporting are related but not interchangeable.

A data field is an attribute stored in a source system, such as OrderDate or Quantity. A measure is a calculation or aggregation used for analysis, such as total revenue. A metric is a quantified measure used to describe performance. A KPI is a strategically significant metric linked to an objective, target, interpretation rule and action. Every KPI is a metric, but not every metric is a KPI.

Dimensions

A dimension is a descriptive perspective used to group, filter or compare facts. Common dimensions include:

  • time;
  • geography;
  • product and category;
  • customer and segment;
  • sales channel;
  • employee or team; and
  • operational status.

Dimensions should be defined carefully. “Region” might mean customer billing region, delivery region, sales territory or warehouse region. A dashboard should state which interpretation is used.

Measures

Measures may be additive, semi-additive or non-additive.

  • Additive: can be summed across all relevant dimensions, such as units sold.
  • Semi-additive: can be summed across some dimensions but not across time, such as an inventory balance at a point in time.
  • Non-additive: should not be summed, such as a percentage, average or ratio.

For revenue, if each transaction has quantity Qi and unit price Pi, transaction revenue is:

Ri = Qi × Pi

Total revenue for a defined set of transactions is:

R = ∑i=1n Ri = ∑i=1n(Qi × Pi)

Here, i indexes transactions, n is the number of transactions, Qi is measured in units, Pi in currency per unit, and R in currency. This calculation assumes that quantity and price are recorded consistently and that returns, discounts and taxes are treated according to an agreed policy.

An average should generally be calculated from the underlying values, not by summing averages. For values x1, x2, ..., xn, the arithmetic mean is:

x̄ = (∑i=1n xi) ÷ n

The denominator must represent the intended population. For example, average order value is usually total revenue divided by number of orders, not the average of customer-level averages unless customers are intentionally weighted equally.

Ratios and rates

A rate compares a numerator with an appropriate denominator. For example, an on-time delivery rate may be defined as:

On-time rate = (Orders delivered on or before the promised date ÷ Eligible delivered orders) × 100%

The definition must state whether cancelled orders, open orders and orders without a promised date are excluded. The numerator and denominator must refer to compatible populations and periods. A percentage without a denominator definition is not a reliable KPI.

5. KPI Design

A KPI specification should make the measure reproducible and actionable. At minimum it should include:

  1. KPI name and purpose;
  2. linked objective;
  3. business definition;
  4. formula or calculation logic;
  5. numerator and denominator, where applicable;
  6. unit of measurement;
  7. grain and population;
  8. dimensions and permitted filters;
  9. target, tolerance and status thresholds;
  10. data source and refresh frequency;
  11. owner and accountable decision-maker;
  12. reporting period and comparison basis; and
  13. known limitations and data-quality rules.

A KPI should answer three questions: What is measured? Why does it matter? What happens when performance changes? If no action is associated with a KPI, it may be informational rather than key.

Targets, thresholds and comparisons

A target is the desired level of performance, such as monthly revenue of £500,000. A threshold is a boundary that triggers interpretation or action. A KPI may use green, amber and red states, but the boundaries must be agreed rather than chosen merely for visual appeal.

Common comparisons include:

  • actual versus budget;
  • actual versus target;
  • current period versus prior period;
  • actual versus forecast; and
  • performance versus an external benchmark.

These comparisons answer different questions. A result can be above last year but below budget. Therefore, a dashboard should label the comparison explicitly and avoid presenting an unexplained percentage change.

Variance from target can be represented as:

Variance = Actual − Target

For a positive-oriented measure, percentage variance is:

Variance % = ((Actual − Target) ÷ Target) × 100%

This formula assumes a non-zero target and a meaningful numerical comparison. For measures where lower is better, such as complaint rate or processing time, interpretation must be reversed or expressed using a clearly defined favourable/unfavourable rule.

6. SMART Objectives and Success Measures

SMART is a practical test for objectives:

  • Specific: states the outcome and scope;
  • Measurable: identifies evidence of achievement;
  • Achievable: is feasible given resources and constraints;
  • Relevant: supports a meaningful organisational priority; and
  • Time-bound: identifies a deadline or measurement period.

“Improve customer service” is not sufficiently SMART. “Increase the proportion of eligible support cases resolved within two business days from 78% to at least 90% by 31 December, without increasing reopened cases above 5%” is more precise. It defines the population, baseline, target, deadline and a quality safeguard.

Success measures should cover more than output. A dashboard project may measure:

  • adoption: percentage of intended users accessing the dashboard;
  • quality: reconciliation accuracy and defect rate;
  • timeliness: data availability by an agreed deadline;
  • decision impact: reduction in reporting time or faster intervention;
  • outcome: improvement in service, revenue, cost or risk; and
  • user experience: task completion and perceived usefulness.

A project can be technically delivered yet unsuccessful if users do not trust or use it.

7. KPI Trees and Causal Reasoning

A KPI tree decomposes a high-level outcome into drivers that managers can influence. It helps prevent the dashboard from displaying only lagging outcomes without showing the factors that explain them.

For example, operating profit may be decomposed as:

KPI tree for operating profit Operating profit Revenue Operating costs Volume Average price Labour cost Other cost
KPI tree showing operating profit decomposed into revenue and operating costs
Figure: KPI tree showing operating profit decomposed into revenue and operating costs

Figure: Illustrative KPI tree linking an outcome to controllable drivers.

The tree is a reasoning aid, not proof of causation. Revenue may depend on volume and price, but changes in price can affect volume. Costs may include fixed and variable components. Analysts should document whether relationships are accounting identities, operational drivers or hypotheses requiring investigation.

A practical dashboard can use a hierarchy: an executive KPI at the top, driver KPIs in the middle and diagnostic dimensions at the detailed level. This supports progressive disclosure rather than placing every measure on one page.

8. The Balanced Scorecard

The balanced scorecard, associated with Kaplan and Norton, organises performance across four complementary perspectives:

  1. Financial: revenue, profit, cash flow and cost control;
  2. Customer: satisfaction, retention, complaints and service quality;
  3. Internal process: cycle time, defects, productivity and compliance; and
  4. Learning and growth: skills, innovation, employee engagement and capability.

The framework counters the risk of managing only short-term financial results. For example, reducing training expenditure may improve current costs while weakening future service quality. A balanced scorecard encourages a portfolio of leading and lagging measures.

PerspectiveExample objectiveExample KPITypical issue
FinancialImprove profitable growthContribution marginRevenue may grow while profit falls
CustomerIncrease loyaltyRepeat-purchase rateSurvey response bias
Internal processImprove fulfilmentOn-time delivery rateIncomplete promised-date data
Learning and growthBuild capabilityCertified staff proportionCertification may not equal competence

The scorecard should not become a list of unrelated measures. Objectives should be connected through a strategy map, and each KPI should have a clear owner and action. Balance also requires attention to unintended consequences. A target for shorter call duration, for instance, may damage customer satisfaction if employees rush conversations.

9. Applied Case: Northstar Office Supplies

The following is an illustrative case created for learning purposes.

Background and problem

Northstar Office Supplies sells to small and medium-sized businesses through field sales, an online channel and a customer service centre. Senior management receives monthly spreadsheets, but regional managers cannot easily identify why revenue and margin vary. Finance and sales also disagree about whether revenue should include cancelled orders, discounts and tax.

The sponsor requests a Power BI dashboard. The initial request is “a sales dashboard with maps, gauges and product charts.” The analyst reframes this request around decisions.

Analysis and requirements

The main decision is how to allocate sales support and pricing attention among regions and product categories. Interviews identify three user groups:

  • the commercial director needs a monthly strategic view;
  • regional managers need weekly diagnosis and customer follow-up; and
  • finance needs reconciliation to the general ledger.

The agreed business objective is: “Improve profitable sales performance while maintaining reliable customer fulfilment.” The requirements are translated as follows:

ObjectiveAnalytical questionKPI or measureDimension
Grow profitable salesWhich regions are below revenue and margin targets?Revenue, gross margin, variance to targetRegion, month
Protect marginWhich products and discounts reduce margin?Gross margin %, discount rateProduct, customer segment
Improve fulfilmentWhich orders are late?On-time delivery rateCarrier, region, month
Retain customersWhich customers have declining activity?Active-customer count, repeat-purchase rateSegment, region

Finance defines revenue as invoiced sales excluding VAT, net of approved discounts and returns. Sales defines an order as active until cancelled or fully returned. These are not interchangeable definitions, so both terms are documented and used for their appropriate purposes.

KPI specifications

For gross margin, the agreed calculation is:

Gross margin = Revenue − Cost of goods sold

and gross margin percentage is:

Gross margin % = (Gross margin ÷ Revenue) × 100%

The percentage is meaningful only when revenue is non-zero and revenue and cost cover the same transactions and period. Finance owns the definition; the commercial director owns action on performance.

The on-time delivery KPI excludes cancelled orders and orders without a valid promised date. The data-quality report separately displays the number excluded, because exclusion can conceal process problems.

Solution design

The proposed dashboard contains three levels:

  1. Executive page: revenue, margin, on-time delivery and customer retention, each compared with target and prior period.
  2. Regional performance page: a matrix by region and month, conditional status, trend and drill-through to product and customer.
  3. Diagnostic page: discount distribution, late orders, data-quality exceptions and transaction detail subject to security rules.

The design uses a star-schema model with fact tables for sales and deliveries and shared dimensions for date, product, customer and region. A date table supports consistent month and financial-year analysis. Row-level security limits regional managers to their assigned regions.

Outcome and learning points

The dashboard reduces manual consolidation and enables managers to identify regional exceptions during weekly meetings. However, the project team avoids claiming that the dashboard itself caused margin improvement. It establishes a baseline and plans to compare subsequent performance with the pre-dashboard period while considering pricing changes, market conditions and seasonal effects.

The case illustrates five principles:

  1. Start with decisions, not visual types.
  2. Agree definitions before writing measures.
  3. Pair outcome KPIs with driver and quality measures.
  4. Assign ownership for both data and action.
  5. Treat exclusions and limitations as visible information, not hidden technical details.

10. Governance, Ethics and Limitations

KPI design involves power: measures influence attention, rewards and resource allocation. Poorly designed KPIs can encourage gaming, shift problems between departments or disadvantage particular groups.

Important governance practices include:

  • maintain a KPI catalogue and version history;
  • record data owners, calculation logic and approval status;
  • apply access controls and least-privilege principles;
  • protect personal and sensitive information;
  • document data retention and lawful processing requirements;
  • test measures for discrimination or unintended disparate effects;
  • distinguish correlation from causation;
  • show data freshness and quality warnings; and
  • provide an escalation route for disputed figures.

Privacy regulations may restrict the display of identifiable customer or employee data. Aggregation, pseudonymisation and role-based access may be required. A dashboard should not expose more information than a user needs for a legitimate business purpose.

Automation and AI can assist with natural-language questions, anomaly detection, forecasting and narrative summaries. These functions require controls for hallucination, bias, explainability, privacy and human review. An automatically generated explanation should be treated as an aid to investigation, not as an authoritative causal conclusion.

Common limitations include incomplete data, changing definitions, delayed refreshes, survivorship bias, inaccurate targets and excessive KPI volume. More measures do not necessarily produce better decisions. A small set of trusted, actionable indicators is usually more effective than a crowded dashboard.

11. Best-Practice Checklist for Power BI Requirements

Before development begins, confirm that:

  • every high-priority requirement is linked to a decision;
  • the audience, frequency and required detail are documented;
  • terms such as customer, sale, order and period have agreed definitions;
  • each KPI has a formula, unit, population and denominator where relevant;
  • targets and status thresholds have an owner and approval;
  • additive and non-additive measures are handled correctly;
  • data sources, refresh schedules and quality rules are known;
  • security and privacy requirements are explicit;
  • drill-down paths support diagnosis rather than merely adding detail;
  • success measures cover adoption, quality, timeliness and business impact; and
  • acceptance tests can demonstrate whether requirements are met.

Chapter Summary

Effective dashboard development begins with business decisions and organisational objectives. Stakeholder elicitation identifies who needs information, what decisions they make, how frequently decisions occur and what action follows. Business questions must be translated into analytical questions that specify measures, populations, periods, dimensions and comparisons.

Measures quantify phenomena; dimensions provide analytical perspectives; metrics describe performance; and KPIs connect strategically important metrics to objectives, targets, interpretation rules and actions. Reliable KPI design requires clear formulas, compatible numerators and denominators, documented exclusions, data ownership and refresh expectations. SMART criteria improve the quality of objectives, while KPI trees connect outcomes to potential drivers. The balanced scorecard broadens attention across financial, customer, internal-process and learning-and-growth perspectives.

A professional Power BI requirements specification also addresses governance, access, privacy, data quality, limitations and success measures. The purpose of a dashboard is not to display maximum information but to support better decisions with trusted and actionable evidence.

Key Terms

Analytical question: A measurable question specifying a subject, population, period, dimension or comparison.

Balanced scorecard: A performance framework covering financial, customer, internal-process, and learning-and-growth perspectives.

Data owner: The person or function accountable for the definition, quality and appropriate use of a data asset.

Dimension: A descriptive perspective used to group, filter or compare facts.

Drill-through: Navigation from an aggregated dashboard view to a more detailed contextual view.

KPI: A strategically significant metric linked to an objective, target, interpretation and action.

KPI tree: A hierarchical decomposition linking an outcome to contributing drivers.

Lagging indicator: A measure that reflects an outcome after it has occurred.

Leading indicator: A measure believed to provide an early signal of future performance.

Measure: A numerical calculation or aggregation used for analysis.

Metric: A quantified measurement used to describe performance or activity.

Population: The defined set of records, entities or events included in a calculation.

Requirements elicitation: The systematic discovery and clarification of stakeholder needs.

SMART objective: An objective that is specific, measurable, achievable, relevant and time-bound.

Success measure: Evidence used to judge whether a dashboard, project or intervention achieved its intended result.

Target: A desired level of performance for a specified measure and period.

Threshold: A boundary used to classify performance or trigger action.

Variance: The difference between an actual result and a comparison value such as a target or budget.

Review Questions

Short Answer Questions

  1. Why should dashboard requirements begin with decisions rather than visual types?
  2. Distinguish a measure, metric and KPI.
  3. What is the difference between an additive and a non-additive measure?
  4. List the four perspectives of the balanced scorecard.
  5. Why must the denominator of a rate be documented?

Long Answer Questions

  1. Explain a professional process for eliciting dashboard requirements from multiple stakeholder groups.
  2. Discuss how a business question can be transformed into an analytical question, using a suitable example.
  3. Explain the main components that should appear in a KPI specification.
  4. Describe how SMART objectives and success measures can be used to evaluate a Power BI dashboard project.
  5. Explain the value and limitations of KPI trees in performance management.

Analytical / Application Questions

  1. A service manager wants to “improve response time.” Design a SMART objective and specify an appropriate KPI, population, target, owner and action threshold.
  2. A company reports a higher average order value but lower total revenue. Identify at least two possible explanations and propose dimensions and measures for diagnosis.
  3. Design a concise balanced-scorecard requirement for a logistics organisation. Include one objective and one KPI for each perspective, together with one data-quality or unintended-consequence risk.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a KPI from a general metric?

A. A KPI is always a financial measure.

B. A KPI is a strategically significant metric linked to an objective, target and action.

C. A KPI can only be calculated from real-time data.

D. A KPI is necessarily more complex than every other metric.

Correct Answer: B. A KPI is a strategically significant metric linked to an objective, target and action.

Question 2

Which is the best example of an analytical question?

A. Do customers like us?

B. Create a customer pie chart.

C. What proportion of customers purchasing last quarter purchased again this quarter, by segment?

D. Improve customer service.

Correct Answer: C. What proportion of customers purchasing last quarter purchased again this quarter, by segment?

Question 3

Which measure is generally semi-additive?

A. Units sold by transaction

B. Inventory balance at month-end

C. Number of invoices

D. Sales revenue by order

Correct Answer: B. Inventory balance at month-end

Question 4

Revenue is £480,000 and the target is £500,000. What is the percentage variance from target?

A. −4%

B. 4%

C. −20%

D. 20%

Correct Answer: A. −4%

Question 5

Which item is not one of the traditional balanced-scorecard perspectives?

A. Financial

B. Customer

C. Internal process

D. Supplier bargaining power

Correct Answer: D. Supplier bargaining power

Question 6

What is the main purpose of a KPI tree?

A. To replace data validation with visual design

B. To decompose an outcome into contributing drivers

C. To guarantee that one measure causes another

D. To list every available database field

Correct Answer: B. To decompose an outcome into contributing drivers

Question 7

Which requirement is most testable?

A. The dashboard must look professional.

B. The dashboard should contain attractive colours.

C. A regional manager can identify regions below target and open product detail from the selected region.

D. Users should enjoy the dashboard.

Correct Answer: C. A regional manager can identify regions below target and open product detail from the selected region.

Question 8

A delivery rate is calculated as on-time deliveries divided by eligible delivered orders. Why must exclusions be documented?

A. To make the dashboard use more colours

B. Because exclusions affect the population and therefore the interpretation of the rate

C. Because all cancelled orders must always be included

D. To eliminate the need for a target

Correct Answer: B. Because exclusions affect the population and therefore the interpretation of the rate

Question 9

Which objective best satisfies SMART principles?

A. Improve service soon.

B. Make customers happier.

C. Increase eligible cases resolved within two business days from 78% to 90% by 31 December.

D. Monitor service performance.

Correct Answer: C. Increase eligible cases resolved within two business days from 78% to 90% by 31 December.

Question 10

Which practice best supports trustworthy KPI governance?

A. Allow each department to change the formula without recording it.

B. Hide data-quality exclusions from dashboard users.

C. Document definitions, owners, sources, refresh rules and approval status.

D. Use as many KPIs as possible.

Correct Answer: C. Document definitions, owners, sources, refresh rules and approval status.

Dashboard & Analytics
Chapter 2 of 15