The 22% That Wasn't There
A shared-services group has merged three regional PMOs into one portfolio office. Each region has logged terminology differently for years. Region A records every uncertainty as an 'issue' - 412 open, of which roughly 60% would be a risk under the new enterprise taxonomy. Region B counts a scope change as a 'change request' only when it exceeds 5% of budget, so its register holds 38 entries; the new definition has no threshold. Region C re-labelled its entries last quarter. The consolidated dashboard now shows 1,180 open 'issues', a 22% quarter-on-quarter fall that coincides exactly with Region C's relabelling. The CIO has already described the fall as evidence that the new governance model is working and wants the trend in next week's board pack. Separately, a managed-service contract defines 'Severity 1 defect' more narrowly than the new enterprise definition, and service credits attach to it.
1. The CIO asks you to sign off the 22% trend for the board pack as evidence that the governance model is working. What do you do, and what do you tell the CIO?
Read the worked answer
The 22% is a measurement artefact, not a performance signal. Signing it off would put a false causal claim in front of the board.
Reasoning
- A time series is only valid if the definition is stable across periods. Region C changed labels last quarter, so this comparison mixes two taxonomies. The exact coincidence of timing is the tell.
- Do the arithmetic before the meeting. If Region A's 412 open items are around 60% risks, roughly 245 entries leave the issue register on reclassification alone - a large share of the fall implied by 22% of 1,180. Build the bridge explicitly: opening balance, reclassifications, genuine closures, new items, closing balance. Only the residual can be called performance.
- Offer a defensible alternative rather than a refusal: present the restated level, and a like-for-like trend with prior periods recast under the new taxonomy. If that cannot be done in a week, present the level only, with a stated note that the trend is not comparable.
- Name the incentive neutrally: the CIO has already attributed the fall to the governance model, so the request carries confirmation pressure. Your job is to make the data usable, not to win the argument.
- Set the forward rule: definitional changes are versioned, announced in advance, and accompanied by a restatement. A silent break in a series is never acceptable.
If the CIO insists, put the caveat in the pack yourself rather than in an email nobody reads.
2. How do you handle the conflict between the contract's 'Severity 1 defect' definition and the enterprise taxonomy?
Read the worked answer
Two different instruments are in play, and neither silently overrides the other.
- The contract definition is legally operative for service credits and remedies until the parties vary it in writing. Relabelling tickets under the enterprise taxonomy to reduce credits would be a breach, not a tidy-up.
- The enterprise taxonomy governs internal reporting, prioritisation and the consolidated dashboard. It is not a contractual document and cannot be imposed unilaterally on a supplier.
- Practical resolution: hold both attributes on every ticket - contractual severity (drives credits, owned by the contract manager) and enterprise severity (drives reporting and engineering priority). Publish a mapping table so the two are never conflated in conversation.
- Flag the gap to procurement and legal as a commercial risk in its own right. If the enterprise definition is broader, the organisation believes it has transferred exposure it has not. That is a finding for the next contract cycle and possibly grounds for a variation now.
- Do not retrospectively reclassify historical tickets in either direction.
The judgement being tested: an internal reporting standard is not a lever for changing contractual entitlements, and the analyst should not decide which one 'wins'. That is a contract-management and legal decision, informed by your mapping.
3. Design the remediation: how do you get from three incompatible taxonomies to one that will hold?
Read the worked answer
Treat the glossary as a governed artefact, not a communications exercise.
- Normative source. Pick one authority per term and record why. Where a term is contested, define it operationally: a risk is an uncertain event that has not occurred; an issue is one that has. A change request is any change to an approved baseline, whatever its size - the 5% threshold is an approval-authority rule, not a definition, and conflating the two is exactly what produced Region B's 38-entry register.
- Ownership and decision rights. One glossary owner, an arbitration route for disputes, and a change board for the glossary itself, versioned and dated.
- Migration. Map every legacy label to the new term, run a scripted reclassification, and dual-code a sample (say 30 tickets per region) to check agreement. Record the conversion in item history rather than overwriting it - auditors will ask what the item used to be.
- Freeze and train. No new labels until publication; a short briefing per team; embed the terms in tool picklists so the correct option is the default.
- Re-baseline publicly. Publish restated counts with an effective date and a bridge from the old series.
Sequencing: glossary and mapping in week one, dual-coding in week two, restated dashboard in week three. The board pack can carry a clearly labelled 'register under restatement' note meanwhile - honest, and faster than defending an artefact.