Operational Integration in Change Management: Connecting Change With Daily Operations

How Change Units make local implementation visible while helping organizations coordinate dependencies, capacity, and decisions across concurrent initiatives

A change initiative can be well planned, properly funded, and professionally managed while still creating serious problems in daily operations.

The project team may report that milestones are being met. Training may be complete. The technology may have been delivered. Yet employees may be struggling with conflicting procedures, unclear responsibilities, competing priorities, and unfinished changes from earlier initiatives.

The difficulty is often not contained within one project. It emerges where several initiatives interact with the same teams, processes, systems, customers, and managers.

This is the purpose of Operational Integration in change management.

Operational Integration connects change initiatives with the operational settings in which change must work. It makes dependencies, cumulative demands, capacity pressures, and conflicting effects visible across teams and organizational boundaries.

Within the GRIFFOX Layered Cake Model, this connection begins with Change Units.

What is Operational Integration in change management?

Operational Integration is the organizational capability to connect the design and implementation of change with the reality of daily work.

It helps an organization understand:

• Where change is being experienced
• How different teams interpret and implement it
• Which initiatives affect the same people and processes
• Where dependencies exist between units
• Whether operational capacity can support current demands
• How local decisions affect other parts of the organization
• Whether intended benefits are appearing in actual operations
• Where project reports and operational experience tell different stories

Operational Integration does not simply mean transferring a completed project into operations. It begins while the change is being designed and continues throughout implementation, adjustment, and stabilization.

The Association for Project Management describes portfolio management as balancing change initiatives with business-as-usual activity while considering the organization’s capacity to deliver. Operational Integration examines that balance where it is actually experienced: inside teams, departments, processes, locations, and business units.

The objective is not to protect operations from every disruption. Meaningful change will often disrupt established routines. The objective is to understand those effects early enough to make responsible decisions about priorities, timing, capacity, dependencies, and implementation.

Why project-level change management may not be enough

Most change methodologies begin with the individual initiative.

They help a project define its stakeholders, communication requirements, training needs, sponsorship, resistance, readiness, and implementation plan. These activities remain important.

The limitation appears when several initiatives operate simultaneously.

Each initiative may ask:

• Are our stakeholders prepared?
• Have we communicated our changes?
• Has our training been completed?
• Are people adopting our new process?
• Is our project progressing as planned?

The organization must ask additional questions:

• How many initiatives are affecting the same stakeholders?
• Are different projects communicating compatible priorities?
• Are teams being trained on processes that depend on unfinished work elsewhere?
• Are several initiatives relying on the same specialists or managers?
• Can employees adopt another change while maintaining operational performance?
• Are projects competing for the same customer attention, data, systems, or resources?
• Is a local implementation decision creating difficulties in another department?
• Which initiative should adjust when demands collide?

No individual project can answer all these questions because each project sees only part of the organizational picture.

Operational Integration adds the connecting perspective.

What is a Change Unit?

A Change Unit is the operational context in which a change is interpreted, implemented, experienced, and sustained.

A Change Unit might be:

• A team
• A department
• A business unit
• A location
• A customer-facing function
• A professional group
• A process community
• A regional operation
• A temporary cross-functional group
• A project team whose own work is changing

A Change Unit is not necessarily a new organizational department. It does not require another box on the organizational chart.

It is a practical way to identify where change becomes real.

For one initiative, a customer service department may be a Change Unit. For another initiative, the relevant Change Unit may include people from customer service, billing, technology, and operations because they share responsibility for one connected process.

The appropriate boundary depends on the change.

The defining question is:

Where must this change be understood, implemented, adjusted, and sustained within a specific operational context?

Change Units and organizational units are not always the same

An existing team or department can be treated as a Change Unit, but the two terms are not interchangeable.

An organizational unit is defined by the formal structure of the organization. A Change Unit is defined by the context and impact of a particular change.

For example, an enterprise resource planning implementation may affect finance, procurement, human resources, technology, and local management. Each function may represent a distinct Change Unit because the change has different implications for its work.

Finance may need to redesign controls and reporting. Procurement may need to change approval processes. Human resources may need to update roles and training. Technology may need to manage integration and support. Local managers may need to adjust responsibilities and operating routines.

Treating all these groups as one general stakeholder population would hide important differences.

Change Units preserve those differences while still allowing the organization to connect them.

A person may also participate in more than one Change Unit. A regional manager could be affected as an operational leader, a system user, and a member of a cross-functional process. These overlaps are often where dependencies and capacity problems become visible.

Why Change Units are useful

They place change in context

The same enterprise initiative can have very different implications in different parts of the organization.

A new reporting requirement may be a minor technical adjustment for one team and a major redesign of daily work for another. Change Units allow implementation to reflect these differences.

They strengthen local ownership

Change cannot be sustained solely by a central project team.

The people responsible for daily operations need enough authority and involvement to interpret the change, identify local constraints, make appropriate adjustments, and incorporate the new way of working into normal operations.

Change Units give that local responsibility a clear place within the change architecture.

They improve the quality of evidence

Enterprise averages can conceal important variation.

An overall adoption rate of 80 percent may appear positive. It becomes less reassuring if one critical operational unit has achieved only 35 percent adoption or if the units with the highest adoption are also experiencing declining customer service.

Change Units preserve the context behind the numbers.

They reveal dependencies

A department may be ready to implement a change but depend on another unit that is not ready. A process may cross several teams. A local solution may create additional work downstream.

Examining Change Units together helps the organization see these relationships.

They make learning reusable

Each Change Unit produces experience about what worked, what did not work, and what needs adjustment. That learning can inform other units and future initiatives without assuming that one local solution will work everywhere.

How the GLCM works within a Change Unit

The five-layer GLCM can be applied within each Change Unit.

Foundation and Experience

The Change Unit examines its context, culture, prior experiences, capabilities, relationships, and readiness for the change.

Two departments participating in the same initiative may begin with very different foundations.

Framework

The unit determines how the broader change approach, principles, methods, data, and tools should be applied within its context.

The enterprise may establish common guardrails while allowing appropriate local adaptation.

Implementation

The Change Unit carries out the change in daily work. It tests new practices, develops capabilities, resolves local problems, and observes the actual effects on people, processes, systems, behavior, and customers.

Recalibration

The unit reviews evidence, reflects on experience, and adjusts the approach when assumptions do not match reality.

Recalibration is more than a retrospective discussion. It is a deliberate point at which evidence can lead to a change in course.

Goal

The unit evaluates whether the intended outcome has been achieved and integrated into operations.

An initiative is not complete merely because a deliverable has been installed. The change must produce a usable and sustainable result in the relevant operational context.

Reflection occurs throughout these layers. Each cycle produces new information and may alter the foundation for the next decision.

From local information to qualified change signals

Change Units observe what is happening close to the work.

They may collect:

• Performance measures
• Employee feedback
• Customer feedback
• Process observations
• Adoption data
• Operational incidents
• Workload information
• Training results
• Manager assessments
• Risk indicators
• Implementation experience

These inputs are not automatically meaningful signals.

Information becomes a qualified change signal when it is interpreted in relation to a management question, baseline, objective, dependency, risk, or decision.

For example:

• A temporary performance decline may be expected during implementation.
• The same decline may become a significant signal if it continues beyond the expected adjustment period.
• It may become an enterprise concern if similar declines appear in several units affected by different initiatives.
• It may indicate a capacity problem if the affected units are also carrying unusually high change demand.

The Change Unit provides the context required to interpret the evidence correctly.

Operational Integration connects related signals across Change Units so that wider patterns become visible.

How Operational Integration connects Change Units

The GLCM already connects an individual change initiative with the operational units in which it must be implemented.

Operational Integration builds on those connections. It makes interactions, dependencies, capacity pressures, and cumulative effects visible across unit and initiative boundaries.

This can be examined through three complementary perspectives.

The top-down perspective asks:

The top-down perspective

• What are the organization’s priorities?
• What should be achieved?
• Which outcomes and guardrails apply?
• What should happen during the next planning period?
• Where are strategic priorities creating competing operational demands?

This perspective provides direction, but it cannot confirm by itself whether the direction is workable.

The bottom-up perspective

The bottom-up perspective asks:

• What are teams and departments experiencing?
• What is already working?
• What is creating difficulty?
• Which assumptions do not match operational reality?
• What has already been implemented or completed?
• What support or decisions are needed?

This perspective brings actual implementation experience into the organizational picture.

The network perspective

The network perspective asks:

• How are Change Units connected?
• Which processes, systems, resources, and responsibilities cross their boundaries?
• What value do these relationships create?
• Where are handoffs failing?
• Which dependencies need to be strengthened or redesigned?
• Where could a decision in one unit create an unintended consequence elsewhere?

This is where Operational Integration goes beyond conventional reporting. It considers the organization as a connected operating system rather than a collection of separate projects and departments.

Operational Integration does not require uniform implementation

Connecting Change Units does not mean forcing every unit to implement change in exactly the same way.

Different units may require different:

• Implementation sequences
• Communication approaches
• Training methods
• Measures
• Local responsibilities
• Support arrangements
• Recalibration cycles
• Timelines

The organization may still require shared outcomes, principles, standards, or regulatory controls. Within those boundaries, local adaptation can improve the practicality and sustainability of implementation.

Operational Integration helps management distinguish useful adaptation from harmful fragmentation.

Useful adaptation respects local context while supporting the shared goal. Harmful fragmentation creates incompatible processes, duplicated work, uncontrolled risks, or contradictory customer experiences.

The connection with the Change Office

When Operational Integration covers several Change Units or initiatives, someone must connect the resulting signals.

This is one of the functions of the Change Management Office.

Change Units own contextual implementation and local observation. The Change Office:

• Brings qualified signals together
• Identifies patterns and contradictions
• Examines dependencies
• Recognizes capacity constraints
• Develops an integrated signal picture
• Prepares decision options
• Escalates issues requiring enterprise authority
• Coordinates management direction back to the affected Change Units

The Change Office should not take over local implementation. It helps the organization understand what the combined operational evidence means.

Enterprise leadership or another authorized governance forum then makes decisions about priorities, resources, sequencing, risk, and strategic direction.

This relationship is part of the broader GLCM Enterprise Change Architecture.

When can a team use the GLCM without Operational Integration?

Not every application of the GLCM requires an enterprise-wide integration mechanism.

A team, department, or project may use the five-layer model independently when the change is sufficiently contained.

This may be appropriate when:

• The change affects primarily one team or department
• Dependencies with other initiatives are limited
• The unit has authority over the required decisions
• Operational capacity can be managed locally
• Customer or regulatory consequences are limited
• The change does not compete significantly for shared enterprise resources
• Implementation can be monitored within the unit
• Problems can be resolved without enterprise prioritization
• Wider coordination would add more effort than value

For example, an IT team introducing an internal development tool for its own use may apply the GLCM to understand its foundation, select an approach, implement the tool, recalibrate based on experience, and evaluate the outcome.

If the tool does not significantly affect other functions, the team may not need Operational Integration across the enterprise.

Likewise, a department that experiences relatively little change may use the GLCM for an occasional local improvement without establishing a permanent cross-unit integration structure.

This is a legitimate and proportionate use of the model.

The decision should depend on impact, not the project label

An “IT project” should not automatically be treated as a local change.

Some technology projects are largely contained within IT. Others alter customer interactions, operational processes, data ownership, employee roles, compliance responsibilities, and management decisions throughout the organization.

The relevant questions are:

• Who must change how they work?
• Which operating processes are affected?
• Which other initiatives depend on this change?
• Are shared systems, data, resources, or customers involved?
• Could the change create capacity pressure elsewhere?
• Can the affected unit resolve the consequences independently?
• Would leadership need an enterprise view if problems emerge?

If the consequences cross meaningful boundaries, Operational Integration becomes useful even if the initiative began as a technical project.

When should Operational Integration be activated?

Operational Integration should be considered when one or more of the following conditions exist:

Several Change Units are affected

The initiative requires coordinated implementation across departments, locations, processes, or professional groups.

Multiple initiatives overlap

Different projects affect the same employees, customers, systems, processes, managers, or resources.

Dependencies influence success

One unit cannot implement or sustain its change without action from another unit.

Capacity decisions exceed local authority

Teams experience competing demands that require enterprise prioritization, sequencing, or resource decisions.

Operational and project information disagree

Project reporting indicates progress while operational evidence shows declining performance, confusion, resistance, or customer impact.

Local adaptation creates enterprise risk

Different units are implementing incompatible processes, controls, technologies, or customer practices.

Leadership needs a cumulative picture

Decisions about continuing, delaying, redesigning, or stopping an initiative require evidence from several parts of the organization.

The level of integration should remain proportional to the complexity and consequences of the change.

A practical example

Consider an organization introducing a new customer relationship management system.

The technology team develops and configures the platform. Sales, customer service, marketing, finance, and compliance will all use or depend on it.

Each function becomes a Change Unit because the change has a different operational meaning.

• Sales needs usable opportunity and account processes.
• Customer service needs accurate customer histories and efficient case management.
• Marketing needs reliable consent and campaign data.
• Finance needs correct billing and revenue information.
• Compliance needs appropriate access, retention, and documentation controls.
• Technology needs stable integration, security, and support.

If the project is managed only from the technology perspective, the system may be delivered while the operating model remains fragmented.

Operational Integration reveals that:

• Sales and customer service use different customer definitions.
• Marketing depends on data that compliance has restricted.
• Finance needs fields that were not included in the initial design.
• Training dates conflict with another enterprise initiative.
• Managers expected to sponsor adoption are supporting several major changes simultaneously.

These are not isolated training or communication problems. They are connected operational issues.

The Change Units provide contextual evidence. Operational Integration exposes the dependencies. The Change Office prepares the combined signal picture and response options. Authorized leadership decides which priorities, resources, timelines, or design choices must change.

A proportionate way to begin

Organizations do not need to map every team, relationship, and initiative before using Operational Integration.

They can begin with one significant change and ask:

1. Which operational contexts will experience this change?
2. Which of those contexts should be treated as distinct Change Units?
3. What does successful implementation mean within each unit?
4. What local information is needed to understand progress and impact?
5. Which dependencies connect the units?
6. What other initiatives affect the same people, processes, systems, or customers?
7. Which decisions can be made within the Change Units?
8. Which issues require Change Office coordination?
9. Which decisions require enterprise authority?
10. How will management direction return through the Change Office to the affected units?
11. How will the organization review whether its decisions improved the situation?

This creates enough structure to reveal meaningful interactions without building unnecessary bureaucracy.

Questions for leaders

Leaders can use the following questions to assess whether change is operationally integrated:

• Do we know where each initiative is actually being implemented?
• Have we identified the relevant Change Units?
• Can local teams adapt implementation within clear boundaries?
• Can teams report what they are experiencing, including contrary evidence?
• Do we preserve local context when information is aggregated?
• Can we see where several initiatives affect the same unit?
• Do we understand cross-unit dependencies and operational handoffs?
• Can we compare change demand with available capacity?
• Is someone connecting signals across initiatives?
• Are enterprise decisions based on both project information and operational reality?
• Does management direction return to the affected units through a coordinated process?
• Do reflection and recalibration continue after initial implementation?

If these questions cannot be answered, the organization may be managing individual projects competently while leaving their combined operational consequences unmanaged.

Connecting change with the organization that must carry it

Operational Integration in change management begins with a simple recognition: change does not take place inside a project plan. It takes place within an operating organization.

Change Units make those operational contexts visible. They allow teams and departments to implement change according to their responsibilities, culture, capacity, and experience. They also generate the contextual signals needed to understand what is actually happening.

Operational Integration connects those signals across boundaries. It reveals dependencies, competing demands, cumulative impacts, and decisions that no individual project or unit can resolve alone.

Some teams can use the five-layer GLCM independently because their change is contained and locally manageable. Other initiatives require connections among several Change Units, a Change Office that integrates their signals, and enterprise governance that can make decisions across the organization.

The appropriate approach depends on the scope and consequences of the change.

The purpose is not to make every initiative more complex. It is to apply enough integration to ensure that change remains workable in daily operations and manageable across the enterprise.

By Harald Lavric | Founder, GRIFFOX Consulting | Creator of the GRIFFOX Layered Cake Model™

About Harald Lavric

Harald Lavric is the founder of GRIFFOX Consulting and the creator of the GRIFFOX Layered Cake Model™. His work focuses on helping organizations connect individual change initiatives with operational reality, enterprise governance, and sustainable organizational development. The GLCM provides an integrated framework for managing change where several initiatives, priorities, and operational demands must be considered together.

Explore the GLCM | Read more GRIFFOX insights | Contact GRIFFOX Consulting