Project
The container for one piece of delivery work: a status, dates, the members involved, and the tasks underneath. It is normally created from the won opportunity or from an existing client, so the relationship and the commercial context arrive with it instead of being re-explained in a kick-off call.
Why it matters in practice. A project is the join between delivery and billing: finished work on a project is what finance reads when deciding what can be invoiced, and the same project carries quoted, billed, and collected value, so a quietly duplicated project doubles the money in view. Be honest about what the project record is and is not — it holds status, dates, members, and tasks, not milestones, a deliverable register, a contract, or a signed document.
Often confused with Project status, Scope, Task.
Task
One unit of work on a project, carrying a status, a priority, an optional due date, and usually one owner. A task is a step taken to produce something — the deliverable is the thing that exists afterwards.
Why it matters in practice. A task is the smallest thing that can be late, reassigned, or handed over, which is why it is the right unit for accountability. When tasks carry owners and dates, a person leaving mid-project leaves a readable list instead of an oral status; when the work lives only as somebody's personal to-do items, the knowledge leaves with them.
Often confused with Deliverable, Assignment, Project.
Assignment
The link between a task and the one person accountable for it. A task can point at a group, and that is exactly the case to be careful about, because the point of the record is a named owner rather than a shared intention.
Why it matters in practice. Shared ownership feels fair and hides slippage, because a task assigned to a group is a task nobody is personally behind. The assignment is also the field that makes moving work a decision somebody can see, which is how a client's job quietly stops moving becomes visible before the client notices it.
Often confused with Task, Role, Hand-off.
Dependency
A recorded link saying one piece of work cannot start until something else exists — a draft before review, a sign-off before invoicing. It makes the order of work explicit rather than held in one person's head.
Why it matters in practice. Unnamed dependencies are why dates slip without anybody being late: the work was waiting, not failing. Writing them down is also what stops a project from being one person's mental model, because the sequence becomes readable by whoever picks the work up next.
Often confused with Due date, Blocker, Task.
Blocker
A flag saying work cannot proceed, with the reason attached: waiting on a client, on material, on an approval, on a decision. It is a state a person has to declare rather than something the system infers from the absence of activity.
Why it matters in practice. A blocker with a name and a reason can be escalated; one without either becomes a task that simply stops being touched. Since the flag has to be raised by a person, it will be raised less often than it happens — so a board that looks clear is weak evidence that nothing is stuck, and the useful habit is to treat an untouched task as suspect.
Often confused with Dependency, Task, Priority.
Hand-off
The transfer of work from one person or one phase to another, with enough state on the record that the person receiving it can continue without a briefing. It works when the task, the assignment, the due date, and the client context live on the record rather than in a conversation.
Why it matters in practice. A hand-over mid-project is where delivery quietly fails, and it is the failure mode project tools are usually bought to prevent: open tasks stay readable, the client stays identifiable, and what is outstanding does not depend on remembering who used to do it. The commercial half is the part most often skipped — the acceptance, the note explaining the work, and the unpaid balance have to move with the work rather than stay with the person who left.
Often confused with Assignment, Scope, Deliverable.
Capacity
How much delivery work a person or a team can genuinely absorb in a period, once existing commitments and the ordinary interruptions are subtracted. It is a planning judgement about commitments, not a measurement anybody takes for you.
Why it matters in practice. Most missed dates are capacity decisions made without counting what was already committed, so the useful question is not how much this project needs but what it displaces. A capacity conversation that only looks at the new project produces a plan that was already impossible before it was agreed, and the client finds out at the worst possible moment.
Often confused with Utilisation, Backlog, Assignment.
Utilisation
The share of somebody's available working time that is already committed, usually estimated forward from open tasks and their due dates rather than measured from recorded effort. It is a judgement about commitments in hand, not a score for how hard somebody worked.
Why it matters in practice. Utilisation is not productivity, and a number near full is not a healthy board — it means there is nothing left to absorb a new request, a sick day, or the extra round of changes a client always asks for at the end. Treat it as a review conversation, and be clear about what it leaves out: this vocabulary holds no timesheet and records no hours against a task, so any figure is an estimate from commitments, and payroll, attendance, and HR records are separate concerns that this system does not keep.
Often confused with Capacity, Priority, Project profitability.
Due date
The date a task or a project is expected to be finished by. It is a commitment the team makes and reads, and it is deliberately separate from the date the work actually happened.
Why it matters in practice. Undated work is where slippage lives, because a task with no date never visibly becomes late — it simply stops being mentioned. Dated commitments are what turn an overdue list into a queue somebody can work, and they are the honest input to any read of how much is already committed. A date everybody has learned to ignore is worse than no date, because it also hides the dates that were real.
Often confused with Dependency, Blocker, Project status.
Recurring task
A task defined by a repeat rule that generates the next occurrence — the client check-in, the site visit, the renewal reminder, the post-delivery call that is meant to happen again. It is a repeating record rather than a one-off reminder somebody set once.
Why it matters in practice. The failure mode is always the same: a repeating commitment exists as a calendar note or a chat message, is seen once, and never again. Modelled as a recurring task it can be assigned, dated, and handed over like anything else — and the duplication question has to be decided deliberately, because the same monthly check-in otherwise lives as a task, a recurring task, and a calendar invite, and then nags the team three times.
Often confused with Task, Due date, Backlog.
Backlog
The ordered list of work that is agreed in principle and not yet started, kept in a sequence somebody chose on purpose. It is a queue with a reason for its order, not a place to dump everything nobody has got round to.
Why it matters in practice. A backlog is where a client asks for something that is not in scope, and it is the honest place to answer yes, no, or later without renegotiating the live project. Its length is a planning signal rather than a health metric: a long backlog with nothing moving usually means the ordering is wrong, not that the team is busy.
Often confused with Priority, Scope, Dependency.
Priority
The order in which work should be attempted when everything cannot be done at once — high, medium, low, or whatever set your team actually uses. It is a decision about sequence, and it only means something relative to the other items in the same list.
Why it matters in practice. Priority is where a planning disagreement surfaces, so a priority that exists in one person's view and is invisible to the rest is not a decision, it is a preference. It also needs a resolution rule: when a high-priority item is older than a low-priority one, something has to give, and a team that never revisits priority eventually stops changing it at all.
Often confused with Due date, Backlog, Capacity.