How leaders determine whether a completed project has produced sustainable operational value

Change management evaluation connecting project completion with operational ownership, sustained value, and learning for the next initiative.

The new system is live. Employees have completed their training. The project team has delivered the agreed requirements, closed the budget, and transferred responsibility to the business.

Three months later, employees still maintain a parallel spreadsheet. Customer exceptions take longer to resolve. Managers continue asking former project team members for help. Another initiative is drawing on the employees who were expected to stabilize the new process.

Was the change successful?

A project completion report cannot answer that question on its own.

Project completion confirms that something was delivered. Change management evaluation determines whether that result has become part of operations, produced sustainable benefits, and created consequences the organization is prepared to accept.

That requires leaders to look beyond milestones, implementation activity, and initial adoption. They must examine what happened after formal project structures began to disappear.

Project completion is not the same as successful change

Projects and organizational change follow different timelines.

A project can close when its agreed deliverables have been completed. Organizational change continues as employees, managers, systems, processes, and customers experience the result.

This difference explains why a formally successful project can produce a disappointing organizational outcome.

For example:

A system may be implemented without improving the customer experience.
Employees may complete training but continue using established workarounds.
A process may become faster in one department by moving work into another.
Initial adoption may decline once implementation support is withdrawn.
A benefit may appear during a quiet period but disappear when demand increases.
The organization may achieve the intended result while creating new risks or capacity problems elsewhere.

A useful change management evaluation begins when leaders stop asking whether the project delivered its scope and start asking whether the organization can use and sustain what was delivered.

Assessment during change and evaluation after completion serve different decisions

An organizational assessment during change examines an initiative that is still being implemented.

Its central question is:

What is happening now, and what should we adjust next?

A change management evaluation after project completion serves a different purpose.

Its central question is:

What did the change actually produce, can the organization sustain it, and what should we do with the result?

The distinction is important.

During implementation, leaders may decide whether to keep the course, adjust the current approach, wait consciously, or return to an earlier design layer.

After project completion, the possible decisions are different:

Confirm and continue the operational result
Extend stabilization or capability support
Correct an ownership, process, system, or governance problem
Expand the change to additional units
Revise the expected benefit
Retire an element that does not create sufficient value
Reopen an investment or enterprise-priority decision

Change Management evaluation is therefore not a delayed project status report. It is a management process for deciding what the organization should retain, strengthen, expand, correct, or discontinue.

Prepare for evaluation before implementation begins

Although the evaluation discussed here takes place after project completion, the conditions for a useful change management evaluation must be established much earlier.

Before implementation, leaders should define:

the business condition the change is intended to improve;
the expected organizational and customer outcomes;
the relevant baseline;
the assumptions behind the expected benefits;
the business owner responsible after project closure;
the evidence needed to judge results;
the period over which effects are expected to appear;
the risks and potential unintended consequences;
the conditions that could affect interpretation.

“Implement a new customer platform” describes a deliverable.

“Resolve customer requests with fewer avoidable transfers while maintaining service quality” describes an outcome that can be evaluated.

The difference is fundamental. Deliverables tell leaders what the project produced. Outcomes indicate what should become different in the organization.

The Project Management Institute’s Benefits Realization Management Framework similarly connects benefits with strategy and includes sustaining benefits after project work has transferred to the business.

A practical chain for change management evaluation

A complete change management evaluation should examine five connected questions.

1. Was the intended capability delivered?

Begin by establishing what the project produced.

Questions include:

Were the agreed requirements completed?
Is the system, process, structure, service, or capability available?
Were important limitations or exceptions left unresolved?
Did the delivered solution differ materially from the approved design?
Were critical dependencies completed?
Is the result technically and operationally usable?
Did the organization receive what it expected?

This first question matters, but it remains close to traditional project evaluation. A delivered capability is only the starting point.

2. Has the change transferred into operational ownership?

Project teams are temporary. Operational responsibility is not.

Change Management evaluation should determine whether the organization can manage the result after temporary project resources leave.

Questions include:

Is there a clearly accountable operational owner?
Do managers and employees understand their continuing responsibilities?
Can operational teams handle routine work and important exceptions?
Are support, maintenance, and escalation arrangements functioning?
Have temporary implementation responsibilities been transferred?
Does the business have the capacity to sustain the new process?
Are former project team members still compensating for incomplete ownership?
Are unresolved problems visible to people with decision authority?
Are operational units able to improve the result as conditions change?

A project has not transferred successfully if its results depend on informal support from people who no longer have an assigned role.

Operational ownership should include more than maintaining the new routine. It should also cover unresolved problems, supporting capabilities, dependencies, performance review, and future adaptation.

3. Are the intended benefits appearing and continuing?

Initial improvement does not always indicate a sustainable benefit.

The change management evaluation should examine:

whether the expected outcome has occurred;
whether it is large enough to matter;
whether it continues over an appropriate period;
whether it is visible under normal operating conditions;
whether it appears across the intended parts of the organization;
whether the organization can maintain it without exceptional support.

Depending on the initiative, evidence might include:

customer outcomes;
service quality;
cycle time;
error rates;
employee capability;
operational reliability;
risk reduction;
financial performance;
compliance;
capacity;
collaboration across units;
decision quality.

A single average can hide significant differences. Overall performance may improve while one region, customer group, department, or process experiences worse results.

Leaders should therefore ask:

Where is the benefit appearing?
Where is it missing?
Under which conditions does it weaken?
Who benefits?
Who carries additional work or risk?
Is the improvement stable or dependent on temporary effort?

4. What costs, risks, and unintended consequences appeared elsewhere?

Every meaningful organizational change interacts with existing work.

A new process may improve one measure while creating consequences outside the project’s reporting boundary. For example:

Faster processing in one department may create more correction work in another.
Centralization may improve consistency while slowing local decisions.
Automation may reduce routine work but increase the complexity of exceptions.
New customer channels may improve access while increasing demand on support teams.
A successful rollout may consume capacity needed for another strategic initiative.
New performance targets may encourage behavior that weakens quality or cooperation.

This is where Operational Integration becomes relevant.

Operational Integration makes dependencies, combined effects, capacity pressures, and consequences across Change Units visible. It helps leaders understand whether a result that appears positive within one project remains positive from the perspective of the wider organization.

The change management evaluation should ask:

Which departments absorbed additional work?
Which dependencies became more important?
Did the change create new bottlenecks?
Were customer consequences distributed unevenly?
Did temporary workarounds become permanent?
Did the initiative weaken another strategic priority?
Are new risks understood and owned?
Is the organization sustaining the result through excessive employee effort?

A benefit should not be considered sustainable if it depends on hidden labor, continuing workarounds, or displaced costs.

5. What should the organization do with the result?

The change management evaluation becomes valuable when it leads to a decision.

Possible outcomes include:

Confirm and continue

The change has transferred into operations, benefits are appearing, material risks are controlled, and ownership is clear.

Extend stabilization

The general approach remains valid, but employees, managers, processes, or systems require additional support before the result can be considered sustainable.

Correct the operational design

The delivered capability is useful, but responsibilities, workflows, technology, measures, or governance arrangements need further adjustment.

Expand the change

Evidence supports applying the approach to additional units, customer groups, or processes. Expansion should consider differences in context and capacity.

Revise the expected benefit

The change created value, but not in the form or magnitude originally expected. Leaders should update assumptions and avoid continuing to report an unrealistic benefit.

Retire an ineffective element

Part of the solution does not produce sufficient value or creates unacceptable consequences. Removing it may be more responsible than defending the original design.

Reopen an enterprise decision

The evaluation may reveal a conflict involving strategy, capacity, priorities, risk, or investment. These questions require wider leadership or governance authority.

The decision should include an owner, required action, timeline, evidence for follow-up, and the conditions that would trigger another review.

Interpret evidence as a connected signal picture

Change management evaluation usually combines quantitative and qualitative information.

Potential sources include:

business performance measures;
customer feedback;
operational data;
employee experience;
financial information;
quality and risk indicators;
usage and adoption data;
support requests;
exception records;
process observations;
leadership assessments;
information from related initiatives.

No single source provides a complete answer.

If a dashboard shows improvement while employees describe growing rework, the discrepancy should be investigated.

Several explanations may be possible:

The dashboard excludes reopened cases.
The improvement is concentrated in routine transactions.
A small but important customer group is experiencing worse service.
Employees are carrying a temporary learning burden.
The change improved one process while moving work elsewhere.
The employees’ experience reflects an earlier period and the situation is now stabilizing.

Within the GLCM, information becomes a signal when it is interpreted in relation to a relevant question, context, baseline, objective, or risk.

A signal picture connects several signals so that patterns, contradictions, exceptions, and uncertainty remain visible. It should not compress every result into one average score or traffic-light status.

Be careful about attributing results

Change management evaluation may establish that an outcome changed without proving that one initiative caused the entire change.

This is especially important when organizations are:

implementing multiple projects;
changing staffing or structures;
responding to market developments;
introducing new policies;
experiencing seasonal demand;
changing suppliers or technology;
facing regulatory or economic disruption.

Suppose customer complaints increased after a new system went live. The timing matters, but it does not prove that the system caused the increase.

Leaders should consider:

what else changed during the same period;
whether different units experienced different results;
whether the effect is concentrated in particular processes;
whether the pattern existed before implementation;
which causal explanations fit the evidence;
which alternative explanations remain credible.

Evaluation should be confident enough to support decisions and honest enough to preserve uncertainty.

Example: evaluating an order-management transformation

Consider a manufacturer that replaced its order-management system while consolidating several warehouses.

The project delivered:

a functioning system;
migrated customer and product data;
new order workflows;
completed employee training;
agreed technical requirements.

The project closed on schedule.

Three months later, evaluation shows that order entry is faster. However, delivery complaints have increased, employees maintain manual tracking files, and warehouse teams spend more time resolving exceptions.

A narrow evaluation might report that:

the system was delivered;
employees are using it;
average order-entry time improved.

A complete change management evaluation asks more.

Operational transfer

Warehouse employees can process routine orders, but complex exceptions still require support from former project specialists.

Benefits

Order entry is faster, but the expected reduction in total order-to-delivery time has not occurred.

Unintended consequences

Sales, warehouse operations, and customer service use different definitions of an urgent order. Faster entry therefore creates more downstream escalation.

Sustainability

The reported improvement depends on manual tracking and additional effort from experienced employees.

Attribution

Warehouse consolidation occurred during the same period, so the organization cannot attribute every delivery problem to the new system.

Management decision

Leadership decides to retain the system, extend stabilization, establish one cross-functional definition for priority orders, clarify exception ownership, and review customer and operational results after another business cycle.

The change management evaluation does not declare the entire transformation successful or unsuccessful. It identifies what produced value, what remains unstable, and what requires further management action.

Connect evaluation to the GLCM layers

The five layers of the GRIFFOX Layer Cake Model provide a way to understand what remains after formal project completion.

Foundation and Experience Layer

What organizational conditions, capabilities, cultural patterns, and previous experiences shaped the result?

Framework Layer

Did the methods, governance, roles, measures, and decision rights support sustainable implementation?

Implementation Layer

What was actually embedded in daily work, and what still depends on workarounds or temporary support?

Recalibration Layer

Did the organization learn, adjust, and respond to operational evidence?

Goal Layer

Was the intended outcome achieved and integrated into the organization?

The change management evaluation should concentrate on the Goal Layer while tracing the result back through the other layers. A missing benefit may have originated in implementation, the framework, or an assumption within the original foundation.

This prevents leaders from interpreting every disappointing result as an employee adoption problem.

Project closure should not end reflection

Reflection cycles should continue after operational transfer.

Post-project reflection can examine:

whether outcomes remain stable;
which assumptions proved correct;
where the design required adaptation;
what employees and managers learned;
which risks became more or less important;
whether customer effects matched expectations;
which capabilities the organization developed;
what should be done differently in the next initiative.

The review schedule should follow the expected path of the benefit.

Some effects appear quickly. Others require a complete financial period, seasonal cycle, customer renewal cycle, regulatory review, or sustained period of normal operations.

Leaders should define:

when the result will be reviewed;
which evidence will be considered;
who owns the change management evaluation;
who can make follow-up decisions;
which signals can trigger an earlier review;
when the change management evaluation can reasonably conclude.

Every completed change alters the foundation for the next one

The GLCM is recursive by design.

A completed change does not disappear when its project closes. Its results become part of the organization that will face the next initiative.

The organization may now have:

new systems and processes;
different responsibilities;
stronger or weaker capabilities;
changed customer expectations;
new dependencies;
additional operating costs;
greater or lower capacity;
new cultural experiences;
increased trust or skepticism;
unresolved risks and workarounds;
lessons about what supports successful change.

These outcomes become part of the next Foundation and Experience Layer.

This connection matters because the next project should not begin with an outdated picture of the organization.

A successful change may create capabilities that make a future initiative easier. A difficult implementation may reduce trust or available capacity. A new platform may create dependencies that future project teams need to understand. A temporary workaround may become an embedded operating risk.

The change management evaluation therefore serves two purposes:

It determines what should happen to the completed change.
It updates the organization’s starting point for what comes next.

This is how organizational learning becomes part of the change system rather than remaining in a project archive.

Connect local outcomes with enterprise governance

Many post-project decisions can be handled by operational owners. Others affect several units, initiatives, or strategic priorities.

A Change Office can help integrate evaluation signals, identify recurring patterns, connect benefits with operational consequences, and prepare options for leadership.

The GLCM Enterprise Change Architecture connects these signals with enterprise decisions involving:

capacity;
dependencies;
risk and impact;
prioritization;
strategic alignment;
governance and decision rights.

This does not transfer operational ownership back to a central office. It ensures that consequences crossing organizational boundaries reach the appropriate decision process.

Common change management evaluation traps

Leaders should watch for several recurring mistakes:

Treating project completion as proof of organizational success
Evaluating deliverables without examining outcomes
Ending measurement when the project budget closes
Leaving benefits without an operational owner
Measuring initial adoption without testing sustainability
Ignoring differences among teams, locations, or customer groups
Claiming benefits without considering other changes
Averaging results until material exceptions disappear
Reporting improvements while overlooking displaced work
Treating temporary workarounds as normal operations
Evaluating the initiative only from the project team’s perspective
Failing to transfer lessons into future change decisions

Questions leaders should ask after project completion

What did the project actually deliver?
Which intended organizational outcome was the delivery expected to create?
Has the result transferred into operational ownership?
Can employees manage routine work and important exceptions?
Are the intended benefits appearing?
Are those benefits continuing under normal operating conditions?
Which units, employees, or customers experience different results?
What additional work, costs, risks, or dependencies appeared elsewhere?
Does the result depend on temporary support or hidden effort?
What other changes may have influenced the outcome?
Which assumptions proved correct or incorrect?
What uncertainty remains?
Should we continue, stabilize, correct, expand, revise, retire, or reconsider the result?
Who owns the next decision and action?
What has this experience changed in the Foundation and Experience Layer for the next initiative?

Evaluation closes one project and informs the next change

Change management evaluation should not repeat a project completion report.

Its purpose is to determine whether the delivered change has become operational, whether its benefits are credible and sustainable, and whether unintended consequences require attention.

A useful evaluation connects delivery, operational ownership, benefits, risks, dependencies, and organizational experience. It leads to a decision about what to retain, strengthen, expand, correct, or retire.

It also updates the organization’s understanding of itself.

Every completed change alters systems, capabilities, relationships, expectations, culture, and experience. These conditions become part of the Foundation and Experience Layer for the next initiative.

Project closure may end a temporary structure. Change management evaluation ensures that its results and lessons continue to inform responsible organizational change.

About the Author

Harald Lavric is the founder of GRIFFOX Consulting and the developer of the GRIFFOX Layer Cake Model. He works with organizations facing complex and continuous change, helping leaders connect strategy, operational reality, organizational learning, and enterprise decision-making. His work focuses on making change more visible, integrated, and manageable across initiatives, teams, and organizational boundaries.