People Analytics Theory, Tools and Techniques

1. 1Start from a live, costly problem, not a technique. The source says People Analytics avoids its pitfalls when it begins with an existing major problem that carries a real challenge. Write the problem as one sentence, e.g. 'call center executives quit at a frantic rate.'
2. 2Convert the problem into a testable question tied to a critical outcome (Step 1 of the six-step process). Pick the few outcomes the organization actually cares about, such as the bottom line or customer grievance redressal, and check them against the mission and vision wording. A testable question names an outcome and something that might predict it. Example: 'Which employees are likely leavers?'
3. 3Before touching data, name the stakeholders outside HR and bring them in (Step 2, cross-functional data team). Identify who owns the data: the HR head, line managers, and data reconciliation experts. The source warns the work must be supported by the departments with a stake and not be confined to HR.
4. 4Audit the outcome measure (Step 3). Record how the current data was captured, how often it is measured, the level (individual, team, department, branch, region, organization), and the formally assigned owner. Without a common base the comparisons are meaningless.
5. 5Reconcile before analyzing. Link the data sets and remove only genuinely redundant records. Over-deleting destroys the linkage you need to infer anything.
6. 6Fix the data-collection rules before you look at results. The source flags selective data collection as a source of researcher bias that may never be reported. Write down what you included, what you excluded, and why.
7. 7Analyze with a method that matches the question (Step 4), and test it on data it has not seen. For prediction, split the data into training, holdout, and testing samples and check for overfitting. For group comparisons, use the comparison-of-means and ANOVA techniques the book teaches.
8. 8Plan for uncomfortable findings and run the loop (Steps 5–6). Decide in advance how you will present results that contradict a respected leader, because employees may side with the person over the study. Build the program, measure, and adjust, keeping the four dimensions in view: measurement, experimentation, sharing, replication.

Take the book's Highhouse Financials exercise. Highhouse is a KPO firm where call center executives quit at a frantic rate, and Ms. Josephine, head of recruitment and talent retention, wants to know whether she can identify potential leavers. An intuition-first HR team would blame pay or a manager and launch a retention scheme. An analytic-minded team first writes the question: 'Which employees in the dataset are likely to leave, and what do the data say distinguishes them?' It names attrition as the critical outcome (Step 1) and brings in line managers and the data owners (Step 2). It checks how attrition was recorded, at what level and how often (Step 3). Then it fits a model, such as the neural network the exercise prescribes, using separate training, holdout, and testing samples. It reads prediction quality on all three, so a model that only memorizes the training data (overfitting) is caught. As the chapter's own question puts it, the HR manager's job is to say what the three sets of results imply for action. Because neural networks are 'black box' models, the team also states plainly what the model cannot explain before recommending a program.

• If the proposed project begins with a technique or tool and not a named business problem, then stop and restate it as a problem with a challenge before any data work.
• If you cannot name the owner, periodicity, and level of an outcome measure, then do not compare it across units; first establish a common base (Step 3).
• If you are building a predictive model, then require training, holdout, and testing samples and compare performance across all three before trusting it.
• If a finding contradicts a respected leader's view, then bring the stakeholders in early and show the method and data lineage, since employees may side with the person over the study.
• If the benchmark only tells you where you stand relative to the industry, then do not claim impact; link the HR metric to an outcome such as profit before drawing conclusions (the gap Fitz-enz's benchmarks left).

• Metrics without inference: reporting benchmarked HR metrics (turnover, retention, recruitment) and stopping there. The tell: you can say how you compare to the industry but cannot say what HR activity changed which outcome.
• Selective data collection: gathering only the data that supports the preferred story. The tell: the analysis plan was written after the data was pulled, and exclusions are not documented anywhere.
• HR-only analytics: running the project inside HR without the departments that hold the data or the stake. The tell: data requests stall and line managers dismiss the results.
• Over-trusting a black-box model: presenting a neural network's output without holdout and testing checks. The tell: strong fit on training data and no one can say how it performs on unseen employees.
• Deferring to authority over evidence: letting a distinguished person's opinion override uncomfortable results. The tell: the study is accepted only when it agrees with the senior view.

• ▸Business problem: one sentence describing the existing, costly issue.
• ▸Critical outcome: the organizational outcome this affects (e.g., bottom line, attrition, grievance redressal) and its link to mission/vision.
• ▸Testable question: the question in a form that data can answer.
• ▸Data owners and cross-functional team: names or roles inside and outside HR, plus any data reconciliation expert.
• ▸Measure audit: how the outcome is captured, how often, at what level, and who formally owns it.
• ▸Inclusion/exclusion rules: what data is in or out, and why, written before analysis.
• ▸Method and validation: technique chosen and how it is checked (training/holdout/testing split, overfitting check).
• ▸Uncomfortable-result plan: who might disagree with a likely finding and how you will share the method with them.
• ▸Adjustment loop: what you will measure after action and when you will revise.

1. 1State the recommendation as one sentence before touching data: 'We should do X because it changes Y outcome.' Y must be an employee, customer, or organizational outcome such as performance. The source defines People Analytics as analyzing HR variables to understand their effects on those outcomes, so a claim that stops at an HR activity count is not yet evidence-based.
2. 2Name the outcome the decision-makers care about and test whether your metric connects to it. Time-to-hire is the source's example: it does not impress key stakeholders until a direct link to workforce quality is established. If you cannot state the link, treat the metric as a scorecard item, not as evidence.
3. 3Write a measurable hypothesis and a goal before running anything. The source's 'intelligent experiment' requires clear goals and objectives, measurable hypotheses, and standard treatment-control procedures. Follow its four steps: design, build, run, analyze. Define who gets the intervention and who does not.
4. 4Pull the data that describes the behavior or outcome and look for anomalies first. Use dashboards or visualizations to find what departs from expectation. Do not start by hunting for a favorable number.
5. 5When something anomalous appears, drill down to the cause before acting. Surface data tells you where to look, not what to change. Ask why the pattern exists, then design the intervention around the cause.
6. 6Calculate ROI for the major work-related activity you are recommending. The source says the way forward is to keep calculating ROI for major activities and to give empirical evidence behind every argument or recommendation. Put the ROI and the evidence in the same document as the ask.
7. 7Close the loop with the line manager. HR works closely with line managers on the company's day-to-day operating objectives, and HR leaders own the consequences of the decisions made. For training, measure whether the required-observed competency gap actually closed. The analyst reports the result so action can start on time.

Kyklosys, a Bengaluru gamification-training start-up, receives about five terabytes of user-generated gaming data daily from over 40,000 users. Rather than leaving it idle, its analysts read the usage dashboards and noticed that middle-level managers were spending four to five hours on one role-play module, far more than expected. The designers did not stop at the anomaly. They drilled down and found the role-play gave participants a sense of leadership. They then built specific leadership-skill-development situations into most of their similar exercises, and the overall popularity of all their modules rose. The sequence to copy is: observe, drill to cause, change the design, check the outcome. The source labels this descriptive analytics and data visualization, and it reports no ROI figure. If you run the same play, you would add the ROI calculation the source calls for, which the passage does not supply.

• If your analysis only compares two departments, branches, or years, then label it a comparison or ranking, not evidence. Hold the recommendation until you can show the impact on organizational performance.
• If your support is a correlation or an industry benchmark, then do not present it as proof. The source says correlation values are often deceptive and benchmarks do not show what value your employees add. Add a test of effect, such as a treatment-control experiment.
• If an efficiency metric (time-to-hire, say) is the centerpiece of your case, then attach its link to workforce quality or another business outcome. Without that link, stakeholders will not be moved.
• If a recommendation involves meaningful spend or effort, then attach an ROI calculation and the empirical basis for it before it goes to leadership.
• If you are recommending training, then define success as closing the required-observed competency gap, and commit to examining and reporting it.

• Scorecard substitution: presenting HR efficiency metrics as the analysis. Tell: the deck reports numbers but never states an effect on an employee, customer, or organizational outcome.
• Ranking mistaken for insight: comparing departments or yearly performance and stopping. Tell: the conclusion is 'Branch A is higher than Branch B' with no account of impact on the business.
• Leaning on correlation or benchmarking as proof. Tell: your justification is 'it correlates' or 'the industry average is X', and nobody can say what value your people added.
• Acting on the surface anomaly without drilling down. Tell: you can describe the pattern (hours spent, a spike) but not why it occurs, so the intervention is a guess.
• No ownership or follow-through: the recommendation ships but nobody examines the result. Tell: no one is assigned to report whether the competency gap closed, and HR and line managers are not working from the same objectives.

• ▸Recommendation: one sentence, 'We should do X because it changes Y'.
• ▸Target outcome (Y): the employee, customer, or organizational outcome at stake.
• ▸Link to outcome: how the metric you track connects to Y; if none, state the gap.
• ▸Hypothesis and goal: a measurable statement you can confirm or reject.
• ▸Design: treatment group, control group, and the four steps (design, build, run, analyze).
• ▸Observed anomaly and root cause: what the data showed and what drilling down revealed.
• ▸ROI calculation: costs, benefits, and method, attached to the major work-related activity.
• ▸Owner and line-manager partner: who is accountable for the consequences of the decision.
• ▸Follow-up check: the required-observed competency gap or outcome to re-measure, and the date to report it.

1. 1Name the forecast target and its type before choosing a technique. A continuous outcome (a score or a count) goes to correlation and linear regression. A yes/no outcome (stays or leaves, joins or does not join) goes to logistic regression, a classification tree, or a neural network. Unlabelled employees you want to group go to cluster analysis. A large set of survey items you want to collapse goes to factor analysis or PCA.
2. 2Confirm you are at the predictive level of maturity. Descriptive work (dashboards, past reports) is reactive. Predictive work uses historical data to find hidden patterns and forecast future outcomes. The firm in the source case first spent a multi-year effort standardizing HR metrics and data collection and building a central data warehouse, so do the same before modeling.
3. 3Start with the simplest model: correlation, then linear regression for continuous outcomes, or logistic regression for binary outcomes. Treat it as the baseline that any more complex model must beat.
4. 4For binary HR outcomes, try a CART decision tree next (Rattle is the tool the source uses). Read the tree as if-then rules a manager can follow. Then run an ensemble (random forest) on the same data and compare the two.
5. 5Evaluate every classifier with an error matrix on both training and validation data. Do not judge a model on training data alone. The source's Rattle outputs report the error matrix for training and validation separately, and random forest has its own error matrix.
6. 6Use a neural network only when the simpler models underperform. The source lists neural networks, support vector machines and decision trees as the methods banks apply to historical loan-repayment data to find which characteristics predict outcomes. HR uses the same logic on historical attrition or hiring data.
7. 7When you have many survey items or employee attributes, run factor analysis or PCA in JAMOVI and read the scree plot to decide how many factors to keep. For segmentation, add the SnowCluster module, use the Optimal Number option first, then run K-means with that number. Interpret the segments from the cluster mean plot.
8. 8Convert each result into an HR decision the business can act on: predicting attrition, comparing recruitment or training routes, or planning succession. Hand the output to HR business partners or Analytics Champions who can explain it to managers.

The book's Alvin dataset covers candidates who appeared for Alvin interviews and either joined or did not join. The outcome is binary, so the question is who is likely to join. A practitioner loads the data into Rattle, splits it into training and validation sets, and builds a decision tree. The tree is read as rules showing which candidate characteristics separate joiners from non-joiners. The error matrix on training and validation data shows how often the tree misclassifies candidates on data it has not seen. A random forest is then run on the same split and its error matrix is compared with the tree's. If the forest is clearly better, you use it for forecasting and keep the tree to explain the drivers. If the two are close, you keep the tree because managers can read it. The source passages name these outputs (Figures 11.7c, 11.8a–c) but do not reproduce the results, so the accuracy figures must come from your own run.

• If the outcome is binary (joined or not, stays or leaves), use logistic regression or a classification tree. Do not use linear regression.
• If the outcome is continuous and you want to explain relationships, start with correlation and linear regression.
• If the audience needs readable rules, use CART. If accuracy matters more than readability, test a random forest on the same data and compare the error matrices.
• If the validation error is much worse than the training error, treat the model as unreliable and simplify it before using any forecast.
• If you have many correlated survey items, reduce them with factor analysis or PCA, using the scree plot to choose the number of factors. If you need employee segments, find the optimal cluster count before running K-means.

• Modeling before the data is standardized. The tell: metrics are defined differently across units and the analysts only produce reports nobody acts on, as in the source firm before its multi-year standardization project.
• Judging fit on training data only. The tell: a very low training error but no validation error matrix in the write-up.
• Choosing a complex technique by default. The tell: a neural network is built before any regression or tree baseline exists, and no one can explain the drivers to managers.
• Picking the cluster or factor count arbitrarily. The tell: K-means is run without the optimal-number step, or factors are retained without checking the scree plot.
• Stopping at the model output. The tell: the forecast has no named HR decision attached, such as attrition, a recruitment or training comparison, or succession planning, so it stays at the reactive, report-only level.

• ▸Workforce question: state the one decision the forecast supports (e.g., attrition, offer acceptance, training comparison, succession).
• ▸Outcome variable and type: name it and mark it continuous, binary, or none (segmentation or reduction).
• ▸Data readiness: note whether metric definitions are standardized and the data source is centralized (yes/no, gaps).
• ▸Baseline model: choose regression or logistic regression and record the result.
• ▸Challenger model: choose CART, random forest, or neural network and say why the baseline is not enough.
• ▸Error matrix, training: record misclassification results on the training data.
• ▸Error matrix, validation: record misclassification results on held-out data and the gap versus training.
• ▸Factor or cluster settings (if used): record the scree-plot or optimal-number result and the number of factors or clusters kept.
• ▸Decision and owner: state the action the output drives and who (HRBP or Analytics Champion) communicates it.

1. 1Define the outcome in two buckets before you measure anything: voluntary and involuntary separations. The source tracks them as separate lag metrics (involuntary retirement rate: layoffs, downsizing, firing; voluntary retirement rate), so a blended number hides what you can actually influence.
2. 2Compute the base lag metrics on a fixed period. Turnover Rate = (terminates in period / average employees in period) × 100. Involuntary rate = involuntary separations / employees at the START of the period. Note the denominators differ (average vs. beginning headcount), so keep each definition consistent over time.
3. 3Cut the base rate by the value dimension. Talent Turnover Rate = high-potential terminates / average employees. Add 'turnover of high-performers' and 'resignations by length of service' from the CIPD retention-and-separation list. This separates losing valuable people from losing anyone.
4. 4Cut by manager and team. Retention rate per manager = (employees under manager − departed) / employees under manager. Rank managers and teams to find where attrition clusters before you theorize about causes.
5. 5Pair each lag metric with lead indicators. The source classes eNPS (% promoters − % detractors), employee satisfaction ratio (satisfied employees / total employees), and employee relations incidents (incidents / headcount) as lead metrics. Track them on the same unit (team/manager) as the lag metric so you can test whether they move first.
6. 6Test the lead–lag link statistically, not by assumption. Use scatter plots first (to catch outliers), then correlation and regression, then CART/ensemble methods for prediction, all covered in the book's analytics chapters. Treat correlations cautiously: the book flags spurious correlation as a trap.
7. 7Benchmark carefully. Industry benchmarks (Saratoga-style retention and separation ratios) tell you where you stand, not whether your HR actions cause retention. The source notes that matching leaders' scores said little about business impact, so judge interventions by your own before/after movement.
8. 8Present the result with low cognitive load. Use a card or gauge for the headline rate. Use a decomposition tree or key-influencer visual to drill by department, manager, or tenure. Cut clutter so viewers do not tunnel onto the most prominent element and miss the real driver.

The source's real anchor is Culina-King Restaurants, the West and South India franchise of a global food and beverage company, which won the 2017 'Best Place to Work' award among retail food chains. Its case is titled 'win attrition war using big data analytics'; the supplied passage does not give its metrics or interventions, so do not copy specifics from it. Here is the method on illustrative numbers (not from the source). A 200-person firm (average headcount) records 24 terminations: Turnover Rate = 24/200 × 100 = 12%. Of those, 4 are involuntary, with 210 employees at period start: involuntary rate = 4/210 ≈ 1.9%, so about 20 exits are voluntary. Three of the 24 were high potentials: Talent Turnover Rate = 3/200 = 1.5%. One manager lost 3 of 10 reports: retention rate per manager = (10 − 3)/10 = 0.70. You then pull that team's eNPS, satisfaction ratio, and relations-incident count, and check whether they were weak before the exits. That sequence points the intervention at one team rather than the whole firm.

• If total turnover rises, split voluntary from involuntary first; if the increase is involuntary (layoffs, firings), it is a business decision, not a retention-program problem.
• If the overall rate looks acceptable but talent turnover rate (high potentials) is rising, treat it as a retention problem anyway; the headline average masks the loss of valuable people.
• If retention rate per manager varies widely across teams, investigate manager-level drivers before launching company-wide programs.
• If a lead metric (eNPS, satisfaction ratio, relations incidents) correlates with later exits, use it as an early-warning trigger; if the correlation vanishes after outlier removal or looks spurious, do not act on it.
• If you only have benchmark comparisons and no internal before/after data, do not claim a retention initiative worked; the benchmark shows position, not impact.

• Mixing denominators (average headcount for one rate, beginning headcount for another) across periods or reports. The tell: the same period yields conflicting rates, or trends jump when someone rebuilds the sheet.
• Reporting a single blended attrition number. The tell: leaders react to a layoff-driven spike with a retention-bonus program.
• Ignoring who left. The tell: turnover is 'on benchmark' while high-performer and high-potential exits go unreported.
• Reading correlation as cause between satisfaction/eNPS and exits. The tell: a strong correlation driven by one outlier on the scatter plot, or an intervention built on a relationship nobody tested.
• Cluttered dashboards. The tell: viewers fixate on the most prominent chart and miss the manager or tenure breakdown that holds the real signal.

• ▸Period and unit: the dates and the team/department/manager covered.
• ▸Average headcount and start-of-period headcount: the two denominators; note which metric uses which.
• ▸Voluntary vs. involuntary terminates: count each separately.
• ▸Turnover rate (%): (terminates / average employees) × 100.
• ▸High-potential terminates and Talent Turnover Rate: high-potential exits / average employees.
• ▸Retention rate per manager: (team size − departed) / team size, for each manager.
• ▸Lead indicators: eNPS (% promoters − % detractors), satisfaction ratio, relations incidents / headcount.
• ▸Resignations by length of service: tenure bands where exits concentrate.
• ▸Benchmark and internal prior-period comparison: industry figure plus your own last period; flag if the change is real or only relative to peers.
• ▸Hypothesis and intervention: the suspected driver, the action, and the metric and date you will re-measure.

1. 1Start from a named, critical business problem, not a theory. The passages warn that People Analytics works best when it begins with 'an existing major problem with a challenge involved.' Write the problem as one sentence, such as 'productivity is below average in unit X,' before you pull any data.
2. 2Get the stakeholders in before you measure. Findings reach beyond HR, so the departments with a stake must support the work. Name them up front, because results may be uncomfortable for some of them.
3. 3Standardize the productivity metrics before you compare anything. The retailer case found that KPIs were 'not in sync' across brand divisions and could not be compared once merged. Fix one definition, one recording rule, and one owner for each metric (revenue per employee, performance rating, project completion).
4. 4Centralize the data. In the retailer case, IT built centralized data warehouses and management information systems for quick storage and retrieval. Pull the productivity measures into one place so they can be merged, for example by joining an employee productivity sheet to other datasets in Power Query.
5. 5Draw the sample from the population with the study objective in mind. Do not assume more data guarantees accuracy. Define who is in scope and why before you analyze.
6. 6Check the picture before you model it. Plot scatterplots to spot outliers and spurious correlation, run correlation, then linear regression, using JAMOVI, Excel, R Commander, or Power BI or Tableau dashboards.
7. 7Test the model's predictors against what the organization can act on. In the Maslow example, physiological needs 'explained' 70% of productivity variance, but the real predictors were external to the organization. Ask: 'Am I actually trying to find a solution to a problem that is actually critical for the organization?'
8. 8Close the loop with action and measurement. Verticalization ends by integrating analytics with action and measurement. Analytics that is not tied to managerial implications, or that uses an invalid measurement tool, is 'worthless' and can be disastrous. Brynjolfsson's four dimensions give a cycle to follow: measurement, experimentation, sharing, replication.

The passages give a Maslow-based productivity case. A company suffers from below-average employee productivity. A researcher applies Maslow's needs hierarchy and finds that physiological needs explain 70% of the variance in productivity. The researcher recommends meeting those needs, and the organization invests heavily to do so. Productivity improves only marginally, because the actual predictors were factors external to the organization. The model was theoretically sound and convincing, but it did not give the organization a workable plan. Applying the steps above would have caught this. Starting from the critical problem would have prompted the question of whether the theory addresses what the organization can change. Testing predictors against actionable levers would have flagged a 70% finding that pointed at things the company could not act on. A second case, the Indian clothing retailer, shows the data side. Inconsistent KPIs across brands made productivity data incomparable. The fix was a multi-year standardization of metrics and collection, a central data warehouse built with IT, and training for HR business partners.

• If KPIs differ across divisions or brands, then standardize definitions and collection before any comparison or modeling.
• If a theory explains a large share of variance but the levers are outside the organization's control, then treat the result as unactionable and look for external or other predictors before spending money.
• If only one powerful person or department wants a particular story told, then check for selective data collection and researcher bias before you report.
• If the problem is not a major, current challenge for the business, then do not start the analysis; People Analytics is meant to start from an existing problem.
• If a result has no linked managerial action or a validated measurement method, then do not circulate it; the passages call such analytics worthless and potentially disastrous.

• Theory-first analysis: a convincing conceptual model that does not yield a workable plan. The tell is a recommendation the organization funds and productivity barely moves.
• Non-comparable metrics: KPIs are defined differently per division. The tell is merged data that cannot be compared.
• Report-only analysts: analysts produce reports that are seldom used for action. The tell is analysts who say they are not treated as strategic partners.
• Selective or biased data collection that backs a powerful person's narrative. The tell is findings that never conflict with leadership's prior view and a collection method nobody can audit.
• Treating it as an HR-only project: other stakeholders are not engaged, and the HR partners doubt top-management support. The tell is half-hearted adoption and unused analytics platforms.

• ▸Critical business problem: write one sentence naming the productivity problem and why it matters now.
• ▸Stakeholders and owner: list the departments with a stake and one accountable sponsor for each.
• ▸Productivity metrics: list each measure (revenue per employee, performance rating, project completion) with its single agreed definition.
• ▸Data sources and consistency check: note where each metric is recorded, by which division, and whether the recording rules match.
• ▸Sample and scope: state the population, how the sample is drawn, and how it ties to the objective.
• ▸Method and checks: record the technique (correlation, regression), the outlier and spurious-correlation checks run, and the tool used.
• ▸Predictor actionability: for each predictor found, mark whether the organization can act on it (internal) or not (external).
• ▸Linked action and measure: state the managerial decision this finding supports and the metric that will show the effect.
• ▸Bias and discomfort check: note who might dislike the result and whether data collection was selective.

1. 1Fix the question before the tool. The source's first verticalization step is task-specific knowledge: state exactly what analysis is needed to know the level of employee satisfaction. Write one sentence naming the outcome (job satisfaction, work engagement, turnover intention or well-being) and the decision it will inform.
2. 2Treat the construct as survey data and plan for its messiness. The source lists job satisfaction and turnover intention as survey data that overlap with performance, productivity and customer satisfaction scores. Identify which sheets hold each, and name one owner for collating them, because gathering and collating people data is the main hurdle.
3. 3Collapse item responses to one comparable score per employee or group. In Power BI the source's step is converting the summated job satisfaction value to an average value (Figure 5.21). Use the average, not the sum, so groups of different sizes can be compared.
4. 4Join satisfaction to the levers you suspect. Use Power Query to append sheets with the same structure and merge sheets on an employee key. The source's example merges an Employee Productivity sheet in. Expand only the columns you need, then check row counts after the merge.
5. 5Plot before you model. Draw a scatter plot of satisfaction against each candidate lever and look for outliers, since the source shows the same plot with and without an outlier. Then run a correlation, and treat a strong correlation as unconfirmed until you have ruled out a spurious one.
6. 6Model satisfaction as the dependent variable. Use linear regression (JAMOVI or the Excel Analysis ToolPak) for one or a few levers. Use one-way ANOVA to compare satisfaction across groups. Use CART or ensemble methods when the relationships are not linear, since the source names decision trees as a comprehensible model.
7. 7If the survey has many items, reduce them first. Use factor analysis or PCA, with a scree plot to choose the number of factors, to see whether the items form distinct constructs such as satisfaction and engagement. Use k-means cluster analysis to find employee segments.
8. 8Show it and link it to action. Put the average on a tachometer gauge, with the gauge angles, start and end values, sector ranges and needle set by you. Add a Key Influencer or Decomposition Tree visual to show what drives the score. Close the loop with the source's final step, integrating with action and measurement: analytics not linked to managerial implications is worthless.

The source's Power BI sequence for job satisfaction runs as follows. Start with a survey sheet of job satisfaction responses and an Employee Productivity sheet. In Power Query, append or merge the sheets so each employee row carries both satisfaction and productivity. Load the table and add a Tachometer visual from AppSource. The raw field arrives as a summated value, so convert it to an average (Figure 5.21). The first gauge is unformatted, so set the gauge axis angles and the start and end values to the endpoints of your survey scale, then define the ranges for each sector and style the needle. Add a slicer so the same gauge can be read by department or location. Then build a Key Influencer visual on the merged data to see which fields move satisfaction. The source supplies no result figures for this walk-through, so the numbers come from your own data.

• If your question is only 'what is the current level?', use an averaged gauge or card with slicers. If it is 'what drives it?', move to correlation, regression, a Key Influencer visual or CART.
• If a scatter plot shows an outlier, then run the correlation with and without it and report both. The source shows the same plot both ways because one point can change the relationship.
• If the survey has many items, then run factor analysis or PCA and check the scree plot before averaging, to confirm the items measure one thing.
• If you are comparing satisfaction across more than two groups, then use one-way ANOVA instead of repeated pairwise comparisons.
• If a finding cannot be tied to an owner and a managerial action, then do not publish it. The source warns that unlinked analytics can be disastrous if recommendations are not accepted.

• Reporting only a descriptive dashboard. The tell: you have an average score and slicers but no driver analysis. Deloitte's 2013 survey of 435 organizations found 56% did only basic operational reporting and 30% scorecards and dashboards, so this is the common stopping point.
• Summing instead of averaging item scores. The tell: groups with more respondents or more items look more satisfied, and the gauge needle exceeds the scale.
• Mistaking correlation for cause. The tell: a satisfaction-versus-lever relationship that disappears in a scatter plot without an outlier, or that has no plausible mechanism. The source includes a spurious correlation dataset for this reason.
• Merging sheets without checking keys. The tell: after the Power Query merge the row count is off, or productivity values are null for many employees.
• Building the model with no measurement or action step. The tell: nobody can say what decision changes if satisfaction moves, so recommendations are not accepted.

• ▸Outcome definition: name the exact construct (job satisfaction, work engagement, turnover intention or well-being) and how the survey measures it.
• ▸Decision it informs: one sentence on the action that changes depending on the result.
• ▸Data sources and owner: list each sheet (survey, performance, productivity, attendance, feedback) and who collates it.
• ▸Join key and merge check: the employee identifier used, and the row count before and after merging.
• ▸Score construction: how items become one average per employee or group, and whether factor analysis or PCA was run.
• ▸Candidate levers: the variables you expect to move satisfaction, as listed by you.
• ▸Method chosen: correlation, regression, ANOVA, CART or clustering, and why it fits the question.
• ▸Outlier and spurious-link check: what the scatter plots showed, with and without outliers.
• ▸Visual and action owner: the gauge or driver visual used, the person who acts on it, and when it will be re-measured.

1. 1Start from the problem the selection process has to solve, such as high attrition at certain outlets. Culina-King began with attrition at several outlets, not with a tool. Write the outcome in one line (retention, sales, promotion, customer satisfaction) before you pick any method.
2. 2Audit the current test for validity. Culina-King's pen-and-paper test was built in-house and never validated against acceptable performance measures. Ask whether anyone has tied test scores to later performance. If not, treat the test as unproven.
3. 3Choose a classification approach that predicts the outcome you named, such as stayers versus leavers, and sorts candidates into bands. Culina-King used a classification algorithm that split test takers into Green (top scorers), Yellow (moderate performers) and Red (low performers).
4. 4Record post-hire performance for a fixed window. Culina-King monitored the selected crew for two quarters. Pick the window before you hire, and record the same metrics for every hire.
5. 5Correlate selection scores with the post-hire data. Culina-King tested whether high scorers delivered returns on the cost of selecting them. Compare results by score band and by outlet, not just overall.
6. 6Read the yield signals across several measures: sales by outlet, promotions within the window, and customer satisfaction scores. Culina-King saw outlets that hired only Green holders post a significant sales rise, with most of those hires promoted within two quarters.
7. 7Check usability before you scale. The source warns that a data recommendation, such as hiring 500 people, means nothing if a small organization cannot act on it. Keep only the variables that most affect the outcome (parsimony), and confirm the hiring team can run the rule.
8. 8Close the loop. Feed the post-hire results back into the selection model and recheck it periodically. The source describes analytics work as a loop of fresh learning, not a one-time plan.

Culina-King Restaurants, the West and South India franchise of a global food and beverage company, faced heavy attrition at several outlets. Its selection test was an in-house pen-and-paper exam that had never been validated against performance. The HR team replaced it with a specialized assessment tool whose classification algorithm predicted new-hire potential and flagged likely 'stayers' versus 'leavers'. Test takers were sorted into Green (top scorers), Yellow (moderate) and Red (low). The team then tracked the selected crew for two quarters and correlated performance with test scores. Outlets that recruited only Green holders saw a significant rise in sales, most of those hires were promoted within the two quarters, and customer satisfaction scores rose across the majority of outlets. In 2017 the franchise won the 'Best Place to Work' award from the Great Place to Work Institute. The lesson: validate selection against post-hire outcomes before you trust it.

• If your selection test has never been checked against performance data, treat it as unvalidated and run a score-versus-performance correlation before expanding its use.
• If the problem is attrition, build the model to separate likely stayers from likely leavers, not just to rank general ability.
• If top-band hires outperform other bands on sales, promotion and satisfaction, restrict hiring to that band where the labor pool allows; if the gap is small, do not tighten cutoffs.
• If a model recommendation exceeds what the organization can resource (the source's example is a recommendation to recruit 500 people), scale it down to a feasible version before presenting it.
• If a variable adds little to predicting the outcome, drop it to keep the model simple and usable.

• Selecting on an unvalidated in-house test. The tell: nobody can show a link between test scores and later performance.
• Measuring only the hiring step and stopping there. The tell: you report pass rates but have no post-hire performance, promotion or retention data.
• Judging performance on one metric. The tell: sales are up but you have not checked customer satisfaction or promotions, so you cannot tell real quality from a narrow gain.
• Building an elaborate model nobody can act on. The tell: the report recommends actions beyond the organization's resources, or lists many variables with little effect on the outcome.
• Treating the model as finished. The tell: the cutoffs and bands have not been rechecked against new cohorts since launch.

• ▸Target outcome: state the one business problem this selection process must fix (e.g., attrition at named outlets).
• ▸Current selection method: describe the test or process and note whether it has been validated against performance (yes/no).
• ▸Predictive classification: list the bands or categories used (e.g., Green/Yellow/Red) and the cutoff for each.
• ▸Tracking window: set the number of quarters you will monitor new hires, fixed before hiring starts.
• ▸Post-hire metrics: list the measures recorded for every hire (sales, promotion, customer satisfaction, retention).
• ▸Score-to-performance result: record the correlation or comparison by band and by outlet.
• ▸Retention comparison: note stayer versus leaver outcomes for each band.
• ▸Feasibility check: confirm the hiring volume and resources the recommendation requires and whether you have them.
• ▸Next review: set the date and the changes to bands or variables to test.

1. 1Write the objective as one sentence before any collection. The passages define quality relative to the objective, so every later choice (respondent, timing, scale, variable) is tested against that sentence.
2. 2Name the right respondent or source. For a turnover study, the passages say to collect from employees serving their notice period, during that company's exit interviews. Write down who qualifies and who does not.
3. 3Define the circumstances and timing. Record the setting (for example, exit interview) and the moment of collection, since 'right circumstances, right time' is part of the definition. Reject records gathered outside that setting.
4. 4Fix the parameters and scale for each measure before fielding. Specify the unit and response scale. Use established multi-item scales where they exist; the passages give value-in-use as one with a set number of items per dimension (3 social, 4 emotional, 3 quality, 3 monetary).
5. 5Audit the questionnaire for completeness. List every variable the planned analysis needs (outcome, predictors, any moderators or controls) and check each has a question. A missing variable cannot be added after collection.
6. 6Check rigor of collection. Document how data was captured and processed: the same procedure for every respondent, with the same instrument and a recorded date.
7. 7Carve the sample out of the population using the objective. Do not treat a normal-looking distribution as proof of representativeness.
8. 8Only then check volume against the technique. Multi-level modeling needs at least 50 per level; structural equation modeling needs ten times the number of items or 200, whichever is more. Add data only if the quality conditions above still hold.

The passages' own case: an HR team wants the factors behind turnover in its company, and the first results disappoint. The tempting move is to gather more data. The passages warn that more quantity helps only if quality is kept, and that analysts who rely on 'more data' and a normal distribution assume a representative sample. The corrective is to restate the objective (explain turnover), then check the three tests: right respondents (people serving notice, not stayers or a random employee pool), right circumstances (their exit interviews at that company), right time (during the notice period). Next, confirm the questionnaire includes every variable the analysis needs and uses correct scales. If the collected data fails any test, re-collect it correctly rather than add more of the same. If the chosen technique then needs a minimum sample (for example 200 for SEM or 10 times the items), confirm volume last.

• If results disappoint, then audit respondent, circumstances, timing, scale and variables before collecting more data; extra data helps only when quality is maintained.
• If the objective is turnover, then source data from those serving notice during their company's exit interviews, not from a general employee survey.
• If a variable needed for the analysis has no question in the instrument, then fix the instrument before fielding; do not plan to analyze around the gap.
• If data passes the quality checks but the sample is small, then compare it to the technique's minimum (50 per level for multi-level; 10x items or 200 for SEM) before running the analysis.
• If a normal distribution is your only evidence of representativeness, then treat the sample as unproven and re-check how it was drawn against the objective.

• Collecting more data when results miss expectations. The tell: sample size grows while the sourcing method stays unchanged.
• Surveying convenient respondents instead of the right ones. The tell: respondents could not have direct experience of the phenomenon, such as stayers answering a turnover question.
• Wrong timing or setting. The tell: data was gathered outside the relevant moment, such as long after exit rather than during the notice period.
• Questionnaire omits a required variable or uses an inappropriate scale. The tell: the analysis plan lists a variable with no matching item, or units differ across items.
• Treating normality as representativeness. The tell: the sample is declared valid because its distribution looks normal, with no link back to the study objective.

• ▸Objective statement: write the single sentence the data must answer.
• ▸Target respondent/source: who qualifies and who is excluded.
• ▸Required circumstances: the setting of collection (e.g., exit interview).
• ▸Required timing: the point in the employee or process timeline for collection.
• ▸Variables required by the analysis: list outcome, predictors, controls, and the item that measures each.
• ▸Scales and parameters: unit, response scale and source of each measure.
• ▸Collection procedure and rigor notes: how data is captured, by whom, and whether it is the same for all respondents.
• ▸Technique and minimum sample: the method chosen, its minimum (e.g., 50 per level, 10x items or 200), and the planned n.
• ▸Pass/fail and fix: mark each field met or not, and state the correction for any failure.

1. 1Audit access before buying anything. List the tools the organization already licenses (the passages name Excel, Power BI, Tableau, R, JAMOVI, Rattle) and ask each HR business partner whether they know they have access. In the clothing-retailer case, most HR partners did not know Tableau and R were available to them.
2. 2Standardize the data before choosing a tool. Define each KPI once, fix how it is recorded, and align definitions across divisions. The retailer's brand divisions used metrics that were out of sync and could not be compared once merged.
3. 3Fix the plumbing. Work with IT to build a centralized data warehouse and management information system so data storage and retrieval are quick and efficient. The retailer treated this as a multi-year effort, not a quick fix.
4. 4Match the tool to the analytic level. Use Excel for dashboards and name ranges, Power BI or Tableau for shared visualization, and JAMOVI, R or Rattle for statistical and machine-learning work (regression, ANOVA, logistic regression, neural networks, CART, factor and cluster analysis). Start at the lowest level that answers the question.
5. 5Train for specific skills, not general awareness. The retailer's structured program targeted building queries, generating and integrating dashboards, and understanding basic predictive analytics techniques and data interpretation.
6. 6Give analysts room to generate insight. Move them beyond producing reports that nobody uses. Make the output an actionable recommendation, not just a data-driven report.
7. 7Visibly secure managerial support. HR partners who doubt top-management backing do not embrace the tools wholeheartedly, so make the sponsorship explicit.
8. 8Run real-time feedback loops on the outputs. The Kyklosys case used live client feedback in descriptive analytics and data visualization to modify its modules, and you can do the same by revising dashboards against user reactions.

A leading Indian clothing retailer set out to build an analytics-driven culture among HR business partners across its brands. Its new internal Workforce Analytics team diagnosed four blockers. Data was recorded inconsistently, and KPIs were not in sync across brand divisions, so merged data was hard to compare. Most HR partners did not know they had access to Tableau and R. Partners doubted that top management would support them. Analysts were not treated as strategic partners, and their reports were seldom used. The HR department ran a multi-year project to standardize metrics and data collection. IT helped build centralized data warehouses and management information systems. A structured training program then taught HR partners to build queries, generate and integrate dashboards, and understand basic predictive techniques and data interpretation. The sequence is the lesson: standardize data, build infrastructure, then train on the tools.

• If HR partners do not know which tools they already have, then run an access and awareness audit before purchasing any new platform.
• If KPIs differ across divisions and merged data does not compare, then standardize definitions and collection before building any dashboard.
• If the question is descriptive (what is happening), then use Excel, Power BI or Tableau; if it asks about relationships, group differences, or prediction, then move to JAMOVI, R or Rattle methods.
• If analysts only produce reports that go unused, then redefine their role around recommendations and secure explicit management sponsorship.
• If users react to a dashboard or module, then feed that feedback back into redesign rather than freezing the first version.

• Buying or deploying tools before standardizing data. The tell: merged numbers from different divisions do not reconcile.
• Assuming licensed tools are in use. The tell: HR partners are surprised to learn Tableau or R is available to them.
• Treating analysts as report factories. The tell: reports are generated but rarely used for decisions, and analysts say they are not strategic partners.
• Providing awareness training without hands-on skills. The tell: staff can name the tools but cannot build a query, integrate a dashboard, or interpret output.
• Launching without visible top-management backing. The tell: HR partners are skeptical and adopt the tools only half-heartedly.

• ▸Tools licensed: list each tool (Excel, Power BI, Tableau, JAMOVI, R, Rattle) the organization can already access.
• ▸Awareness check: for each tool, record how many HR partners know they have access.
• ▸KPI standardization status: for each key metric, note whether the definition and recording method are identical across divisions.
• ▸Data infrastructure: record whether a centralized warehouse or MIS exists and who in IT owns it.
• ▸Tool-to-question match: for each priority HR question, name the analytic level (descriptive, relationship, prediction) and the tool assigned.
• ▸Skill gaps: note who can build queries, generate and integrate dashboards, and interpret basic predictive output.
• ▸Management sponsor: name the executive backing the effort and how that backing is communicated.
• ▸Analyst role: state whether analysts deliver recommendations or only reports, and cite one decision a report informed.
• ▸Feedback loop: describe how user reactions to dashboards are collected and acted on.

1. 1List every recurring people-data output you produce today (reports, dashboards, models, forecasts). Write one line per output. You cannot place the organization on the ladder until you know what it actually produces.
2. 2Sort each output by the question it answers, using the source's Figure 1.2 ladder. Basic reporting, data visualization and descriptive statistics describe what happened (Level 1, descriptive). Data mining, exponential smoothing and predictive modeling estimate what will happen (Level 2, predictive). Simulation, optimization and decision analysis recommend what to do (Level 3, prescriptive).
3. 3Test the descriptive level for reactivity. The source calls it reactive: it tells you if something is going wrong at present and has little scope for predicting patterns or trends. If your dashboards only flag problems after they occur, you are at Level 1 regardless of how polished they look.
4. 4Record any drill-down work separately. The source's Kyklosys vignette shows it: a usage dashboard showed middle-level managers spending four to five hours on one role-play module, and analysts then drilled deep to find the module gave participants a sense of leadership. The source still labels this descriptive. Track it as the upper edge of Level 1 and as the bridge to prediction.
5. 5Claim Level 2 only when you use historical data to find hidden patterns or relationships and forecast a future outcome. The source's HR examples are future employee attrition, which recruitment or training process beats the alternatives, and customized succession planning. Name the outcome and the historical data feeding it.
6. 6Claim Level 3 only when the analysis prescribes a specific solution to a specific need, such as the source's price markdown model that generates discounts to maximize revenue on unsold stock. Expect to fail this test. The source states most firms do not use analytics to prescribe strategy, and that this level requires maturity most firms lack.
7. 7For every output at every level, check the link to action and measurement. The source warns that analytics not tied to managerial implications, or built on an invalid measurement method, is worthless and may be disastrous if recommendations are rejected. Write down who acts on the output and how you will measure the result.
8. 8Set the next-level target as one move up, not two. Choose a single descriptive output to extend into a predictive one, and name the technique from Figure 1.2 (for example exponential smoothing or predictive modeling) that closes the gap.

Kyklosys, a Bengaluru gamification-training start-up with over 40,000 users, receives about five terabytes of user-generated gaming data daily. Its designers read usage dashboards and saw that most middle-level manager clients spent four to five hours on one role-play exercise, far more than expected. That is a descriptive output: a dashboard showing what happened. The analysts then drilled into the module and found it gave participants a sense of leadership. Designers acted by building specific leadership-skill situations into most similar exercises, and the popularity of all modules rose. Placement: Level 1, descriptive, at its most active (the source itself labels it descriptive analytics and data visualization). It is closed-loop, since a finding led to a design change. Nothing in the vignette forecasts future behavior or recommends an optimal design, so it has not reached Level 2 or 3. The next step up would be to use the historical usage data to predict which modules will hold managers' attention.

• If your outputs only report what happened or flag current problems, then place the organization at Level 1 and do not describe it as predictive.
• If you can state a future outcome (such as attrition) and name the historical data used to forecast it, then place that use case at Level 2.
• If a model does not recommend a specific action for a specific need, such as a price markdown that maximizes revenue, then it is not Level 3 however complex the math.
• If an output has no named owner and no measure of the result, then fix that before advancing a level, because the source calls unlinked analytics worthless.
• If you are tempted to claim Level 3 across the organization, then check it against the source's observation that most firms lack the maturity for prescriptive work. Claim it per use case, with evidence.

• Equating tool sophistication with maturity: buying dashboard or modeling software and calling the firm predictive. The tell is that outputs still answer only 'what happened'.
• Calling descriptive work predictive because a dashboard has trend lines. The tell is that no future outcome is named and no historical-pattern model sits behind it.
• Skipping the drill-down. Teams read the dashboard but never ask why, as Kyklosys did with the 4-5 hour module. The tell is that findings stop at the metric and no design or policy change follows.
• Claiming prescriptive maturity without a prescribed action. The tell is that the output offers insight but no specific recommendation tied to a client or business need.
• Building models with no link to managerial action or valid measurement. The tell is recommendations that are ignored or rejected, or a measurement method nobody can defend.

• ▸Output name: the report, dashboard, model or forecast being placed.
• ▸Question answered: what happened / why it happened / what will happen / what to do.
• ▸Technique used: match to Figure 1.2 (basic reporting, data visualization, descriptive statistics, data mining, exponential smoothing, predictive modeling, simulation, optimization).
• ▸Level assigned: descriptive (1), predictive (2) or prescriptive (3). Note any drill-down as 'upper descriptive'.
• ▸Evidence for the level: the future outcome predicted, or the specific action prescribed. Write 'none' if absent.
• ▸Decision owner and action taken: who used the output and what changed (as the Kyklosys design change did).
• ▸Measurement of result: how you will judge whether the action worked.
• ▸Next-level move: one specific step to move this output up one level.
• ▸Review date: when you will re-place this output.

1. 1Diagnose the barriers before you launch anything. The Indian clothing retailer's Workforce Analytics team found four: inconsistent processes and data recording, little awareness of the analytics tools people already had (Tableau, R), a perceived lack of managerial support, and analysts not recognized as strategic business partners. List the equivalents in your own organization, with evidence for each.
2. 2Secure visible top-management conviction first. The retailer case shows a radical shift in conventional decision-making needs that support. Get a named executive to state that decisions in scope will be backed by data, so skeptics stop waiting to see whether support is real.
3. 3Standardize metrics and data collection across units. In the case, KPIs differed by brand division and could not be compared when merged. Fix one definition per metric, one recording rule, and one owner. Budget for this to take years, as it did at the retailer, where it was a multiple-year project.
4. 4Bring IT in to build the plumbing. The retailer's IT department developed centralized data warehouses and management information systems for fast storage and retrieval. Without a single source, standardized definitions have nowhere to live.
5. 5Tell people what tools they already have, then train them. The retailer gave HR business partners a structured program covering building queries, generating and integrating dashboards, and basic predictive techniques and data interpretation. Teach by role, not as a general lecture.
6. 6Appoint Analytics Champions. Identify analytics-savvy employees and promote them formally to the title. Their job is to pass their experience and belief to newly initiated employees, which breaks down apprehension across departments and ranks.
7. 7Recognize analysts as strategic business partners. Put them in decision forums, so their output is used for actionable insight instead of sitting unused.
8. 8Review the culture against the factors the chapter lists: right people on a dedicated analytics team, stakeholders engaged, business needs identified, and the right statistical technique chosen. Fix whichever is missing.

A leading Indian clothing retailer set out to build an analytics-driven culture among HR business partners across its brands. Its internal Workforce Analytics team found four problems: KPIs were measured differently across brand divisions and could not be compared when merged; most HR partners did not know they had access to Tableau and R; many doubted that top management would support them; and analysts were not seen as strategic partners. HR responded with a multiple-year project to standardize metrics and data collection, and IT built centralized data warehouses and management information systems. The firm ran a structured training program covering queries, dashboards, basic predictive techniques and data interpretation. It then named a core group of analytics-savvy employees as 'Analytics Champions' to carry the philosophy to newer staff. The passage says this broke down apprehensions across departments and ranks, and it concludes that the case shows the conviction top management must have to change conventional decision-making.

• If the same KPI is calculated differently across units, then standardize definitions and collection before training anyone or buying dashboards.
• If staff are skeptical about management support, then get visible executive backing first; the retailer's HR partners held back until they believed it.
• If people have tools they do not use, then check awareness and skills before buying more software.
• If resistance sits across departments and ranks, then use peer Analytics Champions rather than top-down mandates.
• If analysts' outputs are produced but not acted on, then fix their standing as strategic partners before adding more analysis.

• Declaring a culture shift without standardizing data. The tell: merged reports from different divisions do not reconcile and arguments turn into disputes about numbers.
• Treating tools as the solution. The tell: licenses exist (Tableau, R) but business partners do not know they have access and never open them.
• Leadership endorsement that stays quiet. The tell: staff are privately skeptical about support and adopt analytics only halfheartedly.
• Analysts kept as back-office report producers. The tell: analyses are rarely used for actionable insight and analysts are not invited to strategy discussions.
• Expecting a quick win. The tell: the standardization project is cut or declared complete after a short time, though the retailer's took years.

• ▸Metric consistency: List each key KPI and whether every unit defines and records it the same way (yes/no, with the difference).
• ▸Data infrastructure: Name the central warehouse or information system holding the data, and its gaps.
• ▸Tool awareness: List the analytics tools available and the share of target staff who know they have access.
• ▸Skills gap: Name the skills needed (queries, dashboards, basic predictive techniques, interpretation) and who lacks each.
• ▸Top-management signal: Record the named executive, the specific commitment made, and where staff have seen it.
• ▸Analytics Champions: List the identified champions, their units, and their remit for sharing practice.
• ▸Analyst standing: State which decisions analysts currently inform and which forums they sit in.
• ▸Barrier log: Record each barrier observed, the evidence, and the owner of the fix.
• ▸Review date: Set the date and the evidence that will show decisions are shifting from intuition to data.

1. 1Write the sponsor's business case from the source's own claims, not from enthusiasm. The passages say analytics is the top technological priority for top management, that investing in analytics skills returns around USD 10 per USD invested, and that the analytics industry was growing above 10% by 2011. IBM assigned 4,000 people to its analytics consultancy. Use these as external anchors, and mark each one as an outside benchmark rather than your own forecast.
2. 2Name one specific decision the sponsor will stop making by instinct and start making on evidence. The foreword frames the field as the move from instinct-driven to evidence-based decision-making. Write it as: 'Today [decision] is made by [habit]; after the pilot it is made by [data view].' Vague aims like 'be more data-driven' fail this step.
3. 3Fund the work to be run for execution, not for the ideal plan. Analytics projects carry high uncertainty, the models or technology may be new, and responsiveness has to be balanced against robustness. Approve a short iterative cycle with permission to change course. Do not approve a fixed up-front specification.
4. 4Define 'value in use' before funding. The source says an analytic model's value can be ascertained only by the extent to which it is applied. Agree the application metric first (who uses the output, for which decision, how often). Then pick the value dimensions to track: social, emotional, quality, monetary. The source's monetary item is 'Buying this XYZ has provided economic value'.
5. 5Secure the data flow that feeds the decision. In the Kyklosys vignette the raw material was usage data of about five terabytes a day, surfaced on dashboards. Make the sponsor responsible for access and for the visualization/descriptive-analytics layer. Without those, the decision shift has nothing to run on.
6. 6Commit publicly to acting on findings, including ones that contradict current practice. Kyklosys changed its module design because the data showed managers spending four to five hours on one role-play. Put in writing what the sponsor will change if the data says so, and who executes it.
7. 7Set a standing review loop. The source says fresh learning requires regular changes in the form of a loop. Schedule recurring reviews where the sponsor looks at application evidence and decides to continue, change, or stop. Do not hold a single launch review.
8. 8Invest in analytics skills as a line item. The USD 10-per-USD return in the source is tied to developing analytics skills. Ring-fence budget and time for it, and review it at the same cadence as the project.

Kyklosys, a Bengaluru gamification-training start-up, serves over 40,000 users and receives about five terabytes of gaming data daily. Its analysts used usage dashboards to see that middle-level managers were spending four to five hours on one role-play exercise, far more than expected. Drilling in, they found the exercise gave participants a sense of leadership. Designers then added leadership-skill situations to most similar exercises, and the popularity of all modules rose. The passage does not describe leadership's role, so treat this as the pattern a sponsor must make possible rather than a record of sponsor behavior. A sponsor would (1) name the decision shifting from designer intuition to dashboard evidence, (2) fund the data pipeline and descriptive analytics, (3) accept a redesign the data suggested, and (4) judge success by application: module use and popularity after the change.

• If a sponsor cannot name the decision that will change, then do not start; the effort has no conviction behind it and nothing to measure.
• If the plan demands a fully specified model before any use, then replace it with an iterative, execution-biased cycle, because uncertainty and new technology make 'ideal plan' investments wasteful.
• If the model is built but nobody applies it, then treat its value as unproven or zero; value is ascertained only by extent of application.
• If findings contradict the sponsor's prior practice, then the sponsor changes the practice or states why not; silent reversion ends the shift to evidence-based decisions.
• If budget covers tools but not skills, then add skills funding; the cited return is tied to developing analytics skills.

• Sponsorship as announcement: leadership declares analytics a priority and cites benchmarks, but no resources or decisions change. Tell: no named decision, budget line, or owner exists after the kickoff.
• Planning bias imposed on analytics work: the sponsor demands a locked plan up front. Tell: the team spends months on the 'ideal plan' and cannot adapt when data or tools turn out different.
• Measuring delivery instead of use: success is declared when the dashboard ships. Tell: no one can say how often the output is used or which decision it changed.
• Selective acceptance: sponsors welcome confirming insights and ignore disconfirming ones. Tell: past decisions, such as design choices, stay unchanged even when the data points elsewhere.
• One-off backing: the sponsor reviews once at launch, with no feedback loop. Tell: no scheduled reviews and no record of changes made after learning.

• ▸Decision to shift: one sentence, 'from [instinct/habit] to [evidence view]'.
• ▸Executive sponsor and execution lead: names; the lead carries the execution bias day to day.
• ▸External benchmarks cited: list the claims used (e.g., USD 10 return per USD on analytics skills) and mark them as outside figures.
• ▸Data and tooling committed: sources, dashboard/visualization layer, and who grants access.
• ▸Resources committed: budget, people, and time, including a skills-development line.
• ▸Value-in-use measure: how application is counted, and which dimensions (social, emotional, quality, monetary) are tracked.
• ▸Pre-committed action: what the sponsor will change if the data contradicts current practice.
• ▸Review cadence: dates of recurring reviews and the continue/change/stop rule.
• ▸Evidence of shift: the first observed case where a decision was made differently because of the data.