Onboarding Guide — Project Best Practices

This article consolidates the key project management principles every much. Consulting consultant needs to know: how implementation projects are structured, how to manage scope, how to run meetings, and what operational habits keep projects on track and customers retained.

Scope: Covers the three project types, implementation phases, GAP analysis, scope management, meeting structures, customer roles, and operational best practices. Does not cover Shoovels operations, ticket writing, or timesheet rules — those are in the Shoovels & Technical Best Practices and muchdoo & Internal Operations articles.

📋 Overview: The 3 Project Types

Note: Implementation projects can also involve version upgrades (customer migrating from Odoo 14/16 to a newer version) or process optimization within an existing Odoo environment — not just greenfield setups.

📍 Key Documents & Where to Find Them

• GAP Analysis (Excel) — The single most important document for a new project. Contains all requirements, phase assignments, time estimates, risk ratings, and the rough project timeline. Find it in the Google Drive project folder.
• Solutions handover document — A summary prepared by Solutions when handing off a signed customer. Shared in the project Slack channel when you are added to it.
• CRM opportunity notes — Early-stage context: demo database links, login credentials, and initial customer notes. Navigate to CRM → [Customer] in muchdoo.
• Asana / muchdoo project board — Live status of all tickets, tasks, stages, assignees, and deadlines.
• 1Password project folder — All database credentials and instance connection details. Save here immediately when you receive them.

Getting onboarded on a new project: Read the GAP analysis first. It tells you what was promised in which phase and why — this is your compass for every scope and priority decision that follows. If you are too short on time to read it fully, upload it to Claudioo or Gemini and ask for a structured summary. Then read the actual document before your first customer meeting.

⚙️ How an Implementation Project Flows

Goal: get the customer live as fast as possible on a solid core. A delayed go-live means wasted months during which processes keep changing — and when they change, so do the requirements you already built against.

🧮 The GAP Analysis — Your Implementation Blueprint

The GAP analysis is the signed agreement between the customer and much. Consulting on what will be built, in which phase, at what estimated cost. Every implementation team member should read it at the start of a project.

A GAP analysis is structured by category (General, CRM & Sales, Inventory, Accounting, Helpdesk, etc.) and lists:

• Customer requirements — written in a standardised phrasing (ask your team for the Claudioo prompt used for GAP writing)
• Phase assignment — which phase each requirement is planned for
• Time estimates — workshop hours, configuration time, development time, documentation
• Risk rating — how likely is this to go over budget or time
• Project timeline — rough milestone dates per phase

The GAP is your scope shield: If the customer requests something that is not in the GAP, you have a legitimate and documented basis to say "this was not in the original scope — it will cost additional budget or require re-prioritisation." This gives you a strong position for an upsell conversation.

🔑 Scope Management: Being Strict With Customers

One of the most important — and hardest — skills to develop is saying no to customer requests that do not belong in the current phase. The risk of agreeing to everything is real: you never go live, resources are wasted on cosmetic changes while critical integrations are not working, and the customer loses trust.

Before agreeing to implement any out-of-scope request, ask these four questions:

1. How many times per day does your team do this?
2. How many people depend on this workflow?
3. How often does the edge case you are describing actually occur?
4. Is the business blocked without this — or is it a preference?

If the answer to all four suggests low frequency and no business-critical dependency: it goes to a later phase. End of discussion — and document it in a ticket so there is a clear record.

⚠️ The scope trap: If you say yes to one cosmetic request, the customer will keep asking for more. Each yes makes the next no harder. Be strict in Phase 1 — it protects the entire project timeline and your go-live date. The more you customise early, the harder version upgrades and long-term maintenance become for everyone.

When offering options to the customer, always present the trade-off clearly: "Option A is the better long-term approach but takes 6 weeks. Option B is less elegant but gets you live by October. Given your timeline, I recommend B." Then let the customer decide with full information.

⚙️ Meeting Structures

Every implementation project runs three types of recurring meetings. Each has a specific purpose — mixing topics across meeting types dilutes their effectiveness.

Jour Fixe (JF) — Weekly Project Update

Weekly (or bi-weekly for well-running projects). Attended by the project team only — no key users, no sponsors.

• Overall status update: where are we, what is progressing, what is blocked
• Walk through the Asana/muchdoo board ticket by ticket: Customer QA tasks, Internal QA tasks, upcoming sprint work
• Prioritisation: what needs to move to the next sprint? Is anything at risk?
• Invite relevant specialists (e.g. finance consultant) if an accounting topic is on the agenda

Avoid discussing granular operational workflows in the JF — those belong in working sessions.

Steering Committee — Monthly Executive Review

Monthly. Attended by the project team and sponsors (company owners, investors, decision-makers). Keep it strategic:

• General project status, milestone progress, go-live readiness
• Budget and timeline overview
• Risks and major decisions requiring executive sign-off
• No ticket-level detail, no operational workflow discussions — sponsors do not care about individual features unless money or timeline is at risk

Exception: Raise an operational topic in the Steering Committee only if it is business-critical — e.g. a major integration is not working and is blocking go-live, or a budget overrun of significant magnitude needs executive approval.

Working Sessions — Operational Deep-Dives

Ad-hoc, as needed. Attended by the relevant SPOC and/or key users. This is where you define and validate specific workflows:

• Requirements workshop for a specific module or milestone (e.g. "Purchasing Requirements Workshop")
• Data setup sessions (warehouse structure, product configuration)
• User training on a specific feature just handed over
• Hands-on testing sessions where key users verify the workflow matches how they actually work

Schedule a requirements workshop for each major milestone before configuration starts — not after. This avoids rework caused by undiscovered process details.

📊 Meeting Types at a Glance

🔑 Key Roles on Every Project

⚙️ Operational Best Practices

No production releases on Fridays

Never push code to production on a Friday. If something breaks after a Friday release, the developer may need to work over the weekend — which is not acceptable as a standard practice. Coordinate release windows with the customer in advance, and target Tuesday–Thursday for production releases.

Similarly, avoid production pushes during end-of-month periods for accounting-heavy projects, or during peak business periods (e.g. Black Week for e-commerce customers).

Tackle risky items first

When planning a phase or milestone timeline, always schedule the riskiest items earliest:

• Integrations — complex, dependency-heavy, frequently underestimated. Do these first.
• Complex workflows in core modules (purchase, sales) — if these become bottlenecks, the whole milestone is at risk.
• Data migrations — the earlier you get real data into the system, the earlier edge cases surface.

Do not work on cosmetic improvements while a major integration is at risk. Get the critical path done first.

Milestone and testing list approach

Structure implementation by milestone (one per major app or process area). After each milestone is complete, produce a testing list covering all processes in that milestone. Have the key users test and sign off before moving to the next milestone. This is your quality gate.

Example: Milestone 1 = Inventory → Testing list covers all inventory processes → Key user sign-off → Milestone 2 = Accounting begins.

Access rights — least privilege

Always configure access rights using the least privilege principle: give each user role the minimum access needed to do their job. Verify this by logging in as the relevant user in Shoovels (Users tab → "Login as →") and confirming they cannot see menus they should not have access to.

1Password — credentials and project info

As soon as you receive a new project, create a 1Password entry with:

• Demo database URL and admin credentials
• Staging and production instance URLs
• Customer contact details (SPOC name, email)
• Any shared team credentials the customer provides

This ensures colleagues can cover for you during vacation without needing to dig through CRM or message you on your days off.

Set clear deadlines for the customer

Every request you make to the customer — data tables, process documentation, testing sign-off — must have a specific deadline. Without a deadline, "I will look into it" becomes a two-week silence. Set the deadline, confirm it explicitly, and follow up if it is missed. Document delays in the ticket so the impact on the project timeline is traceable.

Budget monitoring

Check the Sale Order in muchdoo (Sales → Sale Orders → [Customer]) at a minimum at end of month. For budget-sensitive customers, review weekly during the JF. When the delivered quantity approaches the ordered quantity on any line item, initiate the upsell conversation immediately — do not wait until you are over budget.

⚠️ Common Pitfalls

• Saying yes to everything in Phase 1 — Each yes makes it harder to go live. Cosmetic and non-critical requests accumulate. Be strict from day one, use the four questions, and defer to later phases. A delayed go-live due to scope creep is one of the most common causes of project failure.
• Not establishing a customer SPOC — Without a named SPOC on the customer side, every department head will push their own requirements directly to you. Fifteen-person Jour Fixe meetings are a symptom of this. Establish the SPOC in the kickoff meeting.
• Involving key users too late — Key users know how the operational process actually works. If they only see the system for the first time in Customer QA, you will discover undocumented process details that require rework. Involve them in working sessions during configuration, not after.
• Releasing on Friday — If something breaks on Friday afternoon, the developer works the weekend. This is bad for morale, bad for the team, and avoidable. Never release to production on a Friday.
• Not reading the GAP before customer meetings — The GAP is the signed agreement. Walking into a scope discussion without knowing what was promised puts you in a weak position. Read it first. Use Claudioo to summarise if you are short on time — but then read the original before the meeting.
• Skipping the requirements workshop before configuration — Building a feature based on your assumptions of the customer's process, then discovering the real process in User QA, causes rework. Hold the requirements workshop before you write a single ticket.
• Not saving credentials to 1Password — A colleague covering for you during vacation will waste 30 minutes trying to find a database password. Costs everyone time. Save everything to 1Password on day one.
• Mixing Steering Committee and JF content — Bringing operational ticket details into the Steering Committee wastes executive time and signals poor project organisation. Sponsors care about milestones, budget, and risks — not individual workflow details.

💡 Tips

• Use Claudioo to generate Mermaid code for process diagrams during pre-project phases. Describe the process in plain text → Claudioo produces the Mermaid code → paste into draw.io → the diagram is drawn automatically.
• When you are onboarded on an existing project, read the GAP first, then check the current Asana board for tasks in Customer QA and Internal QA — these tell you what is in flight right now without needing to read every ticket.
• Schedule a requirements workshop for each new milestone before configuration begins — not the other way around. This eliminates the most common cause of rework in Phase 2.
• Prioritise responses by urgency × budget, not just by customer size. A small customer with a production-blocking issue takes priority over a minor question from a large customer.
• Before a Steering Committee, prepare a one-page summary: milestone status (RAG), budget health, top 1–2 risks, and any decisions needed from sponsors. Keep the meeting under 45 minutes.
• If a customer brings a new requirement that is not in the GAP, do not discuss scope or price on the spot. Say "let me review this against the project plan and come back to you by end of week" — then discuss with your team lead before responding.
• Use Claudioo's /jf-prepare skill before every Jour Fixe to pull the latest ticket activity, timesheet summary, and comments from muchdoo into a formatted meeting agenda.