Making the Enterprise Visible Before Integration
An illustrated comparison showing how a fragmented organizational chart can obscure enterprise capabilities, while a reconstructed capability baseline reveals what the organization actually does, where expertise resides, and where shared or overlapping responsibilities affect integration.
Reconstructing an enterprise capability baseline during organizational transition
Primary Relevance
Organizational Engineering & Enterprise Integration
Related i3SCF Capabilities
Capability Architecture & Analysis · Operating Model Modernization · Strategic
Alignment / Value Architecture · Transformation Road mapping
The Challenge
A large engineering enterprise was transitioning from one parent organization to another after years of organizational change. Leadership could not clearly show what the enterprise did, where its capabilities resided, or which organizational components owned or contributed to them. The existing enterprise capability model was approximately 13 years old. Since its creation, the organization had undergone two reorganizations without corresponding updates to the capability baseline. Some support functions remained relatively easy to understand because their organizational structures reflected recognizable administrative, technology, resource, and operational responsibilities. The engineering and program environment was less transparent. Responsibility crossed organizational boundaries, and the existing organizational structure did not provide leadership with a reliable enterprise view of capabilities and ownership.
That gap became increasingly important as the organization transitioned into a new parent enterprise. The organizational chart showed where people reported. It did not adequately show what the enterprise could do.
What We Found
The information needed to reconstruct the enterprise already existed, but it was fragmented.
Mission statements, organizational responsibilities, engineering functions, program activities, services, products, and supporting operations were distributed across organizational documentation, internal collaboration environments, and individual business units. No current model brought those pieces together into a coherent enterprise view. Analysis also revealed that formal organizational boundaries did not always correspond to distinct capabilities.
Multiple engineering components were performing overlapping or duplicative activities even though individual components were intended to concentrate on different areas of work. Other capabilities were inherently shared across organizational boundaries, making ownership and participation difficult to understand from the organizational structure alone. Supporting organizations could identify the services they provided but could not always readily determine which program organization held responsibility for particular areas of mission delivery.
Years of organizational change had therefore created several interconnected issues:
Capability information was fragmented across the enterprise;
Ownership was not always readily visible;
Shared capabilities crossed organizational boundaries;
Similar work existed in multiple organizational components; and
The existing capability model no longer reflected the organization leadership was preparing to integrate.
The transition therefore raised a fundamental question: What, exactly, was the receiving enterprise inheriting?
The Turning Point
The organization did not need another representation of its reporting structure. It needed a representation of its operating capabilities.
In practice, organizational components had largely evolved around the capabilities they performed. The underlying capability structure therefore already existed within the organization, even though years of change had left it undocumented at the enterprise level. The task became one of reconstruction rather than invention.
Existing organizational evidence was examined to identify missions, responsibilities, activities, services, engineering functions, products, and supporting operations. Those findings were organized according to their relationship to mission delivery rather than simply reproducing organizational reporting relationships. For purposes of this case study, the resulting capability architecture can be summarized into four generalized domains:
Enterprise Direction & Program Oversight
Enterprise Support Services
Engineering & Innovation
Solution Delivery & Lifecycle Management
Engineering-focused components concentrated primarily within Engineering & Innovation. Program organizations aligned strongly with Enterprise Direction & Program Oversight. Administrative, technology, resource, and operational functions aligned primarily with Enterprise Support Services. Other capabilities crossed those boundaries.
Solution Delivery & Lifecycle Management, for example, required participation from multiple organizational components as solutions moved from development through delivery, stakeholder feedback, sustainment, and continued improvement. That distinction became central to the analysis:
Capabilities describe what an enterprise must be able to do. Organizational structures describe how responsibility for that work is arranged.
Understanding the enterprise required seeing both.
What We Did
The distributed organizational evidence was converted into a hierarchical capability structure extending from high-level mission capabilities through increasingly detailed capability definitions. The resulting L1–L3 baseline captured more than 550 capabilities across 21 business units, creating a current enterprise capability view after years of organizational change.
Capabilities were organized according to mission and operating responsibilities rather than simply mirroring the organizational chart. The resulting architecture showed:
What capabilities existed across the enterprise
Which organizational components owned or participated in them
Where capabilities crossed organizational boundaries
Where ownership required greater clarity
How different components contributed to mission delivery
Where apparently separate components were performing overlapping work
The reconstructed baseline was cross-checked against existing organizational missions, responsibilities, documentation, and organizational structures. Because organizational components had largely evolved around the capabilities they performed, the resulting model aligned closely with the operating organization. Differences in terminology were primarily semantic rather than substantive.
The baseline was then presented to executive leadership and enterprise architecture leadership for review and validation.
The Results
Organizational leadership approved the reconstructed capability baseline and submitted it to the organization's new parent enterprise as part of the broader organizational transition.
Leadership now had a current L1–L3 representation of the enterprise instead of relying on a capability model developed approximately 13 years earlier and carried through two subsequent reorganizations. The baseline provided a common structure for understanding capabilities, organizational participation, shared responsibilities, and ownership across the enterprise.
More importantly, it gave leadership a different basis for evaluating integration. The discussion could move beyond the question: “How is this organization structured?” to questions such as:
“What capabilities are we integrating?”
“Where do those capabilities reside?”
“Who owns or participates in them?”
“Which capabilities are shared?”
“Where is similar work being performed in multiple places?”
That provided a stronger foundation for subsequent organizational integration and operating-model decisions.
Why It Matters
Mergers, acquisitions, consolidations, reorganizations, and enterprise integrations often begin with organizational charts, staffing structures, financial information, technology inventories, and reporting relationships. Those views describe important characteristics of an organization. They do not necessarily describe its operating capability.
An organizational chart can show who reports to whom while leaving unanswered what the organization can actually do, where those capabilities reside, which capabilities depend on multiple business units, and where similar work is being performed in multiple places. A capability baseline provides that additional perspective. It gives leadership a business-centered view of:
What the organization can do
Where those capabilities exist
Who owns or participates in them
Where capabilities are shared
Where duplication, ambiguity, or gaps may exist
That perspective can support organizational restructuring, operating-model modernization, portfolio rationalization, enterprise integration, and the operational side of M&A due diligence. Before leadership decides how organizations should fit together, it needs a reliable understanding of what those organizations actually do. In this case, reconstructing that view gave leadership an approved enterprise capability baseline it could carry into the organizational transition.