When the Project Closes and the Change Isn't Done

Here is a scene that plays out in organizations running structured delivery frameworks with some regularity.

The project go-live has occurred, all execution gates have closed, the deliverables have been handed over, and the work is in the sustain phase. The PMO (project management office) is looking at the project plan, at the close-out checklist, at the book of work that has a date on it, and saying: we are done. The budget needs to reconcile. The resources need to roll off. The sustain phase has a gate, and this project has reached it.

Across the table, the CMO (change management office) is looking at something different. She is looking at adoption metrics that are not where they need to be. At managers who said the right things in training and are now defaulting to the old process. At a business unit that technically received the change and is quietly already finding ways to work around it. She is saying: we are not done. Sustain is where the work actually sticks -- or doesn't. Closing the project plan doesn't change that.

Neither of them is wrong. That is exactly the problem.

This is not a conflict between two people or departments. It is a conflict between two different theories of what "done" means. And in this case, it is the framework within which they are both working that has created the problem.

What Each Side Is Actually Arguing

The PM's position is coherent. Projects have lifecycles. Budgets have close dates. Resources have other commitments. A delivery framework without a defined end to Sustain is a framework that never actually closes anything. From a project governance standpoint, the question of when Sustain ends is not philosophical -- it is practical, financial, and organizational. The book of work closes. The PMO closes with it.

The CM's position is equally coherent. Adoption does not follow a project timeline. Behavior change is not a deliverable you hand over at go-live and mark complete. Reinforcement, resistance management, coaching through the dip, watching whether the new way of working is actually taking hold in the business -- these happen after the project plan ends, not before. Sustain, from a change perspective, is not the tail end of the project. It is the part where the investment either pays off or quietly fails.

Both positions hold. The conflict is not because one side is being unreasonable. The conflict exists because the framework was built around project logic, and change work does not run on the same clock.

The Framework Problem Underneath the People Problem

Most delivery frameworks -- whatever they are called, whatever the phases are named -- are structured around the lifecycle of a project. They have phases because projects have phases. They have gates because projects need decision points. They have close conditions because projects have to end.

OCM gets fitted into this structure. Deliverables get assigned to phases. Activities get mapped to gates. The CM gets a swim lane in the project plan. And this works, up to a point -- the point being exactly the sustain-adoption conflict described above, where the project logic and the change logic hit each other head-on.

The deeper problem is what the fit reveals. When OCM lives inside the project as a workstream, it inherits the project's constraints: the project's timeline, the project's budget cycle, the project's definition of done. A workstream has a start, milestones, and an end. That structure is appropriate for building a system, migrating data, or redesigning a process. It is not appropriate for building the human capability and organizational conditions that make those things actually land.

When OCM is a workstream, sustainment ends when the project ends. That is not a policy. It is the logic of the container. And it is why the PM and the CM keep having the same argument on every project that reaches this gate.

Someone had to say it.

What Both Sides Actually Agree On

Here is the thing: if you ask the PM and the CM to describe the ideal outcome, they will tell you the same story.

The project closes. The business has internalized the change. The processes, the behaviors, the new ways of working have shifted from project-supported to self-sustaining. Operations have moved from the project team to the business team. Business as Usual has begun. The project plan closes cleanly because there is nothing left for the project to hold.

They agree completely on what that looks like. The conflict is not about the destination. It is about who certifies that they have arrived.

The PMO closes the project plan. But a closed project plan does not confirm that the business is ready to own Sustain independently. It confirms that the project deliverables have been completed. Those are related things, but they are not the same thing. A system can be live, a training program can be complete, a communications plan can have run its full arc -- and the business can still not be ready to carry reinforcement without the project team's support.

This is not a failure of the CM to finish her work. It is a failure of the framework to design the handoff.

The Handoff Is the Design Decision That Was Never Made

Every delivery framework that runs OCM as a workstream has, somewhere inside it, an implicit assumption: that by the time the Sustain gate closes, the business is ready to own what comes next.

That assumption is almost never examined. It is rarely made explicit. It is not usually articulated as a handoff condition that requires a specific readiness check before the project plan can close. It is just assumed -- and then, when the assumption turns out to be wrong, the CM and the PM end up in a room disagreeing about whether Sustain is over.

The business inheriting Sustain is not the same as the business being ready to carry it. Ready means there is a named owner for reinforcement. Ready means frontline managers have the skills and the information to support the change without the project team behind them. Ready means the feedback loops that surfaced resistance during implementation have been handed to someone in the business who will keep listening. Ready means the organization knows what to do when adoption dips -- because it will dip, and the project will not be there to catch it.

If those conditions are not confirmed before the project closes, the project has not actually finished its job. It has just transferred an unresolved problem to a business that was not asked whether it was ready to receive it.

The One Question Worth Asking

This brings us to the question that most delivery frameworks are not designed to ask, and the one that matters most before any Sustain gate closes.

If OCM is a workstream today, what would have to change for it to be a function?

Not a deliverable question. Not a phase question. A structural question.

A workstream lives inside a project. It inherits the project's scope, timeline, and close conditions. It ends when the project ends, because that is what workstreams do.

A function lives in the organization. It has accountability that persists across projects. It holds a portfolio view of change across the entire book of work. It sits upstream of project design -- shaping how projects are scoped and sequenced -- rather than downstream, absorbing the human implications of decisions that were made without it.

When OCM is a function, the Sustain question looks different. The CMO does not need to argue that the project should stay open. She has standing to define, at the framework level, what readiness conditions must be confirmed before Sustain transfers from the project to the business. That conversation happens once, in the framework, rather than on every project that reaches the gate.

The PM does not need to defend the close date. The project closes when the handoff conditions are met -- and those conditions were agreed upon before the project started.

The Sustain conflict is not a failure of coordination between the PM and the CM. It is a symptom of a design decision the organization has not yet made: where OCM actually lives, and what authority it holds.

What the Conflict Is Telling You

The organizations developing delivery frameworks right now -- building out their PMO and CMO working rhythms, mapping deliverables to phases, negotiating where OCM activities belong -- are doing important work. Framework design is not administrative. It encodes assumptions about what the organization values and how it thinks change happens.

The Sustain conflict is a gift, if you treat it as one. It is showing you, precisely and specifically, where the framework has an unresolved design question. Not a communication problem. Not a skills gap. A design question: is OCM a workstream or a function, and what does the answer mean for how we govern the handoff from project to business?

That question is worth answering at the framework level before the next project closes and the same conversation happens again.

Because here is what the conflict is really about, at its core: the project closes when the project is done. The change is done when the business doesn't need the project anymore. Designing a framework that can tell the difference between those two things -- and build the bridge between them -- is the work.

Try This

Before your next project closes the Sustain gate, ask one question in the room: has the business named who owns reinforcement after the project closes -- not who is aware of it, not who attended the training, but who owns it?

If the answer requires a meeting to figure out, the handoff is not ready. And the project is not done.

Seneca Bailey is an organizational change strategist and the founder of Unbroken Work. She writes on change management, organizational design, and the systems that determine whether transformation actually lands. More at unbrokenwork.com.