The Decision-First Framework for Business Intelligence.
A method to link every dashboard to a business question, a defined target and an accountable owner. Applied in international engagements.
Contents
I · Point of view 05–12
Executive summary06The problem07Causes of low return on analytics08Guiding principles09Benefits by type10Scope of use11Engagement entry points12II · The method 13–32
The method on one page14How the loops work15Phase 0 · Readiness and scoping16Phase 0 · Readiness and scoping17Phase 1 · Continuous Discovery18Phase 1 · Continuous Discovery19Phase 2 · Definition and Design20Phase 2 · Definition and Design21Phase 3 · Iterative Development22Phase 3 · Iterative Development23Phase 4 · Validation and Adoption24Phase 4 · Validation and Adoption25Phase 5 · Continuous Value and ROI26Phase 5 · Continuous Value and ROI27Methodology components28Methodology components29Delivery process30Delivery model31Gates and exit criteria32III · Discovery 33–43
Value Questions34Running discovery35Discovery questionnaire36Questionnaire · A–D37Questionnaire · E–F38Questionnaire · G–J39Questionnaire · K–N40A completed questionnaire41Interview notes42From discovery to scope43IV · Indicators 44–55
Metric, KPI and the indicator sheet45The standard KPI row46KPI formulas · finance and commercial47KPI formulas · operations and sustainability48Data understanding49Data dictionary50Smart Dashboards51Smart Dashboards · column design52Alarm → Analysis → Decision53The decision tree54Data with a story55V · Design 56–74
Why design matters57Qualities of an effective dashboard58Designing with a purpose59Simplicity60White space61Symmetry and grids62Layout and visual hierarchy63Color · functions and rules64Color · palettes and status65Corporate colors66Typography67Chart principles · 168Chart principles · 269Chart selection70Common design errors71Practical design tips72Data storytelling73The design canon74VI · Delivery 75–87
Team, roles and RACI76Role descriptions77Cadence and ceremonies78Change control and testing79Deliverables by phase80Data quality and pipeline control81A typical engagement82Scope definition83Estimation method84Training by audience85Dashboard design course86Documentation delivered87VII · Value 88–95
Value dimensions89The ROI model90ROI model · investment91ROI model · benefits92ROI model · viability93The ROI model · worked example94Justifying value in a proposal95VIII · AI 96–99
Analytics maturity and AI97The analytics copilot98Governance of AI in decisions99IX · History 100–103
X · About the author 104–107
About the author105Certifications and education106Goal of the author107XI · Proof 108–111
Industry applications109Scope of each industry dashboard110Closing111Point of view
The problem the methodology addresses, its principles and its benefits.
Dashboards aligned with business decisions and measurable targets
The NGD Methodology is a decision-led method to design, build and sustain analytics. It links each dashboard to a business question, a defined target and an accountable owner, and it measures the value the dashboard produces.
Analytics designed without reference to decisions
Dashboards are commissioned as deliverables, separate from the goals and decisions they should support. Return on investment is rarely tracked, and business users take little part in building the insights, so use declines after go-live.
A five-phase value cycle
Discovery of decisions and Value Questions; definition and design before the data model; a shippable increment every one to two weeks; validation against real decision scenarios; ROI measured again against a baseline. An optional scoping phase comes first.
An adaptive decision system
- Indicator sheets: formula, target, thresholds and owner
- Wireframes, data domains and a data model
- A Minimum Valuable Dashboard, then increments
- Training and an adoption plan by audience
- An ROI baseline and a record of realized value
phases in a continuous cycle, preceded by an optional scoping phase
between shippable increments during development
ROI checkpoints: a preliminary estimate, a baseline, and a re-run after go-live
guiding principles that apply in every phase and every engagement
The problem the methodology addresses
Many BI initiatives do not deliver business impact. Dashboards are decoupled from goals, return on investment is rarely tracked, and business users take no part in building the insights.
Dashboards separated from goals
The project starts from a list of requested reports. The screens display data, but no decision, owner or action is attached to them, so the way the business decides does not change.
Addressed in Phase 1 · Value Questions
Return on investment not tracked
No baseline is recorded before the build. After go-live the value cannot be shown, and the next increment has no business case to support it.
Addressed in Phases 2 and 5 · baseline and ROI re-run
Business users outside the build
Users first see the product at go-live. The people who decide have not validated the definitions, and use of the dashboards declines.
Addressed in Phases 1 to 4 · sector experts, alpha and beta
Several versions of the same indicator · reports that take too long to produce · information isolated in each area · recurring manual reporting · dashboards that are published and then not consulted.
Causes of low return on analytics
The same gaps explain why a technically correct dashboard leaves decisions unchanged. Each gap has a practice that closes it and a phase of the method where that practice is applied.
| Gap | What it looks like | Practice that closes it | Phase |
|---|---|---|---|
| Purpose | “We need a dashboard,” with no decision, owner or action attached | Value Questions and decision mapping; every indicator is derived from a decision and its owner | 1 · Continuous Discovery |
| Design | Data model first and screens last; dashboards that reproduce source tables | Wireframes and the indicator sheet before the data model; navigation designed for each persona | 2 · Definition & Design |
| Delivery | Months of build before any user sees a result | A Minimum Valuable Dashboard first, then a shippable increment every one to two weeks | 3 · Iterative Development |
| Adoption | Go-live followed by declining use | Alpha and beta testing against real decision scenarios, training by audience, coaching | 4 · Validation & Adoption |
| Value | Benefits stated in the proposal and never measured | A KPI baseline before building; the ROI re-run after; indicators nobody uses are retired | 5 · Continuous Value & ROI |
Phase numbers refer to the value cycle described in The method. The Value gap closes in two steps: the baseline recorded in Phase 2 and the realized return measured in Phase 5.
Guiding principles
Decisions before data
Every indicator starts from a decision, the person who makes it and the action taken when it moves outside its threshold.
Phase 1
Design before the data model
Wireframes and indicator sheets come first; the data model is built to serve them.
Phase 2
Value Questions anchor scope
The questions users must answer to decide set the indicators, the interactions and the layout.
Phases 1 and 2
Quick wins, then scale
The Minimum Valuable Dashboard tests feasibility, usability and value early, before the scope grows.
Phases 2 and 3
Measure value before and after
A preliminary ROI and a KPI baseline before building; realized value after, in time saved, efficiency and decision quality.
Phases 1, 2 and 5
Clarity-driven design
Information hierarchy, low cognitive load, a limited palette and a direct link between each metric and an action.
Phases 2 and 3
Business experts in the team
Sector experts validate indicators, translate objectives and co-create the data stories with the BI team.
Phases 1 to 4
One version of the truth
One definition per indicator, documented once and reused by every screen, so two dashboards report the same value.
Phase 2 onward
Benefits by type
The method groups its benefits into four types. Each is reported for the engagement as a measured change against its own baseline.
How the work is done
- Less manual reporting
- More efficient decision cycles
- Reliable measurement of processes and indicators
What the work costs
- Quantified time savings
- Lower operating costs
- Better allocation of resources across data initiatives
Where the organization is going
- Alignment of analytics with organizational objectives
- Visibility of performance and trends
- Faster response to emerging issues
How people use data
- Greater trust in analytics
- Higher data literacy
- More use of data in daily decisions
Scope of use
The methodology covers the analytics lifecycle, from the decisions to be improved to the value realized in production. It applies to a new program, to a single area or module, and to dashboards already in place.
- Decision mapping, personas and Value Questions
- Indicator definitions: formula, target, thresholds, owner
- Wireframes, navigation, data domains and governance standards
- Conceptual and logical data models
- Incremental build with data quality tests
- Alpha and beta testing, training and adoption by audience
- ROI baseline, ROI re-run and retirement of unused metrics
| Situation | Usual starting point |
|---|---|
| A program across several areas | Scoping per area: workshops, prototypes, requirements traced to sources and a sized plan |
| One area or module first | A Minimum Valuable Dashboard for that area, with the design prepared for later modules |
| Dashboards in place with low use | Discovery of the decisions they should serve; model clean-up and source-to-target validation |
| Dashboards in production with ongoing demand | The continuous value cycle: ROI re-run, adoption review and a re-prioritized backlog |
Engagement entry points
An engagement can begin at any of four points. Each maps to phases of the method and ends with a defined result; they can be taken in sequence or separately.
| Entry point | When it fits | What the client receives | Duration |
|---|---|---|---|
| Strategy session | The organization needs to decide where to start | A first list of the decisions to improve and the Value Questions to prioritize | A single working session |
| Readiness & scoping | Several areas, uncertain data feasibility, or a need to size the program before committing | Readiness test; per area, a workshop on BI as cultural change with an ROI exercise and a requirements session; prototypes; requirements traced to data sources; a sized plan for build, test and deployment. Fixed fee, paid on acceptance | About five weeks in the documented case: seven workshops plus four weeks of design and documentation |
| Minimum Valuable Dashboard | One area with a clear decision and available data | The highest-value indicators, the core navigation flow and enough context to decide; indicator sheets; a KPI baseline; trained users | Increments every one to two weeks; total length set in scoping |
| Continuous value | Dashboards in production | ROI re-run against the baseline, adoption and usage review, new backlog items, retired metrics, the plan for the next iteration | Recurring cycle |
The method
The phases of the methodology, their activities, deliverables and exit criteria.
The method on one page
The first loop (1→2→3) turns decisions into a working, measurable product. The second (3→4→5) confirms adoption, measures the value realized and feeds back into design (5→2). Discovery continues throughout.
| 1 | Continuous Discovery | Decisions, personas, Value Questions, preliminary ROI |
| 2 | Definition & Design | Indicator sheets, wireframes, data model, baseline |
| 3 | Iterative Development | Increment every 1–2 weeks, quality tests |
| 4 | Validation & Adoption | Alpha, beta on real decisions, training |
| 5 | Continuous Value & ROI | Realized ROI, retire, re-prioritize |
How the loops work
The five phases form two linked loops that share phase 3. The cycle repeats as business needs change, and each pass strengthens the next.
Building measurable value
Discovery defines the decisions to improve and the value expected. Design turns them into indicator sheets, wireframes, a data model and a KPI baseline. Development delivers the first increment, the Minimum Valuable Dashboard.
Realizing business impact
Validation confirms that the increment is accurate and used in real decisions. The value phase re-runs the ROI against the baseline. What production shows returns to design (phase 2) and shapes the next increment.
Discovery runs continuously
Beta feedback, impact reviews and adoption data keep producing new questions and KPIs. They enter the living backlog directly, so the return path goes to design and discovery does not have to start over.
Short, preliminary ROI: time saved, efficiency, risk reduction and decision quality.
Baseline measurement of every KPI, so that later impact can be demonstrated.
The ROI template is re-run against the baseline with objective metrics, every cycle.
The readiness test
Phase 0 is optional. It starts with a readiness test of the project: five factors are checked before scope is fixed, and each weak factor is mitigated before the build is committed.
| Factor | What the test checks |
|---|---|
| Sponsor | An executive who owns the outcome, secures resources and approves changes |
| Business motivation | A concrete management problem or decision the program must improve |
| Business–IT cooperation | Systems and business areas that share ownership of definitions and data |
| Analytic culture | Teams that already use indicators to decide |
| Technical and data feasibility | Data that exists at the needed grain, with known quality, on a workable platform |
- High-level surveys of the business areas
- Prioritization of requirements
- A proof of concept on the riskiest source
- Secure the commitment of senior management
- Communicate the vision
- Obtain resources
- Provide political backing
- Approve changes
The scoping workshop by area
A fixed-fee phase run area by area. It is paid at its close, after the client accepts the results, so the client sees prototypes and a sized plan before committing to the full program.
- Dashboard prototypes per area
- Documented requirements, each traced to its source and judged technically feasible
- Sizing in time and cost for build, testing and deployment
- Workshop director (coaching), business analyst and modeler, UI designer
- One reference engagement: seven area workshops plus four weeks of design and documentation, about five weeks in total
- Components excluded, such as the data warehouse or ETL
- A cap on standard reports
- A design prepared for later modules while only one is built
Focus: understand business objectives and define measurable value.
Continuous Discovery
Objective. Establish clarity, define value and understand decision requirements. Business outcomes and user needs come before technical requirements.
- Identify and define the user personas who make decisions
- Map the decisions each persona takes and the information each needs
- Document current problems, inefficiencies and opportunities
- Workshops with stakeholders and sector experts on objectives and KPIs
- Short ROI analysis: time saved, efficiency, risk reduction, decision quality
- Decision map by persona
- Value Questions per persona
- Prioritized, living backlog of business questions, KPIs and value opportunities
- Preliminary ROI
- Initial schedule and meeting minutes
Continuous Discovery in practice
| Stakeholders | State strategic objectives in workshops |
| Decision makers | Interviewed by type and level of user |
| Sector experts | Validate KPIs and co-create data stories |
| Project manager | Validates and gathers requirements in detail |
| Business analyst | Runs interviews and documents the findings |
- Discovery questionnaire, blocks A, B, C, F and L
- Interview steps: select, prepare questionnaires, adapt by user level, research, prepare interviewees, conduct, close and review
- Value Questions framework
- ROI template, benefit side
Phase 0 scope and sized plan, when run; access to stakeholders and decision makers
Decision map, Value Questions, prioritized backlog, preliminary ROI
First pass: two meetings in about one week. Afterwards it runs throughout the program.
Focus: structure and prepare what will be built.
Definition and Design
Objective. Translate discovery into structured, buildable designs, with emphasis on clarity, usability and information hierarchy. The dashboard is designed before the data model.
- Define KPIs with formulas, thresholds, owners and measurement logic
- Write analytical user stories ready to build
- Set data domains, governance standards and update expectations
- Design navigation, user flows and wireframes
- Conceptual and logical data models
- Confirm the baseline of every KPI
- Indicator catalog of complete indicator sheets
- Final prototype of dashboards and reports
- Data exploitation model document
- Technology architecture document
- KPI baseline
- Quick-win candidates for the first increment
Definition and Design in practice
| Project manager | Architect of the solution; writes the product definition and estimates effort |
| Sector experts | Validate each KPI and its formula |
| UI and UX designer | Prototypes, navigation and wireframes |
| Data modeler | Conceptual and logical model, granularity |
| Product owner | Sets priorities and approves the design |
- Questionnaire blocks E, K and M, and the data part of H
- Indicator sheet: name, description, objective, formula, thresholds, targets, unit, frequency, control process
- Standard KPI row: actual, target, attainment, lower and upper limit, previous, trend
- Dimensional matrix and clarity-driven design system
Decision map, Value Questions, prioritized backlog, preliminary ROI
Indicator catalog, accepted wireframes, data model, KPI baseline, effort estimate
About one week of product modeling in the earlier project method.
Focus: deliver increments aligned with business goals.
Iterative Development
Objective. Deliver analytics in rapid increments that emphasize value, starting with the backlog items of highest value and ROI.
- Select backlog items by value and ROI
- Build dashboards, KPIs and models incrementally
- Daily stand-ups and mid-sprint check-ins with the business
- Continuous data-quality tests
- Check accuracy, performance and consistency in every iteration
- The Minimum Valuable Dashboard, then each increment
- Database objects, data mart or warehouse
- Extraction flow document
- Model, dashboard and report architecture document
- A shippable increment every one to two weeks
- Changes go to a prioritized list and do not move the final delivery date
- Agreed hours are kept; more hours are justified and requested as a schedule change
Iterative Development in practice
| Development team | Prototype design, warehouse exploitation layer, ETL, dashboards, quality testing |
| Project manager | Manages and facilitates the build |
| Product owner | Sets priorities, approves, enforces the schedule; negotiates the change list |
| Business users | Join mid-sprint check-ins and give continuous feedback |
- Prioritized backlog and prioritized change list
- Effort estimate per product or sprint: activities in hours, each with an owner
- ETL controls: run logs, error table, alert on exception, full or incremental load, rollback
- Project monitoring dashboards: milestones and early deviation alerts
Indicator catalog, accepted wireframes, data model, effort estimate, quick-win candidates
A shippable increment with its data pipeline and documentation
One to two weeks per increment. In the earlier project method a construction sprint ran one to four weeks.
Focus: prove usability and drive change.
Validation and Adoption
Objective. Ensure usability, accuracy and integration into decision processes, then make sure the people who decide use the dashboard.
- Alpha tests by the developers: functional, performance, stress, load, workflow
- Beta tests: user acceptance, with developers guiding the first runs
- Test against real decision scenarios
- Structured feedback to the backlog
- Alpha and beta test-case documents
- User certification of each module
- BI tool manuals and user manuals
- Adoption plan
- Management: reading and deciding
- Analysts: exploring and building views
- Technical staff: running and extending
- Guides, workshops and ongoing coaching
Validation and Adoption in practice
| Developers | Run the alpha tests and guide users through the first beta tests |
| Business users | Run user-acceptance tests and certify each module |
| Training specialists | Train each audience and prepare guides |
| Product owner | Approves the move to production |
- Alpha and beta test-case templates
- Real decision scenarios drawn from the Value Questions
- Training plan by profile: end user, analyst, administrator
- Dashboard design course: fundamentals, dashboard structure, information design
A shippable increment with its pipeline and documentation
A certified module in production, trained users, backlog feedback
One to two weeks of testing. Training follows each module's move to production.
Focus: measure business impact and sustain improvements.
Continuous Value and ROI
Objective. Measure impact, optimize the solution and sustain long-term value. What is learned here returns to design for the next increment.
- Re-run the ROI template against the baseline
- Measure time saved, cost avoidance, efficiency and decision quality
- Monitor adoption and usage
- Refine KPIs, models and dashboards
- Realized-value report
- Adoption and usage review
- Updated, re-prioritized backlog
- List of indicators to retire
Impact reviews add new questions and KPIs and also identify outdated metrics. Those are reviewed with their owners and retired, so the dashboard keeps only indicators that still support a decision.
Continuous Value and ROI in practice
| Sponsor | Receives the realized-value report and decides on the next cycle |
| Product owner | Re-prioritizes the backlog |
| KPI owners | Review their indicators and agree retirements |
| BI team | Recalculates ROI, monitors usage, refines the solution |
- ROI template: investment by category; benefits from process improvement and reporting hours freed; cash flow, ROI = (benefit − investment) ÷ investment, net present value
- Adoption and usage monitoring
- Improvement review of KPIs, user behavior, data patterns and objectives
KPI baseline from phase 2; production use of the certified modules
New questions and KPIs, indicators to retire, a re-prioritized backlog
The sources set no fixed duration; the review recurs every cycle.
Decision design and early value
Components are practices that run across the phases. The first three define who the analytics serve, what each deliverable must answer and how value is shown early.
Persona-centered decision design
The personas who decide define:
- level of detail and granularity
- information architecture
- navigation paths
- update frequency
- visual density and communication style
Value Questions framework
Each deliverable is anchored to the essential questions its users must answer to make informed decisions. The questions select the KPIs, the interactions and the layout.
Starting points: which decisions do you take daily, weekly and monthly; which have most impact; who else depends on this information.
Quick wins approach
High-impact components delivered early:
- demonstrate value sooner
- validate assumptions early
- build user confidence
- reduce risk
- increase stakeholder engagement
The first release, the design system and improvement
The remaining components fix what the first release contains, how every screen is designed and how the solution stays aligned after go-live.
Minimum Valuable Dashboard
The first version of the solution. It contains:
- the highest-value KPIs
- the core navigation flow
- enough context to support meaningful decisions
It validates feasibility, usability and value early.
Clarity-driven design system
Principles, with instant comprehension as the goal:
- information hierarchy
- minimal cognitive load
- white space
- limited color palettes
- visual consistency
- direct connection between metrics and actions
Continuous improvement loop
A recurring review of the KPIs, user behavior, data patterns and business objectives. KPIs change as business priorities shift, and the review feeds the backlog of the next increment.
Design Thinking with Scrum
Design Thinking shapes what is built; Scrum governs how it is delivered. The implementation process puts dashboard design ahead of the data model.
- Model the decision-making process
- Design the dashboards
- Build the business data model
- Build the data mart or warehouse
- Deploy the BI solution
Sector specialists contribute business expertise, good practice and suggestions to each product definition.
One to four weeks, with daily revisions within 24 hours and supervised iterations.
A prioritized list, negotiated with the product owner, that does not move the final delivery date.
Alpha tests by developers, beta tests by end users and a potentially shippable product increment.
The BI factory model
A delivery model focused on team efficiency. Several projects share one pool of specialists, coordinated by a factory manager, while each client keeps a single project manager as its point of contact.
| Factory model | Traditional project model |
|---|---|
| Lower cost: no facilities at the client site, specialist staff, no idle time | Travel to the client site; idle time |
| Staff reused across projects through the effort-estimation matrix | Highly qualified engineers on repetitive tasks |
| One platform for communication, requirements, tickets, feedback and an online schedule | Disordered communication; client standards often absent |
Each specialist's share of time is set per project. The factory manager agrees each initial effort estimate with the project manager, in person-hours by activity and function.
Exit criteria by phase
| Phase | Exit question | Evidence required | Approver | Typical duration |
|---|---|---|---|---|
| 0 · Readiness and scoping | Are we ready, and is the scope feasible? | Readiness test; prototypes; requirements traced to sources and judged feasible; sized plan | Sponsor | About five weeks in one reference engagement |
| 1 · Discovery | Do we know which decisions to improve? | Decision map, Value Questions, prioritized backlog, preliminary ROI | Product owner | First pass about one week; then continuous |
| 2 · Design | Is it buildable and measurable? | Indicator sheets with owners, accepted wireframes, data model, KPI baselines | Product owner | About one week |
| 3 · Development | Is the increment shippable? | Increment demonstrated, data-quality tests passed, documentation updated | Product owner | One to two weeks per increment |
| 4 · Validation | Is it trusted and used? | Alpha and beta passed, user certification, each audience trained | Business users; product owner | One to two weeks of testing |
| 5 · Value | What did it return, and what comes next? | Realized ROI against the baseline, adoption review, re-prioritized backlog, indicators to retire | Sponsor | Every cycle |
In the earlier project method, the path from implementation to production took one to two months per module; later increments ship every one to two weeks.
Discovery
How decisions, business questions and requirements are gathered.
Value Questions and persona-centered decision design
A Value Question is a question a persona must answer to make an informed decision. Each deliverable is anchored to a set of them, and they determine which KPIs, interactions and layout are included.
| B7 | What is your role, and which key decisions do you make daily, weekly and monthly? |
| B8 | Which of those decisions has the greatest impact on your objectives? |
| B9 | Who else depends on this information, and how do their needs differ? |
| Level of detail | Executive summary or transaction-level evidence |
| Information architecture | What is grouped with what, mirroring how the persona decides |
| Navigation path | Summary first or detail first; where the drill-down leads |
| Refresh frequency | Real time, daily or weekly, matched to the decision cycle |
| Granularity | Day, person, transaction |
| Visual density and tone | How much appears on one screen, and how it is worded |
The six choices are recorded per persona during discovery and become the design brief for phase 2. Two personas who read the same indicator at different cycles receive different views of it.
Running discovery: interviews and workshops
Discovery puts business outcomes and user needs ahead of technical requirements. Interviews are prepared for each type and level of user; workshops align the areas and test the first ideas with prototypes.
Select interviewees
The personas who decide, by area and level
Prepare questionnaires
Blocks chosen by phase and respondent
Prepare by user level
Executive, management or technical
Research beforehand
Existing reports, structure, systems
Prepare interviewees
Purpose and topics shared in advance
Conduct
Decisions first, systems last
Close and review
Notes become Value Questions, confirmed with the interviewee
| Level | Focus of the conversation | Blocks |
|---|---|---|
| Executive | Strategic goals, decisions with the greatest impact, definition of success, quick wins | A · B · L |
| Management and analysts | Processes, business questions, indicators and their control, current reports, structure of the views | C · D · E · F · K |
| Technical | Source systems, data architecture per source, infrastructure, users and permissions | G · H · I · J |
| BI as cultural change | Two hours per area: a demonstration of the tool and an ROI exercise the area can obtain |
| Requirements | Two hours per area, with a questionnaire adapted to that area's processes |
| Stakeholders and experts | Strategic objectives and KPIs identified; sector experts validate KPIs and co-create the data stories |
The questionnaire: blocks by phase
Seven instruments in Spanish and English were unified into one questionnaire of 78 questions in 14 blocks. Business context and decisions come first, design next, technical sizing last.
| A | Organization, context | 1–6 |
| B | Role and decisions | 7–9 |
| C | Processes | 10–15 |
| D | Business questions | 16–17 |
| F | Current situation | 29–33 |
| L | Value and adoption | 63–66 |
| E | Goals, risks, alerts | 27–28 |
Asked of the sponsor, area heads, process owners and each persona.
| E | Indicators | 18–26 |
| K | Structure, experience | 57–62 |
| L | Readiness criterion | 67 |
| M | Scope, budget, risk | 68–72 |
| H | Data quality, security | 47–48 |
Asked of area heads, analysts, each persona and the project manager.
| G | Source systems | 34–36 |
| H | Data, per source | 37–48 |
| I | Infrastructure | 49–52 |
| J | Users and growth | 53–56 |
Asked of IT and data owners. Sent as an annex to the proposal.
| N | Project systems | 73–78 |
Used only when the system to be built manages projects.
Organization, decisions, processes and business questions
- What is the company's economic activity?
- How is the company or area organized? A high-level description, its core functions, and the organization chart if one exists.
- Which areas will the BI system serve? List each one, its function and its relation to the project.
- What are the area's objectives, and what information does each objective require?
- Which strategic goals should BI help the company reach?
- Who are the main stakeholders? For each department: which insights does it need, how will they influence its decisions, and how does it access and use data today?
- What is your role, and which key decisions do you make daily, weekly and monthly?
- Which of those decisions has the greatest impact on your objectives?
- Who else depends on this information, and how do their needs differ?
- Which main processes touch BI or are affected by it?
- What is the objective of each process?
- Which processes are most critical to the strategic goals?
- What are the current pains in handling and processing data?
- How are these processes managed and tracked today, and with which tools or systems?
- Which process improvements are expected from BI? Which workflows, reports or tasks are repetitive, manual or inefficient and should be redesigned or automated?
- What are the main business questions you need to answer to succeed in your work?
- How is each question answered with information today, and how often? Which key performance indicators answer it?
Indicators and the current situation
- How many indicators are planned? Detail them if possible.
- What is the control and evaluation process for each indicator?
- For each indicator, a sheet: name, description, objective, formula, thresholds, targets, unit of measure and measurement frequency.
- List the area's business metrics, with the formula of each KPI.
- Which KPIs are used today (progress %, estimated vs actual time, budget executed, quality, satisfaction)? How often are they measured, and who analyzes them?
- Which metrics do you monitor today, and which matter most?
- Which influence decisions directly, and what action is taken when they are above or below what is expected?
- Are any metrics kept by hand that should be automated? Which targets or thresholds apply?
- What additional context (trends, comparisons, breakdowns) is needed to interpret them correctly?
- Which strategic goals, KPIs or risks should the solution help monitor or improve?
- What level of detail, which alerts and which contextual breakdowns are needed to decide well?
- Which reports or dashboards exist today? List them with their frequency, and whether they are spreadsheets or come from a system.
- Has a similar system been implemented before?
- Which problem should BI solve? What problems exist today, and what do you expect to improve?
- Are there proposals or projects to improve how information is recorded, managed and analyzed?
- Which information do you rely on today, and how do you obtain it? What challenges, delays or gaps do you face in accessing or interpreting it?
Questions 19 and 20 produce the indicator sheet. Question 24 separates a KPI from a metric: if no action follows when the value leaves its range, it is reported as context. Questions 27–28 are asked in phase 1; the rest in phase 2.
Sources, data, platform and users
- Which systems are in use today (ERP, CRM, other transactional systems), and which will feed the data mart or data warehouse?
- Which information is automated, and which is not?
- What would you improve in the transactional systems?
| 37 | Source or database type: Oracle, SQL, spreadsheet, CSV, other |
| 38 | Refresh frequency: daily, weekly, monthly |
| 39 | Transaction volume: average records per day |
| 40 | Size of the source, database or spreadsheet |
| 41 | Monthly growth of the database, in % |
| 42 | Years of history to keep in the warehouse (the Spanish forms recommend three to five at most) |
| 43 | Number of operational tables, files or sheets |
| 44 | Grain: down to the day, the person, the transaction |
| 45–46 | Existing data marts; size of the current BI platform's metadata (migration and maintenance projects) |
| 47–48 | Data quality and integrity challenges; security and privacy requirements and how they are met today |
- Hardware required for the expected load and processing.
- BI platforms and tools under consideration; existing licenses or vendor preferences.
- Scalability plans if the company or the data volume grows.
- Planned process changes that may affect BI.
- How many users will access the system? How many access today, and what growth is expected?
- Who will use it: which areas and which users?
- Expected user profiles (administrator, leader, team, client) and multi-user access with permissions.
- Web, mobile or both; offline work or always online.
Experience, value, project scope and project-management systems
- What must be visible as soon as the dashboard opens, and what can go to drill-down or secondary views?
- Which comparisons are essential: period over period, target vs actual, segments?
- How should the information be grouped to reflect your analysis or decision process?
- Summary first or detail first? Which filters or cuts do you need?
- Which visualization styles do you find most intuitive? Do you need to export or share?
- What would make the dashboard easy to adopt from the first day?
- Which results should this initiative help achieve, for you and for the organization?
- Which quick wins would be most significant?
- How would you define success shortly after implementation, and in the long term?
- What would encourage constant use of the dashboard, and what could hold it back?
- Which feature, KPI or improvement would bring immediate benefit? By which criterion will we know the dashboard is effective and ready?
- Expected scope and deliverables: dashboards, reports, data models.
- Visualization types required. Do sector regulations affect reporting?
- Timeline from start to rollout and key milestones; expected term and maximum duration.
- Estimated budget and internal or external resources.
- Project risks and mitigation strategies.
- Types of projects managed and the areas that take part.
- How project management is organized (project office, autonomous teams, leaders); roles; approval and follow-up structure.
- Steps from creation to closure; methodology (agile, Scrum, waterfall, hybrid); tools in use.
- Required functions, resources to manage (human, financial, material), integrations with ERP, CRM, email and calendar; report and indicator types.
- Projects per month; years of history to migrate; data to import and export.
- Additional comments.
A completed sizing questionnaire
The sizing annex of a proposal to an equipment dealer in the United States, completed by a client executive. The answers set the grain, history, refresh and security of a financial module.
| Question | Answer |
|---|---|
| Source systems | Dealer management system; financial accounting package |
| Automated today | General ledger and financial information; part already in existing BI cubes |
| Database type | SQL Server, IBM DB2, spreadsheets |
| Refresh | Daily |
| Records per day | “To line item detail” |
| Size | “Database & Excel files” |
| Monthly growth | Unknown |
| Years of history | Five, “like current system” |
| Tables | To be defined |
| Grain | Transaction level |
| Users | 30 |
| Who | Finance and some managers, with restrictions by role |
| Answer | Requirement |
|---|---|
| Three source types | Extraction for each; spreadsheets governed as a source |
| Part in existing cubes | Existing cubes reviewed and reconciled before rebuilding |
| Transaction-level grain | Facts stored at line-item level |
| Five years, daily | Initial load of five years; daily incremental load |
| 30 users, restricted by role | Role-based security in the model |
| Financial module first | Design prepared for later modules; only the financial module built |
From interview notes to Value Questions
Notes taken during the first interview with a capital-projects program of an engineering services firm in the United States. They were written inside the first question of the functional questionnaire and later shaped three dashboards: a four-quadrant project view, a program view and a project-request view.
The notes record 33 projects; the proposal later wrote “about 30”. Exact figures from the notes are carried into the scope.
| Note | Draft Value Question or follow-up | Feeds |
|---|---|---|
| One project dashboard, one page | What is the status of this project, on one page? | Project view |
| Who is spending, funding | Which projects are spending, and who funds each one? | Program view |
| Hours used to sponsor projects | How many hours has each sponsored project consumed? | Program view |
| Problems, risk, prioritize; thresholds identified | Which projects need attention first, by risk and threshold? | Indicator sheets |
| Canceling projects at the 75% | Follow-up: confirm the rule and the measure it refers to | Confirmation list |
| Schedule, cash flow, budget, risks, forms | Source inventory: scheduling tool, look-ahead plan, ERP cash flow, budget spreadsheet, escalation log | Blocks G–H |
The draft questions are shown here to illustrate the method; each is confirmed with the interviewee at the close of the interview.
From the questionnaire to the scope chapter of a proposal
The answered questionnaire becomes the scope chapter of the proposal, section by section, in the same order. Sizing is expressed as attributes against metrics, and every limit on the build is written down.
| Scope section | Fed by blocks | |
|---|---|---|
| A | Project objectives | A (strategic goals) |
| B | Objectives and organization of each area | A |
| C | Management problems | C, F |
| D | Improvement proposals | C, F |
| E | KPIs by area, each with its definition | D, E |
| F | Dimensions and attributes by area | H (grain), D |
| G | Count of attributes and metrics | E, H |
| H | Reports by area, with a ceiling | F |
| I | Dashboards | K |
| An agricultural inputs company in Peru | 78 attributes and 60 metrics; at most 40 reports in standard format without customization; one dashboard per area, plus a sales-force dashboard refreshed every two hours |
| A steel producer | Data warehouse and extraction excluded from the scope |
| An equipment dealer in the United States | Design prepared for later modules; only the financial module built |
| A port terminal operator in Peru | A paid scoping phase that ends with time-and-cost sizing of the next phases, invoiced on acceptance |
Indicators
How indicators are defined, measured and read.
Metric and KPI: definitions and the indicator sheet
A quantity measured from the data: tons processed, hours of downtime, net sales. It describes what happened.
A metric selected because a decision depends on it. It carries a target, thresholds, an owner and the action taken when the value is above or below what is expected.
| Field | Content | Example |
|---|---|---|
| Name | Business name used on every screen | Gross margin % |
| Description | What it measures, in one sentence | The share of every dollar sold that is profit |
| Objective | The decision or goal it serves | Know which product earns most each month |
| Formula | Calculation, with its denominator | (Sales revenue − cost of sales) ÷ sales revenue |
| Unit · frequency | Unit of measure; how often it is measured | % · monthly |
| Target | The value to reach | 25% |
| Thresholds | Limits that set the status color | < 25% ≥ 25% |
| Control process | Who reviews it, when, and against what | Finance, at month close, against target and prior month |
| Owner · action | Who acts, and what is done when it is out of range | Category manager · reprice or renegotiate when red |
| Data source | System and table, recorded per requirement | Sales and cost of sales from the ERP |
The original sheet holds eight fields, from name to frequency, and is requested together with the control and evaluation process of each indicator. Owner and action are fixed in the design phase; the data source is recorded in the requirements document.
The standard KPI row
The same columns appear in the scorecards of the author's proposals: indicator, actual, target, status, lower and upper limit, prior value and trend. Value, target, status and trend are the building block of the final application.
| Indicator | Actual | Target | Status | Lower | Upper | Prior | Trend |
|---|---|---|---|---|---|---|---|
| Gross margin | 23.1% | 25.0% | 92% | 25.0% | 30.0% | 24.8% | ▼ |
| On-time delivery | 96.2% | 95.0% | 101% | 93.0% | 100% | 94.9% | ▲ |
| Days of cover | 11.4 | 10.0 | in band | 8.0 | 12.0 | 13.0 | ▼ |
| Status | Compliance against target (actual ÷ target, or target ÷ actual when lower is better); the color comes from the limits on the sheet |
| Limits | Lower and upper thresholds from the indicator sheet; outside them the status turns red |
| Prior | The same measure one period earlier |
| Trend | Direction against prior; its color depends on whether the move is favorable for that indicator |
| Compliance | 23.1 ÷ 25.0 = 92.4%, shown as 92% |
| Status | 23.1% is below the lower limit of 25.0%: red |
| Change | 23.1 − 24.8 = −1.7 points; relative change −1.7 ÷ 24.8 = −6.9% |
| Days of cover | 11.4 lies inside the 8–12 band; the fall from 13.0 is favorable, so the arrow is green |
Financial variant: a consolidated line per indicator with budget compliance and change against the prior year, then the income statement for the period and year to date, then each indicator over time, then the view by country.
KPI formulas: finance and commercial
Definitions from the author's documents, with formulas checked; a standard definition is used and marked where a document gives none.
| KPI | Formula | Note | Basis |
|---|---|---|---|
| Profit margin | Sales revenue − cost of sales | Course case | Document |
| Profit margin % | Profit margin ÷ sales revenue | Red below 25%, green at or above 25% | Document |
| Sales growth % | (Current period − prior period) ÷ prior period | Corrected: the case divided by the current month. Sales of 100 → 150 grow 50% | Corrected |
| Net sales | Sales after discounts | Agricultural inputs company | Document |
| Overstock % | Items with overstock ÷ total items | Agricultural inputs company | Document |
| Days of stock | Inventory ÷ average daily sales | Named in the document without a formula | Standard |
| DSO | Accounts receivable ÷ revenue × days in period | Analyzed against budget, against an industry standard and over time; detail by customer, invoice, product, category and supplier | Standard |
| DIO | Inventory ÷ cost of sales × days in period | Standard | |
| DPO | Accounts payable ÷ cost of sales × days in period | Standard | |
| Cash conversion cycle | DIO + DSO − DPO | Cement producer, operating-cycle view | Standard |
KPI formulas: operations, safety, environment and economics
The mining data framework names each KPI and supplies its input columns. The formulas below are the standard definitions written on each indicator sheet.
| KPI | Formula |
|---|---|
| Production vs target | Production (t) ÷ production target (t) |
| Throughput | Tons processed ÷ operating hours |
| OEE | Availability % × performance % × quality % |
| MTBF | Operating hours ÷ number of failures |
| MTTR | Repair hours ÷ number of repairs |
| Energy per ton | Energy (kWh) ÷ tons processed |
| TRIFR | Recordable incidents × 1,000,000 ÷ hours worked |
| LTIFR | Lost-time incidents × 1,000,000 ÷ hours worked |
The safety rates require hours worked in the data; the framework includes them. The normalizer (per million hours, or the 200,000 hours used in US OSHA rates) is stated on the sheet.
| KPI | Formula |
|---|---|
| Water per ton | Water used (m³) ÷ tons produced |
| GHG intensity | Emissions (t CO₂e) ÷ tons produced |
| Grievance resolution rate | Grievances resolved ÷ grievances opened |
| Cash cost per ton | Total cash cost ÷ tons |
| EBITDA margin | EBITDA ÷ revenue |
| Operating margin | Operating income ÷ revenue |
| CAPEX utilization | Actual CAPEX ÷ budgeted CAPEX |
| ROIC | NOPAT ÷ invested capital |
| Forecast vs actual profit | (Actual profit − forecast profit) ÷ forecast profit |
Data understanding: column roles
Before a single chart, each column gets a role. The role decides how it is used: dimensions slice, metrics add or average, dates carry time, and columns with no role are left out of the model.
| Role | Use | Example: mining operations | Example: mortgage operations |
|---|---|---|---|
| Hierarchy | Slice and drill, general to detail | Zone → equipment type → unit → shift | Region → branch → loan officer |
| Time | Trend and period comparison | Date | Application date, close date |
| Context | Explain why something changed | Weather, blasting status, material | Loan type, employment type |
| Metric | What is measured | Tons, grade, recovery, throughput | Amount, time per stage, revenue per loan |
| Target | What it is compared against | Production target (t) | Set on the indicator sheet |
| Failure and root cause | From symptom to cause | Failure flag, failure type, root cause | Escalations, denial reasons |
| Flag | Alert without reading every value | Water flag = High Usage | Fraud or anomaly risk |
| Cost and loss | Translate operations into money | Energy kWh, maintenance cost, ore loss % | Cost per loan, default rate |
Roles are assigned per source and recorded in the data dictionary. A target that does not exist in the data is defined on the indicator sheet and stored as its own column.
The data dictionary and the preparation checklist
| Field name | Column | Description | Role · unit |
|---|---|---|---|
| Equipment | Equipment_ID | Unit identifier within its type | Hierarchy |
| Ore processed | Ore_Processed_tons | Tons fed to the plant | Metric · t |
| Recovery rate | Recovery_Rate_% | Metallurgical efficiency | Metric · % |
| Unplanned downtime | Downtime_hours | Unscheduled hours stopped | Metric · h |
| Production target | Production_Target_tons | Planned production | Target · t |
| Root cause | Root_Cause | Cause recorded for the failure | Root cause |
The author's dictionary format lists the visible field name, the technical name and a description; role and unit are added here so the dictionary also serves the model.
- Business names for every field
- Codes translated (0/1 → No/Yes)
- Correct types: measure, dimension, date; categories stored as dimensions
- Text numbers converted (“$1,200” → 1200)
- Grain stated: one row is a sale, a day, a person
- Values normalized before entities of different size are compared (per ton, per customer, per capita)
- Continuous dates for trend; date parts for seasonality
- A quality sheet for records that do not match between sources
The Smart Dashboards framework
A specification that starts from one wide table per subject and ends in recommended views. The mining version covers operational, environmental, financial and social performance.
| Dashboard | Focus | KPIs | Recommended views |
|---|---|---|---|
| Production and process | Process output against the production plan | Ore mined, ore processed, grade, recovery, throughput, unplanned downtime, production vs target | KPI cards, trend lines, compliance gauges, decomposition tree from zone to equipment to root cause |
| Efficiency and asset reliability | Use of critical assets: availability, performance, quality | OEE, MTBF, MTTR, energy per ton, haul-truck utilization, maintenance backlog, drill-and-blast efficiency | Decomposition of availability losses, failure Pareto, asset-criticality heat map, energy bars |
| Safety and workforce | Operational safety and people development | TRIFR, LTIFR, near-miss reports, training hours per employee, turnover, safety-audit compliance | Rate cards, incident lines, stacked training bars, heat maps by zone or shift |
| Environment and sustainability | Environmental impact, resource efficiency, ESG | Water per ton, GHG per ton, tailings stability, stripping ratio, reclamation, environmental incidents, dust and noise compliance | Consumption and emission lines, target gauges, maps of tailings and reclaimed areas |
| Financial and economic | Profitability and economic sustainability | Cash cost per ton or ounce, EBITDA margin, CAPEX utilization, revenue per ton, operating margin, forecast vs actual profit, ROIC | Cost waterfall, plan-vs-actual variance, revenue treemap, EBITDA line |
| Community and governance | Community relations, transparency, compliance | Local employment, community investment, grievance resolution, regulatory compliance, local content in purchasing, ESG score | Community impact maps, investment bars, compliance cards, composite ESG index |
The indicator sheet carried into columns
In the framework, a monitored measure travels with its target, its compliance and its flag. The status is computed once, in the data, and every view reads the same answer.
| Part | Water | Dust |
|---|---|---|
| Value | Water_per_Ton_m3pt | Dust_Compliance_% |
| Target | Target_Water_per_Ton_m3pt | Target_Dust_Compliance_% |
| Compliance | Water_Use_Compliance_% | (the value itself) |
| Flag | Water_Flag = High Usage | Dust_Flag = Non-compliant |
| Hierarchy | Mine zone, equipment type, equipment, shift, operator |
| Context | Weather, blasting status, material type |
| Failure | Failure flag, failure type, root cause |
| KPIs | The measures and their targets |
| Loss and cost | Ore loss, energy, fuel, maintenance cost |
| Category | Variables |
|---|---|
| Loan | ID, type, amount, interest rate, application date, close date, status |
| Borrower | Age, income, credit score, employment type, location, debt-to-income |
| Operations | Loan officer, time per stage, communication count, escalations |
| Financials | Revenue per loan, cost per loan, default rate |
| Customer feedback | Satisfaction score, comments, resolution time |
| Compliance | Review dates, denial reasons, state licenses |
The operations dashboard built on it tracks the approval cycle from application to close, time per stage, conversion by loan type, officer productivity, satisfaction and NPS, and anomaly risk, with drill-down by region, branch and officer. The pilot data cover three simulated years, so the views can show a before and after.
Alarm, analysis and decision: the structure of every view
The status light says something is off: value, target, status and trend on one line. The first decision layer, the executive screen, is built only of alarms.
Drill down through the decision tree (revenue, cost, profit, cash cycle) to the node where the variance sits. Indicators from different areas are read together: collective intelligence.
The last layer carries the evidence for the action the indicator sheet defines (the order, the call, the price change) and names its owner.
“A profit waterfall is where the leaks show: unplanned costs, discount anomalies, prices and indicators off budget, sales left on the table.”
The financial decision tree
Views are organized as layers of a decision tree. A first engagement can deliver only the first decision layer; later dashboards extend the navigation to the last layer.
| 1 | Is the status outside its limits? If not, the value is recorded and its trend watched. |
| 2 | If it is, drill to the next layer and find the node that carries the variance. |
| 3 | Read the context and root-cause columns at that node. |
| 4 | Cross with indicators of other areas when the cause lies outside the node. |
| 5 | Apply the action on the indicator sheet; the owner confirms it. |
| 6 | The next period's status shows whether the action worked. |
Demonstration data with embedded scenarios
Prototypes and training use synthetic data with planted scenarios, so users learn to find a problem and trace it to its root. Each scenario is designed with a cause, a window and a signature.
Written into the data as a value of the failure type, root cause or anomaly columns, so the drill-down ends at a named cause.
Bounded in time and place: one zone, one unit, one shift, for weeks or a quarter. Seasonal patterns recur each year; incidents occur once.
The set of related measures that move together in a consistent direction, plus the flags that change state. Random background failures keep the signal from being the only movement.
| Scenario | Cause recorded | Window and scope | Signature |
|---|---|---|---|
| Crusher power loss | Power loss | One pit, one crusher, two months | Downtime up; recovery, throughput and ore processed down |
| Hydraulic seal wear | Seal wear | One pit, one excavator, one quarter | Unplanned stops and MTTR up; availability, performance and OEE down |
| Rainy season | Weather | All zones, June to September, every year | Unplanned stops up, truck utilization down, slip-and-fall near misses up |
| Night-shift contractors | Training gap | One pit, night shift, contractors, one quarter | Recordable and lost-time incidents up; PPE and audit compliance down; turnover up |
| Cash-cost surge | Fuel and logistics | One pit, one quarter | Unit cash cost and OPEX up; EBITDA and operating margins down |
| Grievance spike | Traffic detours | One pit, one quarter | Grievances up; resolution, SLA, media sentiment and social license down |
Question → hypothesis → view → revision: the dashboard is the sequence of views that carries the thread.
Design
The design standard applied to every dashboard.
Why design determines whether a dashboard is used
A dashboard, like a website, has to be designed so that its users can move through it and understand its content quickly. Simplicity is the main means to that end, and the information is the most prominent part of the design.
“A dashboard must turn data into information, and information into knowledge for the business.”
The author's design manual
Each principle is stated as a rule and, where it helps, shown as a before and after built on the same data, following the format of the author's design manual.
Where does the most important content go? How should charts and text be arranged to create a visual rhythm? How can white space help the user absorb the information?
What meaning does color give to the data? How is a palette chosen, and which color is reserved for what?
Which typefaces are used, at which sizes, and how is emphasis created with them?
Qualities of an effective dashboard
Four qualities describe a dashboard that people use without assistance. They serve as the review criteria for every layout in this part.
Simple
Austere formats. Ornament, effects and decoration are left out; every element carries information.
Good use of space
Indicators are placed according to their relevance, each in the zone of the screen that matches its weight.
Intuitive
Anyone in the intended audience can understand the information without prior training.
Interactive and navigable
Controls let the user change or personalize the view of the data and move through its structure without getting lost.
Information hierarchy
The most important content is read first.
Minimal cognitive load
Each view answers one question.
White space
Space separates groups and lets the eye rest.
Limited palette
Few colors, each with a function.
Visual consistency
One template, one set of sizes and colors across views.
Metric to action
Every indicator leads to an owner and an action.
Designing with a purpose: audience, need and use
| Audience | Who consumes the dashboard? |
| Need | What information does that person need? |
| Use | What are the objectives of the dashboard? |
The answers are agreed with the project leaders, the technical team or the executive sponsors before the design process starts. The brand is researched at the same time, so that the prototype starts from the client's styles.
“If the main objectives are not clear, no matter how good the interface looks, the dashboard is bound to fail.”
The author's design manual
| Tier | What it holds | Where it goes |
|---|---|---|
| Primary | Alarms: KPI tiles with target, status and trend | Top left, largest |
| Supporting | Trend and breakdown that explain the alarm | Center and right |
| Detail | Tables and drill-down for the analyst | Bottom, or a second tab |
| Out | Indicators on which no decision depends | Removed, or kept in a report |
The tiers follow the alarm, analysis and decision structure of every view described in the toolkits.
Simplicity
The design should be subtle, clear and minimal. Color, imagery and layout support the user's goals and leave nothing that competes with the data.
Values labeled on the bars make the axis and gridlines unnecessary. Sorting puts the largest channel first.
A purpose for every element
Anything that does not inform the reader is removed.
No background images
Photos or graphics behind the data are avoided; the logo sits small in the header.
One color palette
A single palette across the dashboard, with one accent.
Emphasis by weight
Light, regular and bold weights and a few sizes create the hierarchy.
White space
White space is important and often overlooked. It gives the eye places to rest; without it, every element runs together and the most important content cannot be told apart.
Rest
Empty areas give the eye a place to pause between groups of information.
Sections
Space delineates sections and replaces borders and boxes.
Groupings and rank
Related items sit close together; the spacing itself ranks and organizes the content.
The cost
White space may mean giving up some content. The gain in comprehension justifies it; the rest moves to a drill or a second view.
Symmetry and grids
Symmetry makes a layout predictable, so the design can guide the user in the intended direction. The grid is the organizing pattern behind it, applied with judgment.
- Arrange objects symmetrically; symmetry draws the eye and invites the user to engage with the content
- Keep margins and spacing between elements constant: breathing zones prevent a cramped, claustrophobic screen
- Group objects that share a strong relationship or relevance
| Practicality and visual harmony | A shared style and visual system |
| Aligned, connected elements | Regular, repeatable patterns |
| Consistency across all views | Space divided into clear fields |
| An answer to “where does this go?” | A standard, reusable structure |
Every block starts and ends on a column edge, and gutters are the same everywhere. The same grid is reused in every view of the dashboard.
Layout and visual hierarchy
Visual hierarchy organizes the elements so that the main message reaches the user. Position, size, weight and color decide what is read first.
- The most important indicators go top left; the bottom right receives the least attention
- One primary view is highlighted; the other views support it
- The decision layer fits on one screen, without scrolling
- Unity: every element works with the others to build one message
- Visual rhythm: charts and text alternate so the page reads in sequence
Reading usually starts top left and sweeps in a Z; the center also receives some attention. This book treats the pattern as a working heuristic for placing content.
Position
Top and left are read first; the primary view takes the first zone.
Size
The primary view and the headline figures are the largest elements.
Weight
Bold for values and titles, regular and light for labels and context.
Color
One accent marks what needs attention; everything else stays neutral.
Color: functions and rules
Choosing colors without criteria is one of the most common errors. Color draws interest, focuses attention and can prompt the response that leads to action.
Focus
An accent marks what matters most.
Difference
Contrasting colors show difference.
Belonging
Analogous colors group related items.
Action
Status colors call for a response.
| 1 | Strong colors only for the most important content |
| 2 | Let the brand inform the design and its colors |
| 3 | The fewer colors, the more effective the dashboard |
| 4 | Avoid an excess of bright, saturated colors |
| 5 | Light backgrounds for panels and charts |
| 6 | Keep the chosen palette consistent throughout |
| 7 | Red, green and yellow stay out of charts unless they show status |
| 8 | Start in grays, then add color where it carries meaning |
Dark: striking with few colors, but light text is harder to read. Reserved for control rooms and wall screens, with contrast checked.
Light: flexible, and dark text reads without effort; the default in this method. In both, green and red mark only the changes.
Color: palettes by data type and status colors
Contrasting colors show difference; analogous colors show similarity and group. A given value range keeps the same color in every view of the dashboard.
| Indicator | Actual | Target | Status | Trend |
|---|---|---|---|---|
| Fill rate | 96.2% | 95.0% | On target | ▲ |
| Days of cover | 11.4 | 10.0 | In band | ■ |
| Gross margin | 23.1% | 25.0% | Below | ▼ |
- Red, amber and green are reserved for status and never used for categories
- Color is never the only signal: a symbol and a word go with it, so the status reads for color-blind users and in grayscale
- The undesirable color sits on the undesirable side; reverse a divergent scale when a high value is bad, such as cost or delay
- Colors with their own meaning are assigned correctly; a medals view with silver and bronze swapped is an error that is easy to miss
Respecting corporate colors
The corporate identity is the reference for colors, typefaces, logos and layouts. Designing within the client's brand guidelines is the starting point of every prototype, within the limits that data imposes.
Primary navy · secondary red
Navy and its tints carry the data · grays carry context · one neutral accent
In this illustration the brand red would read as an alarm next to the status colors. It stays in the logo and the header; the data palette is derived from the navy.
The logo sits small in the header. It is never placed behind the data as a background.
Typography
Type must allow fast reading without effort. A typeface communicates on its own and carries associations, so the choice is made for legibility first.
Revenue 1,284
Light, modern and simple. Easy to read on screens and mobile devices. The default for dashboards.
Revenue 1,284
Classic and traditional. Easy to read in long text; suited to editorial design and printed reports.
Revenue 1,284
Hard to read, especially in numbers and at small sizes. Kept out of dashboards.
| Size | Margin 23.1% |
| Weight | Margin 23.1% against a regular label |
| Color | Margin 23.1% in the single accent |
| Position | Top of the screen, or the first quadrant |
- One sans-serif family with several weights (light, regular, semibold, bold); a second family only for figures, as in this book
- Fixed sizes for titles, body and labels, used uniformly in every view
- Text aligned; labels horizontal
- No runs of capitals in body text and no underlining, which reads as a link
- A minimum size defined for each target device and checked on that device
Design principles for charts
Each principle removes something that costs reading time and adds no information. Before and after use the same data.
Remove unnecessary elements
Backgrounds, full gridlines, borders, redundant legends and excess precision go.
Remove borders
Heavy frames and grids are replaced by white space and a light baseline.
Use flat colors
Gradients and shading add nothing to the value. Flat color is the norm; bars stay sorted.
Design principles for tables and chart types
Fewer lines in tables
Lines, borders and fills only where white space cannot do the job, and then in very light tones.
| Project | Year 1 | Year 2 |
|---|---|---|
| Alpha | 210,000 | 190,000 |
| Beta | 185,000 | 200,000 |
| Gamma | 160,000 | 175,000 |
| Delta | 140,000 | 150,000 |
| Epsilon | 205,000 | 185,000 |
| Zeta | 150,000 | 220,000 |
| Total | 1,050,000 | 1,120,000 |
| PROJECT | YEAR 1 | YEAR 2 |
|---|---|---|
| Alpha | 210,000 | 190,000 |
| Beta | 185,000 | 200,000 |
| Gamma | 160,000 | 175,000 |
| Delta | 140,000 | 150,000 |
| Epsilon | 205,000 | 185,000 |
| Zeta | 150,000 | 220,000 |
| Total | 1,050,000 | 1,120,000 |
No 3D charts
Depth effects distract and take longer to interpret; the bars become hard to compare.
Legible labels
Axis labels are never rotated; abbreviate them, or turn columns into horizontal bars.
An appropriate visualization
Part of a whole reads better as sorted bars in one color than as a pie with a color per slice.
Chart selection by business question
| Question | Chart | Notes |
|---|---|---|
| How far am I from target? | KPI tile with status; gauge only for % attainment | Always with target and prior period |
| How is it evolving? | Line on a continuous date | Date parts (month, weekday) for seasonality |
| Who is bigger? | Sorted bars, Top N | Horizontal labels; manual order only to highlight |
| Where does the loss come from? | Decomposition tree; Pareto for the vital few | Zone → asset → cause |
| Where is risk concentrated? | Heatmap (zone × shift) | One hue, light to dark |
| How is the result built? | Waterfall | Cost to margin; where the leaks are |
| Plan vs actual? | Bars with a target tick, or variance chart | Two aligned panels in place of a second y-axis |
| How is the total split? | Bars or treemap | Pie only for 2–3 parts of a meaningful whole |
| Where does it happen? | Map | Normalize per capita or per unit first |
| How does a process flow? | Funnel; time by stage | Application → decision → close |
| How do two measures relate? How is it distributed? | Scatter; histogram or box plot | Distrust the average — look at the spread |
Common design errors and their corrections
| # | Error | Correction |
|---|---|---|
| 01 | Spilling beyond one screen | Keep the decision layer on one screen; move detail to a drill or a second tab |
| 02 | Too little context | Show every number with its reference: target, prior period, threshold |
| 03 | Too much precision or detail | Round to what the decision needs; summarize, then drill |
| 04 | Complexity for its own sake | Choose the simplest chart that answers the Value Question |
| 05 | Poorly arranged information | Group by how the persona decides; most important top left |
| 06 | Highlighting the wrong thing, or nothing | One accent for what needs attention; everything else gray |
| 07 | Useless decoration | Remove backgrounds, borders, 3D and ornaments |
| 08 | Misusing color | Status colors only for status; one palette; never color alone |
| 09 | An unattractive display | Grid, alignment, white space and a consistent template |
| 10 | Misusing typography | One family, weights for emphasis, horizontal labels |
Few's list also covers choosing a deficient measure, choosing inappropriate display media, poorly designed display media and inaccurate encoding of quantitative data. The chart principles and the chart-selection table in this part address them.
Practical design tips
The author condensed her design manual into a single sheet of tips for practitioners. Its premise: the user experience decides whether a dashboard succeeds, and the dashboard must be navigable and interactive.
Simplicity
Austere formats; every element has a purpose. Less is more.
Typography
One sans-serif family, used in several weights.
Hierarchy
Visual hierarchy organizes the elements so that the main message reaches the user.
Purpose and unity
Set objectives and communicate the data; the elements work together to build one message.
Color
One highlight color for the information that matters. Light backgrounds are more flexible and look cleaner.
Emphasis
Size, weight, color and position direct the eye to what matters first.
Grids
A grid aligns and connects the elements and keeps every view consistent.
White space
Space lets the eye rest, separates groups and ranks the content.
Data storytelling techniques
A dashboard is the sequence of views that carries a narrative thread. The author builds it from a business question and tests it view by view.
| Technique | Practice |
|---|---|
| Prepare the data | Business names, codes translated (0/1 → No/Yes), correct types |
| State the denominator | % of total, of the column or of the row answer different questions |
| Distrust the average | Segment and look at the distribution before concluding |
| Time and season | Continuous date for trend; month or weekday for seasonality |
| Explain outliers | Annotate them and drill to the raw records |
| Normalize | Per capita, per ton or per customer before comparing |
| Technique | Practice |
|---|---|
| Explicit indices | Weights written in the indicator sheet |
| Quality sheet | A view of the records that do not match |
| Color with meaning | The undesirable color on the undesirable side |
| Instruction text | “Select one or more countries on the map to see the split” |
| Cross-filtering | Selecting in one view filters the others |
| Order | Top N, descending; manual order only to highlight |
The design canon
- Data becomes information, then knowledge
- Audience, need and use agreed first
- Indicators prioritized before layout
- Brand researched before the prototype
- One business question per view
- Business names and a data dictionary
- Most important content top left
- Hierarchy by position, size, weight, color
- One primary view; the rest support it
- Decision layer on one screen
- White space to rest, separate and rank
- Symmetry, constant spacing, groups
- One grid; canvas size fixed at the start
- A purpose for every element
- No background images; logo in the header
- No heavy borders or redundant legends
- Values labeled; axis dropped where possible
- Flat colors; no gradients, no 3D
- Tables ruled with space and light lines
- One palette, few colors, consistent
- Grays first; one accent for what matters
- Red, amber, green for status only
- Light background by default
- Sequential, divergent or categorical by data
- Undesirable color on the undesirable side
- Never color alone; contrast checked
- One sans-serif family, several weights
- A second family only for figures
- Emphasis by weight, size, color, position
- Uniform sizes by role; text aligned
- No capitals in body text, no underlining
- Minimum size set per target device
- Bars before pies; pies for two or three parts
- Horizontal labels
- Bars sorted by value; Top N
- Continuous date for trend, parts for season
- Normalize before comparing sizes
- Status and trend symbols beside values
- Every number with target, prior, threshold
- The precision the decision needs
- Titles that say what to look for
- Instruction text for each interaction
- The denominator of every percentage
- The distribution behind the average
- Outliers annotated and explained
- Interactive and navigable
- Cross-filtering between views
- Filters to reduce clutter and data volume
- Reusable templates and themes
- A quality view for unmatched records
- Reviewed against the common errors
Delivery
Team, operating rules, quality control, timeline and training.
Team structure and responsibilities (RACI)
Each phase has one accountable role. The product owner approves the work of the cycle; the sponsor approves scope at the start and value at the end.
| Role | Responsibility | 0 · Scope | 1 · Discover | 2 · Design | 3 · Build | 4 · Validate | 5 · Value |
|---|---|---|---|---|---|---|---|
| Sponsor | Owns the outcome; resources, political cover, approves changes | A | I | I | I | C | A |
| Product owner | Sets priorities, approves increments, enforces the schedule | R | A | A | A | A | R |
| Project manager · architect | Runs delivery; designs the solution and its guidelines | R | R | R | R | R | C |
| Business analyst · modeler | Questions, indicator sheets, dimensional model | R | R | R | C | C | R |
| UI/UX designer | Wireframes, design system, prototypes | C | C | R | R | C | I |
| Data & dashboard developers | Pipelines, model, dashboards | I | I | C | R | R | C |
| QA analyst | Data-quality tests, alpha tests | I | I | C | R | R | I |
| Sector expert | Validates KPIs, co-creates data stories | C | R | R | C | R | C |
| Business users | Beta tests, adoption | C | C | C | I | R | C |
R responsible · A accountable · C consulted · I informed. One person can hold several roles; the analyst-modeler is usually the only full-time role, the project manager works part time, and the designer enters at design.
Roles and what each one does
| Role | What the role does | When engaged |
|---|---|---|
| Sponsor client | Secures the commitment of senior management, communicates the vision, obtains resources, provides political cover and approves changes to scope. | Throughout; approves at the scoping and value gates |
| Product owner client | Determines priorities, enforces the schedule and is responsible for approvals. Negotiates the prioritized change list. | Throughout |
| Project manager · architect | Manages and facilitates execution. Designs the solution and sets the guidelines to build it. Single point of contact for the client; reports progress. | Throughout, part time |
| Business analyst · modeler | Runs interviews and questionnaires, writes indicator sheets, builds the dimensional model: dimensionality, attributes, grain and hierarchies of each indicator. | Throughout, full time |
| UI/UX designer | Translates requirements into wireframes and prototypes; applies the design system to every view. | From design onward |
| Data developers | Build the extraction flow, the warehouse exploitation layer and the loads, with their logs and controls. | Build sprints |
| Dashboard developers | Build the semantic model, measures, dashboards and reports in the BI tool. | Build sprints |
| QA analyst | Tests product quality: source-to-target checks, functional, performance, stress and load tests. | Concentrated in the later sprints |
| Sector expert | Brings business expertise, good practice and suggestions of new indicators and forms of analysis; validates KPIs. | Discovery, design, validation |
| Business users client | Advise and observe; run the accompanied beta tests and certify each module. | Discovery, validation |
Added when the scope requires it: a data scientist for predictive analytics, a workshop director for change-management workshops, a training specialist. The client provides hardware or cloud capacity, BI licenses, ETL tools, development environments and collaboration tools.
Sprint rules and ceremonies
Work runs in short, supervised iterations. Every sprint starts from the prioritized backlog and ends with an increment the business can use.
What every sprint observes
- An increment every one to two weeks
- Backlog items chosen by value and expected return
- An effort estimate per sprint: each activity with its hours and its owner
- Daily revision of progress and blockers
- A demo at the end of every sprint
- Progress visible to the client at all times: project dashboards on web and mobile, early alerts of deviation, milestone tracking
| Ceremony | Who | Purpose |
|---|---|---|
| Discovery workshop | Stakeholders, sector experts, analyst | Decisions, questions and value opportunities |
| Sprint planning | Product owner, team | Select backlog items; estimate hours |
| Daily revision | Team | Progress, blockers, next steps |
| Mid-sprint check-in | Team, business users | Confirm direction before the demo |
| Sprint demo | Product owner, users | Review and accept the increment |
| Impact review | Sponsor, product owner | Realized value; new backlog items |
Change control and acceptance testing
Changes to what is already built go to a prioritized list. The list is negotiated with the product owner and does not move the date of the final deliverable.
Developer tests
Functional, performance, stress, load and workflow tests before any user sees the increment.
Accompanied acceptance
End users test the module with developers guiding the first sessions. Results are recorded as test cases.
Certification, then production
Each module is certified by its users before it moves to production. Agreed hours are honored.
Deliverables by phase
Each phase closes with named deliverables. Producing them on schedule is how deviations in time, cost and scope are kept in check.
| Phase | Main activities | Deliverables | Accepted by |
|---|---|---|---|
| 0 · Scope | Area workshops, requirements meetings, prototypes, sizing | Project charter, initial schedule, methodology document, meeting minutes; requirements and source documentation; sized plan for the next phases | Sponsor |
| 1 · Discover | Interviews, decision mapping, value questions | Decision map by persona; Value Questions; prioritized backlog; preliminary ROI | Product owner |
| 2 · Design | Indicator sheets, dimensional analysis, prototypes, architecture | Indicator catalog; process–dimension matrix; hierarchy and measure tables; prototype design; logical model; technical architecture; KPI baseline | Product owner |
| 3 · Build | Data objects, extraction flow, model, dashboards | Data-mart objects and final physical model; extraction-flow document; model, report and dashboard documentation; working increments | Product owner |
| 4 · Validate | Alpha and beta tests; training by audience | Alpha and beta test cases and results; user certification; tool and user manuals | Business users |
| 5 · Value | Impact review, ROI re-run, backlog review | Realized-value report; adoption and usage review; re-prioritized backlog; final report with observations | Sponsor |
Data quality and pipeline control
Every load leaves a record, every failure lands in an error table and raises an alert, and every figure on a dashboard reconciles to its source.
| Control | What it records or does |
|---|---|
| Load log | Date, duration, success or failure and parameters of every run |
| Error table and alert | Rows that fail a rule are kept with the reason; an exception sends an email alert |
| Full, incremental, rollback | Loads run in full or incrementally; a failed load is rolled back so users never see a partial state |
| Source-to-target validation | Figures on the dashboard are reconciled with the source system before release |
Typical engagement timeline
An optional paid scoping phase of about five weeks: workshops per area, prototypes and a sized plan.
The Minimum Valuable Dashboard reaches production; later sprints add to it.
The cycle repeats module by module, about four weeks each; past programs ran from 8 to 24 weeks.
Scope definition
The scope chapter of a proposal is the answered discovery questionnaire, organized by area. What is excluded is written down as plainly as what is included.
| A | Project objectives |
| B | Objectives and organization of each area |
| C | Management problems the area faces |
| D | Proposed improvements |
| E | KPIs by area, each with its definition |
| F | Dimensions and attributes by area |
| G | Count of attributes and metrics: the basis of the size estimate |
| H | Reports by area, with a stated maximum |
| I | Dashboards |
- Select the interviewees
- Prepare questionnaires by area process
- Prepare each interview by user type and level
- Research before the interview; prepare the interviewees
- Conduct, close and review the results
Estimation method
The estimate is built bottom-up from the product definition: hours per activity and per role, agreed before the build starts, and the frame for the whole project.
Who carries the hours
- Analyst-modeler full time
- Project manager part time, about 8–20 hours a week
- Designer from the design phase
- QA concentrated in the later sprints; training in the last
Outside the service fee
- Licenses, billed at project start or provided by the client
- Travel, at the client's cost
- Infrastructure and tools the client provides
A bank of hours
- Hours drawn per deliverable against a signed service order
- Each deliverable tracked by status: to be assigned, in development, pilot run, in production
- Planned and actual hours reconciled per line
The share of analysis varies with the work. In one module-based program analysis took about 60% of a module's hours; in a bank-of-hours program with a national tax and customs authority, development took the larger share.
Adoption and training by audience
We train, we communicate every step and we make users part of the change. The ROI exercise is conducted with each area so that every team can quantify its own benefit.
- Training is delivered as each module goes into production
- Support by email and calls follows each training
- Skills are assessed first; content is grouped by learner profile
- Guides, workshops and coaching accompany validation
| Audience | Learns to | Hours |
|---|---|---|
| End users and managers | Read status, drill to cause, decide; publish and share analyses; subscriptions, alerts and exports | ≈ 8 |
| Analysts | Explore, filter, build ad-hoc views; advanced reports, functions, thresholds and drill maps | ≈ 16 |
| Modelers | Source mapping; attributes, dimensions, hierarchies, facts and metrics; aggregations | ≈ 10 |
| Administrators | Install and configure; security, caching, scheduling, monitoring | ≈ 6 |
Reference hours from a platform training program; topics and hours are adapted to the client's BI tool. The dashboard design course is offered in addition (next page).
Dashboard design course syllabus
A course on the design method, delivered alongside tool training. It teaches the people who will build the next dashboards to apply the same rules as the program team.
Foundations
- Audience: who uses the dashboard and which decision it serves
- Dashboard types: the kinds of dashboard and the reader each serves
- Creating value: tying each view to a value question
- Choosing ratios and dimensions: the indicator sheet in practice
Dashboard structure
- Format: canvas size and the device it is read on
- Structure and layout: emphasis zones, grids, placement by relevance
- Design principles: simplicity, white space, symmetry
- Functionality: filters, navigation and drill paths
Information design
- Interface design: hierarchy of titles, KPIs and charts
- Fonts and colors: one palette, weights for emphasis, corporate colors
- Chart selection: the chart that answers the question
- Chart formatting: direct labels, minimal axes and gridlines
Module and topic names follow the course index. The descriptions summarize the corresponding rules in the toolkits of this book.
Documentation delivered
The client receives the documents needed to run, extend and audit the solution without the delivery team.
Plan and record
Project charter · plan and schedule · methodology document · meeting minutes
What was asked
Requirements document · analysis method · list of variables and indicators
How it is measured
Process–dimension matrix · hierarchy tables · measure tables · indicator sheets
How it is built
Applied strategy, including cultural change management · prototype design · logical model · technical requirements and architecture
How it runs
Data-mart objects · final logical and physical model · ETL document: loads, scheduled tasks, log management, procedures
What users see
Documentation of the model, reports and dashboards · solution report
Keeping it running
Installation manuals for development and production · tool manual · user manual
What was learned
Final report with observations · realized-value report · re-prioritized backlog
Each document is delivered with the phase that produces it, as listed in the deliverables by phase, and accepted at that phase's gate. The set is complete at closure.
Value
How value is estimated, measured and reported.
Value dimensions and when value is measured
Value is estimated before the build, measured as a baseline during design and measured again with objective data after release.
Short ROI
Estimated with each area from its own losses and report hours: time saved, efficiency, risk and decision quality. Sets priorities for the backlog.
Starting values
Every KPI in the indicator catalog gets a measured starting value. Without a baseline, later impact cannot be demonstrated.
ROI re-run
The ROI template is run again against the baseline with objective metrics, every cycle. Results feed the backlog and retire unused indicators.
| Benefit group | Benefits the program is expected to produce |
|---|---|
| Strategic | Alignment with objectives; visibility of performance and trends; faster response to emerging problems |
| Operational | Less manual reporting; shorter decision cycles; reliable measurement of processes and KPIs |
| Financial | Quantified time savings; lower operating costs; better allocation of resources to data initiatives |
| Cultural | More trust in analytics; higher data literacy; more use of data in daily work |
The ROI model
Three sheets: what the program costs and when, what it returns and from when, and whether the return justifies the investment at a rate that reflects its risk.
What it costs, when
- Infrastructure (servers, cloud)
- Licenses, with annual maintenance
- Implementation services, spread over the program
Two engines of value
- Process improvement = annual loss × improvement rate, one line per objective (lost sales, waste, excess stock)
- Hours released = salary × share of time spent on reports, by profile
- Qualitative benefits listed without a price
Return on the investment
- ROI = (benefits − investment) ÷ investment
- Net present value at a risk-adjusted rate: r = rf + country risk + β × market premium
- Payback in months
- Re-run with actuals against the baseline
Time saved · efficiency gained · decision quality · cost avoided · risk reduced
Preliminary in phase 1 · baseline in phase 2 · realized in phase 5, every cycle
Run with each area in the scoping workshop: an adoption tool as much as a business case
The investment sheet
Every cost is entered with the month in which it is paid. The timing of the investment drives net present value and payback as much as its total.
| Category | Payment rule | US$ |
|---|---|---|
| Warehouse server | Fixed asset, paid in month 6 | 3,000 |
| BI application server | Fixed asset, paid in month 6 | 3,000 |
| BI platform licenses | Intangible; half in month 1, half in month 2; maintenance at 18% a year from year 2 | 11,224 |
| Implementation services | Start-up cost, twelve equal monthly installments | 62,800 |
| Total investment | Year 1 | 80,024 |
| Years 2 and 3 | License maintenance only, each year | 2,020 |
Figures from the worked example of a pharmaceutical distributor; client anonymized.
- Group costs as fixed assets, intangibles and start-up
- Enter each cost in the month it is paid
- Carry recurring costs, such as maintenance, into every later year
- Show each year's total and the cumulative investment
The benefits sheet
Two sources of benefit are priced: losses the program reduces and report-preparation hours it releases. Each line carries its base, its rate and its owner's agreement.
| Objective | Annual base | Rate | Per month |
|---|---|---|---|
| Reduce lost sales | 2,000,000 | 2% | 3,333 |
| Control input waste | 70,000 | 1% | 58 |
| Control excess stock | 3,800,000 | 2% | 6,333 |
| Subtotal | 9,725 |
Year 1 counts nine months: 87,525. Years 2 and 3 apply a conservative 1% to every line: 58,700 a year.
| Profile | Per month | Per year |
|---|---|---|
| Three analysts | 1,035 | 12,420 |
| Two area heads | 280 | 3,360 |
| Two area managers | 200 | 2,400 |
| Subtotal | 1,515 | 18,180 |
Year 1 counts nine months: 13,635.
Better organizational performance, cost reduction, better support to stakeholders, better access to data.
Viability: ROI, net present value and payback
The program is viable when its net present value is positive at a discount rate that reflects the risk of the project and of the country where it runs.
| Measure | Formula |
|---|---|
| ROI | (benefits − investment) ÷ investment, per year and cumulative |
| Net cash flow | benefits − investment, per year |
| Net present value | Σ net cash flowt ÷ (1 + r)t, for t = 1 … n |
| Payback | investment ÷ monthly benefit, counted from the first month of benefits |
| Decision rule | Accept when net present value > 0 |
Benefits ÷ investment is a benefit-to-cost ratio and is reported under that name. An internal rate of return is reported only when the cash flows change sign; when every yearly flow is positive it does not exist.
| rf · risk-free rate | US Treasury, 5-year | 2.62% |
| Country risk | Sovereign spread of the client's country | 1.60% |
| β · project beta | Risk of the project relative to the market | 1.5 |
| Market premium | Market return − risk-free rate | 10.58% |
| r | rf + country risk + β × market premium | 20.1% |
ROI model: worked example
ROI in year 1 (nine months of benefits)
Cumulative ROI after three years
Net present value at 20.1%
Approximate payback from first benefits
| US$ | Year 1 | Year 2 | Year 3 |
|---|---|---|---|
| Investment | 80,024 | 2,020 | 2,020 |
| Process improvement | 87,525 | 58,700 | 58,700 |
| Hours released | 13,635 | 18,180 | 18,180 |
| Benefits | 101,160 | 76,880 | 76,880 |
| Net cash flow | 21,136 | 74,860 | 74,860 |
| Cumulative ROI | 26% | 117% | 203% |
Benefits: lost sales cut by 2%, input waste by 1% and excess stock by 2% of their annual value, plus report-preparation time released for three analysts, two area heads and two managers. Discount rate: 2.62% + 1.60% + 1.5 × 10.58% = 20.1%. Year-2 and year-3 process benefits use a conservative 1%.
How proposals justify value without a full model
Before the data for a full model exists, a proposal justifies value with one of three methods. Each is replaced by the full model once discovery provides the bases.
Estimate the hours staff spend today preparing the information the project will automate, and the months needed to recover the fee from those hours. No spreadsheet; a single, checkable argument.
In the scoping workshop each area estimates the return it can obtain. The exercise produces the first figures and commits the area to them.
A list of ROI levers the client quantifies with its own data, paired with the KPIs that will measure success.
| Lever | Valued through |
|---|---|
| Cost reduction | Hours, errors and overhead removed |
| Efficiency | Time before and after, translated into money |
| Better decisions | Delays avoided |
| Customer satisfaction | Customer retention |
| Competitive advantage | Contracts won |
| Risk mitigation | Penalties avoided |
| Also listed for the client to value: resource optimization · revenue · scalability · operating savings | |
AI
The role of artificial intelligence in analytics, and its governance.
Analytics maturity and the role of AI
AI creates value only when it is embedded in real business decisions. Adoption is practical, progressive and controlled: each stage rests on the one before it.
| Stage | Questions or focus | Typical solutions |
|---|---|---|
| Descriptive | What is happening, where the significant variations are, which indicators need attention now | Enterprise data integration · executive and operational dashboards · report automation |
| Diagnostic | Why the variations occur, which factors weigh most, where to act | Root-cause analysis · exploration and drill-down · key drivers |
| Predictive | Demand, risk, performance, capacity, cost; models chosen for practical use | Forecasting · applied predictive models · future risk |
| Prescriptive | Which action to take, simulated before it is executed | Scenario optimization · decision rules · alerts and recommendations |
| Autonomous | Intelligence acts while the business remains in control | AI embedded in processes · decision automation · continuous optimization |
The analytics copilot architecture
Natural-language questions over program-performance data, with every figure traceable. The language model interprets the question; a deterministic query engine calculates the answer.
A figure produced by a query can be reproduced and audited. The model reads the question and drafts the layout; it does not produce the figures.
Z-score, modified Z-score (MAD), combined Z-score, linear trend regression, STL seasonal decomposition, Isolation Forest; Prophet optional.
Each indicator's finding is reported with the detection method, the significance of its trend and the anomalies found, in answer to the challenge's explainability criterion.
Governance of AI in decisions
Intelligence acts while the business remains in control. Before an AI capability recommends or acts, its limits, its autonomy, its audit trail and the point of human approval are set, and they are reviewed against real results.
| Control | What is set before the capability runs | Evidence kept |
|---|---|---|
| Decision limits | The scope within which the system may recommend or act, with breach thresholds and a rollback envelope | Approved scope; threshold register |
| Autonomy level | Declared per capability: alert and recommendation (prescriptive stage) or automated decision inside set limits (autonomous stage) | Approved scope and authorized users |
| Audit trail | Bound to the capability at run time; every answer carries its method and the data used | Streaming audit trail with retention; auditable reports |
| Human approval | The final decision stays with a person; override and escalation paths are defined in advance | Decision logs; corrective-action register |
| Monitoring | Model drift, accuracy, fairness and latency measured against the approved model; adjustment by real results | Monitoring log; drift Δ |
| Continuity | Mandatory guardrails; a fallback model; periodic review and re-approval of every capability | Review records |
History
The stages of the methodology and the practices that remained.
History of the methodology
Start of the business intelligence consulting practice.
Corporate BI method for a cement producer: dimensional lifecycle, performance-management cycle, readiness test, “Alarm, Analysis, Decision”.
Agile BI practice: Scrum plus BI best practice, design thinking, 1–4 week sprints, alpha/beta, BI factory model.
The author wins the best-dashboard award in the MicroStrategy Dashboard Showcase Contest.
Dashboard design standard written; design method course in every program.
Adaptive agile BI method: Value Questions, Minimum Valuable Dashboard, ROI re-run. Facilitated a federal performance-metrics workshop with a live dashboard demonstration.
The NGD Methodology, first edition, with AI-assisted analytics; 20 industry dashboards built with it.
Stages of the methodology
Each stage kept the practices that worked and added what the previous one lacked. This first edition of the book consolidates all of them.
| Period | Stage | What it introduced |
|---|---|---|
| 2008 | Business intelligence consulting practice | Start of the practice: corporate reporting and data warehouse projects. |
| 2013 | Corporate BI method | Dimensional data warehouse lifecycle combined with a performance-management cycle; a methodological and an engineering track; readiness test; training by profile; the alarm, analysis and decision structure. |
| 2015–2018 | Agile BI method | Scrum combined with BI practice; sprints of one to four weeks; sector experts in the team; alpha and accompanied beta tests; prioritized change list; Design Thinking before construction; the BI factory model. |
| 2017 | Dashboard design standard | The written design standard and the dashboard design course delivered with every program. |
| 2025 | Adaptive agile BI method | The five-phase value cycle; Value Questions; persona-centered decision design; the Minimum Valuable Dashboard; ROI measured against a baseline and re-measured after delivery. |
| 2026 | The NGD Methodology, first edition: AI-assisted analytics | The analytics maturity model; the analytics copilot architecture; governance of AI in decisions; the industry dashboards of Next Gen Dashboards. |
Continuity and change across stages
| Sector experts | Business experts work beside the BI team and validate the indicators. |
| Design before construction | Prototypes and wireframes precede the data model. |
| Two levels of testing | Alpha tests by the team; beta tests accompanied, with end users. |
| Prioritized changes | Change requests enter a prioritized list or backlog. |
| Improvement after delivery | Maintenance and growth, later continuous value and ROI. |
| Training by profile | Executive, analyst and technical audiences, later AI literacy. |
| Estimation and control | Effort estimation, later the ROI template measured against a baseline. |
Unit of delivery
From sprints of one to four weeks within a one-to-two-month project, to an increment every one to two weeks in a continuous cycle.
What is measured
From agreed hours and schedule, to ROI measured against a baseline and re-measured after delivery.
Governance
From data governance standards to governance of AI in decisions: approved limits, monitoring and human approval.
Scope of analytics
From descriptive dashboards to prescriptive and AI-assisted decisions, with people accountable for the final call.
About the author
The author's career, her clients and the goal behind Next Gen Dashboards.
Zoila Gonzalez
Founder, Next Gen Dashboards · Founder, Tsubaki · MBA, Johns Hopkins Carey Business School
An analytics career that began with the first job and has continued in analytics since, implementing business intelligence systems from scratch for companies and public institutions.
Years old
First role, in analytics
Business intelligence projects for corporate clients: scorecards, dashboards, reports and information portals, built from the business question.
Years old
A complete ETL in Python and Oracle
Designed and built the company's data integration process, reducing its processing time from hours to eight minutes.
Years old
Her own analytics company
Business intelligence services across Peru: SUNAT, Banco Financiero, Cementos Pacasmayo, Cencosud and the national ministries of Education and Health. She grew the company and completed a successful exit through the sale of her shares.
Experience
International experience
Business intelligence and data programs for Citibank in the United States and Latin America, for Expedia, and for healthcare organizations in Maryland. MBA from Johns Hopkins Carey Business School.
Certifications and education
- Project Management Professional (PMP), Project Management Institute
- Lean Six Sigma Black Belt, Six Sigma Global Institute
- Lean Six Sigma Green Belt, Six Sigma Global Institute
- Certified ScrumMaster (CSM)
- Healthcare Project Management (CHPM)
- MicroStrategy Certified Developer: Project Designer, Report Developer, Document Developer
- MBA, Johns Hopkins Carey Business School
- B.S. in Systems Engineering, Universidad Peruana Unión
- Professor of Information Engineering, Universidad del Pacífico
- Data Visualization Storytelling
- Data Visualization for Data Analysis and Analytics
- Learning Data Visualization
- Presenting Data Effectively to Inform and Inspire
Business intelligence for everyone
Her goal is that every organization uses business intelligence: easy to use and easy to implement, whatever the size of the business.
companies served
clients
projects
successful implementations
Why Next Gen Dashboards
Next Gen Dashboards condenses the main sectors, metrics and indicators of that practice. Each dashboard is an example of how dashboards are implemented for clients.
How to use it
The logic of each sector is stable, so the examples apply directly to a real organization. Companies and data in the dashboards are fictional.
Proof
The methodology applied in industry dashboards, and how to engage.
Industry applications
Each dashboard starts from its Value Questions, carries indicator sheets with targets and benchmarks, compares with last year, and plants the stories a real team would have to find.
Scope of each industry dashboard
| Industry | Decision areas covered | Fictional company modeled |
|---|---|---|
| Airline | On-time performance, delays, network revenue, cost and fuel, fleet, crew and baggage | An airline with a Denver hub |
| Bank risk (Basel) | Risk appetite, capital and RWA, credit, market, liquidity and operational risk, stress testing | A regional bank |
| Banking | Global position, lending funnel, credit risk, client view and relationship managers | A corporate bank |
| Construction | Job finance, revenue against plan, bids, earned value, safety and ready-mix plants | A general contractor in Texas |
| Digital marketing | Paid media, attribution and incrementality, creative, conversion, cohorts and LTV | A direct-to-consumer brand |
| Education | Admissions, students, learning assessment, faculty and finance | A university in Texas |
| Government | Funding, health centers, workforce and community indicators by state | A federal community-health program |
| Healthcare | Emergency care, quality and safety, workforce, beds and operating rooms, revenue cycle | A health system in Florida |
| Hospitality | Revenue and pricing, fair share against the comp set, booking pace, channels and guest sentiment | A hotel group |
| Insurance | Membership, premium and medical loss ratio, cost per member, claims and utilization | A health plan in Maryland |
| Logistics | Network scorecard, on-time delivery, cost per mile, warehouse, fleet and drivers, CO2 | A carrier and 3PL in Memphis |
| Manufacturing | SQDCP scorecard, OEE and losses, quality, OTIF, maintenance, cost per unit | A motor and gear-drive plant |
| Mining | Integrated performance index, production, equipment, safety, environment and finance | A copper-gold mine in Arizona |
| People & HR | Headcount, salary model, turnover, talent acquisition, pay equity and engagement | A consumer-goods company |
| Pharma | Indicator management, production against forecast, stock cover, OEE, quality release and sales | A generic drug plant in North Carolina |
| Real estate | New-home sales, supply, months of supply and mortgages by submarket and builder | The Phoenix metro market |
| Retail inventory | Stock against plan, availability, purchase orders, open-to-buy, shrink and cover | A grocery chain in Texas |
| Retail | Sales, targets, margin, promotions, customers and inventory | A grocery chain in Texas |
| Sales pipeline | Pipeline flow from lead to close, open pipeline by country, forecast and bookings, customer success, retention and expansion | A B2B software company in Chicago |
| Telecom | Active lines, gross adds, churn, revenue and ARPU, contact center and customer experience | A mobile and home-internet carrier |
Dashboards for Executive and Operational Decision-Making.
Zoila Gonzalez · Founder, Next Gen Dashboards · ngdashboards.com