9.1 KiB
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:
-
Evaluate System B
-
Design the migration
-
Migrate the data
-
Test
-
Train users
-
Deploy
-
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
My organizational context
My team's capacity is shared between several types of work:
- Departmental projects
- Product initiatives and continuous product work
- Operational responsibilities and incidents
- Tickets and requests
- Work dependent on IT teams such as DevOps and Security
This means that project delays cannot be understood only by looking at project timelines. Project work competes with operational and product work for the same finite team capacity.
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
- Outcomes and Definition of Done
- Scope and Scope Creep
- Milestones vs Tasks
- Capacity and WIP
- Portfolio Management