Running the Machine: What Operational Thinking Actually Looks Like in a Project

There's an ongoing debate in delivery management circles about whether project managers should think of themselves as CEOs of their projects. The appeal is obvious — it signals ownership, breadth of accountability, strategic thinking. It sends the periscope up.

The problem is that it signals the wrong kind of ownership. In most organizations, the project manager does not hold the purse. Someone else owns the funds, authorizes the resources, and is accountable for whether the benefits of the investment are realized. Even in the most expansive PM roles, outcomes and benefits are shared accountability with decision-makers — and shared accountability, in practice, means someone else is making the calls that define what success actually requires.

If the CEO hat doesn't fit, a different one might be more useful: the COO. Chief Operating Officer. The person accountable not for the mission itself, but for the quality of the operation that delivers on it.

That reframe changes what a project manager focuses on, and more importantly, what they design for.

The Question a COO Answers

Strip away the title and what remains is a specific professional obligation. The COO designs and runs an operating environment that enables a team to deliver agreed-upon goals with respect for resources, humanity, and the future.

In project terms, that translates to a guiding question:

Based on the benefits and outcomes needed, what outputs get us there, and what is the most respectfully resilient way to achieve them?

"Respectfully resilient" does real work in that sentence. Respectful because the operation involves people — their time, their talent, their trust — and deserves to be designed with that in mind. Resilient because the operation exists in the real world, where conditions change, and the design has to absorb that change without breaking.

The COO doesn't set the destination. The COO designs the engine that gets there — and takes responsibility for whether that engine runs with integrity.

Designing the Operation

Thinking like an operator starts with a business design question: what does the project need to be able to do? Not what does it need to deliver — that's the scope conversation. This is the capability conversation.

Decision-making, communication flows, data flows, quality management, responsiveness to new information — these are the processes that make a project operate, and they're separate from the deliverables the project produces. A project with excellent scope definition and terrible decision-making processes will fail just as reliably as one with poor scope.

Before going deep on any of these, an operator checks what's already in place. Respectful resilience includes not reinventing wheels or consuming airtime that isn't needed.

• What exists in the organization that can be leveraged?

• What standards or regulations constrain the choices?

• What's the make-or-buy decision for each capability the project needs?

That last question is underrated. Some project capabilities need to be purpose-built because nothing in the existing environment fits. Others can be borrowed, partnered on, or adapted from what's already working. An operator who builds everything from scratch is spending the project's political and resource capital on infrastructure instead of outcomes. An operator who borrows everything without checking fit is hoping the borrowed machinery works for a purpose it wasn't designed for.

The judgment between those extremes — what to build, what to borrow, what to adapt — is a core operational skill, and it's one that distinguishes experienced project leaders from those still learning the craft.

Operating With Four Lenses

Once the design is in place and the project is moving, the operational discipline becomes about vigilance across four areas. These aren't process steps — they're concurrent, persistent, and present in every healthy project regardless of method.

Team. Developing and leading people toward their best self-directed selves. This means more than staffing and skills matrices. It means succession-managed collaboration, growth opportunities within the project, and an environment where capability expands through the work rather than being consumed by it.

Task. Managing activities for efficiency and effectiveness. This is the visible, trackable, reportable part of project management — the schedules, the backlogs, the dashboards. It matters, and it isn't the whole job. An operator who over-indexes on task management at the expense of the other three lenses produces a project that looks healthy on paper and feels brittle in the room.

Traffic. Coordinating the flow of information, input, and decision-making for helpful exchange and reducing unnecessary noise. Every project has a signal-to-noise problem. Meetings that exist by habit rather than purpose, status reports that duplicate each other, communication channels that create more confusion than clarity. An operator designs for traffic management the way an engineer designs for flow — not by adding capacity, but by removing friction.

Trouble. Keeping watch for instability, emerging risks, and the early signals that something is shifting. This is the alerting system, the radar, the practice of noticing what hasn't gone wrong yet but might. It's also the escalation design — when something is spotted, where does it go, how fast, and what happens when it gets there?

From this vigilant foundation, a project can absorb change, support innovation, and maintain the trust of its stakeholders. Without it, every adaptation feels like a crisis and every course correction costs more than it should.

The Operational Test

A project manager thinking like a COO can answer a specific set of questions from the strength of how the project operates, not just from the content of what it delivers:

• How do we make decisions, and how are we funded?

• How do we collaborate and communicate, and how do we get work done?

• How do we measure success, and how do we raise alerts?

• How do we confirm alignment, and how do we ask for help?

• How do we deliver our results into a new business as usual?

If those answers are clear, connected, and practiced, the operation is healthy. If they're aspirational or live only in the project manager's head, the operation is fragile — no matter how good the Gantt chart looks.

Leadership Reflection

• If someone joined your project team next week, could they understand how the project operates — not just what it's delivering, but how decisions get made, how information flows, and where to go when something goes sideways? If that understanding lives mostly in your head, what would it take to make it visible and shared?

• Consider the four lenses — team, task, traffic, trouble. Which one gets the most of your operational attention right now, and which one are you neglecting? What's the cost of that imbalance?

This Field Note is part of Maypop Grove’s work in Project Recovery. It supports the practice of Strengthen Systems: building the routines, decision flow, operating rhythm, and feedback loops that help real work hold together.

Next step: Look at one project and ask whether the operating system is clear enough to carry the work.