Projects vs Daily Operations
Most people hold both kinds of work at once: the thing that has to ship by March, and the queue that refills every morning. They pull in opposite directions, they are measured differently, and only one of them will interrupt you. Knowing which is which changes how you spend a Tuesday.
In short
- Operations keep the organisation running. Projects change what it is.
- Operations are improved by making them more repeatable. Projects are improved by reducing uncertainty earlier.
- Operational work is urgent and arrives on its own; project work is important and waits. That asymmetry is why projects slip.
- Every finished project turns into somebody’s operations. Plan the handover, or the project never truly ends.
Two different kinds of good
The mistake isn’t confusing the definitions — most people can tell a product launch from a support queue. The mistake is applying one’s standard of excellence to the other.
An excellent operation is boring: the same input produces the same output, faster and cheaper each quarter, with fewer surprises. An excellent project is the opposite — it is a controlled encounter with things nobody knew yet, and its measure of success is that the uncertainty got resolved before it got expensive.
| Aspect | Project | Daily operations |
|---|---|---|
| Purpose | Produce a specific outcome that doesn’t exist yet | Keep an existing service running reliably |
| Duration | Temporary — a defined start and an agreed end | Ongoing, with no planned end |
| Nature of the work | Unique, variable, full of decisions | Standardised, repeatable, mostly execution |
| Measured by | Deliverables, deadline, budget, quality at handover | Throughput, response time, error rate, cost per unit |
| Improved by | Better planning, earlier detection, tighter feedback | Removing steps, automating, reducing variation |
| Staffing | People borrowed for a while, then returned | A standing team that owns the service |
| What “done” means | Accepted and handed over | Nothing. It runs again tomorrow. |
| Typical failure | Late, over budget, or delivers the wrong thing | Slow drift: quality erodes, backlog grows, nobody notices |
The calendar fight nobody schedules
Here is the part that matters for anyone whose week contains both. Operational work has a property project work doesn’t: it arrives. A customer emails. A build breaks. A ticket lands. Project work never arrives; it sits in a plan, patiently, and someone has to go to it.
The predictable result is that a person with both types of work does the operational work first every single day — not out of poor discipline, but because the urgent thing is in front of them and the important thing isn’t.
If your project is staffed by people who also carry an operational load, the plan has to say what share of their week is protected and who covers the queue while it is. A plan that quietly assumes full-time attention from part-time people is not a plan — it’s a wish. 3.3 Resource Allocation deals with this directly.
How to tell, in ten seconds
Three questions settle almost every case:
- Can you describe what “finished” looks like? If yes, and someone would notice it happening — project. If “finished” is just “the queue is empty for now” — operations.
- Have you done this exact thing before? Many times, the same way? Then you need a checklist and a faster process, not a plan.
- Would you staff it with borrowed people? Projects pull people from their normal jobs. Operations are owned by the team whose job it is.
Two answers pointing one way is usually enough. If they conflict, look at the third question — staffing is the most honest signal, because it’s where the organisation reveals what it actually believes about the work.
They feed each other
The two are not rivals; they are a cycle. Every project that succeeds ends by creating new operations — a system to run, a service to support, a process to follow. And operations are where the next project comes from: the friction people live with every day is the requirements document for whatever gets built next.
That handover point is where a surprising amount goes wrong. A project that ships without deciding who operates the result leaves the project team quietly running it forever, unable to start anything else. 7.1 Deliverables Handover covers doing this properly; 7.0 Project Closure covers why the last 5% is the part most teams skip.
What this means for you, by role
If you run a team
Decide the split explicitly and defend it. “Everyone does both” without a stated ratio means project work gets whatever is left, which is nothing during a busy week. Some teams solve this by rotating an on-call role so the rest of the team is genuinely free.
If you do the work
Track the two separately, even informally. “I lost eleven hours to tickets this week” is a fact your manager can act on. “I’m behind” isn’t, and tends to be read as a personal failing rather than a capacity problem.
If you manage the project
Estimate in available hours, not calendar hours. A person at 50% availability doesn’t finish a 10-day task in 20 days — context switching costs more than the arithmetic suggests.
If you sponsor it
Approving a project without freeing capacity is approving a delay you haven’t been told about yet. The most useful thing a sponsor does is decide what the team stops doing.
How this looks in AB
AB Projects is built for the project side of this comparison. Every workspace expects a start date, an end date, members and a deliverable — the ingredients of real project work. Routine work (recurring tickets, customer queues, standing support) is better served by a standing board that never closes.
Two practical habits that follow from this page:
- Keep them in separate views. A Kanban board with a fixed set of columns suits an operational queue; a Gantt timeline suits work with a deadline and dependencies. Mixing them into one list is how project tasks become invisible.
- Make the interruption load visible. If operational tasks live in AB too, the volume becomes an argument you can show rather than a complaint you have to make.
Terms used on this page
- Operations
- Repeating work that keeps an existing service running — support, payroll, order processing. No planned end, and improved by making it more consistent rather than more novel. More →
- Business as usual (BAU)
- A common name for operational work, especially when contrasted with change or project work in budgeting conversations. More →
- Handover
- The transfer of a finished deliverable, plus documentation and responsibility, to whoever will operate it. The bridge between the two halves of this page. More →
- Availability
- The share of a person’s working time genuinely free for project work, after operational duties, meetings and leave. Plans built on 100% availability are always late. More →
- Context switching
- The cost of moving between unrelated tasks. Two half-days on one thing produce less than one full day, which is why fragmented project time under-delivers. More →
- Throughput
- How much work a process completes per unit of time. The headline metric for operations, and a poor one for projects, where finishing the right thing beats finishing many things. More →
Related reading
2.0 The Project Lifecycle
What a project actually does between its start and its end, phase by phase.
3.3 Resource Allocation
Planning around people who are only partly available — which is nearly everyone.
7.1 Deliverables Handover
Turning a finished project into someone’s operations without leaving the team holding it.