Build a People Analytics Practice

1. 1Step 1 — Assess business requirements: examine competitors and the external market, interview line managers and executives, survey HR customers, and review corporate and business-unit strategy; categorize identified people needs into buckets (workforce development, labor relations, customer service, compensation/benefits) to form HR strategy.
2. 2Step 2 — Build the inverse tree: place HR's strategic priorities at the top layer (identical across all four Balanced Scorecard perspectives — strategic, operations, customer, financial), then dissect each priority into its factors, break factors into detailed measures, and drive down to the raw-data items at the bottom of the tree.
3. 3Step 3 — Translate raw data into formulas: never leave raw counts 'as is' when relating them to time, population, or expense adds meaning. Convert to Rate ([part/whole]x100), Ratio (one number over another), Composition ([subpart/total]x100), or Index (weighted combination against an anchor).
4. 4Step 4 — Segment every result by workforce dimension: organization structure, demographics, employment levels, function, and employment experience. Segmentation isolates high-impact intervention targets and reveals behavior patterns across populations.
5. 5Step 5 — Score each candidate metric against GM's quality categories: Subjective=0, Quantifiable=1, Results=1, Qualitative=3, Predictive=6; then apply feasibility: Easy=1, Moderately Difficult=-1, Difficult=-2.
6. 6Step 6 — Code each metric's link to objectives as direct (X) or contributory (C), then sum quality ratings plus feasibility into a single Comparative Rating for side-by-side prioritization.
7. 7Step 7 — Assign one team member to define categories and set weights based on each metric type's relative value to the business; circulate to the metrics planning team for feedback before locking the matrix.

Verizon's business objective — 'Position Verizon to become a leading global player in telecommunications' — enters the tree through the strategic perspective as the priority Staffing/Leadership. That priority breaks into factors including Talent Acquisition, Retention, Promotions, and Workforce Diversity. Talent Acquisition breaks into detailed measures Extended Offers, Accepted Offers, and New Recruit Yield; Retention breaks into Hourly Short-Term Terminations and Salaried Short-Term Terminations. These bottom-level items are the raw data. In Step 3, raw termination counts become a Turnover Rate — [Terminations / Average Headcount] x 100 — and offer counts become an Applicant Ratio (Applicants / Offers Accepted) or Average Time-to-Fill (Total Days to Fill / Offers Accepted). Each rate is then segmented (e.g., hourly vs. salaried, per the raw-data split) to show where turnover concentrates.

• If a candidate metric will 'raise the red flag' before performance deteriorates and enables forecasting of financial impact, then classify it as Predictive (score 6) and prioritize it — GM values predictive metrics considerably more than any other type.
• If a metric cannot be communicated as a number (e.g., employee morale stated in subjective terms), then it scores 0 and should be reworked into a quantifiable form before it earns a place in the matrix.
• If a metric requires data that may not currently exist (Difficult to Measure, -2), then weigh its quality score against the collection cost; a high comparative rating like Skills Gap (9) can still justify building the data.
• If raw data is being reported as a bare count, then convert it into a rate, ratio, composition, or index by relating it to time, population, or expense to yield insight.
• If two metrics tie on comparative rating, then favor the one coded as a direct measure (X) of the objective over a contributory measure (C).

• Selecting metrics that are easy to collect but not aligned to strategy — the tell: metrics that never trace back up the inverse tree to a corporate business objective.
• Reporting raw counts (e.g., number of terminations) without expressing them against headcount or time — the tell: numbers that can't be compared across units or periods because they lack a denominator.
• Failing to segment results by workforce dimension — the tell: an org-wide average that hides where the real problem sits and offers no high-impact intervention target.
• Loading the scorecard with quantifiable-but-lagging metrics and no predictive ones — the tell: HR only reports problems after financial performance has already dropped.
• Letting a metric that scores well on quality slip through despite prohibitive feasibility — the tell: a metric appears on the dashboard but the supporting data is never actually available to populate it.

• ▸Candidate Metric — name the specific measure being evaluated
• ▸Objective Link (X/C) — code as direct measure (X) or contributory measure (C) per objective
• ▸Quality Rating — assign: Subjective 0 / Quantifiable 1 / Results 1 / Qualitative 3 / Predictive 6
• ▸Feasibility Rating — assign: Easy 1 / Moderately Difficult -1 / Difficult -2
• ▸Comparative Rating — sum quality total + feasibility into one comparison number
• ▸Formula Type — specify Rate, Ratio, Composition, or Index and write the exact formula
• ▸Segmentation Dimension — note how results will be split (org structure, demographics, employment level, function, experience)
• ▸Owner & Weight — record the team member assigning ratings and any weight applied for relative business value

1. 1Build two core ratios: Market-Ratio (an employee's actual pay divided by the market pay rate for that role) and Compa-Ratio (an employee's actual pay divided by the pay-range midpoint). Both signal whether pay sits above, at, or below reference.
2. 2Gather clean source data before computing anything. Confirm current salaries, pay-range midpoints, and market benchmark rates are captured in your HRIS (SAP, Peoplesoft); where a field is missing, work with IT/HRIS to create it rather than estimating.
3. 3Run a Compa-Ratio for every employee, then sort by role, level, and pay range to spot clusters below 0.90 (underpaid, flight risk) and above 1.10 (over range).
4. 4Add a Flight Risk Formula alongside compa-ratio to connect pay position to retention: low compa-ratio plus high performance rating is your highest-priority correction group.
5. 5Test pay-equity hypotheses using correlation and regression in Excel's Data Analysis toolpack: regress salary against role/level while including gender or ethnicity as a categorical variable to see if a protected characteristic explains pay after controlling for legitimate factors.
6. 6Cross-check any adjustment logic against employment-discrimination case law: pay criteria must relate to job performance (Griggs v. Duke Power) and any consideration of sex as a promotion/pay factor must be moderate, flexible, and case-by-case (Johnson v. Transportation Agency).
7. 7Tie compensation competitiveness to the Voluntary Turnover Rate metric (Permanent Resignations / Permanent Headcount); a rising rate points to salary uncompetitiveness among other causes.
8. 8In unionized environments, engage the union early, show that analytics produces more equitable pay regardless of gender or ethnicity, and provide clear justification for how employee pay data is used.

Take an employee earning $54,000 in a role whose pay-range midpoint is $60,000 and whose market rate is $58,000. Compa-Ratio = 54,000 / 60,000 = 0.90, and Market-Ratio = 54,000 / 58,000 = 0.93 — both flag the employee as paid below reference. Now pull their Retention data: they sit in the top quartile of performers, so they contribute to the Total Top Quartile Performer Resignation Rate risk if they leave. You run the Flight Risk Formula and confirm elevated risk driven by pay position. Because losing a top performer degrades company profitability (the depletion ratio logic — lost top talent predicts worse profitability), you prioritize a correction toward the 1.0 compa-ratio. You document that the adjustment is based on performance and market data, not a protected characteristic, keeping it defensible under Griggs.

• If compa-ratio is below 0.90 AND the employee is a top-quartile performer, then prioritize a pay correction before the next voluntary-turnover cycle.
• If a regression shows salary correlates with gender or ethnicity after controlling for role and level, then treat it as a pay-equity red flag and investigate, not a coincidence.
• If a pay or selection criterion does not relate to job performance, then remove it — Griggs v. Duke Power prohibits it regardless of intent.
• If compa-ratio exceeds 1.10 with no offsetting performance or scarcity justification, then freeze increases rather than compound over-range drift.
• If you operate in a unionized company, then engage the union before adjustments and lead with equity and benefit framing, not efficiency alone.

• Comparing pay only to the range midpoint (compa-ratio) and ignoring the external market rate (market-ratio) — the tell is a workforce that looks 'in range' internally while losing candidates and staff to competitors.
• Treating a raw diversity/pay breakdown as equity analysis without regression controls — the tell is claiming 'no pay gap' from averages while never testing gender/ethnicity as a variable against role and level.
• Using selection or pay tests that exclude protected groups without a job-performance link — the tell is a criterion nobody can tie to actual role requirements (the Griggs error).
• Letting managers act on statistical pay-risk scores as certainties — the tell is treating a probability-based flight-risk model as a guaranteed resignation, driving over- or under-reaction.
• Rolling out pay analytics in a unionized company without early union engagement — the tell is grievances or resistance appearing only after adjustment decisions are announced.

• ▸Employee/Role ID — one row per employee to enable sorting by role and level.
• ▸Actual base salary — current pay pulled from HRIS.
• ▸Pay-range midpoint — reference point for compa-ratio.
• ▸Market rate — external benchmark for the role.
• ▸Compa-Ratio — actual salary / midpoint; flag <0.90 or >1.10.
• ▸Market-Ratio — actual salary / market rate; flag below 1.0.
• ▸Performance quartile — top-quartile flags priority for correction.
• ▸Flight-risk / voluntary-turnover indicator — low compa-ratio + high performance = highest priority.
• ▸Adjustment justification — job-performance/market rationale documented for legal defensibility.

1. 1Define the outcome you want to predict from personality traits: attrition (stays >6 months), performance rating, or safety. Anchor on a specific business threshold like Xerox's target of recovering training investment before an employee quits.
2. 2Administer a standardized instrument — a 30-minute personality/scenario test (as Xerox does) that scores traits and job scenarios, or capture 'Personality Traits' and 'Skillsets Score' as numeric inputs for regression.
3. 3Convert scores into an actionable band: red for low potential, yellow for medium, green for high. Decide upfront your acceptance rule (Xerox mostly hires greens, accepts some yellows only if trainable).
4. 4Run correlation first to see which traits move with the outcome, then build multiple regression to get coefficients. Use the passage's model form: Performance Rating = -1.014 + 0.099*Social Network Size + 6.674*Social Network Diversity Index + 0.250*Skillsets Score.
5. 5Validate against a trial period before full rollout — Xerox ran a half-year trial that cut attrition 20% before handing all call-center hiring to the algorithm.
6. 6Combine personality with proximate predictors known to matter (commute time, social-network count of 1-4, creative vs inquisitive) rather than relying on prior experience, which the data showed does not predict top performers.
7. 7Recompute coefficients periodically and monitor whether banded scores still separate stayers from leavers, since triggering events and role stagnation also drive attrition.

Xerox previously hired call-center staff with relevant experience, assuming experience predicts retention. An analytics algorithm overturned this: experience did not matter for top performers; personality did. The data showed creative applicants usually stay at least six months while inquisitive ones usually don't, and the ideal worker lives near the job, has reliable transportation, uses one to four social networks, and is not overly inquisitive or empathetic. Applicants take a 30-minute test with forced-choice items like 'I ask more questions than most people do' versus 'People tend to trust what I say,' producing a red/yellow/green score. Xerox mostly hires greens and accepts yellows only when it believes it can train them. After a half-year trial cut attrition by 20 percent, Xerox handed all call-center hiring to the software.

• If an applicant scores green, hire; if yellow, hire only when you assess you can train them; if red, reject.
• If prior job experience is your main screen but data shows it doesn't correlate with retention or performance, replace it with trait scoring.
• If a candidate uses more than four social networks or lives far from the job, downgrade their retention prediction even with good trait scores.
• If the trait is 'creative,' expect ≥6-month tenure; if 'inquisitive,' expect early exit — weight accordingly for roles requiring training payback.
• If a regression coefficient is large and positive (e.g., 6.674 for Diversity Index), prioritize that trait in selection over smaller-coefficient factors.

• Screening on experience instead of personality — the tell: your top performers show no experience pattern yet still outperform, so your filter adds no lift.
• Treating single traits in isolation — the tell: 'inquisitive' looks positive alone but the model shows it predicts early quitting, so context flips the sign.
• Deploying the model to full hiring without a trial — the tell: you can't cite a measured effect like Xerox's 20% attrition cut before rollout.
• Misreading regression coefficients as guarantees rather than expected changes — the tell: you promise a fixed performance number instead of a predicted value like 6.57.
• Ignoring triggering events and role stagnation — the tell: high-trait-scoring employees still leave because they stalled in-role 10+ months, which raises exit odds a statistically significant one point.

• ▸Predicted outcome: state the target (attrition <6mo / performance rating / safety)
• ▸Instrument: name the test and its length (e.g., 30-min forced-choice + scenarios)
• ▸Trait inputs & scores: list each trait with its numeric value (e.g., Skillsets Score = 8)
• ▸Regression equation: paste your fitted formula with intercept and coefficients
• ▸Predicted value: compute the outcome from the equation (show the arithmetic)
• ▸Band: assign red / yellow / green with the score cutoffs
• ▸Acceptance rule: green=hire, yellow=hire if trainable, red=reject
• ▸Context flags: commute distance, social-network count (1-4 ok), creative vs inquisitive
• ▸Validation note: trial period length and measured effect (e.g., attrition cut %)

1. 1Pull the demographic and contextual attributes the passages name explicitly from your HRIS as descriptive fields: tenure ('how long has John been with the company'), marital status, salary market-ratio, performance rating, and traveling time to office. HRIS reports these but cannot find correlations, so treat this as raw input only.
2. 2Reframe each descriptive attribute into a predictive question. 'How long has John been with the company' becomes 'How long will John stay'; 'What is John's marital status, salary market-ratio, traveling time' becomes 'What variables affect John's tenure'. This conversion (Section 6.1) is the pivot from Level 1 descriptive to Level 3 predictive.
3. 3Encode categorical context variables for regression. Follow the book's Multiple Regression Examples 12.2 and 12.3: a categorical variable with 2 values and one with 3 values require dummy-coding before Excel's regression can accept them alongside numerical inputs like tenure and commute time.
4. 4Run a Correlation Matrix (Section 11.2) across all demographic/contextual predictors and the outcome (attrition, tenure, performance) first, to see which variables actually relate before spending modeling effort. Correlation tells you if a relationship exists; regression tells you which variables have the most impact.
5. 5Build the predictive model. For a binary outcome ('will John leave next quarter'), use Logistic Regression (12.4); for a continuous outcome (predicted tenure, sales), use Multiple Regression (12.1-12.3). Enter demographic and contextual attributes as independent variables.
6. 6Structure the context around the ARHAT framework: ask the question, review literature, formulate the hypothesis (e.g. longer commute predicts higher attrition), analyze data, then tell the story.
7. 7Contextualize the quantitative output with qualitative analysis — attitudes, opinions, life experiences — so a regression coefficient on 'commute time' gains explanatory color rather than sitting as a naked number.
8. 8Report using data storytelling (Brent Dykes: data + visuals + narrative), tailoring depth to the audience type — keep it concise for Top Management, give Subject-Matter-Experts something new.

Take John as the passages frame him. Descriptively, HRIS tells you his tenure, marital status, salary market-ratio, performance rating, and traveling time to office. You convert these into the predictive question the book poses: 'What variables affect John's tenure with the company?' You build a correlation matrix in Excel and find traveling time correlates negatively with tenure. You then run a multiple regression with tenure as the dependent variable and marital status (dummy-coded per Example 12.2), salary market-ratio, performance rating, and commute time as independents. The model shows which context variable carries the most impact on how long John stays. To predict the binary 'Which Sales employee is likely to leave next quarter,' you switch to logistic regression (12.4) with the same predictors. Finally you wrap the coefficients in a three-act narrative for management: why they should care, how acting on commute/market-ratio helps, and what to do.

• If the outcome is binary (leave / stay), then use logistic regression (12.4); if the outcome is continuous (predicted tenure, sales), then use multiple regression (12.1-12.3).
• If a demographic attribute is categorical (marital status, department), then dummy-code it before regression per Examples 12.2 (2 values) and 12.3 (3 values); never feed raw text categories in.
• If you only need to know whether a relationship exists between a demographic and an outcome, then run correlation first; only move to regression when you need to know which variable has the most impact.
• If your finding is a bare coefficient, then add qualitative analysis (focus-group quotes, attitudes) to contextualize before presenting — data alone provides no contextual information.
• If presenting to Top Management, then keep it concise and lead with the resolution; if presenting to Subject-Matter-Experts, then give them something new they don't already know.

• Stopping at HRIS output and calling it analytics. The tell: your report answers only 'what happened' (tenure, marital status counts) and never 'what variables affect' — you're stuck at Level 1 descriptive.
• Confusing correlation with causation or impact. The tell: you claim commute time 'drives' attrition from a correlation coefficient without running regression to see which variable actually has the most impact.
• Feeding categorical demographics into regression as raw labels. The tell: Excel returns errors or nonsense coefficients because marital status or department wasn't dummy-coded (see 12.2/12.3).
• Presenting demographic coefficients with no narrative or context. The tell: the audience interprets the same data differently and disengages because you showed data instead of telling a story.
• Applying demographic predictors without regard to legality. The tell: you ignore the court-ruling cases (Griggs v. Duke Power, Johnson v. Transportation Agency) and build a model on protected attributes that creates adverse-impact exposure.

• ▸Descriptive attribute: name the raw HRIS field (e.g. traveling time to office).
• ▸Variable type: numerical or categorical (and number of categories if categorical).
• ▸Encoding action: dummy-code categorical per 12.2/12.3, or leave numerical.
• ▸Predictive question: rewrite the descriptive fact as a 'what affects / how likely' question.
• ▸Outcome variable: the dependent variable (tenure, attrition next quarter, performance).
• ▸Correlation result: positive / negative / zero relationship with outcome.
• ▸Model choice: logistic (binary outcome) or multiple regression (continuous outcome).
• ▸Qualitative context: the attitude/quote that explains this variable's effect.
• ▸Legal check: confirm attribute doesn't create adverse impact (Griggs / Johnson).

1. 1Define your outcome variable precisely before analyzing anything: separate Voluntary Turnover Rate (Permanent Employee Resignations / Permanent Headcount) from involuntary exits, and track Total Top Quartile Performer Resignation Rate (top-quartile resignations / permanent headcount) separately because losing your best people costs more than headline turnover reveals.
2. 2Move up the Analytics Maturity Model rather than stopping at descriptive: don't just report '100 employees resigned' — run diagnostic analysis to learn 'because they were not given overtime pay,' then predictive ('overtime pay improves retention by x%'), then prescriptive ('at least 2 hours of overtime improves retention').
3. 3Assemble leading indicators that precede turnover: Absenteeism Rate (Sick Days / Permanent FTE), Overtime per Individual Contributor Headcount, Labour Cost per FTE, Benefits as Percentage of Labour Costs, and Climate Culture Rating (percent giving top ratings to 'good place to work') — treat rising absenteeism and excessive overtime as early warnings of future turnover.
4. 4Test relationships with correlation before building a model: use Excel's correlation coefficient to check, for example, whether Glassdoor Company Ratings correlate with Company Attrition Rate, then confirm compensation drivers by correlating Labour Cost per FTE against your voluntary turnover.
5. 5Build a flight-risk score with logistic regression in Excel (categorical output: resign / stay), using predictors your diagnostic step surfaced; if Solver throws errors, apply the book's Solver-error fixes rather than abandoning the model.
6. 6Layer in Organizational Network Analysis to catch risks pay data misses: run an ONA survey (NodeXL for visualization) and use ONA graph metrics in a logistic regression to predict employee churn based on how connected — or isolated — a person is in the network.
7. 7Translate the model into retention actions and re-measure: pair prescriptive findings with succession readiness (Readiness Ratio, Succession Planning Rate) so that when a flagged key person leaves you have candidates ready, then track Depletion Ratio (annual percent of lost top talent) as the profitability-linked scorecard.
8. 8Report using the ARHAT framework's 'Tell the Story' step — know the audience, develop a narrative, develop visuals — because executives act on a structured story, not a raw regression table.

A company with 1,000 employees lost 100 of its top talents last year, giving a Depletion Ratio of 0.10, which signals worse predicted profitability because it is losing its best leaders and innovators. To find the cause, you move past the descriptive '100 employees resigned' to diagnostic analysis and discover they resigned because they were not given overtime pay. You confirm the driver by correlating Labour Cost per FTE and Overtime per Individual Contributor Headcount against your Voluntary Turnover Rate, then build a logistic regression in Excel to predict staff resignation. The prescriptive finding lands as 'at least 2 hours of overtime will improve retention,' a specific, testable action. You also check your Succession Planning Rate for the vacated key roles and find a Readiness Ratio of only 0.30 — 30 qualified successors for 100 key jobs — meaning a real gap that predicts higher cost and slower growth during recruitment. You present all of this to executives as a narrative with visuals rather than a table of coefficients.

• If voluntary turnover is rising, then check salary competitiveness, leadership credibility, retention practices, and the external job market before assuming any single cause — the metric description names all four.
• If Absenteeism Rate or Overtime per Individual Contributor Headcount is climbing, then treat it as a leading indicator of future turnover and investigate now, not after resignations spike.
• If Labour Cost per FTE is too low or Benefits as Percentage of Labour Costs is below benchmark, then suspect compensation as a turnover and absenteeism driver.
• If your Depletion Ratio or Top Quartile Performer Resignation Rate is high but overall turnover looks fine, then prioritize regrettable-talent loss over headline numbers.
• If a key role has a low Readiness Ratio, then flight-risk mitigation for its incumbent becomes urgent because you cannot backfill quickly.

• Stopping at descriptive analytics — reporting 'what happened' in a dashboard without asking why — the tell is executives who nod at the number but take no action.
• Tracking only aggregate Voluntary Turnover Rate and missing that your top-quartile performers are the ones leaving — the tell is stable overall turnover alongside a rising Depletion Ratio or declining performance.
• Reading correlation as causation: finding Glassdoor Ratings correlate with attrition and concluding ratings cause exits without diagnostic or regression follow-up — the tell is a single scatterplot presented as proof.
• Building a flight-risk model but ignoring succession, so a predicted departure hits a role with a 0.30 Readiness Ratio and no backfill — the tell is scrambling recruitment after a resignation you already forecasted.
• Producing a technically sound regression but no story — the tell is a slide full of coefficients that no executive can turn into a decision, which the ARHAT 'Tell the Story' step exists to prevent.

• ▸Voluntary Turnover Rate: enter Permanent Employee Resignations / Permanent Headcount.
• ▸Top Quartile Performer Resignation Rate: enter top-quartile resignations / permanent headcount.
• ▸Depletion Ratio: enter top talents lost last year / total employees.
• ▸Leading indicators: log Absenteeism Rate, Overtime per Individual Contributor Headcount, and Climate Culture Rating.
• ▸Diagnostic cause: state the 'because...' reason behind the resignations.
• ▸Correlation check: record the coefficient between your suspected driver (e.g., Labour Cost per FTE) and turnover.
• ▸Flight-risk prediction: note the logistic regression output (resign / stay) per key employee.
• ▸Succession backfill: enter Readiness Ratio and Succession Planning Rate for each at-risk key role.
• ▸Prescriptive action + owner: state the specific intervention (e.g., '2 hours overtime') and who executes it.

1. 1Define your safety outcome as a countable, dated metric: number of workplace accidents, injuries, or safety-related incidents per period per unit (store, plant, team), so it can enter a regression as a dependent variable.
2. 2Pair the safety count with an engagement or driver variable from the same units and periods — the passages treat 'Workplace Accidents' as something you predict from Employee Engagement using Correlation & Regression, so pull engagement scores alongside incident counts.
3. 3Identify and approach the data owners who control incident logs and survey data; expect knowledge-hiding, so line up an influential stakeholder to sponsor access and publicly recognize owners once they deliver in a usable format.
4. 4Convert any categorical safety fields (incident: Yes/No) into dummy variables (1 = presence of an incident, 0 = absence) before running regression; use logistic regression (glm() in R) when the outcome is binary Yes/No rather than a count.
5. 5Run correlation first to size the relationship, then multiple regression to predict incident levels from engagement and any other drivers; in Excel the Regression tool cannot read non-numeric data, so verify all inputs are numeric.
6. 6Engage domain experts to explain surprising results — a month with high incidents may have a context (new hires, process change) the numbers alone hide, mirroring how customer-turnover spikes were sometimes deliberate.
7. 7Trace the business value through the profit chain: quality/safety outcomes correlate .21 with profitability, so quantify improved safety in dollar terms rather than incident counts alone.
8. 8Prep business heads in advance that findings may be inconclusive or merely confirm what was suspected — even confirmation gives you evidence to act on, so manage expectations before presenting.

The passages report that quality/safety outcomes have a positive correlation of .21 with profitability. Turnover relates to profits at -.03, and turnover relates to quality/safety at -.12. To find how much of turnover's profit effect runs through safety, you multiply the two paths: .21 × -.12 = approximately -.025. That -.025 is a large portion of the total -.03 effect of turnover on profits, meaning most of turnover's damage to profitability travels through degraded quality and safety outcomes. So if you are modeling why turnover hurts the bottom line, the safety channel is the dominant mechanism, not a footnote. This tells you that stabilizing headcount protects profit largely by keeping accidents and defects down — the operational lever to watch is the incident rate, not just the resignation rate.

• If the safety outcome is a Yes/No incident flag, then use logistic regression (glm()); if it is a count or rate, then use multiple regression.
• If any predictor is categorical (gender, shift, team), then convert to dummy variables (1/0) before running the model — otherwise the Excel Regression tool will fail.
• If data owners stall or give incomplete files, then escalate to an influential stakeholder rather than re-asking, while keeping the owner relationship intact.
• If the regression only confirms what leaders already suspected, then treat it as evidence to justify action, not a wasted effort.
• If safety improves but you must prove worth, then convert incident reductions into profit using the .21 quality/safety–profitability correlation.

• Feeding alphanumeric incident categories straight into regression — the tell is the Excel Regression tool refusing to run or returning errors on non-numeric data.
• Treating a binary incident outcome with ordinary regression instead of logistic — the tell is predicted values outside 0–1 that make no sense as probabilities.
• Presenting inconclusive or confirmatory results as failures — the tell is stakeholders feeling let down because expectations weren't set in advance.
• Accepting delayed or incorrect data from a knowledge-hiding owner at face value — the tell is a colleague who promises data 'later' and never follows through, then supplies incomplete fields.
• Reporting raw incident counts without translating to business value — the tell is executives nodding but not funding the intervention because the profit link (.21 to profitability) was never shown.

• ▸Outcome metric: name the exact count/flag (e.g. incidents per store per month)
• ▸Outcome type: mark Count or Yes-No (drives regression vs logistic)
• ▸Predictor 1: engagement score per unit, same period as incidents
• ▸Predictor 2+: other driver (shift, tenure, new-hire ratio) — dummy-code if categorical
• ▸Data owner + access sponsor: who holds the log, who can escalate
• ▸Correlation result: coefficient between predictor and safety outcome
• ▸Model output: regression/logistic prediction of incident level
• ▸Profit translation: apply .21 quality/safety-to-profit link to estimate dollar impact
• ▸Expectation note: what you told business heads about possible inconclusive/confirmatory findings

1. 1Assess your data against the DELTA first step: is people data accessible, consistent, and of high quality? Inventory every HR IT system holding people data and flag disparate systems, which multiply redundancy and inconsistency.
2. 2Check whether your systems support time tracking of data. If they do not, you cannot run longitudinal analysis or establish causal relationships between HR variables — prioritise fixing this before attempting predictive work.
3. 3Build toward a single trusted repository by integrating data across systems: consolidate disparate HR IT feeds and remove redundancy and discrepancy, which is the primary purpose of HRIS/IT.
4. 4Apply the enterprise-wide perspective (DELTA step 2): integrate data, analytical applications, and processes throughout the enterprise, including horizontal integration so HR data connects with other functional-area data.
5. 5Secure inter-functional data access through collaboration and interpersonal skills, since difficult-to-access cross-functional data is a named barrier; get HR managers oriented toward data usage.
6. 6Assess data fundamentals for accuracy, completeness, consistency, validity, and accessibility rather than waiting for perfect or larger data — Feinzig's rule is that no dataset is perfect, so confirm fundamentals and move forward.
7. 7Collect the proper data first, then model and predict performance using HR metrics that gauge contribution to business objectives — identify the specific variables (dependent and independent) the model needs before choosing tools.

IBM moved away from relying on managerial surveys as its data source for career development. Management updates employees' skills growth quarterly and highlights areas for future improvement, creating consistent, time-tracked people data. This data is combined with AI skill inference of each employee. The technology Blue Match then uses that integrated data to list all internal job openings suitable for that employee. The case shows the construct in action: rather than depending on incomplete or subjective survey data, IBM sought an alternate, higher-quality data source and integrated skill data with inference to feed a working application. Sheri Feinzig frames the underlying principle — focus on quality of data over size, assess data fundamentals accurately, and then move forward.

• If you run disparate HR IT systems, then expect increased redundancy and inconsistency, and consolidate toward a single repository before building metrics.
• If your systems cannot track data over time, then do not attempt longitudinal analysis or causal claims between HR variables — fix time tracking first.
• If data is incomplete or inaccessible but fundamentals are sound, then proceed anyway — never wait for perfect or larger data (Feinzig).
• If the insight requires inter-functional data, then use collaboration and interpersonal skills to gain access, since that data is difficult to reach.
• If existing HRIS/IT delivers inadequate, incomplete, inaccessible, non-integrated, or outdated data, then treat the system as an inhibitor and remediate integration before scaling analytics.

• Treating survey data as sufficient when better sources exist — the tell is IBM's replacement of managerial surveys with skills updates plus AI inference; if your source is subjective self-report, question it.
• Waiting for perfect or bigger data before starting — the tell is stalled projects; Feinzig's point is that no dataset is perfect and size doesn't matter.
• Leaving disparate systems unintegrated — the tell is data redundancy and inconsistency across HR IT systems that corrupt any downstream metric.
• Attempting causal or longitudinal conclusions on systems that don't track data over time — the tell is confident claims about HR variable relationships with no time dimension in the data.
• Only 39% of business people rate their people data as good or very good — the tell is proceeding as if data quality is solved when most organisations report it isn't.

• ▸System inventory: list every HR IT system holding people data.
• ▸Accessibility: is each data source reachable by the analyst? (yes/no + blocker)
• ▸Consistency: are values consistent across systems, or is there redundancy/discrepancy? (note conflicts)
• ▸Completeness: which required fields are inadequate, incomplete, or outdated?
• ▸Validity: does the data actually measure the intended HR variable? (yes/no + note)
• ▸Time tracking: does the source record data over time to allow longitudinal/causal analysis? (yes/no)
• ▸Integration: is data integrated horizontally with other functional areas and into a single repository? (yes/no)
• ▸Inter-functional access: which cross-functional data is needed and who owns it?
• ▸Go/no-go: are data fundamentals sufficient to proceed per Feinzig's rule? (proceed / remediate first)

1. 1Map your analytic need to the maturity level first: use descriptive/visualization tools (Excel dashboards, Power BI, Tableau) for pattern-spotting, and reserve statistical/ML tools (logistic regression, neural networks, CART, factor/cluster analysis) for predictive and diagnostic questions.
2. 2Standardize metrics and data collection across divisions before layering on any tool—inconsistent KPIs make merged data uncomparable and any dashboard built on top will be untrustworthy.
3. 3Engage IT to build centralized data warehouses and management information systems so storage and retrieval are fast and standardized, rather than letting each business unit hold non-standardized data.
4. 4Audit tool access: confirm which HR partners actually have access to platforms like Tableau and R, since adoption fails when users don't know the tools already exist for them.
5. 5Choose visualization software by task—Excel for name-ranged column arrays and form controls, Power BI and Tableau for interactive dashboards—and train users on building queries, generating dashboards, and integrating them.
6. 6Lean toward cloud storage for gathering data, since 85% of surveyed managers derive patterns using visual analytics tools and increasingly rely on the cloud.
7. 7Build in execution bias over rigid planning: analytics projects carry high uncertainty and the model or technology may be new, so keep the stack flexible enough to adapt as requirements change.
8. 8Judge each tool or model by value in use—an analytic application is only valuable to the extent it is actually applied, so measure adoption, not just capability.

A leading clothing retailer in India built an internal Workforce Analytics team to move its HR business partners toward a data-driven culture across brands. The team found four blockers: non-standardized data with out-of-sync KPIs that couldn't be merged, HR partners unaware they already had access to Tableau and R, perceived lack of top-management support, and analysts confined to report-generation rather than insight. In response, HR launched a multi-year project to standardize metrics and the data collection process, with IT developing centralized data warehouses and MIS for quick storage and retrieval. To drive adoption, the firm ran a structured training program so HR partners became proficient in building queries and generating and integrating dashboards. This sequence—fix the data architecture first, then confirm tool access, then train—shows that the technology stack (Tableau, R, warehouses) only produced value once metrics and skills were aligned around it.

• If the question is 'what happened' or 'show me patterns', then use descriptive/visualization tools (Excel, Power BI, Tableau); if it is 'what will happen' or 'why', then use predictive/statistical/ML methods.
• If data is unstructured and KPIs differ across units, then halt tool rollout and standardize metrics and collection first—merging inconsistent data invalidates comparison.
• If HR partners don't know they have access to Tableau or R, then adoption, not procurement, is your bottleneck—fix awareness and training before buying more tools.
• If the analytics model or technology to be used is unknown or new, then favor execution bias and flexibility over a fixed plan, because uncertainty demands quick adaptation.
• If an analytic application isn't being used, then treat its value as unrealized—value in use is measured by the extent it is applied, not by its technical sophistication.

• Deploying dashboards on non-standardized data across brands—the tell is that merged KPIs won't reconcile or compare between divisions.
• Assuming tool access equals tool use—the tell is that platforms like Tableau and R sit idle because most HR partners don't even know they have access.
• Confining analysts to report generation—the tell is reports get produced but are seldom used for actionable insight, and analysts aren't treated as strategic partners.
• Over-planning an analytics project like a traditional one—the tell is rigidity when the model or technology turns out to be new and requirements shift mid-project.
• Building capability without securing top-management support—the tell is skeptical HR partners who don't wholeheartedly embrace the analytics-driven culture.

• ▸Analytic question type: state whether descriptive, diagnostic, or predictive to pick the tool tier.
• ▸Chosen tool: name the software (Excel / Power BI / Tableau / R / ML method) matched to the question.
• ▸Data standardization status: confirm KPIs are in sync and collection is consistent across units (yes/no + gaps).
• ▸Data infrastructure: note whether a centralized warehouse/MIS with IT support exists for storage and retrieval.
• ▸Tool access check: list which users actually have access to the chosen platform.
• ▸Skills gap: identify training needed in query-building, dashboard generation, and integration.
• ▸Sponsorship: record the top-management support committed to the project.
• ▸Value-in-use metric: define how you'll measure actual adoption/application of the tool.
• ▸Flexibility plan: note how the stack will adapt if the model or technology proves new or requirements change.

1. 1Collect key hypotheses from executives at the outset. Book brief conversations to sift the research questions down to what leaders actually want answered, but keep them short so you don't taint your ability to treat the data with an open mind.
2. 2Cap stakeholdering at roughly 5% of your total effort per Schleyer's recipe. It is high-leverage for framing but produces diminishing returns; too much collaboration up front spoils the objectivity of the analysis.
3. 3Partner early with Finance or Operations during the data-gathering phase. Share the work burden of gathering, cleaning, and connecting disparate data so the partnership is established before you need their buy-in on conclusions.
4. 4Convert every proposal into financial outcomes. Shake financial acumen liberally into the story because no proposal is worthy of a leader's time unless it expresses itself in financial terms; this creates interest and urgency from line management and the HR community.
5. 5Reduce research to one memorable slide that says what the insight means and how to act on it. Sprinkle in a pinch of myth-busting to make it memorable, but not so much that it damages productive collaboration.
6. 6Run a formal stakeholder meeting to secure data access. Bring the sponsor, purpose, and requestor details; write a rationale for the project and demonstrate how the data will be used, and state up front that no individual names or results will be reported.
7. 7Involve stakeholders in defining what a meaningful difference is. When you present group comparisons, ask leaders to set the threshold for a 'real' difference (e.g., 5% or 10%) rather than relying on statistical significance alone.
8. 8Keep sponsors engaged through implementation. Taking insights into action separates consultants from business partners; involving analysts and stakeholders in execution surfaces resistance that points back to shortcuts in the analysis.

In the Retain & Grow scenario, the VP of HR asks you to produce measures showing the initiative's effectiveness. Rather than analyzing in isolation, you and the VP run several iterations and brainstorming sessions to agree on a set of KPIs segmented into efficiency, effectiveness, and outcomes measures, and on how to display them for business leaders. When you go to gather data owned by other departments, you file formal requests, get several approvals, and state that no individual results will be reported and that results will be grouped in units no smaller than three or five. At presentation time, a stakeholder asks whether the turnover differences among three business units (8.6%, 9.1%, 8.8%) are statistically significant; because you ran the ANOVA, you answer with authority. You then note that although the difference is statistically significant given the large sample, it is not practically meaningful, and you let the stakeholders define through discussion what a 'real' difference would be. The shared framing from the start is what makes the leaders accept the finding.

• If a proposal cannot be expressed in financial outcomes, then do not put it in front of a leader.
• If executives supply hypotheses, then collect them briefly at the start, but if the conversations start shaping your reading of the data, then stop and treat the data with an open mind.
• If a result is statistically significant but the gap is small (like 8.6% vs 9.1% turnover), then treat it as not meaningful and have stakeholders define the threshold that matters.
• If data is owned by another department, then partner with Finance or Operations early and file a formal request naming sponsor, purpose, and requestor before analysis begins.
• If you hit heavy resistance during implementation, then read it as a tell that the analysis took shortcuts, and revisit the analysis rather than pushing harder.

• Over-investing in stakeholdering: too much collaboration spoils objectivity and biases the analysis. The tell is that your conclusions echo executives' pre-existing beliefs.
• Skipping the financial translation. The tell is that leaders lose interest or the proposal never earns time on their agenda.
• Delivering raw regression, T-tests, and P-values to leaders. The tell is glazed eyes; the savory flavor of statistics is an acquired taste for most, so it belongs behind the scenes.
• Requesting data with no sponsor, rationale, or confidentiality assurance. The tell is stalled or denied approvals from data gatekeepers.
• Handing off insights without staying through implementation. The tell is that nothing changes operationally, and the work reads as consulting rather than partnership.

• ▸Executive sponsor: name the leader accountable for the initiative.
• ▸Key hypotheses collected: list the questions executives most want answered.
• ▸Data owner/gatekeeper: name who controls each data source and what approvals are needed.
• ▸Confidentiality statement: note the minimum group size (3 or 5) and that no individual results are reported.
• ▸Business case / rationale: one line on what the data will be used for and how it will be consumed.
• ▸Financial outcome framing: state the insight's dollar impact for the one-slide story.
• ▸Meaningful-difference threshold: record the gap stakeholders agree counts as 'real' (e.g., 5% or 10%).
• ▸Implementation owners: name analysts and stakeholders responsible for taking insights into action.

1. 1Build a complete data inventory before anything else: catalogue every people-related data set, where it resides (including payroll, performance, targets and incentive systems outside HR), exactly which fields are involved, and flag any personally identifiable information. You cannot govern data you cannot see.
2. 2For each data set, document the full lifecycle: who the data are divulged to, how they are processed or analysed, and how they are used inside the organization — including data processed by third parties or external systems.
3. 3Apply the minimization test to every collection decision: collect, store and analyse the smallest amount of data that answers your most important questions. Reject any capture that exists only because it is technically possible.
4. 4Check consent and legal basis against the applicable regime (GDPR in the EU/UK, the different US federal/state landscape) and secure specialist legal advice, since the regulatory landscape keeps shifting.
5. 5Secure the data technically — apply encryption and data protection controls proportionate to sensitivity — and treat a breach as an existential risk (see WannaCry, Community Health Systems Inc.).
6. 6Run a transparency and ethics review on the intended use: ask whether it could be perceived as discriminatory or as 'Big Brother' monitoring, and whether the benefit to employees is clear.
7. 7Communicate the business case at every level and every function, not just leadership: explain what you collect, why, how it benefits the company and the employee, and be open about time frame, disruption and cost. Poor communication here breeds mistrust.
8. 8Bring all of this together into a written data governance framework covering privacy, consent, ethics, transparency, security and compliance, and revisit it as regulations and your data holdings change.

A company wanting to become a top-three consultancy provider decides to strengthen its employer brand to attract talent, which pulls it toward collecting more people-related data. Before capturing anything new, the HR team inventories existing holdings and finds employee data scattered across payroll and performance/incentive systems, much of it personally identifiable. Rather than build 'the biggest database in the world' — the exact instinct one of the world's largest retailers had until its CEO told the data team to build the smallest database that could answer the company's most important questions — they collect only what serves the brand and hiring objective. They check the legal basis under the relevant privacy regime, encrypt sensitive fields, and screen the intended use for discrimination or surveillance perceptions. Then they sell the approach across all functions, explaining the tangible benefit to both business and employees. The result: data stay a valued asset that supports the brand rather than a liability that erodes trust — the same trust that matters when 84 per cent of employees would consider moving to an employer with an excellent reputation.

• If a data set contains personally identifiable information, then map its full lifecycle (residence, recipients, processing, use) and secure a documented legal basis before using it.
• If you cannot state a clear question the data will answer and a benefit to the employee, then do not collect it — collect the smallest data set that achieves the goal.
• If a use could be perceived as discriminatory, poorly explained, or as monitoring without purpose, then stop and rework the transparency and communication before deployment, because it erodes trust and morale.
• If you intend to monetize employee data as a revenue stream, then reconsider — the practice is largely unheard of, the data are personal and sensitive, and the reputational cost outweighs it.
• If you want other functions to use HR data, then first make sure they understand its value and governance, or they will not incorporate it and mistrust will grow.

• Diving in and collecting all kinds of data 'because you can' with no business rationale. The tell: staff feel Big Brother is watching with no sense of why, and morale drops.
• Burying your head in the sand because the volume is overwhelming and never starting. The tell: no data strategy, no inventory, competitors moving ahead.
• Governing only what sits inside HR while payroll, performance and incentive data live ungoverned elsewhere. The tell: you discover PII you did not know you held during an audit or breach.
• Deploying a data use without communicating the business case at every level. The tell: mistrust and cultural fallout even when the use is technically sound.
• Treating security as optional or under-scoped. The tell: an incident like WannaCry or the Community Health Systems breach exposes unencrypted sensitive employee data.

• ▸Data set name: what the data set is called and its primary purpose
• ▸Location/system: where the data reside, including systems outside HR (payroll, performance, incentives)
• ▸Contains PII? (yes/no): flag any personally identifiable information
• ▸Legal basis/consent: which regime applies (e.g. GDPR, US state/federal) and the recorded consent or lawful basis
• ▸Recipients: who the data are divulged to, internally and externally (third-party processors)
• ▸Processing & use: how the data are analysed and how insights are used in decisions
• ▸Minimization check: the specific question this data answers and why less data will not do
• ▸Security controls: encryption and protection measures applied, proportionate to sensitivity
• ▸Transparency/communication status: how this use is explained to affected employees and buy-in obtained

1. 1Start from the business question, not the technique: define the hypothesis and specify what proving or disproving it delivers (financial value, risk mitigation, or engagement impact) before touching data.
2. 2Assess potential value at the end of the project up front — decide whether the work is worth doing, whether a sponsor is needed, and whether stakeholders will release budget for skills, data, or technology.
3. 3Match the analytical approach to the outcome type: reporting/descriptive work answers 'what happened,' while advanced analytics is reserved for the business questions where causal or predictive insight moves the needle. Move from 'reporting' to 'outside-in' business-driven framing, as AEO did.
4. 4Identify which of the Seven Types of Stakeholders the work touches (business executives, HR leaders, managers, employees, functional stakeholders, technology/data owners, unions/works councils) and estimate the impact on each before scoping.
5. 5Route the data through governance: confirm who owns the data, that its use complies with regulation (GDPR risk of fines up to 4% of global annual revenue), and that the technology/data infrastructure can support the chosen method.
6. 6Prototype iteratively and incrementally — build modules that immediately demonstrate intent to solve a strategic problem, then gather feedback and refine before scaling.
7. 7Split effort deliberately: budget roughly half your time for the analytics development itself and half for stakeholder management and communication, because change management does not happen in a vacuum.
8. 8Validate against the business, not just statistically: ensure the output translates into actionable insights and recommendations, and secure the sponsor before proceeding to full build.

Steffen at The Viessmann Group wanted to bring HR into a data-driven world with ViGrow, an outcomes-driven platform covering development, cost, skills gaps and strategic direction. Rather than building in isolation, he treated method and adoption as one problem: 50 per cent of the team's time went to people analytics development and 50 per cent to stakeholder management and communications. He ran a rigorous campaign of presentations, town halls and global roadshows across countries as distant as China, Turkey and the US, engaging almost 25 per cent of employees in a three-month period. Feedback loops sharpened the platform — suggesting use cases sparked more use cases, making the system stronger both top-down and bottom-up. In parallel he secured senior executive buy-in by involving them iteratively and incrementally, using prototypes and modules that demonstrated HR's intent to solve strategic problems. The result was a platform whose job cards and career profiles served both individual employee development and aggregate executive decision making.

• If the hypothesis, once proven or disproven, produces no financial value, risk mitigation, or engagement impact, then do not proceed — the work loses focus and generates substandard value.
• If the business question only asks 'what happened,' then use descriptive reporting; reserve advanced analytics for questions requiring prediction or causal understanding.
• If the work touches employee or workforce data, then run a compliance/governance check first — the H&M €35.3m fine for employee surveillance is the cost of skipping it.
• If the project needs budget for skills, data, or technology or has significant stakeholder impact, then secure a committed sponsor before building.
• If you cannot spend meaningful time on stakeholder engagement, then rescope — a technically sound model with no adoption delivers no business outcome.

• Staying a 'reporting' team: producing dashboards that describe the past instead of answering business questions. Tell — outputs are recurring reports nobody acts on, not recommendations tied to a decision.
• Selecting technique before defining the question. Tell — the team leads with 'we should build a predictive model' rather than the business problem it solves.
• Skipping the up-front value assessment. Tell — work proceeds without knowing who the sponsor is or whether budget will be released, and stalls midway.
• Treating analytics development as the whole job and neglecting stakeholder management. Tell — a finished model or platform that no executive or employee will engage with or adopt.
• Ignoring governance and data ownership. Tell — surprise compliance escalations, reputational risk, or regulatory fines surface after the analysis is already run.

• ▸Business question / hypothesis — state it in one sentence, business-first
• ▸Value if proven or disproven — financial value, risk mitigation, or engagement/experience impact
• ▸Outcome type — descriptive, predictive, or causal, and the technique matched to it
• ▸Data structure & source — what data, who owns it, is it fit for this method
• ▸Governance & compliance check — regulatory exposure (e.g. GDPR) and mitigation confirmed
• ▸Stakeholders impacted — which of the Seven Types and expected impact on each
• ▸Sponsor & budget — named sponsor, budget for skills/data/technology confirmed yes/no
• ▸Effort split plan — % to analytics development vs % to stakeholder management/communication
• ▸Validation & translation plan — how findings become actionable recommendations for the business

1. 1Before trusting coefficients, run the four linear-regression assumption checks in sequence: linearity/additivity, constant error variance, normally distributed errors, and collinearity — a model can produce output while silently violating any of these.
2. 2Test linearity and additivity by plotting residuals against fitted values and against each input; if you see systematic curvature rather than random scatter, the linear form is misspecified and you extend the model with quadratic or higher-order polynomial terms (section 4.6.2) or interactions (4.6.1).
3. 3Check constant error variance (homoscedasticity) by inspecting the residual-vs-fitted plot for a fanning or funnel pattern; a widening spread signals non-constant variance that biases your standard errors and therefore your coefficient confidence.
4. 4Check normally distributed errors using a Q-Q plot or distributional inspection of residuals; departures at the tails undermine the confidence intervals and hypothesis tests attached to each coefficient.
5. 5Screen for high collinearity and multicollinearity between input variables before interpreting individual coefficients, since correlated inputs inflate standard errors and make coefficient signs and magnitudes unstable and uninterpretable.
6. 6For logistic and multinomial models, assess fit and goodness-of-fit (sections 5.3.2, 6.4.2) separately from coefficient significance, then pursue parsimony by gradual, safe elimination of variables (6.4.1) rather than dropping several at once.
7. 7For proportional odds models, explicitly test the proportional odds assumption by sighting the coefficients of stratified binomial models and running the Brant-Wald test (7.3.1–7.3.2); if it fails, abandon the single-coefficient model for an alternative (7.3.3).
8. 8Only after assumptions hold and fit is acceptable do you interpret coefficients as ratios and make predictions (4.3.4), keeping the simplest adequate model.

Take the proportional odds logistic regression case from section 7. You are modeling an ordinal outcome such as higher ratings in an employee survey on a Likert scale, and the model reduces every input's effect to a single set of coefficients across all category cutoffs — for example, each unit increase in input x raises the odds of y being in a higher category by a fixed ratio. That reduction is only valid under the proportional odds (parallel regression) assumption: the 'slope' of the logistic function must be the same for all category cutoffs, meaning no input has a disproportionate effect on any single level of the outcome. You validate this two ways: first sight the coefficients of stratified binomial models (7.3.1) to see whether they stay roughly parallel across cutoffs, then confirm formally with the Brant-Wald test (7.3.2). If the coefficients diverge and the test flags a violation, you cannot collapse to one coefficient set and the modeling approach fails, so you move to an alternative in 7.3.3. Skipping this step would let you report a single clean odds ratio that the data never supported.

• If the residual-vs-fitted plot shows systematic curvature, then the linearity/additivity assumption is violated — add polynomial or interaction terms rather than reporting the linear coefficients.
• If residual spread fans out with fitted values, then error variance is not constant — do not trust the reported standard errors or coefficient confidence until you address it.
• If input variables show high collinearity, then do not interpret their individual coefficients — the inflated standard errors make sign and magnitude unreliable.
• If the Brant-Wald test or stratified binomial coefficients show the slope differing across cutoffs, then the proportional odds assumption fails — switch to an alternative model in 7.3.3.
• If two models fit comparably, then keep the more parsimonious one, reached by gradual safe elimination of variables one at a time.

• Reporting coefficients from a model that runs cleanly but violates an assumption — the tell is you never produced a residual plot or ran an assumption test.
• Fitting a proportional odds model and interpreting the single odds ratio without testing proportional odds — the tell is no stratified binomial comparison and no Brant-Wald result in your write-up.
• Confusing statistical significance with goodness-of-fit — the tell is you quote p-values on coefficients but never assess whether the model actually fits (5.3.2, 6.4.2).
• Dropping several variables at once during simplification, distorting the remaining estimates — the tell is coefficients that jump sharply between model versions instead of the gradual, safe elimination approach.
• Ignoring collinearity because each variable 'looks significant enough' — the tell is unstable or wrong-signed coefficients and unexpectedly wide confidence intervals.

• ▸Model type: name it (linear / binomial / multinomial / proportional odds) to select the relevant assumptions.
• ▸Linearity & additivity: record residual-vs-fitted pattern (random / curved) and action taken.
• ▸Constant error variance: note whether spread is even or fanning, and fix applied.
• ▸Normality of errors: log Q-Q plot / distribution result for residuals.
• ▸Collinearity check: list correlated input pairs and whether any coefficient was excluded.
• ▸Assumption-specific test: for proportional odds, record stratified-binomial sighting and Brant-Wald outcome (pass/fail).
• ▸Goodness-of-fit: state the fit measure and verdict, separate from coefficient p-values.
• ▸Parsimony: note variables eliminated one-by-one and whether fit held.
• ▸Interpretation status: mark whether coefficients/predictions are now safe to report.

1. 1Fix the four interlocking quantities before you collect data: significance level (alpha, the Type I error rate), desired power (1 minus the Type II error rate), the effect size you consider meaningful, and the required sample size — power analysis solves for whichever one you leave open, typically sample size.
2. 2Match the power method to the model you intend to run: use simple hypothesis-test power analysis (Chapter 11.2) for a t-test or correlation, linear-regression power analysis (11.3) for continuous outcomes, log-likelihood power analysis (11.4) for logistic/multinomial outcomes, and hierarchical power analysis (11.5) when data are nested.
3. 3Set the effect size from something defensible — a prior study, a pilot, or the smallest effect that would change a people decision — rather than defaulting to a 'medium' convention, because the required n scales sharply with how small an effect you insist on detecting.
4. 4When your data have a latent hierarchy or grouping (employees within teams, repeated events per person), plan power under the hierarchical/mixed framework, since the effective sample size is smaller than the raw row count once you account for within-group correlation.
5. 5Run the calculation before fieldwork: input alpha (commonly 0.05), target power (commonly 0.80), and the expected effect size to get the minimum n; if the number exceeds your available population, either widen the effect size you will commit to detecting, reduce the number of predictors, or accept lower power and state it.
6. 6Recompute after you know your realistic sample: given the n you can actually obtain, back out the smallest effect your study can reliably detect, so you know in advance which effects you will and will not be able to see.
7. 7In people analytics specifically, treat small employee populations as a binding constraint — if the required n is unreachable, choose a method appropriate to small samples rather than forcing a model your data cannot power, and report the limitation.
8. 8Reproduce the same power computation in Python (11.6) if that is your stack, so the sample-size logic travels with the modeling code.

Suppose you want to test whether a learning program raises performance ratings, and you plan a Welch's t-test comparing trained versus untrained employees. Before pulling data, you decide alpha = 0.05 and target power = 0.80, meaning you accept a 5% chance of a false positive and want an 80% chance of detecting the effect if it is real. From a prior cohort you estimate the difference in mean ratings corresponds to a modest effect size, so you run a power analysis for a simple hypothesis test (Chapter 11.2), which returns a minimum n per group. If that n exceeds the number of trained employees available — a common squeeze in people analytics where populations are relatively small — you either commit only to detecting a larger effect, which lowers the required n, or you accept that with your available sample the study can only detect a large program effect and you document that ceiling. This keeps you from running the model, finding a non-significant result, and wrongly concluding the program does nothing when the study was simply underpowered.

• If the outcome is continuous, then use linear-regression power analysis (11.3); if it is binary or categorical, then use log-likelihood power analysis (11.4).
• If the data are nested (employees within groups, repeated events), then compute power under the hierarchical/mixed framework (11.5), never with a flat single-level formula.
• If the required n exceeds your available population, then either raise the minimum effect size you commit to detecting or reduce predictors — do not silently proceed at low power.
• If you cannot justify an effect size from prior data or a pilot, then state the assumption explicitly and report the smallest detectable effect for your actual n.
• If your employee population is small, then let power analysis pick the method — prefer a simpler test your data can power over a richer model it cannot.

• Running the model first and doing power analysis never — the tell is a non-significant result reported as evidence of 'no effect' with no statement of what effect the sample could have detected.
• Using the raw row count as the sample size in nested data — the tell is a hierarchical structure (repeated measures, teams) modeled as if every row were independent, inflating claimed power.
• Plugging in a conventional 'medium' effect size with no source — the tell is a suspiciously round required n and no reference to a pilot or prior study.
• Ignoring the small-population constraint typical of people analytics — the tell is a required n far larger than the organization's headcount, waved away rather than resolved.
• Optimizing only Type I error (chasing p < 0.05) while never setting a power target — the tell is alpha stated but power (1 minus Type II error) absent from the plan entirely.

• ▸Research question and outcome type: state the outcome and whether it is continuous, binary, or categorical.
• ▸Model to be run: name the method (t-test, linear, logistic, hierarchical) and matching power section (11.2–11.5).
• ▸Data structure: note any nesting/grouping and the expected within-group correlation.
• ▸Alpha (Type I error rate): set the significance level, e.g. 0.05.
• ▸Target power (1 − Type II error): set desired power, e.g. 0.80.
• ▸Effect size and its source: record the value and the pilot/prior study/decision threshold it comes from.
• ▸Required sample size: enter the n returned by the power calculation.
• ▸Available sample and gap: state the n you can actually obtain and whether it meets the requirement.
• ▸Smallest detectable effect at available n: if the gap is negative, record the effect ceiling and the decision to proceed, adjust, or switch methods.

1. 1Frame the inference as a claim about the population Ω, not the sample S: you are using the relationship between measured data X and outcome y to describe a relationship between constructs and outcome that holds to a high degree of statistical certainty beyond your data.
2. 2Define the model form explicitly as y = f(X) + ϵ, and decide parametric vs non-parametric. If you assume a formula (e.g. linear), you have committed to assumptions that must be checked before the inference is trustworthy.
3. 3Confirm the outcome satisfies the basic condition for your regression type (e.g. a continuous outcome for linear regression) before generalizing anything.
4. 4Run a power analysis to estimate the minimum sample size needed to detect the effect size of interest at your chosen error rate — do this before or alongside modeling, since people analytics data sets are rarely large.
5. 5Interpret each coefficient in its own terms and test its significance; drop or re-specify terms that are not significant (as with the Yr1 variable removed when it was not significant linearly).
6. 6Distinguish coefficient magnitude from importance and standardize your reasoning: larger coefficients (e.g. dummy variable coefficients) do not imply greater importance.
7. 7Validate the fitted relationship against alternatives (e.g. compare a quadratic term against the linear fit) and, in any predictive use, test on new data to guard against overfitting.
8. 8State the generalization limit explicitly: report which elements of the relationship can be carried from S to Ω and to what degree of statistical certainty.

Testing whether a quadratic term improves a linear model shows the discipline of valid inference in miniature. The author had already removed Yr1 from the model because it was not significant when modeled linearly. Rather than assume that a curved relationship might exist, he explicitly trialed a polynomial term using I() in the R formula notation so the ^ symbol is interpreted literally as 'the square of Yr1'. The resulting fit measure of 0.5304198 was compared against the prior fit, and the conclusion was that modeling Yr1 as a quadratic makes no difference. The inference held: no new term was retained because the data gave no evidence for one. Contrast this with the interaction model, where someone scoring very low in both Year 2 and Year 3 was awarded an unreasonably high score due to the intercept — a fit too tightly aligned to past data to generalize.

• If the outcome variable fails the basic condition for the model (e.g. not continuous for linear regression), then do not use that regression type — choose a variant matched to the outcome.
• If your sample size is below the minimum from a power analysis, then treat the inference as underpowered and do not generalize it to the population.
• If a term is not statistically significant, then remove it or refrain from claiming it as a driver — as with Yr1 modeled linearly.
• If a coefficient is large, then check whether it is a dummy variable or on a different scale before treating it as more important than smaller coefficients.
• If the model is used to predict rather than explain, then validate on new data, because a tight fit to past data (like the interaction model's inflated low-low score) signals overfitting rather than a generalizable relationship.

• Running multivariate models without understanding the underlying mathematics — the tell is being unable to explain why a coefficient or fit statistic means what it claims.
• Treating higher coefficients as more important — the tell is ranking drivers by raw coefficient size while ignoring scale and dummy-variable effects.
• Ignoring power — the tell is confidently generalizing from a small people-analytics data set that was never large enough to support the inference.
• Overfitting and then generalizing — the tell is nonsensical fitted values, like the interaction model awarding an unreasonably high score to someone scoring very low in both years.
• Adding terms without testing them against alternatives — the tell is keeping a quadratic or interaction term that produces no improvement in fit (e.g. no movement from 0.5304198).

• ▸Population Ω claim: one sentence on what relationship you want to generalize beyond the sample
• ▸Outcome condition: state outcome type and confirm it fits the chosen regression
• ▸Model form: write y = f(X) + ϵ; mark parametric or non-parametric
• ▸Assumptions to check: list each assumption the model form commits you to
• ▸Power/sample size: required minimum n from power analysis vs actual n
• ▸Significance results: list each term and whether it is significant (keep/drop)
• ▸Coefficient interpretation: note scale and dummy status before ranking importance
• ▸Alternative tested: which competing specification was compared and the fit difference
• ▸Generalization statement: which elements transfer from S to Ω and to what certainty

1. 1Define the target profile behaviorally before sourcing: analyze data sets from people you want to attract versus those you want to avoid, and identify the specific attributes that predict fit (as JetBlue found 'helpful' beat 'nice' for flight attendants).
2. 2Boost your employer brand deliberately — how current, ex-, and potential employees view you as an employer — and align it with your overall company/product brand so the two send the same message; use LinkedIn and Glassdoor data to see how you are perceived.
3. 3Identify your most effective recruitment channels using data on where your best candidates actually come from, rather than defaulting to expensive advertising you cannot tie to outcomes.
4. 4Screen and assess using talent analytics: mine test scores, interview answers, and application metadata for predictors of performance and retention (one client found the browser used to apply — Firefox/Chrome vs. pre-installed — predicted self-driven candidates).
5. 5Automate the high-volume, low-judgment steps first — candidate assessment and sifting hundreds of applications — to free HR time and cut per-hire cost, while machines can predict churn better than humans.
6. 6Validate predictors against actual on-the-job performance, not just gut feeling about background, education, and experience; correlate hire-source data with retention and performance to confirm the profile holds.
7. 7Apply talent analytics across all tiers, not only low/mid vacancies — Purple used it to select CEO Sam Bernards — but weight rigor to the cost of error, since C-suite mistakes are the most expensive.
8. 8Track cost-per-hire against quality: measure advertising, selection cost, and the downstream cost of a poor culture fit, then compare against the ROI of your data-driven changes.

JetBlue Airlines had long treated 'niceness' as the top attribute for flight attendants and recruited against it. Working with the Wharton Business School, the company ran customer data analysis and found that, in customers' eyes, being helpful mattered more than being nice — and helpfulness could even compensate when someone was not so nice. JetBlue used this evidence to redefine the target profile and narrow candidates more effectively. The lesson: the attribute you assume matters may not be the one your customers actually value, and only data exposes the gap. Note also this required no Google-scale infrastructure — a partnership and a focused analysis were enough. Contrast this with the client who discovered browser choice predicted self-driven candidates, which let them dramatically streamline their process from a single insight.

• If you are relying on gut feeling or assumptions about background, education, and experience, then stop and build a data-based profile of your ideal hire (as Xerox did for call-centre workers).
• If a role is low or mid-tier and high-volume, then automate assessment and selection first; if it is C-suite, then still use talent analytics but weight rigor to the outsized cost of a wrong appointment.
• If your employer brand and your product/service brand send different messages, then fix the misalignment before spending more on channels — mixed signals undermine attraction and retention.
• If a predictor (like browser type) correlates with your desired profile but you cannot connect it to job performance, then keep validating before you let it drive selection decisions.
• If a hire turns out to be a poor culture fit or lacks required skills, then treat it as an expensive, measurable mistake and feed it back into refining the profile.

• Optimizing for the wrong attribute — recruiting for 'niceness' when customers actually reward 'helpfulness'; the tell is high scores on your criteria but weak customer/performance outcomes.
• Treating recruitment as gut feeling despite the data being available; the tell is decisions justified by 'how things have always been done' rather than evidence.
• Using discriminatory or poorly explained selection data; the tell is eroded trust and morale when staff learn how data drove decisions (Chapter 6 warns ill-considered use is harmful).
• Applying analytics only to low-tier roles while filling the highest-cost C-suite seats on instinct; the tell is disproportionate damage from a single bad senior appointment.
• Chasing a statistical predictor without validation, so a spurious correlation drives hiring; the tell is that the 'predictor' does not hold up against actual retention and performance over time.

• ▸Role & tier: name the position and mark low/mid/C-suite (drives rigor level)
• ▸Target attributes: list behavioral attributes derived from data on high performers to attract
• ▸Avoid attributes: list traits from data on people you want to screen out
• ▸Validated predictors: name each data signal and the performance/retention outcome it correlates with
• ▸Employer brand check: note how the role/company appears on LinkedIn/Glassdoor and any misalignment with product brand
• ▸Channels ranked: list sourcing channels ranked by quality-of-hire and cost, not volume
• ▸Automation candidates: mark which assessment/selection steps you will automate to free HR time
• ▸Cost-of-error estimate: state advertising + selection cost + expected cost of a poor fit for this role
• ▸Validation date: set when you will re-check predictors against actual on-the-job performance

1. 1Decompose fit into Kristof's (1996) three congruence dimensions before you measure anything: value congruence, personality congruence, and work environment congruence. Treat these as separate scored constructs, not a single blended rating.
2. 2Define the target and independent variables up front, PO-fit style. Make turnover intent the target (probability an individual changes jobs within a period) and treat value/personality/environment congruence as independent variables predicting it.
3. 3Collect KSA and personality data using instruments the source supports: run structured online games or psychometric tests among candidates/employees to gauge personality and cognitive skills, as the restaurant case did with frontline staff.
4. 4Capture the organisation side with an engagement/culture instrument — administer McKinsey's Organizational Health Index (OHI, 37 management practices) to measure how favourably employees perceive management and environment, then align that perception profile against candidate values.
5. 5Profile your high performers first: like Google, use the employee database to describe traits of key performing employees in each area, then build hiring plans and fit criteria against that empirical profile rather than assumed job specs.
6. 6Draft explicit hypotheses linking each congruence variable to the outcome (the restaurant team wrote 100+ hypotheses tying independent variables to store/employee performance) so fit claims are testable, not intuitive.
7. 7Model fit with a supervised technique where target and variables are predefined — logistic regression on turnover intent — and supplement with unsupervised learning to surface fit patterns leaders did not anticipate.
8. 8Close the loop with intervention: since voluntary turnover is 'avoidable by timely interventions,' use low-fit signals to trigger specific actions (relocation, career-advancement, supervisor-relationship fixes) named in the source as turnover drivers.

A quick-service restaurant chain wanted to explain performance variation traced to frontline staff. Instead of treating fit as a hunch, the analysts added personality traits and cognitive skills as independent variables, collecting the data by running a series of online games among restaurant employees. They then measured the organisation side by administering McKinsey's Organizational Health Index (37 management practices) to gauge employee perception of management and environment, and tracked behaviour with sensors capturing movement, conversation tone/duration, and collaboration. External variables — demographics, commute distance, prior retail experience — rounded out a dataset exceeding 10,000 data points. Senior leaders drafted more than 100 hypotheses linking these person and organisation variables to outcomes, then ran logistic regression supplemented by unsupervised learning. The results were 'myth-busters,' defying the leaders' prior assumptions about what drove fit and performance — the operational lesson being that measured fit beats leadership intuition.

• If an employee resigns over a fixable organisational factor (e.g., unable to live together after a spouse's transfer), then the turnover is avoidable — intervene (relocate) rather than backfill.
• If turnover removes an unproductive employee, then treat it as functional and do not intervene; if it removes a high performer, treat it as dysfunctional and prioritise a fit-based retention action.
• If your model must predict who will leave, then measure turnover intent (probability of changing jobs in a period), not just end-of-year attrition rate, because intent is the earlier, actionable signal.
• If value, personality, and environment congruence are all high, then expect better work attitudes, lower turnover intention, and higher performance (Westerman and Cyr); prioritise these hires as 'hired for the organisation,' not just given a job.
• If retention issues vary sharply across your business units, then attribute it to differing organisational-culture values (Sheridan) and localise fit criteria per unit rather than applying one firm-wide standard.

• Treating fit as one score instead of three dimensions — the tell: you can't say whether a misfit is about values, personality, or work environment, so interventions are generic and miss.
• Relying on exit interviews alone to explain departures — the tell mirrors the healthcare firm that ran exit interviews yet 'was unable to locate the real reasons for turnover' until it modelled the data.
• Letting senior-leader intuition define fit criteria — the tell: your assumptions go untested and get 'myth-busted' the moment you actually model 100+ hypotheses against real data.
• Measuring only annual attrition percentage (leavers/average headcount) — the source notes this measure 'is seldom used' because it's a lagging figure that can't tell you who intends to leave.
• Ignoring the organisation side of fit — the tell: you screen KSAs and personality but never administer a culture/health instrument like the OHI, so 'organisation fit' is asserted, not measured.

• ▸Target variable: state as turnover intent — probability this person changes jobs within [period].
• ▸Value congruence score: candidate values vs. firm values, source instrument used.
• ▸Personality congruence score: instrument (e.g., online games/psychometric test), traits captured.
• ▸Work-environment congruence score: OHI or engagement-survey perception of management/environment.
• ▸KSA match: candidate knowledge/skills/abilities vs. profile of your identified key performers.
• ▸External variables logged: demographics, commute distance, prior relevant experience.
• ▸Hypotheses drafted: list each independent variable → outcome relationship to be tested.
• ▸Model + method: supervised (logistic regression) plus unsupervised check, dataset size.
• ▸Intervention trigger: for low-fit / high-intent cases, name the specific avoidable-turnover action (relocation, career path, supervisor fix).

1. 1Replace annual satisfaction surveys with short 'pulse' surveys that measure how staff feel monthly, weekly, or even daily, so you catch mood shifts while you can still act on them.
2. 2Instrument engagement at the source: use analytics tools to scan and analyze the content of staff e-mails and public posts on Facebook or Twitter to gauge sentiment — but first check Chapter 6 privacy rules, which vary country to country, before touching any communications.
3. 3Start engagement work at hiring: apply the machine learning recruitment methods to identify candidates most likely to commit long-term, based on their employment history and patterns from existing employees who demonstrated high loyalty.
4. 4Build a churn-prediction model in the Google mold — run algorithms against historical employee data to flag who is most likely to leave before they resign.
5. 5Track happiness geographically (store-by-store or unit-by-unit); when a location with historically stable moods shows a drop, route it to management to investigate the cause and take action.
6. 6Copy Google's evidence-based perk logic: decide interventions (meals, holiday allowance, nap pods, growing space) based on what the data say increases engagement and retention, not on generosity or gut feel.
7. 7Reject the salary myth — pair retention data with the practices that actually keep people engaged: communicating and rewarding successes, plentiful training and development, and clear career progression opportunities.

Google treats engagement as a data problem, not a benevolence problem. It gives staff free meals, generous paid holiday, access to 'nap pods,' and space to grow their own fruit and vegetables at work — but these policies were implemented because the data told Google's leadership they would increase employee engagement and retention, not merely because leadership is generous. Separately, Google has for years run algorithms to predict which employees are most likely to leave, because competition for talent in Silicon Valley is intense and even a top employer must work to retain people. The payoff shows in outcomes: despite consistently high turnover across the tech world, Google is regularly voted the number one company to work for by Fortune. Xerox demonstrates the retention half of the equation — using data to reduce employee attrition by 20 per cent. The pattern: measure engagement continuously, predict churn, then apply targeted retention practices rather than assuming pay fixes everything.

• If you still run an annual staff satisfaction survey, then replace it with pulse surveys — the annual survey is a costly, time-consuming activity that misses shifting moods.
• If a unit that previously showed stable moods shows a drop in happiness, then escalate to management to investigate the cause and take necessary action.
• If you want to analyze employee e-mails or social posts for sentiment, then first confirm the privacy rules for that country (Chapter 6) before collecting anything.
• If you are hiring for retention, then weight candidates by employment history and loyalty patterns from your own high-commitment employees, not by prestige signals.
• If retention is slipping, then check communication, recognition, training, and career progression before assuming the problem is compensation.

• Assuming retention is all about compensation — the tell is a comp-and-benefits fix that fails to move attrition because you never addressed recognition, development, or progression.
• Measuring engagement only through easy or copied KPIs (absenteeism, training hours per FTE) because they are simple or because other companies use them — the tell is metrics no one can tie to a business outcome.
• Leaning on annual satisfaction surveys — the tell is stale data and 'wasteful, expensive' cycles that surface problems long after the moment to act has passed.
• Scanning employee e-mails and social posts without clearing privacy rules — the tell is a data source deployed uniformly across countries with different laws.
• Treating perks as generosity rather than tested interventions — the tell is spending on benefits with no data showing they raise engagement or retention.

• ▸Unit / location: name the store, team, or site being monitored
• ▸Pulse cadence: state whether you measure daily, weekly, or monthly
• ▸Baseline mood: record the historically stable happiness level for comparison
• ▸Current mood + delta: log latest reading and the change from baseline
• ▸Trigger threshold: define the drop that routes the case to management
• ▸Churn-risk flags: list employees the prediction model marks as likely to leave
• ▸Hiring-loyalty fit: note whether new hires match long-term commitment patterns
• ▸Retention levers applied: tick which — recognition, training, progression — are active
• ▸Privacy clearance: confirm the country's rules for any communications data used

1. 1Decide first whether job satisfaction can be measured directly or must be decomposed into attributes. Because satisfaction is subjective, you cannot quantify it in one number—identify its associated traits: satisfaction with supervisor, subordinates, salary, employee benefits, and career growth opportunities.
2. 2Select a scale for each subjective attribute. Choose among nominal, ordinal, interval, or ratio, then decide whether a rating or ranking technique fits your data collection. For attitude items an interval rating scale supports later correlation and predictive work.
3. 3Anchor which attitudes to collect in logic, not guesswork. Draw on your own experience, conversations with experts or seniors, or a theoretical framework to outline the specific attitudes that plausibly move the outcome you care about (e.g., sales, customer satisfaction, retention).
4. 4Build a comprehensive employee database that holds attitudes, behaviours, and on-job performance together, as Google does, so you can track and monitor key metrics over time and feed them into models.
5. 5Frame the analysis as a system: specify inputs, transformation, and outputs, then classify the problem as classification, clustering, or association before choosing a tool. Test relationships between attitude metrics and business outcomes with correlation before committing to a predictive model.
6. 6Identify dependent and independent variables. Treat the business outcome (sales, revenue, attrition) as dependent and the attitude attributes as independent, so you can quantify how much each attitude contributes.
7. 7Segment employees by their attitude and performance profiles, learn what each segment values most, and treat each segment differently—tie interventions to career development and cultural norms, not only variable pay.
8. 8Present findings to the right stakeholders (analyst, line manager, and top executives for strategy), then define concrete actions and flag areas needing further investigation, such as a sub-group whose adverse attitude traces to pay dissatisfaction.

A global restaurant chain wanted to enhance customer satisfaction. Correlation analysis of historical frontline-employee data against customer satisfaction rates revealed a significant relationship between the two, so the firm decided that improving frontline retention would raise revenue. It built a model on more than 10,000 data points spanning individual employee, shift, restaurant, and financial and operational performance details, choosing unsupervised learning to cluster employees. The clusters were labelled 'socialisers', 'potential leaders', 'entrepreneurial taskmasters', and 'conservative taskmasters', with the last being most consistent in job performance. Crucially, performance depended strongly on career development opportunities and cultural norms rather than the variable compensation then being offered. Acting on these findings produced significant improvements in customer satisfaction, speed of service, sales, and attrition rates.

• If a variable like job satisfaction cannot be measured directly, then decompose it into named attributes (supervisor, pay, benefits, career growth) and quantify those instead.
• If the attribute is subjective, then apply a scaling technique (nominal/ordinal/interval/ratio) and decide rating vs. ranking before collecting data.
• If a decline in a business outcome could stem from either attitudes or product/quality, then test the attitude link first with correlation, and only build a predictive model once a significant relationship is confirmed.
• If analysis shows adverse attitudes concentrated in one segment or region, then isolate the driver (e.g., pay dissatisfaction among southern salespeople) and open a targeted follow-up investigation rather than acting chain-wide.
• If clustering reveals performance is driven by career development and cultural norms rather than variable pay, then redirect investment there and treat each employee segment differently based on what it values.

• Trying to quantify satisfaction as a single direct number. The tell: no list of attributes exists, so nothing can actually be measured or scaled.
• Choosing attitudes to collect arbitrarily. The tell: the analyst cannot cite experience, an expert, or a theory that justifies why those specific attitudes should affect the outcome.
• Jumping to a tool before classifying the problem. The tell: no decision was made on whether it is a classification, clustering, or association problem, so tool choice is unmotivated.
• Assuming variable compensation drives attitudes and performance. The tell: interventions ignore career development and cultural norms that the data actually shows matter more.
• Presenting statistical findings without the line manager or top executives. The tell: results never translate into a defined action plan, so no strategy or intervention follows.

• ▸Target attitude construct: name the evaluative state under study (e.g., job satisfaction, engagement, commitment).
• ▸Directly quantifiable? state yes/no; if no, proceed to decompose.
• ▸Associated attributes: list traits to measure (supervisor, subordinates, salary, benefits, career growth, cultural norms).
• ▸Scale per attribute: assign nominal / ordinal / interval / ratio and rating vs. ranking.
• ▸Data source: name the employee database fields and metrics tracked over time.
• ▸Dependent variable: the business outcome tied to the attitude (sales, revenue, attrition, customer satisfaction).
• ▸Relationship test: record correlation result linking attitude metric to outcome.
• ▸Segments identified: label employee clusters and note what each values most.
• ▸Action & follow-up: define the intervention, stakeholders to inform, and any sub-group flagged for further investigation.

1. 1Define the psychological state you are measuring before you write items: decide whether 'engagement' means organizational engagement (commitment to the firm) or psychological job engagement (mental focus/concentration), because that decision determines your item set and factor structure.
2. 2Build a multi-item scale that operationalizes each perception construct (job strain, engagement, job satisfaction, person-organization fit, perceptions of justice), grouping items so each sub-construct has enough items to be detectable — e.g. three items on organizational engagement and six on mental engagement.
3. 3Run exploratory factor analysis on the response pattern to confirm whether your items measure one construct or split into sub-factors; if two sets of responses emerge, you are measuring two constructs, not one.
4. 4Run reliability analysis on each confirmed scale (e.g. the four-item engagement scale in Example 2) before aggregating items into an index; do not build an 'engagement index' or 'inclusion index' from items that fail reliability.
5. 5Test group differences with the independent samples t-test (comparing engagement levels between two groups/functions) or one-way ANOVA for more groups, and use multiple regression to predict team-level engagement from context variables.
6. 6When tracking a changing work environment over time — e.g. stress levels every six months over two years, or commitment at three time points in a values-change project — use the one-way repeated measures ANOVA (same participants across time points).
7. 7Link the perception data to outcome data (task/contextual performance, well-being, intention to quit) and to context data (leadership, function, location, client profile) so the perception acts as the measurable mediator, not a stand-alone score.
8. 8Feed results back into business context and actions — screen survey comments alongside the quantitative scores so the numeric index is interpreted against what employees actually said.

A survey provider defines engagement as a blend of two ideas: mental concentration when people do their job, and a sense of commitment to the organization. Three items are written to tap organizational engagement and six to tap mental engagement linked to concentration. When responses come in, factor analysis of the pattern shows employees answer the two subsets differently, and a two-factor structure appears rather than a single engagement factor. This tells you the scale is measuring two sub-constructs, so aggregating all nine items into one engagement index would blur two distinct psychological states. The correct move is to report two scores, run reliability on each, and only then compare them — for instance using an independent samples t-test to see whether one function scores lower on organizational engagement than another, pointing to a leadership or fairness issue rather than a focus problem.

• If factor analysis reveals two response patterns from a supposedly single scale, then split it into sub-constructs and report each separately instead of one blended index.
• If you are comparing the same employees or teams across three or more time points (e.g. a merger or values-change project), then use one-way repeated measures ANOVA; if only two time points, use the paired samples t-test.
• If you want to compare engagement between two different groups or functions, then use the independent samples t-test; for more than two groups, use one-way ANOVA.
• If a scale item shows a response pattern inconsistent with the rest of the construct, then treat it as badly designed (measuring something other than the intended construct) and drop or revise it before building the index.
• If perception data sits isolated in HR, then link it to operational, customer and client-profile data before diagnosing, so you prescribe a fix that matches the actual problem rather than casting the whole foot when one toe is broken.

• Aggregating items into a single engagement or inclusion index without factor analysis — the tell: internal contradictions where the 'index' moves but sub-groups of items disagree.
• Treating engagement as mere job satisfaction or 'feeling happy at work' — the tell: your definition ignores discretionary effort, commitment to stay, and willingness to exceed stated job requirements.
• Keeping perception data siloed in the HR department — the tell: you can describe scores but cannot link them to revenue, customer satisfaction, or turnover outcomes.
• Using the wrong repeated-measures test for the design — the tell: applying an independent samples t-test to data where the same participants appear at each time point, ignoring the paired structure.
• Building indices from unreliable items — the tell: skipping reliability analysis, so a four-item scale is used even though its items do not hang together.

• ▸Construct name: the specific perception being measured (e.g. organizational engagement, job strain, perceptions of justice)
• ▸Definition: one-line operational definition distinguishing it from adjacent constructs
• ▸Item list: the survey items intended to tap this construct
• ▸Hypothesized factor structure: one factor or named sub-factors, with item counts per factor
• ▸EFA result: number of response patterns/factors actually found
• ▸Reliability score: reliability analysis outcome per scale/sub-scale — pass or revise
• ▸Comparison test chosen: t-test / one-way ANOVA / repeated measures ANOVA, with justification from design
• ▸Linked outcome/context data: which performance, turnover, well-being or context sources this construct is joined to
• ▸Action + business context: the decision or intervention this metric will inform

1. 1Define discretionary effort as an observable behavior scale, not a feeling. Write items that describe actions—'I work harder than my job requires', 'I put a huge amount of effort into my job', 'I help out my teammates', 'I go the extra mile'—rather than attitudes.
2. 2Use multiple indicators per construct so you can test reliability; single-item measures cannot be checked, so you cannot separate real variation from ambiguous wording or measurement error.
3. 3Attach a consistent frequency response scale (here 1 = I always do this to 5 = I never do this) and collect responses; the passage example has 832 employees complete the survey stored in 'Chapter 5 RAW Survey Results.sav'.
4. 4Run reliability analysis in SPSS: Analyze > Scale > Reliability Analysis, move the four items into the Items box, then under Statistics tick 'Item', 'Scale', and 'Scale if item deleted'.
5. 5Read Cronbach's alpha against the 0.70 threshold. If it falls below, inspect the 'Cronbach's alpha if item deleted' column to find the item dragging reliability down.
6. 6Drop the offending item when its removal materially raises alpha, and confirm the item's ambiguity through face validity reasoning before deleting.
7. 7Once you have a reliable behavior scale, feed it into predictive models (multiple regression, e.g. to predict team-level engagement or performance) rather than stopping at a descriptive snapshot that invites the 'So what?' response.
8. 8Connect the behavior back to hard outcomes—diversity work, for instance, is argued to 'engender greater discretionary effort', so model whether that discretionary-effort behavior actually links to retention, innovation, or team performance.

A four-item scale meant to measure discretionary effort / organizational citizenship behaviour is tested on 832 employees. The items are 'I work harder than my job requires', 'I put a huge amount of effort into my job', 'I help out my teammates', and 'I go the extra mile', scored 1 (always) to 5 (never). The full four-item Cronbach's alpha comes back as 0.681, below the 0.70 standard. The 'alpha if item deleted' column shows that removing 'I go the extra mile' would raise alpha to 0.787. That item carries high measurement error—likely because 'go the extra mile' is ambiguous and interpreted differently by different respondents. The hidden gem: the remaining three items form a coherent, reliable measure of OCB at alpha 0.787, so you retain those three and discard the fourth despite its intuitive face validity.

• If a construct matters for prediction, then measure it with multiple behavioral indicators—never a single item, because single items cannot be tested for reliability.
• If Cronbach's alpha is below 0.70, then examine the 'alpha if item deleted' column before trusting the scale.
• If deleting one item raises alpha meaningfully (e.g. 0.681 to 0.787), then that item carries excess unique variance and should be dropped.
• If an item has strong face validity but plausibly multiple interpretations (like 'I go the extra mile'), then treat high face validity as insufficient—reliability evidence overrides it.
• If your analysis only describes a snapshot ('12 per cent of senior managers are...'), then keep going to modelling, because a bare descriptive figure invites 'So what?' with no context.

• Measuring discretionary effort with one question. The tell: you cannot report a reliability figure and cannot tell whether response variation is real or wording noise.
• Keeping an item purely on face validity. The tell: alpha stays low (0.681) while the deletion column flags a clear improvement you ignored.
• Confusing attitude with behavior—writing 'I feel motivated' instead of 'I work harder than my job requires'. The tell: the scale drifts toward engagement/feeling rather than observable action.
• Stopping at descriptive dashboards. The tell: stakeholders respond 'So what?' or 'I'll look at this later' because the number has no benchmark or predictive link.
• Assuming the diversity–discretionary-effort benefit is automatic. The tell: you cite the business case but never quantify or model the link, and it stays 'difficult to quantify' and slow to realize.

• ▸Construct name: state the behavior being measured (e.g. discretionary effort / OCB)
• ▸Item list: write 4+ action-worded indicators, no feelings
• ▸Response scale: define anchors and direction (e.g. 1 = always to 5 = never)
• ▸Sample size: record number of completed responses (e.g. 832)
• ▸Full-scale Cronbach's alpha: enter value and mark pass/fail vs 0.70
• ▸Alpha-if-deleted per item: list each item's value
• ▸Item to drop: name the item whose removal most raises alpha
• ▸Revised alpha: enter alpha after deletion and confirm ≥0.70
• ▸Downstream model: note which predictive analysis will use the validated scale

1. 1Frame performance as a prediction problem: pick a measurable output (performance rating, sales revenue, resignation flag) as your dependent variable, then list candidate predictors you can actually pull — Social Network Score, Social Network Diversity Index, Competency/Skillsets Score, Personality Traits.
2. 2Build the productivity baseline before you model. Compute Revenue per FTE (Revenue / Permanent FTE) and Profit per FTE ((Revenue - Operating Cost) / Permanent FTE) so you know whether headcount is growing faster than revenue and whether you have the right people at the right price.
3. 3Add leading-indicator metrics that predict decline: Absenteeism Rate (Sick Days / Permanent FTE) and Overtime per Individual Contributor Headcount (Overtime Hours / Permanent IC Headcount). Rising values on either flag a disengaged workforce and future turnover.
4. 4Run a correlation in Excel's Data Analysis toolpack between each predictor and the performance output to see which relationships are strong enough to keep before building a regression.
5. 5Fit a multiple regression in Excel to predict the performance rating from Social Network, Skillsets, and Personality Traits; fit a logistic regression when the output is categorical (will resign / won't resign).
6. 6Convert the regression into a scoring rule: capture the coefficients so any employee's inputs produce a predicted rating or HiPo flag, then rank the workforce.
7. 7Tell the story with the ARHAT framework's Step 5 — know the audience (Executives), develop the narrative, and build visuals so non-technical stakeholders act on the finding rather than debating the math.

Using the book's ONA example, an employee is scored on three inputs: Social Network Score of 16, Social Network Diversity Index of 3, and Competency Score of 8. Feeding these into the multiple-regression model built in Excel NodeXL, the model predicts this employee is a high-potential (HiPo) with a performance rating of 9. The strength of the network variables means someone well-connected across diverse groups is predicted to perform higher than a comparably skilled but isolated peer. You then apply the same coefficient set across the whole roster to rank talent for succession and development spend. Because the inputs come from an ONA survey plus an existing competency record, the model reruns cheaply each cycle. The output feeds directly into a HiPo shortlist you can defend to executives with the visualized network graph rather than a gut call.

• If staff headcount is growing faster than Revenue per FTE, then stop hiring and diagnose before adding cost — the metric is warning you productivity per head is falling.
• If Overtime per Individual Contributor is consistently high, then hire additional employees, because sustained overtime drives up absence rates and turnover.
• If Absenteeism Rate is rising, then treat it as a leading indicator of future turnover and disengagement, not just a scheduling nuisance.
• If the output you're predicting is categorical (resign vs. stay, HiPo vs. not), then use logistic regression; if it's a continuous number (rating, sales, EBIT), then use multiple regression.
• If Readiness Ratio is well below 1 (e.g., 0.30), then flag a succession gap that predicts higher cost and slower growth while key roles sit vacant.

• Reporting raw numbers with no narrative — the tell is executives nodding but taking no action; the fix is ARHAT Step 5 (audience, narrative, visuals).
• Treating absenteeism and overtime as isolated HR admin metrics instead of engagement/turnover leading indicators — the tell is these rise for months before anyone links them to attrition.
• Skipping the correlation check and dumping every variable into a regression — the tell is a model with predictors that don't actually relate to performance, producing unstable coefficients.
• Judging productivity on Revenue per FTE alone while ignoring cost — the tell is a 'productive' team on revenue that is unprofitable once Profit per FTE is computed.
• Building a HiPo/performance score once and never rescoring — the tell is a stale shortlist while depletion ratio quietly climbs as top talent leaves.

• ▸Performance output variable: name the dependent measure (rating, sales, resignation flag).
• ▸Revenue per FTE: enter Revenue / Permanent FTE.
• ▸Profit per FTE: enter (Revenue - Operating Cost) / Permanent FTE.
• ▸Absenteeism Rate: enter Sick Days / Permanent FTE.
• ▸Overtime per IC Headcount: enter Overtime Hours / Permanent IC Headcount.
• ▸Predictor inputs: list Social Network Score, Diversity Index, Competency/Skillsets, Personality Traits per employee.
• ▸Model type: choose multiple regression (continuous) or logistic regression (categorical).
• ▸Predicted score / flag: record model output per employee (e.g., rating 9, HiPo yes).
• ▸Executive narrative + visual: one line on the finding, the audience, and the chart used to present it.

1. 1Define the prediction window and outcome first: model the probability an employee resigns voluntarily within a fixed period (e.g. next 12 months), using Voluntary Turnover Rate (Permanent Employee Resignations / Permanent Headcount) as the ground-truth label for training.
2. 2Assemble leading-indicator inputs the passages flag as predictive: absenteeism rate (sick days/FTE), overtime hours per individual contributor, Climate Culture Rating (% top ratings on 'good place to work'), Labour Cost per FTE vs benchmark, Glassdoor rating, tenure/age band, team connectedness, and ONA position (peripheral = flight risk).
3. 3Run a logistic regression with resignation (1/0) as the dependent variable and these indicators as predictors, following the book's 'Logistic Regression Example: Predict Staff Resignation' — this yields a per-employee probability score.
4. 4Cross-check the regression with a correlation pass ('Correlation Example: Predict Employee Flight Risk') to confirm each predictor actually moves with resignation before trusting the model.
5. 5Layer ONA metrics: identify peripherals (unconnected nodes) and score them as elevated flight risk, especially where they overlap with high performance (top-quartile performers).
6. 6Rank employees by Flight Risk score and restrict access to that scored list to senior managers trained in interpreting it — treat the score as confidential per the privacy warnings.
7. 7Trigger targeted interventions on high-score, high-value employees (Google's promotion signal, culture/connection fixes, compensation review) rather than broad programs.
8. 8Validate against actual outcomes each cycle: compare predicted high-risk cohort to who actually resigned, then re-fit.

Google's people analytics found that new salespeople who did not receive a promotion within four years were much more likely to leave. Translate that into a flight-risk model: for the sales population, create predictors including 'years since last promotion,' tenure, and performance quartile, then run logistic regression against a resignation label. A salesperson at year four with no promotion returns a high probability score; the manager sees this before the resignation. Cross-referencing Culture Amp's Box finding — connection to team matters more than pay or boss relationship — you add an ONA-based 'team connectedness' variable and flag peripherals. Glassdoor's data quantifies the lever: raising a company's overall rating by one star correlated with a four-percentage-point higher chance employees stay, so a low-culture-rating team member scores higher risk. The intervention for the year-four unpromoted, weakly-connected salesperson is a promotion/mobility conversation plus team integration, not a blanket perk rollout.

• If an employee is a top-quartile performer AND scores high flight risk, then escalate immediately — Total Top Quartile Performer Resignation Rate is the costliest loss.
• If an employee is a peripheral node in the ONA AND talented, then treat as flight risk regardless of survey scores.
• If absenteeism or overtime is rising for an individual or team, then read it as a leading indicator of future turnover and investigate before scores update.
• If Labour Cost per FTE is below benchmark or benefits % is low, then attribute part of the flight risk to compensation and route to a comp review, not an engagement program.
• If the Flight Risk score is to be shared, then restrict it to senior managers trained in interpretation and confidentiality — do not distribute broadly.

• Treating turnover intent as actual turnover: modeling only past resignations misses the antecedent state — the tell is you only find out after people have already left.
• Ignoring leading indicators (absenteeism, overtime) because they sit in Productivity metrics not Retention — the tell is a 'sudden' resignation that overtime data flagged months earlier.
• Over-weighting pay while ignoring connection and culture — Culture Amp/Box showed pay and boss matter far less than team connectedness; the tell is comp raises that don't reduce quits.
• Broadcasting Flight Risk scores without access control or interpretation training — the tell is privacy complaints, employees learning they were secretly scored, and eroded trust.
• Building the model on data employees don't know was collected or don't agree with — the tell is legal/union pushback; start in jurisdictions where laws allow and engage unions early.

• ▸Prediction window: fixed period the score covers (e.g. next 12 months)
• ▸Performance quartile: mark top-quartile — raises priority if high risk
• ▸ONA position: central / knowledge broker / peripheral (peripheral = elevated)
• ▸Years since last promotion: flag if exceeds role threshold (e.g. 4 for sales)
• ▸Absenteeism & overtime trend: rising / flat / falling (rising = warning)
• ▸Culture/connection signal: Climate Culture Rating or Glassdoor + team connectedness
• ▸Compensation position: Labour Cost per FTE and benefits % vs benchmark
• ▸Flight Risk score: logistic-regression probability (0–1)
• ▸Access & intervention: authorized senior manager + chosen action

1. 1Locate your organization on the maturity continuum first: descriptive (narrating events and metrics), predictive (forecasting future outcomes), or prescriptive (narration + prediction + recommendation). Most HR functions start descriptive; name your current level honestly before promising insight you cannot yet produce.
2. 2Establish the hROI discipline: for every human capital investment (a wellness program, an increment schedule, a hiring channel), define the metric that will validate its return in numbers, not narrative. Harrah's does this by measuring how wellness programs move engagement and how engagement moves revenue.
3. 3Integrate data sources before modeling. Assemble the attribute set that describes the outcome you care about — Experian used ~200 attributes including supervisor performance and commuting distance to predict attrition. Inventory which of those you actually hold, and note gaps.
4. 4Frame the problem using the LAMP framework and a process/systems view (Figures 1.1, 1.2): specify Logic, Analytics, Measures, and Process so the analysis connects to a decision, not just a report.
5. 5Choose the analytical class to the decision. If you need a forecast (promotion rates, staffing counts, attrition risk), use predictive tools such as ANN or KNN with R. If you need a recommended action by segment, move to prescriptive modeling as Nielsen did.
6. 6Validate outcomes with proper evaluation — cross-validation (Cv), AUC, lift charts (Figure 5.1) — before you circulate a prediction as decision-relevant. Unvalidated numbers erode the exact credibility hROI is meant to build.
7. 7Vary the HR action by employee life cycle. Predictive output should tell you when to act, not just who is at risk — e.g. new-hire first-year contact points versus tenure-based retention strategies.
8. 8Extend proven models outward: from internal workforce planning (matching forecast demand against current capability to size staffing gaps) toward managing the external employee supply chain as conditions shift.

Nielsen built a predictive model of turnover and retention, then converted it into prescriptive retention strategies segmented by employee tenure. For the first year of new hires, the model prescribes that establishing critical contact points is decisive for retention, so managers of new hires are reminded to contact them at those points. This is the capability progressing across the continuum: prediction (who leaves and when) becomes recommendation (what a manager should do, and by when). Compare Experian, which stayed at the predictive tier — computing attrition risk from ~200 attributes such as supervisor performance and commuting distance — and reduced turnover 2–3% over one year of implementation. Both start from integrated people data, but the prescriptive step is what turned Nielsen's forecast into a manager action. The lesson: capability is not owning a model; it is closing the loop from data to a validated, tenure-specific action.

• If you cannot yet state the hROI of a people investment in numbers, then you are at the descriptive tier — do not market predictions you cannot validate.
• If the decision needs a recommended action by segment (tenure, life-cycle stage), then build prescriptive on top of prediction rather than shipping a raw risk score.
• If a predictive model is going to drive a live HR decision, then evaluate it first with cross-validation and AUC/lift; if those are absent, treat the output as exploratory only.
• If two employee segments value different things (Convergys found six-month increments beat annual ones for retention), then vary the intervention by segment instead of applying one uniform policy.
• If your model lacks the attributes that actually explain the outcome (supervisor quality, commute, tenure), then fix data integration before adding algorithm complexity.

• Treating a dashboard as capability. Tell: leadership can narrate metrics but cannot say what action any number should trigger — stuck at descriptive while claiming predictive.
• Reporting predictions without validation. Tell: no AUC, cross-validation, or lift chart accompanies the forecast, and confidence rests on the tool's reputation rather than tested error.
• Chasing algorithms before data. Tell: the team debates ANN vs KNN while the attribute set omits drivers like supervisor performance or commuting distance that Experian found predictive.
• Prediction that never becomes action. Tell: an attrition risk score exists but no one has defined the life-cycle contact points or interventions, so nothing changes — Nielsen's prescriptive step is missing.
• Uniform interventions across segments. Tell: one retention policy for all tenures, ignoring that increment timing (Convergys) or first-year contact matters differently by segment.
• Confusing self-reported readiness with real capability. Tell: citing that only 39% report 'good' data and 31% know what best-in-class looks like (Deloitte 2017), yet assuming your own function is the exception without evidence.

• ▸Business question: the HR decision this analysis must inform (one sentence)
• ▸Current maturity tier: descriptive / predictive / prescriptive — with the evidence for that claim
• ▸Outcome variable: the people outcome being predicted (e.g. attrition, promotion rate)
• ▸Attribute inventory: predictive attributes needed vs. attributes actually held (list gaps)
• ▸Technique + tool: chosen method (e.g. ANN, KNN in R) and why it fits the decision
• ▸Validation plan: metric(s) to be used — cross-validation, AUC, lift chart
• ▸hROI definition: how the investment's return will be shown in numbers
• ▸Life-cycle / segment rule: how the recommended action varies by tenure or segment
• ▸Action owner + trigger: who acts, on what threshold, and by when

1. 1Map the five required competency areas against your current team: business acumen, HRM/HR process knowledge, data analytics/statistics, IT/data engineering, and marketing/storytelling (visualization and communication). Score each as present, thin, or absent.
2. 2Fill the HRM competency with people who have insight into recruitment, hiring, firing, and compensation, plus a scientific background in social sciences to identify relevant personnel factors (e.g. known turnover drivers studied since the 1930s) and to explain firm-specific findings against literature.
3. 3Fill the data analytics competency with an analyst who has statistical knowledge — correlation and regression at minimum, and predictive analytics and data mining for advanced work — and an aptitude for working with data and statistics.
4. 4Fill the IT competency with programming skills and knowledge of the company's IT infrastructure, because analysis requires aggregating data from different systems (e.g. Applicant Tracking System, Performance Review System).
5. 5Anchor the business competency in the operating model: start every project with an analytics question that matters to the business, and maintain intimate knowledge of what's going on so you can explain patterns and build a plan to act on them.
6. 6Fill the marketing/storytelling competency with someone who converts 'analytical numbers' into actionable visualizations and chooses the delivery channel (meeting, dashboard, or email) to fit the audience.
7. 7If any competency is absent, do not staff around it — either hire new people with the missing skillset or partner with departments that have it in abundance, specifically Finance and IT.
8. 8Operate cross-functionally like Alexander: coordinate with analytics counterparts across the rest of the organisation so a single question produces a board-ready set of recommendations.

A firm found employee turnover was especially high in its international division but could not explain why — a failure of the business/HR-context competency to interpret the data. The team combined skillsets: IT and data engineering aggregated data across systems, and the data analyst included the number of hotel bookings per employee as a variable, treating frequent international travel as a stress factor. The analytics competency surfaced a strong statistical relationship: hotel bookings and international flights predicted turnover, concentrated among recently married women in their thirties. The HR-context competency, backed by social-science literature on turnover drivers, explained the pattern — extensive travel strains relationships and these women often wanted to settle down. Because the driver was a factor the firm could influence relatively easily, the finding became actionable. This only worked because IT, analytics, and HR context were all present and integrated; missing any one would have left the result unfound or unexplained.

• If HR professionals don't know where to start or the required skills aren't historically present in HR, then hire new people with different skillsets rather than expecting HR generalists to self-upskill.
• If the missing skill is data engineering or financial modeling, then partner with IT and Finance where those skills exist in abundance instead of building from scratch.
• If a result contradicts a manager's or HR practitioner's gut feeling, then treat interpretation-and-communication as the binding constraint and lead with literature-backed explanation, not raw numbers.
• If your audience is managers, then send a monthly report by email rather than relying on a dashboard, because managers forget about dashboards and don't use them.
• If the project doesn't start from a question important to the business, then stop — the business competency is missing and the work will add no value.

• Business competency missing: the team commits to analyses that add no value (a fad) and managers don't act on the data. Tell — no one asked for the finding and nothing changes after delivery.
• Data analytics competency missing: the team gets stuck running simple analyses, failing to find cause and effect or build predictive models. Tell — output is descriptive reporting only, never explanatory.
• IT competency missing: the team struggles to obtain and aggregate all the relevant data across systems. Tell — analysis stalls at data collection or relies on a single incomplete source.
• HR-context competency missing: the team struggles to interpret outcomes and build valid models, and results seem inexplicable. Tell — a real driver like hotel bookings is never tested because no one knows the HR literature or the business.
• Marketing/storytelling competency missing: HR analytics fails to be adopted by the business. Tell — correct findings sit in a dashboard that managers ignore instead of a channel they open.

• ▸Business acumen — name the person; do projects start from a business-important question? (present/thin/absent)
• ▸HRM/HR process — who covers recruitment, hiring, firing, compensation and social-science research background?
• ▸Data analytics — who can run correlation, regression, and predictive/data-mining models?
• ▸IT/data engineering — who has programming skills and knowledge of the IT infrastructure to aggregate sources?
• ▸Marketing/storytelling — who converts numbers into visualizations and picks the delivery channel?
• ▸Gap-fill plan — for each absent/thin area: hire new skillset or partner with which department (Finance/IT)?
• ▸Cross-functional counterparts — which analytics contacts elsewhere in the org will you coordinate with?
• ▸Delivery channel per audience — meeting / dashboard / monthly email, matched to who acts on it
• ▸Failure-mode check — which of the five 'what if a skillset is missing' symptoms are currently showing?

1. 1Start from a top-three strategic business issue, not from the data — confirm the question matters to the CEO/CFO before analyzing. If average tenure is 15 years, flight-risk prediction is not worth pursuing.
2. 2Screen every finding for actionability: separate manipulable drivers (engagement, safety policy, L&D) from fixed control variables (sex, age). Report and act on drivers; keep fixed attributes as controls only.
3. 3Translate 'analytical numbers' into a single stupidly simple message before choosing any visual — decide the one thing the audience should do.
4. 4Match delivery channel to how central the data is to daily work: use a self-service dashboard only for data managers touch daily; otherwise a monthly/quarterly PDF emailed to their inbox, since dashboards get forgotten.
5. 5Design the presentation layout deliberately: decide where graphs sit and reject weak visuals (e.g., don't use a speedometer for an engagement score if a clearer format exists).
6. 6Pair every finding with a concrete follow-up intervention plan — never present a problem without at least having thought about how to fix its root cause.
7. 7Decide the audience and access controls before sharing — restrict individual-level risk scores so a manager cannot confront an employee with a raw '80% chance you will leave' figure.
8. 8Integrate into existing communication flow where possible: a short, well-timed message in a tool like Slack can beat an entire HR dashboard.

Credit Suisse (~48,000 employees) faced high turnover with costs estimated in the tens of millions but hard to pin down. Rather than reporting the abstract turnover percentage, analysts identified the factors that predicted turnover — the manipulable drivers — and connected them to a dollar figure the CFO cares about. The reframed message was operational: a one-point reduction in turnover saves $75–100 million. That translation from an 'analytical number' to a business-impact story is what prompted action and interventions. Contrast this with a finding that sex predicts turnover intentions: interesting, but you cannot change an employee's sex, so it holds no value until you ask WHY and find something you can influence. The lesson is that impact came from actionability plus a message tied to a strategic priority, not from the sophistication of the model.

• If the driver cannot be changed (sex, age), then keep it as a control variable and do not present it as an actionable recommendation.
• If the data is not part of managers' day-to-day work, then send a scheduled email/PDF report instead of relying on a self-service dashboard.
• If the finding contradicts a manager's gut feeling, then invest extra effort in visualization and a simple message, because the numbers alone will not persuade.
• If a finding has no concrete follow-up intervention, then do not present it — build the intervention plan first.
• If the analysis targets an individual (e.g., flight risk score), then restrict who receives it to prevent misuse in direct confrontation.

• Producing dashboards no one uses — the tell: managers never log in and the data goes unread; switch to a pushed report.
• No translation to actionable insights — the tell: the finding is fascinating but nobody can take action (e.g., 'sex impacts turnover intentions').
• Analyzing data before a business-driven plan — the tell: intriguing insights with no connection to the core business; analytics becomes a fancy HR showpiece.
• Showing complicated statistical models to time-poor executives — the tell: eyes glaze over and the model is not adopted.
• Over-cluttering with irrelevant numbers — the tell: you drown the business in data instead of delivering one simple message, so nothing changes.

• ▸Strategic issue: name the top-three business challenge this finding serves
• ▸Single message: state in one plain sentence what the audience should conclude
• ▸Actionable driver: name the manipulable factor (not a fixed control) to act on
• ▸Business impact: express the finding in the audience's terms (e.g., dollars, risk)
• ▸Audience: who decides/acts, and what access they should (not) have
• ▸Channel: dashboard, emailed PDF report, meeting, or app message — justify by data centrality
• ▸Visualization choice: the graph type and layout placement; reject weak visuals
• ▸Follow-up intervention: the concrete action that addresses the root cause
• ▸Cadence: how often this is delivered and what reminds the audience to act

1. 1State the assumption you are testing as a falsifiable question, e.g. 'Can our hiring managers predict new-hire performance?' — not a vague desire to 'use data'. Google framed exactly this question before touching a spreadsheet.
2. 2Pull the HR data you already amass but rarely use — interview scores, training records, appraisal outcomes — and connect each to a measurable business outcome (actual performance, sales, attrition), so you compare prediction against reality.
3. 3Run the numbers to test the assumption directly: compare what decision-makers predicted against what actually happened. Google's task force compared interviewers' predictions to new hires' actual performance.
4. 4Convert the finding into a single defensible number and, where possible, a dollar amount and ROI, so HR speaks the organization's language and can show impact on the business.
5. 5Re-analyze before you act: did you answer the question you asked or a different one? Did you include all relevant factors (labor market, hierarchy, environment)? If not, cycle through the analytics process again.
6. 6Redesign the decision process to remove human bias — structure it. Google automated interviews with qDroid, which supplies tested, predictive questions so interviewers don't invent their own biased ones, then rate on specific scales.
7. 7Force the change even against resistance: everyone still wanted to interview the new hire, so Google made a top-down call to cap interviews at four, because data showed no gain past the fourth.

Google's managers each spent roughly five to ten hours interviewing every new hire, assuming they were hiring world-class performers — an assumption they had never tested. A small task force of data scientists compared interviewers' predictions of future performance against the actual performance of new hires. The interviews reliably predicted only whether the interviewer liked the candidate, not who would perform better; a bad first impression at the handshake was almost impossible to reverse. The data also showed that after the fourth interview, managers were no better at estimating performance than after the tenth. Google acted on the evidence: it capped candidates at four interviews and built qDroid to supply extensively tested, job-performance-predictive questions, converting each candidate's rated answers into a single predictive number. This is evidence-based decision-making — validating an untested assumption with data and redesigning the process to be both more efficient and more effective.

• If a decision rests on a manager's hunch that has never been tested against outcomes, then run the numbers before trusting it — humans are poor predictors of performance.
• If an algorithm predicts even 30% of future performance, then prefer it to human gut feel, because it already outperforms humans by far.
• If additional inputs (extra interviews, more effort) stop improving prediction accuracy, then cap them — Google saw no gain past the fourth interview.
• If you cannot connect a people policy to a business outcome and express it as an ROI or dollar amount, then you have measured efficiency, not effectiveness, and haven't yet done evidence-based HR.
• If a finding is surprising or interesting, then re-analyze and check for omitted context (labor market, self-fulfilling prophecy, hierarchy) before acting.

• Measuring efficiency instead of effectiveness — managing HR 'as economically as possible' while never calculating whether policies actually work. The tell: cost-per-head metrics with no link to performance or business outcomes.
• Confirmation bias / self-fulfilling prophecy — expecting an outcome, then including only confirming evidence. The tell: your results conveniently match the hypothesis you started with.
• Ignoring environmental context — running attrition analysis without the national labor market, so you can't explain year-to-year churn differences. The tell: results that don't reconcile with reality.
• Answering the wrong question — reporting a finding without checking it addresses the original question. The tell: new questions pop up that you skip past instead of cycling back through.
• Trusting gut over tested numbers even after evidence contradicts it — 'no manager would believe his hunch was incorrect.' The tell: decision-makers demanding to keep an unproductive practice (interviewing the new guy) despite the data.

• ▸Untested assumption: state the belief driving the decision in one sentence
• ▸Falsifiable question: rephrase it as a testable question (e.g. 'Can X predict Y?')
• ▸Existing data source: which HR data you already hold that bears on this
• ▸Business outcome to connect: the actual result you'll compare predictions against
• ▸Prediction vs. reality check: how you'll compare what was expected to what happened
• ▸Confounding factors to include: labor market, hierarchy, expectations, environment
• ▸Single number / ROI: the metric and dollar value the finding converts to
• ▸Bias-removal redesign: the structured change (e.g. standardized questions) you'll make
• ▸Re-analysis note: did you answer the original question — yes/no, and what to re-run

1. 1Start from a decision known to be bias-prone (hiring, promotion, pay) where the same choice is made repeatedly and identically across candidates — this is where structure pays off. Do not start with a rarely-made or one-off decision.
2. 2Test your current assumption before redesigning: measure how well the existing method predicts the outcome you care about. Google measured whether interviewers actually predicted new-hire performance before changing anything.
3. 3Remove interviewer discretion over inputs: build a fixed question set rather than letting each evaluator invent their own. Google's qDroid app supplies questions by function so interviewers do not formulate their own — this is the mechanism that cuts bias.
4. 4Validate the questions against the outcome: only keep items that have been tested and proven to predict job performance, then score candidates on specific, defined scales rather than overall impression.
5. 5Convert scattered ratings into a single quantified output. Google stores answers in-app, rates on specific scales, and converts everything to one number shown to be highly predictive of future performance.
6. 6Standardize the process across all subjects so comparisons are like-for-like, and cap the volume of subjective touchpoints (Google forced no more than four interviews per candidate) so more human judgment does not creep back in.
7. 7Re-audit for hidden influence: check whether context (manager, labor market) or your own expectation (self-fulfilling prophecy) shaped the result before you trust it.

An investigation by BBC Radio Five Live sent out job applications with identical CVs but different names. 'White candidates' (John Andrews, Jenny Hughes) were invited to interview 23% of the time; 'Black African applicants' (Abu Olasemi, Yinka Olatunde) 13%; 'Muslim candidates' (Fatima Khan, Nasser Hanif) only 9%. Same qualifications, wildly different callback rates — evidence of unconscious bias operating even at organizations actively promoting diversity. The lesson for structured methods: had the screen scored applications only on validated, job-relevant criteria (as Google's qDroid does with tested questions), the name would carry no weight because it never enters the scoring. The bias here lives in the unstructured, discretionary step — the human reading the name — which is exactly the step structure removes.

• If the same decision is made repeatedly and identically across many people (hiring, promotion), then structure and automate the inputs; if it is a rare one-off, the payoff is too small to justify the build.
• If interviewers formulate their own questions, then bias is uncontrolled — replace with a fixed, function-specific question set before doing anything else.
• If a question or scale has not been tested against the actual outcome (job performance), then do not include it in the score.
• If you found exactly the result you expected, then re-analyze for the self-fulfilling prophecy: you may have looked for confirming evidence and ignored the contrary.
• If two people are compared but sit under different managers or different labor-market years, then treat context as part of the model — an untracked manager or environment can fake a bias finding.

• Adding structure but leaving evaluators free to invent their own questions — the tell: two interviewers of the same candidate ask completely different things, so scores are not comparable.
• Trusting your redesigned process without validating it against outcomes — the tell: you have a slick scoring sheet but no evidence the scores predict performance, exactly the untested assumption Google exposed.
• Piling on more human touchpoints thinking more judgment reduces error — Google's people spent 100,000+ hours interviewing over ten years with no better hires; the tell is high effort with flat outcome quality.
• Confirmation via self-fulfilling prophecy: expecting a group or person to perform a certain way, then unconsciously feeding the evidence that proves it — the tell is a result that perfectly matches your prior with no surprises.
• Ignoring environmental context when comparing people, so a labor-market or manager effect gets misread as an individual/bias signal — the tell: attrition or performance gaps you cannot explain year over year.

• ▸Decision being made — name the exact people-decision (e.g. interview scoring) and confirm it repeats across candidates
• ▸Current method audit — how is it decided today, and have you measured whether it predicts the outcome? (yes/no)
• ▸Target outcome — the single measurable result the decision should predict (e.g. future job performance)
• ▸Fixed input set — list the standardized, function-specific questions/criteria every subject faces identically
• ▸Validation status — for each criterion, note whether it has been tested against the target outcome
• ▸Scoring scales — the specific defined scales used to rate each answer, replacing overall impression
• ▸Single output number — how ratings are combined into one predictive score
• ▸Discretion cap — limits on subjective touchpoints (e.g. max interviews) to stop judgment creeping back
• ▸Context/expectation check — managers, labor market, and your own prior expectation reviewed for hidden influence

1. 1Start from a business question that matters, not from available data: frame HR's contribution as something the business already cares about (e.g., 'Can a hiring manager predict employee performance?' or 'What is turnover costing us?').
2. 2Convert the people problem into a numeric rating and a dollar amount so HR speaks the organization's shared language: numbers.
3. 3Calculate the ROI of the people policy in question — show the added value in money terms, since human capital is nearly 70% of operating expenses and the workforce changes fastest.
4. 4Assemble the three skillsets analytics requires: someone who knows the IT infrastructure to obtain and aggregate data, an analyst with statistics aptitude to build valid models, and a communicator who translates 'analytical numbers' into actionable visualizations.
5. 5Present results against gut feeling directly: expect the numbers to contradict a manager's hunch (Google proved managers could not predict performance), and prepare to defend the evidence.
6. 6Match the communication channel to the audience — meeting, dashboard, or email — and choose the visualization that fits that channel, because how you communicate the data influences its impact.
7. 7Use analytics to measure the effectiveness of your own policies (leadership training, sales training, appraisal systems, hiring quality) so HR moves from 'fee burner' to a discipline that demonstrably earns the business money.
8. 8Pursue the strategic seat deliberately: quantify impact repeatedly to earn a CHRO-style board role, recognizing HR becomes a true business partner only once it quantifies its own impact and actively influences decisions with data.

Google asked whether a hiring manager could predict a new employee's performance. According to the literature they could not — yet no manager would believe his hunch about a new hire was worthless. Google ran the numbers instead of relying on gut feeling, and the analytics showed selection could be improved. By selecting better candidates, the company built a stronger and more suitable workforce and added to long-term profitability. The strategic point is not just 'better hires' — it is that HR demonstrated, in numeric and dollar terms, that its practices contributed to the business. That demonstrated contribution is exactly what shifts HR from support assistant to serious business partner.

• If HR relies on gut feeling to defend a policy, then it stays a business assistant; convert the claim into a numeric rating and ROI to be taken seriously.
• If even a weak algorithm predicts 30% of future performance, then prefer it over human judgment — humans are bad decision-makers and this already outperforms them by far.
• If your finding contradicts the manager's intuition, then interpret and communicate it carefully rather than softening it — that contradiction is the point of evidence-based HR.
• If one of the three skillsets (IT/data, statistics, business communication) is missing, then do not launch: without communication HR fails to be adopted; without stats you build invalid models; without IT you cannot aggregate the right data.
• If a result comes from another firm's context, then do not assume it generalizes — people research suffers a reproducibility crisis, so analyze for your firm, since workload is perceived differently at a Big 4 firm than at a local municipality.

• Managing HR purely for efficiency and cost reduction — the tell: policies are justified by 'cheaper' rather than by measured effectiveness, so HR stays a 'fee burner.'
• Committing to analyses that add no value to the business (a fad) — the tell: the team runs analyses no manager asked for and no decision changes as a result.
• Getting stuck on simple analyses that never reach cause-and-effect or predictive models — the tell: dashboards describe the past but never answer 'will this policy have the effect we want?'
• Leaving results as raw analytical numbers — the tell: findings are technically correct but managers don't act on them because they were never turned into actionable visualizations matched to the audience.
• Trusting unconscious bias in decisions — the tell: identical CVs get different callback rates (BBC test: white 23%, Black African 13%, Muslim 9%) while everyone believes they are being rational and fair.

• ▸Business question: the decision the business already cares about, phrased as a question
• ▸Current basis for decision: is it gut feeling or evidence? name the hunch being challenged
• ▸Numeric rating: convert the people problem into a single measurable number
• ▸Dollar impact / ROI: added value or cost in money terms (tie to the ~70% human-capital spend)
• ▸Data sources & aggregation: which systems, who owns the IT access to pull them
• ▸Model & validity: analysis method used and why it is valid for your firm's context
• ▸Contradiction check: where does this result oppose a manager's intuition, and how will you defend it
• ▸Communication channel & visual: meeting / dashboard / email + the visualization chosen for it
• ▸Decision requested: the specific action or approval you want the business to take

1. 1Stop the peanut-butter approach: instead of spreading the same training or staffing investment evenly across the organization to appear fair, identify the roles and units where improved talent moves strategic outcomes most, and concentrate spend there.
2. 2For any intervention, map it through the three-part talentship chain: efficiency (spend to programs/practices produced), effectiveness (programs to change in talent quality or organizational state), impact (that change to strategic success). Assign a measure to each link, not just the efficiency link most HR systems default to.
3. 3Choose the analysis type deliberately: use cost-effectiveness (C/E) when comparing alternative programs aimed at the same non-monetary goal, and cost-benefit/ROI when you must decide whether the program should exist at all.
4. 4For ROI, itemize inflows (measured savings vs. a prior-year baseline: absenteeism, health-care, turnover, productivity), the offsetting outflows (program investment), the timing of each across future periods, and a discount rate for risk and inflation. Compute ROI = total expected benefit / program investment.
5. 5Set the level of analysis to match the strategic question. Because interventions and outcomes (store sales, customer satisfaction, unit ROI) usually live at the work-unit or business-unit level, aggregate attitudes/engagement to that level even when individual-level relationships look weak.
6. 6Before crediting an intervention, screen for symptom substitution and confounds: verify that a drop in the target metric (e.g., absenteeism) is not offset by rises elsewhere (tardiness, idling, lower productivity, turnover), and use multivariate controls when linking spend to distant outcomes like stock price.
7. 7Evaluate interventions as a portfolio, not one at a time. Ask whether pairing a program (e.g., training) with a complementary lever (e.g., individual incentives tied to training outcomes) would raise combined value beyond the standalone ROI.

A hospital ran a positive-incentive attendance program across 164 employees. Absenteeism fell an average of 11.5 hours per employee (32 percent) during the incentive period. Savings were computed as 11.5 hours × average hourly wage $29.35 × 164 employees = $55,362 per year. The direct cost was 2,194 bonus hours × $22.58 = $49,540, giving net savings of $5,822 and an ROI of $5,822 / $49,540 = 11.75 percent. The passage flags cautions: employees who treat sick leave as an earned right may not respond, and the decline could mask symptom substitution (tardiness, idling, turnover). The analysis holds only if those offsets are checked; otherwise a positive ROI overstates the true effect.

• If you must decide whether a program should exist at all, then use cost-benefit/ROI, not C/E — C/E only compares alternatives pursuing the same goal and can't justify existence.
• If a target metric improves but adjacent metrics (tardiness, productivity, turnover) worsen, then treat it as symptom substitution and escalate to comprehensive interventions informed by focus groups and targeted attitude surveys.
• If the strategic question concerns unit performance (sales, customer satisfaction, ROI), then aggregate attitudes/engagement to the work-unit level even when individual-level correlations are weak — relationships are often stronger and more stable at aggregate levels.
• If you're evaluating one HR investment in isolation, then also model it as part of a portfolio, because complementary levers (incentives tied to training) may raise combined value.
• If benefits and costs span multiple future periods, then discount future flows for risk and price inflation before reporting ROI.

• Reporting only efficiency measures (cost per training hour, cost per hire) and calling it strategic — the tell: you can state what was spent but cannot show any change in talent quality or in a strategic outcome.
• Spreading equal investment everywhere to be 'fair' — the tell: leaders and employees show justifiable skepticism about programs everyone 'must do,' and returns look diffuse and unremarkable.
• Crediting a program for a metric drop without checking offsets — the tell: absenteeism falls but tardiness, idling, or turnover quietly rise, and no focus-group/attitude data was collected to confirm.
• Analyzing at the wrong level — the tell: weak individual-level attitude-behavior correlations lead you to abandon an engagement intervention, missing strong aggregate work-unit or business-unit relationships.
• Trusting a single clean ROI number — the tell: the calculation hides subjectivity in which inflows are counted, how they're timed, and the discount rate chosen, and ignores portfolio interactions.

• ▸Intervention & target unit: name the program and the specific roles/units where talent matters most
• ▸Efficiency measure: cost per unit of program produced (e.g., cost per training hour, bonus hours × wage)
• ▸Effectiveness measure: the change in talent quality or organizational state (e.g., skill gain, engagement level)
• ▸Impact measure: how that change moves a strategic outcome (unit sales, customer loyalty, ROA/EPS, stock price)
• ▸Baseline savings: absenteeism, health-care, turnover, productivity gains vs. prior-year baseline
• ▸Program investment: total outflow (consultant fees, bonus hours, overhead pulled from SG&A)
• ▸ROI: total expected benefit ÷ program investment, with future flows discounted for risk/inflation
• ▸Symptom-substitution check: adjacent metrics monitored (tardiness, idling, turnover) and confirmed not rising
• ▸Portfolio note: complementary levers that could raise combined value (e.g., incentives tied to training outcomes)

1. 1Fix the business question before touching data: move from the descriptive form ('How many hours of training did our Sales employees clock last year') to the predictive form ('What is the impact of the training programme on Sales?'). The second question is what justifies budget.
2. 2Evaluate every training program against the Kirkpatrick Model's four levels (Reaction, Learning, Behavior, Results) and add Jack Phillips' fifth level (ROI). Do not stop at Level 1 satisfaction scores — those tell you nothing about impact on the business.
3. 3Compute training ROI to a financial figure by translating results into monetary value, then push it further to compute the impact of Training on Earnings Per Share (EPS) so the number lands with finance stakeholders, not just HR.
4. 4Build a predictive model with Excel's Analysis ToolPak: run a Multiple Regression to predict training's Impact on Customer Service, using training as an input variable and the customer service metric as the output.
5. 5Interpret each regression coefficient as the change in the output per unit of the input, hold the significance (p-value) test to confirm the training variable is not noise, then state the prediction in plain business terms.
6. 6Close with the ARHAT story-telling step: know your audience (finance and L&D leadership), develop the narrative around the ROI/EPS number, and build the visuals (clustered column or combination chart) so the analytic converts into a decision to fund or cut the program.

Take the passage's Multiple Regression example: 'Predict training's Impact on Customer Service.' You gather each employee's training hours (input) alongside their customer service score (output) from the HRIS, since the HRIS reports descriptive facts like total training hours but cannot itself find the correlation. You load the data into Excel's Analysis ToolPak regression tool and read the coefficient for the training variable: it quantifies how much the customer service score rises per additional training hour. You confirm the p-value shows the relationship is not random, then you tell the story — for example, an employee's predicted customer service rating increases by the coefficient amount for each hour of training, which lets L&D defend the program's continuation. You elevate this to Level 5 by converting the service gain into dollars and finally into EPS impact, mirroring the Hilton Worldwide University and JetBlue University cases that measured training's business impact predictively.

• If your training report shows only 'total training hours' or satisfaction scores, then you are stuck at Kirkpatrick Level 1 and descriptive analytics — escalate to Level 3/4 and a predictive model before claiming impact.
• If a stakeholder is finance, then translate training results to ROI (Phillips Level 5) and EPS impact; a behavior-change number alone will not move a budget conversation.
• If the regression coefficient for training is present but its p-value is high, then treat the training-performance link as unproven and do not fund on that basis.
• If you can pose the descriptive question ('how many hours') you can always develop its predictive counterpart ('what is the impact') — always pair them so you know which analytics level you are operating at.
• If HRIS is your only source, then use it for demographics and training-hour descriptions but pull in outcome data (sales, customer service) and run correlation/regression separately, because HRIS cannot discover patterns.

• Stopping at Level 1 reaction scores: the tell is a slide full of 'learners rated the course 4.5/5' with no link to any performance or revenue metric.
• Reporting training hours as if they were impact: the tell is a dashboard of 'total training hours by department' presented as proof of L&D value with no output variable.
• Skipping the significance check: the tell is a confident claim built on a regression coefficient whose p-value was never reported or examined, so noise gets sold as effect.
• Never reaching finance language: the tell is an accurate behavior-change finding that gets ignored because it was never converted to ROI or EPS impact.
• Confusing correlation with a defensible causal claim: the tell is a bold statement that 'training caused the improvement' from a single correlation, without the diagnostic 'why' step or controls.

• ▸Program name & business question: write the predictive form ('What is the impact of X training on Y?')
• ▸Level 1 Reaction: capture satisfaction score and note it is not impact
• ▸Level 2 Learning: capture pre/post skill or knowledge gain
• ▸Level 3 Behavior: define the on-job behavior metric being tracked
• ▸Level 4 Results: name the business output (e.g., customer service score, sales revenue)
• ▸Regression setup: list input variable (training) and output variable, tool = Excel Analysis ToolPak
• ▸Coefficient & p-value: record the training coefficient and whether p-value confirms significance
• ▸Level 5 ROI / EPS: convert the results into dollar value, then into EPS impact
• ▸Narrative & visual: one-line story for finance + chosen chart (clustered column / combination)

1. 1Pull ethnicity composition from your HRIS as a descriptive baseline (e.g. 70% Chinese : 20% Malay : 10% Indian) — HRIS reports the demographics but will not surface correlations, so this is only the starting input.
2. 2Convert the ethnicity mix into a single diversity index number (the passages work an example that resolves to an index of 2.7); this scalar lets you use diversity as one variable in a model.
3. 3Assemble the outcome and control variables you want to predict — the passages predict Sales using diversity index plus advertising spend (e.g. $90) — so gather revenue, EBIT, market share, and cost drivers alongside the index.
4. 4Load the data into R and run Multiple Regression to predict diversity's impact on Sales, Revenue and EBIT; R runs the regression from a few commands with no need for paid software like SPSS.
5. 5Frame the analysis with the ARHAT five steps: ask the question, review literature (cite the Deloitte and market-share cases), formulate a hypothesis (diversity correlates with the outcome), analyze the data, then tell the story to a known audience with a clear narrative and visuals.
6. 6Test related inclusion outcomes: the Deloitte case links diversity and inclusion to actual absenteeism, so run correlation between your diversity/inclusion measures and absenteeism records to check the belonging dimension, not just headcount mix.
7. 7Cross-check against employment law before acting on results — Griggs v. Duke Power (1971) bars practices that discriminate even via ability tests, and Johnson v. Transportation Agency (1987) permits sex as one flexible factor in promotion where women are underrepresented.
8. 8Move up the maturity ladder: use descriptive analytics for the current mix, diagnostic to ask why, predictive (the regression) for likely impact, and prescriptive to recommend which composition or spend to target.

You want to know whether ethnicity diversity affects sales. Your workforce mix is 70% Chinese : 20% Malay : 10% Indian, which you convert into a diversity index of 2.7. You add a control variable — advertising spend of $90 — and load both alongside historical sales into R. Running R's Multiple Regression function, you predict company sales given a diversity index of 2.7 and $90 of advertising. This mirrors the book's Case 3, 'Diversity Improves Market Share, Revenue, and EBIT.' You can extend the same regression to test the Deloitte finding that diversity and inclusion correlate with actual absenteeism.

• If you only need to know the current workforce composition, then use HRIS/descriptive analytics; if you need to know its impact on sales or EBIT, then move to predictive Multiple Regression.
• If ethnicity is expressed as percentages, then convert it to a single diversity index before modeling so it becomes a usable regression variable.
• If a selection or promotion practice screens out a protected group, then check it against Griggs v. Duke Power — the practice must not be designed, intended, or used to discriminate.
• If women or minorities are underrepresented in a role, then sex or minority status may be considered as one flexible, case-by-case factor per Johnson v. Transportation Agency, not as a rigid quota.
• If your question is 'what is the demographic makeup' it is descriptive; if it is 'what impact does the makeup have on outcomes' it is predictive — pick the analysis type to match the question.

• Stopping at the HRIS demographic report and calling it diversity analytics — the tell: you can describe the mix but cannot state its effect on any business outcome.
• Feeding raw ethnicity percentages into a model instead of converting to an index — the tell: no single diversity variable exists to regress against sales.
• Omitting control variables like advertising spend — the tell: sales differences get wrongly attributed entirely to diversity.
• Acting on regression results without legal review — the tell: a screen or promotion rule that adversely affects a protected group and echoes the Griggs violation.
• Treating an affirmative action factor as an absolute quota rather than a flexible one — the tell: the plan is rigid instead of the moderate, case-by-case approach upheld in Johnson.

• ▸Workforce ethnicity mix: enter each group's percentage (e.g. 70/20/10).
• ▸Diversity index: record the computed index number (e.g. 2.7).
• ▸Outcome variable: name the business metric to predict (Sales, Revenue, EBIT, or absenteeism).
• ▸Control variable(s): list confounders such as advertising spend ($90) or region.
• ▸Analysis level: mark descriptive, diagnostic, predictive, or prescriptive.
• ▸Hypothesis: state the expected diversity-to-outcome relationship (ARHAT step 3).
• ▸R method: specify Correlation or Multiple Regression.
• ▸Legal check: note Griggs / Johnson compliance status for any resulting action.
• ▸Audience & narrative: name who receives the result and the one-line story.