SecondBrain/10 Knowledge/CTO Academy/Project Management/Projects vs Operations.md

Duration: 25–30 minutes

## Definition

### What is a project?

A **project** is a temporary effort undertaken to create a specific, unique outcome.

A project has:

- A defined objective or outcome
    
- A beginning
    
- An end
    
- Work required to reach that end
    
- Someone accountable for delivering it
    

The important word is **temporary**.

Once the desired outcome has been achieved, the project should end.

### What are operations?

**Operations** are recurring activities required to keep a service, product, system, or organization functioning.

Operations generally:

- Repeat
    
- Continue indefinitely
    
- Have no natural completion date
    
- Maintain an existing capability rather than create a new one
    

A useful distinction:

> **Projects create or change something. Operations run and maintain something.**

---

## Simple Mental Model

Ask:

> **"Can I clearly describe what happens when this work is finished?"**

If yes, it is probably a **project**.

If the answer is essentially "we keep doing it," it is probably **operations**.

---

## How It Works

Consider three types of work.

### 1. Project

You currently use System A and want to replace it with System B.

The work might involve:

1. Evaluate System B
    
2. Design the migration
    
3. Migrate the data
    
4. Test
    
5. Train users
    
6. Deploy
    
7. Decommission System A
    

Eventually:

**Done.**

The project disappears from the active project list.

### 2. Operations

Your team monitors production websites.

Every week:

- Alerts occur
    
- Tickets arrive
    
- Bugs are investigated
    
- Services are monitored
    
- Problems are resolved
    

There is no point where you say:

> "Great. Production monitoring is complete forever."

It continues because it is an operational responsibility.

### 3. Project that creates an operation

This is extremely common in technology.

Suppose you introduce a new monitoring platform.

**Project:**

> Implement automated website monitoring.

Once implemented, the project ends.

But it creates a new operational responsibility:

> Monitor alerts and respond to incidents.

The project therefore moves through:

**Build → Deliver → Operate**

A common management mistake is never making that transition explicit. The "project" then remains open indefinitely even though the project itself finished months ago.

---

## Example

Imagine the company wants automated testing for website releases.

### Project

**Implement an automated website testing pipeline**

Outcome:

> Critical website tests run automatically before deployment.

Possible project work:

- Identify critical tests
    
- Select tooling
    
- Build test suite
    
- Integrate with deployment pipeline
    
- Validate results
    
- Document process
    
- Train the team
    

Once those things are delivered and accepted:

**Project closed.**

### Operations

Afterward:

> Maintain and operate the automated testing pipeline.

Your team might:

- Investigate failed tests
    
- Add tests as websites change
    
- Update dependencies
    
- Fix broken automation
    

That work continues.

It shouldn't keep the original implementation project permanently open.

---

## How It Fits Into the Bigger Picture

This distinction matters because projects and operations need different forms of management.

**Projects require:**

- Outcomes
    
- Scope
    
- Milestones
    
- Deadlines
    
- Dependencies
    
- Risks
    
- Completion criteria
    

**Operations require:**

- Service levels
    
- Processes
    
- Capacity
    
- Quality measures
    
- Recurring responsibilities
    
- Operational KPIs
    

This also connects directly to what you've been learning about **measurement and output**.

For projects, useful output might be:

> "Migration completed and accepted."

For operations, output might instead be:

> "95% of requests completed within SLA."

You shouldn't necessarily measure both types of work the same way.

---

## My Company / Real-World Context

Your Monday board gives us several good examples.

### Umami

This looks like a project if the objective is something such as:

> Implement Umami analytics and migrate the required tracking from the existing solution.

There should eventually be a point where implementation is complete.

Afterward, however, maintaining analytics becomes operational work.

---

### Suppression de Mogador

This sounds strongly project-oriented.

There is a target state:

> Mogador is no longer required and can be safely decommissioned.

Once that state is achieved, the project ends.

---

### Pipeline QA d'automatisation

If you're **building** the QA pipeline:

**Project.**

Once the pipeline exists, maintaining and using it becomes:

**Operations.**

---

### Monitoring de la synchro Mogador

This one is interesting.

If the objective is:

> Create automated monitoring for the Mogador synchronization.

That's a **project**.

If the work is:

> Regularly monitor Mogador synchronization and intervene when problems occur.

That's **operations**.

The title alone doesn't tell us which one it is.

And that's already useful.

---

### Gouvernance des données

This is where things get more complicated.

Data governance itself is **not a project**.

You don't eventually announce:

> "Data governance is finished."

It's an ongoing organizational capability.

However:

> Establish the company's first Data Governance Framework

could absolutely be a project.

That project might deliver:

- Data ownership model
    
- Governance policies
    
- Data classification
    
- Data quality process
    
- Data catalog
    
- Governance committee
    
- Roles and responsibilities
    

Once established, the project ends.

Then:

> Operate the Data Governance Program

becomes ongoing work.

This distinction is especially important for large initiatives.

---

## CTO Perspective

A technology leader isn't simply managing a list of work.

They need to understand **what kind of work the organization is doing**.

If projects and operations are mixed together, several problems appear.

A project board can become permanently full because operational responsibilities never leave it.

The organization can also appear to have enormous numbers of "projects" when much of the workload is actually recurring operational work.

More importantly, both consume the **same people's capacity**.

Suppose an integrator theoretically has 35 hours available.

They might spend:

- 15 hours on tickets and support
    
- 5 hours on maintenance
    
- 5 hours in meetings
    
- 10 hours on projects
    

From a project-planning perspective, that person doesn't have 35 hours of project capacity.

They have roughly **10**.

This is one reason understanding projects vs operations becomes important later when we study **capacity and WIP**.

### Questions to Ask

- What specific outcome makes this project complete?
    
- Is this temporary work, or will someone need to continue doing it indefinitely?
    
- When this project ends, what operational responsibility does it create?
    
- Who will own that responsibility after the project closes?
    
- Are recurring operational activities consuming capacity that I'm currently treating as available project capacity?
    

---

## Meeting Scenario

**Situation:**

Your VP asks:

> "Why is the team working on so many projects? I see 15 projects assigned to the department."

You review the list and realize several entries are actually recurring activities such as monitoring, maintenance and ongoing governance.

**Possible response:**

> We're currently mixing projects and operational responsibilities in the same portfolio. I'm separating them so we can see how many actual projects we're delivering and how much team capacity is being consumed by ongoing operations. That should give us a more accurate picture of our project capacity.

That is considerably more useful than simply saying the team is busy.

---

## Key Takeaways

- A **project is temporary** and delivers a specific outcome.
    
- **Operations are ongoing** activities required to maintain a capability or service.
    
- Projects often **create something that later becomes operational**.
    
- A broad initiative such as "Data Governance" can contain projects without itself being a project.
    
- Mixing projects and operations makes workload and capacity harder to understand.
    
- Every project should have a point where you can confidently say **"this is done."**
    
- Before estimating project capacity, you need to understand how much capacity operations already consume.
    

## Related Concepts

- [[Project Outcome]]
    
- [[Definition of Done]]
    
- [[Scope]]
    
- [[Milestone]]
    
- [[Capacity]]
    
- [[WIP]]
    
- [[Portfolio Management]]