Reference Model Import Gone Wrong
A government agency adopted an industry reference process model wholesale to accelerate a digital transformation. Eighteen months and a substantial licence later, business units report that the model 'does not describe what we do'. Staff have created local variants: three different versions of the 'case assessment' process, two competing definitions of 'citizen', and a 'temporary' spreadsheet that has run the eligibility process for 14 months. The vendor's model covers 80% of the agency's activities but the missing 20% is the agency's statutory core. The CIO wants to re-baseline on a different vendor's model. The CDO wants to abandon reference models entirely.
1. Diagnose the failure. Was the reference model the problem?
Read the worked answer
The reference model was not the problem; the adoption method was. Three distinct errors, worth separating because they have different fixes:
- Coverage gap in the wrong place. 80% coverage sounds good until you learn the missing 20% is the statutory core. Generic models are built for the common case; an agency's differentiating, non-negotiable work is exactly what a generic model omits. Adopting it as the target means the most important work is unmodelled - so it gets handled outside the model, by spreadsheets.
- No localization discipline. Local variants (three 'case assessment' processes, two 'citizen' definitions) are the predictable result of publishing a model without a rule for how a unit may deviate and who approves it. Absent that rule, every unit deviates, and the model becomes one more document nobody owns.
- Model treated as target, not as reference. A reference model is a starting vocabulary and a completeness check. It was treated as the answer, so no one did the work of describing the agency's actual value streams, and the gap was never surfaced as a decision.
So: re-baselining on another vendor reproduces the failure with a new licence fee. Abandoning reference models throws away a genuinely useful checklist.
2. Propose a path forward that satisfies neither the CIO's nor the CDO's opening position, and address the spreadsheet.
Read the worked answer
Neither position survives scrutiny: a new vendor model has the same generic-vs-statutory gap; abandoning reference models loses the completeness check that would have caught the gap sooner. The path:
- Model the statutory core first, from the agency's own reality. Value streams and capabilities for the 20% the vendor omitted. This is where the risk and the mandate live, and it is the part no vendor can supply.
- Retain the existing model for the commodity 80%, with an explicit, published mapping between vendor terminology and agency terminology (including a single agreed definition of 'citizen' - owned, versioned, and cited by every process).
- Institute a deviation rule. A unit may deviate from the standard process only with a recorded, time-boxed exception approved by a named owner. This is what converts three variants into one standard plus two governed exceptions. Without this rule, any model - vendor or homegrown - decays the same way.
- The spreadsheet is a finding, not a nuisance. It has run a statutory process for 14 months, which means it encodes business rules nobody has documented and probably a control gap. Treat it as a source: extract its rules, model them, migrate them, then retire it with a named owner and a date. Do not delete it first - you would destroy the only record of how eligibility actually works.
Sequencing matters: the deviation rule and the 'citizen' definition are cheap and can land in weeks; they stop the bleeding while the statutory-core modelling runs.