{"id":8983,"date":"2026-10-11T10:46:59","date_gmt":"2026-10-11T10:46:59","guid":{"rendered":"https:\/\/aboutknowledge.com\/?p=8983"},"modified":"2026-11-05T03:45:39","modified_gmt":"2026-11-05T03:45:39","slug":"odoo-project-management","status":"publish","type":"post","link":"https:\/\/aboutknowledge.com\/zh\/odoo-project-management\/","title":{"rendered":"Odoo Project Management"},"content":{"rendered":"

Where it fits<\/h2>\n

Odoo Project is not trying to be a heavyweight project planning tool. It has no complex critical path analysis and no elaborate resource levelling.<\/p>\n

What it does have is something more useful for most businesses: tasks connected to the rest of your company.<\/strong><\/p>\n

A task can be linked to a customer, generate a timesheet entry, and turn those hours into an invoice. That chain is the reason to run projects inside Odoo rather than in a separate tool.<\/p>\n

Projects and tasks<\/h2>\n

A project<\/strong> is a container. A customer engagement, an internal initiative, an ongoing service line.<\/p>\n

A task<\/strong> is a piece of work inside it, with an owner, a deadline, a description and a stage.<\/p>\n

Tasks move through stages<\/strong> on a kanban board. You define the stages, and they should describe what has happened rather than what someone hopes.<\/p>\n

A working set for most teams: New, In Progress, In Review, Done. Add stages only when you can say what decision each one supports.<\/p>\n

Setting up a project properly<\/h2>\n

Choose your stages carefully<\/h3>\n

The same rule as the CRM pipeline. Under seven stages, each one a checkable fact.<\/strong><\/p>\n

“In Review” is checkable \u2014 either someone is reviewing it or they are not. “Nearly Done” is an opinion, and every person will read it differently.<\/p>\n

Decide the billing model first<\/h3>\n

If this is customer work, decide before you start:<\/p>\n

Fixed price.<\/strong> You agreed a price. Timesheets tell you whether you made money, but do not drive the invoice.<\/p>\n

Time and materials.<\/strong> You bill hours worked. Timesheets drive the invoice directly.<\/p>\n

Milestone.<\/strong> You bill at defined points as work is delivered.<\/p>\n

This choice affects how you configure the project and how the sales order links to it. Changing it halfway through an engagement is messy.<\/p>\n

Templates for repeat work<\/h3>\n

If you deliver the same kind of project repeatedly, build a template with the standard task list.<\/p>\n

Every new project starts with the tasks already there. It saves setup time and, more importantly, it stops people forgetting steps.<\/p>\n

Timesheets on tasks<\/h2>\n

Employees log hours against tasks. Odoo shows planned versus actual on every task and rolls it up to the project.<\/p>\n

Two things this gives you.<\/p>\n

Billing.<\/strong> With time and materials, logged hours flow into the customer invoice. Log the hours, invoice the hours, no re-entry.<\/p>\n

Honesty about cost.<\/strong> Even on fixed-price work, knowing that a job you quoted for forty hours took seventy is how the next quote gets better.<\/p>\n

The requirement:<\/strong> people have to actually log time. This is a management commitment. Partial timesheet data is worse than none, because it looks complete and is not.<\/p>\n

Connecting projects to sales<\/h2>\n

The link between Sales and Project is what makes this worth doing.<\/p>\n

Set a service product to create a task<\/strong> or create a project<\/strong> when the sales order is confirmed. Now selling the work automatically creates the work.<\/p>\n

The chain runs: quotation \u2192 sales order \u2192 project and tasks \u2192 timesheets \u2192 invoice.<\/p>\n

For a services business, that is the whole operational cycle in one system, with no export at any point.<\/p>\n

FIGURE 1: FROM QUOTATION TO INVOICE, THROUGH THE WORK<\/p>

Quotation<\/p>