odoo-project-phasing
Skill2 starsChanged 14 days agoMITView on GitHub
Segment an Odoo implementation into phases using fit-gap category, Must/Nice priority and dependencies - foundation and standard Must Haves first, configuration and Nice to Haves next, all custom development and integrations last - with scope, prerequisites, deliverables, acceptance criteria, effort and risks per phase.
Files
Odoo Project Phasing
Phase rules
| Phase | Contents | Why this order |
| Phase 1: Foundation | Company, localization, accounting setup, users/access, master data, STD/CFG Must Haves of the core flows | Every other module posts to accounting and relies on master data |
| Phase 2: Operations | Remaining STD/CFG Must Haves (inventory routes, purchase, manufacturing, POS…), data migration of opening balances | Builds on the foundation; this is the earliest possible go-live |
| Phase 3: Enhancements | STD/CFG Nice to Haves, Studio items, reports and dashboards | Low-risk value adds once users are stable on the standard |
| Phase 4: Development (always last) | Every CUS item and every integration, Must Have or not | Needs specs, development, code review and testing cycles. Doing standard first often shrinks or removes the custom work |
Special cases. Ask the user about these. Do not decide them yourself:
- A Must Have CUS item that blocks go-live: still plan it in Phase 4, but propose an interim workaround for Phases 1–3 or a go-live after Phase 4. The user chooses.
- LIM items are not phased. They go in the limitations register with their agreed alternative.
Dependency ordering
Within a phase, order the items by dependency: Accounting → Products/Partners → Purchase/Sales → Inventory → Manufacturing → Reporting. Draw a mermaid flowchart of the dependencies.
For each phase, document
- Scope (the REQ list), prerequisites, deliverables
- Acceptance criteria (they link to the review guide scenarios)
- Effort (the sum of fit-gap ranges plus overheads), labelled indicative
- Risks and mitigations, and which client roles must take part (key users)
- An exit gate: client sign-off before the next phase starts
Output: docs/06_project_phases.md.
In this repository8 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- odoo-connectSkill
- odoo-demo-db-builderSkill
- odoo-documentationSkill
- odoo-fit-gapSkill
- odoo-implementation-workflowSkill
- odoo-requirements-analysisSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.