Should This Be a Project or an Operating Model Change?

Should This Be a Project or an Operating Model Change?

A practical question that can determine whether transformation creates lasting value—or simply delivers another project.

There is a question leaders should ask much earlier in a transformation than they often do:

Are we actually running a project, or are we changing the way the business operates?

It sounds like a matter of semantics.

It isn’t.

The distinction has real consequences for investment, governance, accountability, talent, technology, and—ultimately—the value the organization gets from the change.

We see this pattern regularly. An initiative starts with a defined scope, a budget, a project team, and a target go-live date. Everyone knows what needs to be delivered.

But somewhere along the way, the initiative begins changing much more than the original brief suggested.

Decision rights move. Teams are reorganized. Processes cross functional boundaries. New capabilities are required. Performance measures change. Technology becomes embedded in day-to-day work.

At that point, the organization isn’t simply delivering a project.

It is changing its operating model.

And treating the latter as the former can create a very predictable outcome: a technically successful project that doesn’t produce the business change leadership expected.

“The project is the vehicle. The operating model is the destination.”

Start with the change—not the project plan

The natural organizational response to a significant initiative is to build a project.

There is a comfort to the structure. A project has a sponsor, workstreams, milestones, risks, dependencies, and a budget. Progress can be reported. Decisions can be escalated. Eventually, the project can be closed.

That discipline is valuable.

But it can also create a blind spot.

When the project structure arrives before the organization has defined what needs to be different, the project plan can become the de facto definition of the transformation.

The team starts optimizing for delivery rather than outcomes.

The system goes live.

The process is documented.

Training is completed.

The steering committee closes the program.

And then the business discovers that people are still working around the new process, managers are still making decisions the old way, and the expected benefits aren’t showing up at the pace originally assumed.

The issue isn’t necessarily poor project management.

The issue is that the project solved for delivery when the business needed to solve for a new way of operating.

What actually makes something an operating model change?

An operating model describes how an organization turns strategy into execution.

It connects the practical elements of the business: people, processes, technology, governance, decision rights, capabilities, and performance management.

That means an operating model change doesn’t necessarily require a major reorganization.

It can be much more subtle.

Suppose a company introduces a new digital sales platform.

The technology implementation may be a project.

But if salespeople now work differently, customer ownership changes, marketing and sales responsibilities shift, new data capabilities are required, incentives are redesigned, and managers use new performance metrics, the organization has changed how it operates.

The platform is only one component.

The operating model is the bigger picture.

This is why the first question shouldn’t be, “What are we implementing?”

It should be:

“What will the business do differently when this is successful?”

That answer tells you a lot about the nature of the change.

Five signals that you’ve outgrown the project definition

Not every initiative requires an operating model redesign. But there are some reliable signals that the original project framing may no longer be sufficient.

1. The change is intended to be permanent

Projects end.

Operating models are designed to endure.

If the organization expects the new way of working to remain in place for years, it deserves more thought than a temporary implementation structure.

The project may still be responsible for getting the organization there. But someone needs to own what happens afterward.

2. Decision rights are moving

This is one of the strongest signals.

If the initiative changes who can make decisions, who owns outcomes, who approves exceptions, or where accountability sits, you’re changing more than a process.

You’re changing how the organization works.

And decision rights should never be left as an accidental consequence of implementation.

They should be designed.

3. New capabilities are required

Technology doesn’t create capability by itself.

A new platform may require different skills. Automation may require new data and analytics capabilities. A new customer model may require different commercial and service capabilities.

The question is not simply whether the organization can deploy the solution.

It’s whether the organization can operate and improve it at scale.

4. Measures and incentives are changing

Organizations pay attention to what they measure.

If the initiative introduces new KPIs, service levels, incentives, management routines, or reporting structures, it is influencing behavior.

That makes measurement part of the operating model—not simply project reporting.

5. Nobody knows who owns it after go-live

This is the simplest test.

Ask:

“Who owns this on the day after the project closes?”

Who funds it?

Who governs it?

Who improves it?

Who owns the underlying capabilities?

Who makes decisions when the model encounters something the project team never anticipated?

If those answers are unclear, the project isn’t finished.

The organization hasn’t yet designed the mechanism that will sustain the change.

The go-live trap

One of the most persistent misconceptions in transformation is that go-live equals change.

It doesn’t.

Go-live means something has been deployed.

Whether the business has actually changed is a different question.

This distinction matters because organizational change is rarely linear. People adapt. Workarounds emerge. Priorities shift. New leaders arrive. Customers behave differently than expected. The business encounters exceptions that weren’t visible during design.

The operating model has to absorb all of that.

A successful transformation therefore needs more than implementation.

It needs institutionalization.

The new way of working has to become part of how decisions are made, how people are managed, how performance is measured, and how resources are allocated.

“Go-live is a milestone. It is not evidence that the organization has changed.”

Don’t turn every project into an operating model exercise

There is an equally important caution.

The answer isn’t to turn every project into a massive transformation program.

That’s another form of poor judgment.

Some initiatives are genuinely projects. They have a defined outcome, limited organizational impact, and a natural endpoint.

If a company is replacing a piece of equipment, refreshing a website, or delivering a contained capability with minimal impact on roles and decision-making, a project approach may be exactly right.

The goal isn’t to make every initiative bigger.

The goal is to make the management approach fit the nature of the change.

That requires leaders to be honest about what is actually changing.

A better way to frame the work

At Cybaxis, we think about this as a simple sequence:

Strategy → Operating Model → Initiatives → Execution → Value

The strategy establishes where the organization is going.

The operating model defines how the organization needs to work to get there.

The initiatives translate that model into action.

Execution makes the change real.

And value is the test of whether the whole system is working.

Problems arise when organizations skip the operating model step.

A collection of projects gets launched. Each one has a business case. Each one has a sponsor. Each one has milestones.

But the projects may not add up to a coherent future state.

One team is redesigning processes. Another is implementing technology. A third is restructuring roles. A fourth is changing performance metrics.

Everyone is busy.

But nobody is necessarily designing the system those changes create together.

That’s where an operating model lens becomes powerful.

It provides the connective tissue.

So, which is it?

The answer doesn’t have to be complicated.

Ask four questions:

What is changing?

How long is it intended to last?

What will people, teams, and leaders need to do differently?

Who owns the new way of working once the project is over?

If the answers point to a one-time deliverable, manage it as a project.

If they point to a sustained change in how the organization makes decisions, allocates work, develops capabilities, measures performance, and delivers value, treat it as an operating model change.

And if it’s somewhere in between, acknowledge that.

Not every transformation fits neatly into one box.

What matters is that the organization makes the choice deliberately rather than discovering six months after go-live that the project was carrying a much larger organizational change on its shoulders.

The question behind the question

Ultimately, this isn’t really a debate about projects versus operating models.

It’s a question about what kind of change the business is actually trying to make.

If leadership wants a deliverable, build and manage a project around that deliverable.

If leadership wants the business to operate differently, start by designing what “different” needs to look like.

Then determine which projects, capabilities, organizational changes, and investments are required to get there.

That shift in perspective can change everything—from the business case and governance model to the way success is measured.

More importantly, it puts the focus where it belongs:

on the business outcome, not the project activity.

At Cybaxis, we help leaders make that distinction.

We work with organizations at the point where strategy meets execution—helping leadership teams translate ambition into practical operating models, prioritize the changes that matter, and turn complex transformation into a set of decisions the organization can actually execute.

If you’re about to launch a major initiative, don’t start with the project plan.

Start with a more fundamental question:

What are we actually changing—and what will it take for that change to become the way we operate?

Talk to Cybaxis about the change you’re considering.

The right answer at the beginning can save a great deal of work at the end.