Case Study: Post-Acquisition IT Merger
Scenario
A traditional manufacturing company ("AlphaCorp," 2,000 IT staff, ITIL 4 maturity level 3) acquires a smaller digital-native company ("BetaTech," 200 IT staff, DevOps/Agile culture, no formal ITIL). The board requires full IT integration within 18 months under a single operating model, tool set, and governance structure. The challenge involves merging fundamentally different cultures, tool stacks, processes, and organizational structures without disrupting customer operations.
Phase 1: Assessment (Months 1-2)
Four Dimensions Analysis
| Dimension | AlphaCorp | BetaTech | Conflict? |
|---|---|---|---|
| Organizations and People | Hierarchical; RACI-driven; change advisory board approves all changes | Flat; squad-based; engineers deploy autonomously | High |
| Information and Technology | ServiceNow ITSM; on-premises data centres; CMDB-based | Jira + PagerDuty; AWS; infrastructure as code | High |
| Partners and Suppliers | Long-term outsourcing contracts with large SIs | Direct cloud vendor relationships; open-source | Medium |
| Value Streams and Processes | ITIL 4 processes; ticket-based workflows | CI/CD pipelines; GitOps; ChatOps | High |
Complexity Context: Complex
"This merger is complex, not ordered. You cannot predict how two cultures will interact." The team adopted a probe-sense-respond approach: make small changes, observe effects, and adapt.
PESTLE Scan
| Factor | Impact on Merger |
|---|---|
| Economic | Board pressure to realize $15M in annual IT cost synergies within 18 months |
| Social | BetaTech engineers fear bureaucratic slowdown; AlphaCorp staff fear job displacement |
| Technological | Dual tool stacks (ServiceNow + Jira) create integration complexity |
| Legal | Both companies serve customers in different regulatory jurisdictions |
Phase 2: Design the Target Operating Model (Months 2-4)
Key Leadership Decisions
| Decision | Choice | Rationale |
|---|---|---|
| Operating model | Federated (not centralized) for the first year | Forcing centralization on BetaTech would trigger mass resignation |
| Governance | Guided pattern (not directive) | High enough authority for compliance; flexible enough for innovation |
| Practices | Harmonize 12 core: Incident, Problem, Change, Service Desk, SLM, Knowledge, Risk, Security, Monitoring, Release, Deployment, Continual Improvement | These 12 are essential for unified reporting; other practices remain team-specific |
| Tools | Keep ServiceNow as system of record; integrate Jira via API | Replacing BetaTech's toolchain immediately would be destructive |
| Culture | "Best of both" integration team with leaders from each company | Avoids "winner takes all" dynamics |
Value Stream Mapping
The integration team mapped three critical value streams:
- Incident to resolution (current: 2 different processes; target: 1 unified process with context-adapted workflows)
- Request to fulfilment (current: ServiceNow for Alpha, Slack bot for Beta; target: unified portal with self-service)
- Idea to production (current: waterfall for Alpha, CI/CD for Beta; target: hybrid with governance guardrails)
Phase 3: Integration (Months 4-12)
Wave 1: Unified Incident Management (Month 4-6)
| Component | Integration Approach |
|---|---|
| Severity classification | Aligned on 4-level severity scale (both companies had different scales) |
| Escalation paths | Combined into single matrix with on-call rotations from both teams |
| Communication | Standardized: all Major Incidents use a single war room process |
| Tooling | Jira incidents auto-sync to ServiceNow as system of record |
| SLAs | Harmonized to the stricter standard (AlphaCorp's regulated customers) |
Result: Unified incident process reduced Mean Time to Resolve (MTTR) by 15% because cross-team knowledge sharing identified solutions faster.
Wave 2: Change Enablement Harmonization (Month 6-9)
AlphaCorp's Change Advisory Board (CAB) approved all changes weekly. BetaTech deployed 50+ changes per day through CI/CD with no CAB.
| Solution | Detail |
|---|---|
| Standard changes | Pre-approved category expanded to include BetaTech's automated deployments (if they pass automated policy checks) |
| Normal changes | Lightweight async review replaces weekly CAB for medium-risk changes |
| Emergency changes | Single expedited process for both companies |
| Policy as code | BetaTech's CI/CD pipelines include policy-as-code checks that satisfy AlphaCorp's compliance requirements |
💡
Key insight: The solution was not forcing BetaTech into the CAB or abolishing it. It was automating the controls that the CAB provided, enabling velocity and governance to coexist.
Wave 3: Knowledge and Culture Integration (Month 9-12)
| Initiative | Purpose |
|---|---|
| Cross-team rotations | Engineers spend 2 weeks embedded in the other company's teams |
| Unified knowledge base | Single Confluence/wiki with content from both companies |
| Joint retrospectives | Monthly retros with mixed teams to surface integration issues |
| Shared on-call | Combined on-call rotations build trust and shared context |
| "Translation guide" | Document mapping AlphaCorp terminology to BetaTech terminology |
Phase 4: Governance Evolution (Month 12-18)
| Phase | Governance Pattern | Why |
|---|---|---|
| Month 1-6 | Guided | Both companies need direction but also flexibility to adapt |
| Month 6-12 | Guided → Federated | BetaTech teams demonstrate compliance through automation; reduced oversight |
| Month 12-18 | Federated | Integrated operating model is stable; teams govern within agreed boundaries |
Outcomes (18 months)
| Metric | AlphaCorp (Before) | BetaTech (Before) | Merged (After) |
|---|---|---|---|
| MTTR | 4 hours | 45 minutes | 1.5 hours |
| Change failure rate | 12% | 3% | 5% |
| Deployment frequency | Weekly | 50+/day | 20+/day (average across teams) |
| Employee satisfaction (IT) | 68% | 82% | 75% |
| Voluntary turnover (IT) | 8% | 22% (post-acquisition anxiety) | 11% |
Lessons Learned
| Lesson | ITIL v5 Connection |
|---|---|
| Culture integration is harder and more important than tool integration | Organizations and People dimension; Westrum culture model |
| "Best of both" beats "winner takes all" | Guiding principle: "Start where you are" |
| Automating governance controls enables velocity without sacrificing compliance | Governance patterns; Policy as Code |
| Value stream mapping reveals waste hidden by organizational silos | Value streams and processes dimension |
| The complexity context changed over time (Complex → more Ordered as integration matured) | Complexity contexts are not static |
Discussion Questions
- The organization chose a "Guided" governance pattern initially. What would have gone wrong with a "Directive" pattern?
- BetaTech had 22% turnover post-acquisition. How does ITIL v5's Organizations and People dimension address retention during change?
- The change enablement solution replaced the CAB with "policy as code." Is this appropriate for all organizations, or only those with mature CI/CD?
- Using the Value Co-Creation model, who are the "providers" and "consumers" in this merger scenario?