1.2.2: Operations and projects- two different engines

Projects versus Operations 

Projects and operations look similar from a distance. Both involve people doing planned work, following schedules, spending budget, and reporting progress to someone above them. But they behave very differently, and mixing them up causes real damage to a portfolio. Projects are temporary. They exist to create something new and then they end. Operations are ongoing. They exist to keep the business running day after day, with no defined endpoint built into their purpose.

Class examples make the split clear. Projects include building a freeway, designing a car, organizing a wedding, or launching a new website, each one a defined effort that closes out once its unique result exists. Operations include running customer service, managing vendors and contractors, handling sales, purchasing materials, training employees, and maintaining equipment like jet engines, each one a repeatable function that continues indefinitely as part of how the business simply operates. Even something as large as a nationwide vaccination rollout can sit on the operations side once it becomes a repeatable, ongoing process rather than a one-time build, which is a useful reminder that scale alone doesn't determine which category a piece of work belongs to.

Key Definition: Burning Money Versus Making Money

Projects are temporary endeavors that burn money to create unique products, services, or results. Operations are ongoing, repetitive tasks that make money and increase efficiency. That single contrast, burning capital to build something new versus generating revenue from something already built, is the fastest way to sort a given activity into the right category when the label isn't obvious at first glance.

That contrast holds up well as a mental shortcut, but the deeper reason it matters is that projects and operations don't just spend money differently, they behave differently as a matter of underlying nature, which shapes everything about how each one should be planned and controlled.

How Projects and Operations Actually Differ

Projects and operations carry genuinely different characteristics that go beyond simply "new versus ongoing." Projects burn money. They are unpredictable, since building something that has never existed before inherently involves discovering problems along the way that no one could have fully anticipated at the outset. They need heavy planning along with monitoring and control, precisely because that unpredictability has to be actively managed rather than assumed away. Operations make money. They aim to increase efficiency, refining an existing process rather than inventing a new one. They are more predictable, though they still need monitoring and control to stay healthy, since predictable work can still drift or degrade without attention, it just drifts more slowly and more quietly than a project typically would.

Building a Freeway Versus Running Customer Service

Building a new freeway is unmistakably a project. It has a defined start, a specific engineering design that has never existed on that stretch of land before, a fixed set of deliverables, and a closeout date once the road opens to traffic. Running customer service, by contrast, is unmistakably operations. There's no end date built into the work itself, the process repeats call after call and ticket after ticket indefinitely, and its success is measured by ongoing efficiency and consistency rather than by a single delivered outcome. A software app being built for the first time follows the freeway's pattern, temporary, unique, and destined to close out once launched. Application support for that same software once it's live follows customer service's pattern instead, an ongoing function that continues for as long as the software exists.

Notice that the freeway and the app are structurally identical as projects despite looking nothing alike on the surface, and the same holds for customer service and application support as operations. What actually determines the category isn't the industry or the subject matter, it's whether the work is building something new and temporary or sustaining something that already exists indefinitely.

The Handoff From Project to Operations

Most valuable organizational work eventually crosses the line between these two categories, since a project's whole purpose is usually to produce something that operations will then run for years afterward. This creates a transition lifecycle where completed, unpredictable project deliverables are handed over to predictable operational teams for long-term sustainment, echoing the benefits transition discipline studied earlier in program management, where an unmanaged handoff was shown to quietly undo months of careful delivery work.

Important Concept: The Project-to-Operations Handoff

A project's deliverable doesn't finish creating value the moment it's built, it starts creating value once it's successfully absorbed into ongoing operations. The new freeway only generates its intended economic benefit once a transportation department has taken over its maintenance schedule. The new website only generates value once a support team is trained, staffed, and ready to keep it running. This handoff moment, from unpredictable project delivery to predictable operational sustainment, is one of the highest-risk points in the entire lifecycle of an investment, since a poorly managed transition can strand a perfectly good deliverable with no one prepared to keep it functioning.

That handoff risk is exactly why the monitoring and control mechanisms appropriate to each side of the line look so different from one another, and confusing the two, applying the wrong kind of oversight to the wrong kind of work, is one of the more common ways this transition goes wrong.

Different Monitoring for Different Kinds of Work

Project volatility calls for monitoring and control mechanisms built around detecting deviation early and adjusting course quickly, tools like earned value management, risk registers under active review, and frequent milestone checkpoints, all designed around the assumption that the unexpected will happen and needs to be caught fast. Operational predictability calls for a different set of mechanisms entirely, ones built around maintaining consistency over long stretches of time, quality control sampling, service level agreements, and trend monitoring designed to catch slow drift rather than sudden deviation. Applying project-style volatility monitoring to a stable operational process tends to generate noise and false alarms over normal variation, while applying operational-style trend monitoring to a genuinely volatile project tends to miss problems until they've already grown large enough to be undeniable.

A portfolio manager needs both kinds of mechanisms available and needs to know which one belongs where, since the whole portfolio is typically made up of some components still in their volatile, project phase and others already living in their stable, operational phase. Getting this pairing right connects directly to a broader skill portfolio managers rely on throughout their work: adjusting understanding and strategy as new detail becomes available rather than locking in a single fixed view too early.

Progressive Elaboration in Portfolio Strategy

A portfolio manager should be able to apply principles of progressive elaboration to adapt portfolio strategy as new operational realities and component details emerge. Progressive elaboration means accepting that early-stage understanding of a component is necessarily incomplete, and refining that understanding continuously as more information becomes available, rather than treating an initial plan or categorization as fixed and final. A component that looked like a straightforward project at initiation may reveal, partway through, that a piece of what was scoped as project work is actually better handled as an operational function, or vice versa, and a portfolio manager willing to revise that classification as reality clarifies avoids locking a component into the wrong kind of oversight for the rest of its life.

That same willingness to revise understanding as reality clarifies is exactly what's missing in the failure pattern that causes the most damage when projects and operations get blurred together.

When Operational Costs Quietly Eat Project Budgets

A common failure point is letting operational costs quietly eat into project budgets. This happens when daily service demands spike and someone decides to pull from capital funds instead of raising the issue formally, treating a temporary funding source as a convenient patch for an ongoing shortfall. Once that habit starts, it becomes very hard to stop, and it slowly starves the organization's ability to invest in anything new, since money meant to build the future keeps getting diverted to simply keep the present running.

Myth: Operational Work Can Borrow a Project's Framework Without Consequence

It's tempting to think that wrapping an ongoing operational need in a project's structure, a defined scope document, a schedule, a dedicated budget line, is simply good discipline applied to operational work, with no real downside. Doing this quietly reclassifies recurring, ongoing costs as one-time capital spending, and once that reclassification takes hold, it becomes very difficult to reverse, since the operational need never actually goes away once the "project" closes out on paper. The organization ends up with a capital budget that looks healthy on a portfolio dashboard while silently funding activities that will need funding again next quarter, and the next, indefinitely. The deeper danger isn't sloppy bookkeeping, it's that this practice makes the portfolio's own data lie to the people relying on it to make investment decisions.

That kind of quiet reclassification is corrosive precisely because it doesn't look like a crisis in the moment, it looks like resourcefulness, someone solving a real problem with money that happened to be available. The organization only discovers the damage later, when capital funds meant for genuine new investment turn out to already be committed to operational demands nobody formally acknowledged as ongoing.

Keeping the Line Visible and Defended

A good portfolio manager keeps this line visible and defended. Operations should be funded to run efficiently on their own budget. Projects should be funded to build the future. When the two budgets stay separate, the organization can grow without quietly starving itself, preserving its ability to invest in what comes next rather than perpetually patching what already exists.

Effective portfolio management requires rigorously separating and balancing the capital burn of new initiatives against the revenue generation of steady-state operations. That balance is not a one-time decision made when a portfolio is first assembled, it's an ongoing discipline, revisited as components move through the transition lifecycle from project to operations and as progressive elaboration reveals that a piece of work belongs on a different side of the line than originally assumed. A portfolio manager who defends that line consistently protects the organization's ability to keep building, even while everything already built keeps running well underneath it.