Choosing What to Model First in a Merger
Two regional insurers have merged. You are the sole business architect, hired 6 weeks ago, with a 9-month mandate to 'produce the target operating model'. Leadership wants a single capability map for the combined group. You have: 14 interviews done, a legacy application inventory for the larger firm only, and a strategy document from each firm that uses different vocabulary (one speaks of 'product lines', the other of 'customer segments'). The CIO wants an application rationalization list in 30 days. The COO wants clarity on duplicated back-office functions within 60 days. Nobody has agreed what the merged entity's value proposition is. A consulting firm has offered a pre-built industry reference model for a fee.
1. What should you sequence first, and why, given the competing 30- and 60-day demands?
Read the worked answer
The 30-day application list and the 60-day duplication analysis are both downstream of an agreed capability framework and value proposition, and both will be re-done if you skip it. But the mandate does not permit a 6-month pure-blueprint phase.
Sequence:
- Weeks 1-3 - Agree the value proposition and a one-page capability map at level 1. Use the two strategy documents as inputs, not as truth; reconcile their vocabularies explicitly (product line vs. segment is a value-stream difference, not a capability difference). Capabilities are stable across both firms; that is precisely why they are the right unifying lens.
- Weeks 3-5 - Decompose only the capabilities the two demands touch. Back-office duplication needs level-2/3 on shared services; app rationalization needs level-2 on capabilities that consume applications. Do not model the whole enterprise to level 3.
- Then deliver the 30-day list as 'applications mapped to capabilities, with heat indicators' - it is defensible because it is anchored, and it is honest about the missing inventory for the smaller firm (flag as a gap, do not hide it).
- The 60-day duplication analysis falls out of step 2 naturally.
The reference model is a legitimate accelerator for a starting taxonomy, but adopt it as a checklist to challenge your map, not as the map. Buying it and publishing it unmodified guarantees neither firm recognizes itself and the map gets rejected.
2. The CIO says 'capabilities are academic, just give me the app list.' How do you respond without capitulating?
Read the worked answer
Do not argue abstraction vs. practicality - argue rework cost. Concretely: an app list built without a capability anchor answers 'what do we own' but not 'what is it for', so every decommission decision reopens the same argument ("but that app supports claims"). With a capability anchor, the decision becomes 'we have three applications supporting the same level-2 capability; which one survives?' - a decision the CIO can actually chair.
Offer a trade: deliver the app list in the 30-day window with a thin capability column, using the level-1/level-2 subset only. This costs the CIO nothing in time and gives you the anchor. It also converts the CIO from skeptic to sponsor, because the list becomes more useful, not later.
Escalation of last resort: if the CIO insists on a pure inventory, deliver it but attach a one-page note stating the assumption (no capability anchor, decisions reversible) so the risk is documented rather than absorbed silently by you.