Odoo 19 Project: choose a workable delivery process

Applicability

Odoo 19; app installation, subscription, access rights and mail configuration must match each workflow. Examples are fictional; UI translations may differ.

Research method

Odoo 19 official documentation research only; no new Odoo product test. Source checks apply only to the scopes listed below.

Choose one delivery milestone and define what the customer must accept. Odoo Project is useful when work needs shared ownership and traceable handovers; a new board will not fix an undefined scope. This is a process-design guide based on Odoo 19 documentation, not a project we have run in a test database.

Contents

• Choose the smallest useful workflow
• Separate stage from completion
• Use dependencies only for real blockers
• Decide whether Gantt, timesheets and automation earn their cost
• Review a delayed project without hiding the cause

Choose the smallest useful workflow

For a fictional office website project, use stages such as Ready, Doing and Customer review. Write the entry rule alongside each stage in the team handbook: Ready means assets and scope exist; Customer review means a reviewable page and acceptance questions have been supplied. These are proposed business rules, not built-in Odoo stage definitions.

Odoo allows multiple assignees. For this example, nominate one accountable person in the task description even when several colleagues contribute. Otherwise a shared assignment can still leave nobody deciding whether work is ready.

Separate stage from completion

Open Project, select the project and create a task using the plus button. Enter a title and assignee, then open the task to add the deadline and the evidence expected. The official task form documents Customer and Sales Order Item as conditional fields for billable work; do not expect them on every project.

A Kanban stage describes where work sits. Task status expresses its state within that workflow. Odoo 19 documents Done and Canceled as closed statuses independent of stage. Dragging a card into a column named “Complete” is therefore not an adequate team rule for closing it.

Use a description that can be checked: “Contact form captures name, email and request; project lead records whether the flow meets agreed requirements.” Avoid “Finish website”, which hides several decisions in one card. Moving stages can reset Approved or Changes Requested to In Progress, so confirm status when making a handover rather than treating a previous approval as permanent.

Use dependencies only for real blockers

A dependency is justified when work cannot proceed before a predecessor outcome. In the example, build cannot be accepted until agreed copy is available, but drafting a test checklist can run independently.

In project Settings, under Tasks Management, enable Task Dependencies if that process requires them. On the successor task, use Blocked by → Add a line to select predecessors. The documented dependency workflow can place successors in Waiting until predecessors reach an accepted terminal/approval condition. Do not remove the dependency simply to hide a delay: record who can supply the missing outcome.

When “work cannot start” appears wrong, inspect every predecessor, its status and whether the link points in the right direction. A long task chain may reflect tasks that are too large rather than a need for more elaborate scheduling.

Decide whether Gantt, timesheets and automation earn their cost

Allocated time is a budget; recorded timesheets are actual entries. Neither is proof that a customer accepted the work or that it is billable. A task taking six hours against a four-hour budget raises a scope or estimating question before it raises an invoice.

This guide makes no free-plan promise and gives no edition-wide Gantt entitlement. The official stage documentation explicitly notes that Automations activates Studio and may affect pricing. Confirm the actual subscription and installed apps before treating any advanced view or rule as included.

Review a delayed project without hiding the cause

At each review, choose the nearest milestone and check its owner, deadline, predecessor and acceptance evidence. If a task is overdue because copy was never approved, moving the deadline alone erases the symptom but leaves the dependency unresolved. Record the missing decision and a person who can resolve it.

Use this readiness check before onboarding a whole team: one named milestone; a small task set with accountable owners; a definition of Done; a permitted visibility scope; and a separate decision about timesheets or billing. APAA can help turn the chosen process into a scoped setup. Bring the milestone and one fictional task example, rather than a list of desired features.

Sources

• Task creation

  Task title, assignees, deadlines and billable-project fields

  Source checked Oct 21, 2026

• Task stages and statuses

  Custom stages, closed statuses and Studio automation condition

  Source checked Oct 21, 2026

• Task dependencies

  Project setting, Blocked by and predecessor behavior

  Source checked Oct 21, 2026