Root Cause Analysis For HR Requests

Root cause analysis in HR starts by rewriting the request as a problem statement.

The statement names the decision, who takes it, the criteria, the constraints, the accuracy required and the date.

The practitioner then splits the problem into parts until one cut shows where it sits, and tests each candidate cause against evidence before anyone agrees a solution.

A technology director says attrition is too high and asks for a retention strategy.

A practitioner who accepts that wording starts designing a strategy for a cause that nobody has identified.

Peter Block calls the client's first description the presenting problem, and says he never accepts it as the real problem without his own discovery and analysis.

Why Requests Arrive As Solutions

A manager who feels pain in a function starts to explain its cause, and then asks for the remedy that follows from the explanation.

Block observes that when the manager's account of the cause is accurate, the manager's own attempts at a solution usually succeed.

By the time a request reaches HR those attempts have usually failed, which suggests that the account of the cause was wrong.

Harless observed that organisations facing a problem look for solutions before the problem is defined or any alternative has been considered.

Kaufman and Guerra-Lopez define a need as a gap between current results and desired results, and stress that the gap lies in results and not in processes, methods or means.

A workshop, a retention strategy and a new appraisal form are all means, so the first task is to find the result each one is meant to change.

Conn and McLean list four common failures in problem solving, and the first two happen before any analysis starts.

• Weak problem statements. They lack specificity, the decision maker's criteria and constraints, the action that follows if the problem is solved, and a time frame and required accuracy

• Asserting the answer. The answer rests on experience or analogy, and is shaped by availability, anchoring or confirmation bias

Conn and McLean call rushing into analysis with a vague statement a clear formula for long hours and frustrated clients.

A Retention Request Redefined

Block describes a large technical organisation that could not keep new employees beyond two or three years.

Managers asked the first-line supervisors why the younger people left, and the supervisors gave three reasons.

Salaries did not match the local cost of living, housing was scarce and expensive, and young people wanted too much too soon.

Top management accepted all three, adjusted pay for short-service employees, opened a housing section in the personnel department and held workshops on the realities of a business career.

A year and a half later turnover was no lower, and in some sections it was higher.

Management then asked the company's training group, acting as internal consultants, to look at the problem.

The training group interviewed first-line supervisors and short-service employees, and the employees gave a different account of why people left.

• An orientation on company vision, mission and culture

• No responsible assignment for almost a year

• No accurate feedback from supervisors on how they were doing

• Supervisors with no time for new hires under pressure to deliver perfect work

The training group redefined the problem as one of insufficient support, attention, meaningful tasks and feedback for new hires.

Block points out that this moved the cause from one that no one in management held responsibility for to one where management was a player.

He describes it as a move from the language of innocence, which blamed salary, housing and expectations, to the language of accountability.

Supervisors and new hires then agreed how much time they would spend together, which tasks the new hire would carry and when feedback would come.

Management supported supervisors in giving that time.

Turnover levelled off over the following year and began to fall in the second year.

The first three interventions rested on the supervisors' account alone, and the employees were not interviewed until the second attempt.

What A Problem Statement Contains

Conn and McLean list six characteristics of a good problem statement.

• Focused on outcomes, not activities or outputs

• Specific and measurable wherever possible

• Clearly bound in time

• Explicit about the decision maker's values and boundaries, including the accuracy needed

• Wide enough to allow unexpected answers

• Solved for the whole organisation and not one part of it

They add that one sentence rarely holds all six, so their teams use a worksheet that captures the whole context.

For an HR request, the practitioner can complete an equivalent worksheet in the meeting with the sponsor, with six entries.

1. The decision the work informs, and who takes it

2. The criteria the decision will be judged against

3. The constraints, including budget and timing

4. The action that follows if the problem is solved

5. The accuracy required

6. The date the answer is needed

The accuracy entry sets the effort, because a choice between two options needs less precision than a decision on how much to spend.

For example, the technology director's request could be rewritten as follows.

• Decision. Whether to change pay bands, progression rules or manager practice for engineers, taken by the technology director with the finance director

• Criteria. Regretted exits among engineers fall, at a cost below the replacement cost of the exits avoided

• Constraint. No increase in the total salary budget before April

• Action. One funded change agreed in the March planning round

• Accuracy. Enough to choose between the three options, without sizing each one precisely

• Date. The March planning meeting

Conn and McLean also recommend testing a statement against a challenging antithesis.

For the retention request, that means asking what the data would show if most of the leavers were people the function was content to lose.

Splitting The Problem

Conn and McLean report that few problems can be solved without being broken into component parts.

A team studying asthma in Sydney found its insight only after separating incidence from severity.

Incidence in Western Sydney was 10 per cent higher than in Northern Sydney, while hospitalisation was 65 per cent higher and deaths 54 per cent higher.

That split pointed the team to socioeconomic status, tree cover and air quality, and led to a proposal to address respiratory health through natural solutions.

Conn and McLean call the choice of split the cleaving point.

A people problem can be cut in several ways, and each cut points to a different owner.

• Tenure band. Separates selection and onboarding from progression

• Regretted and unregretted exits. Shows how much of the problem the business would choose to keep

• Manager. Locates the problem in particular teams

• Role family. Points to market pay

• Destination. Shows who is hiring the leavers

The first cut that leaves one segment with far more exits than its share of headcount is the one to pursue.

Logic Trees And MECE

A logic tree lays the split out as branches that can each be tested.

Conn and McLean require the branches to be mutually exclusive and collectively exhaustive, which they abbreviate to MECE.

Overlapping branches produce double counting, and a gap between branches leaves a cause unexamined.

A tree that splits leavers into pay, manager and career is not MECE, because a leaver who quit over a pay band cap belongs in two branches.

Splitting the same leavers by tenure band gives branches that do not overlap and that cover everyone, because each leaver has exactly one tenure band.

Conn and McLean advise checking whether a tree is MECE when clear hypotheses will not come out of it.

Conn built a logic tree of factory siting variables during an internship at Canon.

It became the department's core tool because it put trade-offs buried in dense reports onto one page and opened the weighting of variables to discussion.