Here are the updated the project guidelines for our projects and how to manage them internally: https://docs.google.com/document/d/1YLYrboPlbeV3089NBBVwIxZ2rukhLpRpknF8WQwShUA/edit?usp=sharing

Here are the major changes that we'll apply starting from now on:

Name of the projects in the Pipe: Keep a clean name such as : Customer X (XXXh)

• During the project duration, update the Sales as much as possible regarding the important steps of a project: when project hours' reach some milestone (75%,50%,...), when a phase has been put in production, potential new apps, customer complaints, new dev, ...
• When a new Pack is sold for a customer, centralize all the hours on the same task by removing hours on the previous Pack and adding them to the Initially Planned Hours of the first Pack
• When working on a PM/BA, put both consultants as "Assignees" of the project
• Clarifications of the different projects' stages

The guidelines regarding the centralization of the hours will be applied for the new Packs sold but you can put in place all the other guidelines starting now (renaming the projects, keep the Sales updated for any important information, put the PM/BA in the project). You can also make sure that each of your projects are in the correct stages and that your Pipe is clean.

QuickStart

New project

Name of the project

When receiving a new project in the Pipe, give it a name that makes sense regarding the project. A good structure for the name of the project is : “ Customer Name (# hours)” E.g. : Customer A (100h)

Project description

The project description’s form needs to be completed before assigning someone to the project. All the relevant information should be there:

• Everything related to company and contacts information
• Project scope, potential evolution, reasons of the Pack (following this documentation)
• All information regarding the legacy system and data to migrate from the previous tools of the customer
• A clear description of the business flows. This part is one of the most important and should contain a lot of information regarding what has been discussed with the customer during the qualification. This part needs to contain identified Odoo business processes and not only pure business processes from the customer. Use as much as possible the Odoo terminology and not the customer one to make sure the description is understandable directly.
• Keep those workflow explanations simple and explicit it if the customer is not in line with the Standard solution and what should be modified
  • E.g. Names of the different documents to use in Odoo, don’t use customer’s specific names for delivery order / purchase orders /
    sales orders / etc., explain if a document needs to be modified and what we should add / remove, etc.

Project follow-up

During the project life, all relevant information should be logged on the project’s task. The Chatter should be a log of every news potentially having an impact on the project’s life. Working like this is helping all the stakeholders of the project allowing us to work all in the same way and have the same speech towards the customer. Those conversations can be informal but the outcome needs to appear somewhere on the task in Odoo, it allows us to have a complete overview of what is happening for this project and understand directly the potential issues we faced on the project.

For BAs

Keep the Sales aware of the hours remaining on the Pack when reaching certain milestones (75% remaining on the Pack, 50%, …) Informing the Salesperson when a certain phase of the project has been pushed in production Potential application the customer would like to add to his subscription regarding their workflow Customer’s complaints about the scope, implementation, Methodology, Timesheets, … If you have a demand for a development to be made on the project. The Sales will then be able to explain what is the commercial impact of this (use of Odoo SH, maintenance fees, etc.) If the customer requires a migration or plans to upgrade his database in the near future

For Sales

When the customer is complaining about the Methodology, timesheets, BA’s work. Those information allow us to modify our way to approach the project if needed and make sure the implementation is still successful Every information regarding a change of platform (SaaS to SH or to on-premise for example) Commercial discussions potentially impacting the project’s life Every other information you find relevant regarding the project that could impact BA’s work If the customer requires a migration or plans to upgrade his database in the near future

Following those guidelines will make sure we can coordinate internally before announcing anything to the customer and will allow us to be more reactive if anything goes wrong in our discussions with our clients.

New Pack (Upsell)

When a new Pack is sold for an existing project, it still needs to be paid before we can start working on it. If we went negative for some reason on the previous Pack (not without your manager’s consent), you’ll need to transfer the negative hours from the previous Pack to the new one. If the Pack is sold for an existing project, the same person will be assigned to the project. Regarding the task, you can remove the hours of the new Pack and manually input them on the previous Pack. You need to modify the hours on the tasks titles and then move the new Pack (with 0 hour) in the column “Upsell Done”.

This way, we’ll be able to do a complete follow-up on the Pack from only one task. This way of working greatly simplifies the different developments when we face larger projects, allowing us to centralize everything on the same project.

Please make sure to log a note on the previous Pack such as : “Hours transferred to this pack: “link”. Same goes for the main Pack, log a note saying: “Hours transferred from: “link”

Example:

On the main Pack and

On the new Pack

Project handover

In general; we should try to avoid as much as possible to handover our projects. Project handover will always result in a loss of information about the project which is usually cumbersome both for the new consultant assigned and the customer. Handover is generally the least preferable solution for us but it’s sometimes necessary.

When we need to handover a project for internal reasons (consultant previously assigned that cannot manage the implementation, consultant leaving, holidays), we have a few things to put in place. The time spent doing the handover needs to be flagged in the timesheets with the tag [HANDOVER] for us to know exactly how much time we spent on this. Those hours will be added to the initial hours of the Pack afterwards to be fair both for the consultant and the customer. This needs to be explained completely to the customer to avoid as much confusion as possible. Handover time should also be reduced as it’s mostly based on the project’s documentation, which should be clear and understandable for everybody picking up the project during the implementation. Of course, handover time will depend a lot if the project is completely standard or full of customisations and developments and the time spent will be a case by case discussion.

For the consultant that needs to hand their projects over, this template needs to be filled with all the relevant projects’ information.

QS Pipe

Stages

Unassigned

Stage where a task is created when the Sales Order is validated by the customer. Project waiting for a review of the functional description. Only projects that are marked as “Paid and project handover filled in” (green button) are reviewed and assigned

Assigned

Project assigned to a Business Analyst. This column makes the green button disappear automatically. The project will be ready to go to the next column once the handover is done with the Sales and that the Kickoff email is sent. Make sure the following information is correctly set:

• Reviewer: Salesperson of the subscription
• Subscription (Extra info tab): Add the subscription of the customer

Example:

Kickoff and Qualification

Kickoff phase of the project. The project will stay in this phase as long as we’re still in the kickoff phase. The kickoff phase is considered over once you have all the necessary information about the project and that you feel ready to start the implementation. The purpose of the kickoff is to: Get to know each other with your customer Remind them of our Methodology Communicate the role and responsibilities of each stakeholder Confirm the feasibility of the project Come up with an implementation plan to reach a common goal defined with the customer

Configuration

The Configuration phase is when nothing is yet in production on the project and that we’re still configuring the database. Configuring the database means working on data import / testing / customizations / general Odoo configuration before going live with the system. The project should stay as little as possible in this phase as the goal is to put them in production as soon as possible with a first phase. Keep in mind that the main priority is delivering the project on time and on budget and if your customer comes up with new requests, this will directly impact the deadline of the initial plan.

Production

This column is used once a project has a part of the scope used in production on the customer’s side. If we have identified 5 phases on the project during the kickoff, the project will be in this column once the first phase is used in production. Keep in mind that the first modules in production should be the ones that are bringing the most value to the customer (they want to replace their Inventory or manage their Sales first for example).

E.g. The project you have to implement has the following apps: CRM, Sales, Invoicing, Accounting, Inventory, Purchase, Manufacturing, Quality, Email Marketing, Your phasing has been established as followed: Phase 1: CRM / Sales / Invoicing Phase 2: Inventory / Purchases Phase 3: Manufacturing / Quality Phase 4: Accounting Phase 5: Email Marketing Once you put the Sales workflow in Production (Phase1), the production goes to the column “Production”.

Putting a project into production is a stressful moment for the customer and the consultant. Make sure to clear your Calendar before the production launch to be as reactive as possible if something goes wrong with the go-live. Doing a pre go-live is also a good idea before the official one, to make sure you tackled most of the issues before the real one.

Tips: Plan a call with your customer to have a last check before the launch. Make sure the users have been well trained and that there are no more unidentified issues Never delay the go-live. You know the best if the customer is ready to go-live or not so avoid asking your SPoC if he’s ready for it, explain to him WHY you think he’s ready for it. Schedule a few meetings in the go-live week with your customer to do a follow-up Make it count ! Go-live is a very important part of the project and make it understand to the customer that you just reached a great milestone in the project Don’t plan a go-live if you cannot do a proper follow-up (end of the week if the customer works during weekends, before your holidays) Don’t start a new phase before stabilizing the phase you just put live with the customer

In Support

This column is used for projects that have all their phases implemented. Once the project is in production, the customer’s main point of contact should be the Support Team. The BA can still be involved in the project if the customer needs to extend the initial scope of the project, if their questions require the expertise you gained during the project or if they want a new development for example. Keep in mind that your job mainly consists in implementing projects and not doing endless support for your customers. We have a dedicated team that is handling the Support and projects fully implemented rarely require an urgent intervention.

Note: If the project is in production and a customer comes back to put a new workflow in production, you can put back the project in the column “In production” and “In Support” once the news workflow is implemented.

Cancelled

Column used for projects that are not in other columns and that we do not need to implement. E.g. Error from the Sales in the validation of a project

Upsell Done

When we have a new Pack for an existing customer, we’ll remove all the hours from this new Pack, transfer them to the main Pack and put the new Pack in this column. We shouldn't have any Packs with remaining hours in this column.

On Hold

This column contains projects that are not active anymore but that are in the middle of their implementation. We generally consider putting projects in this column after 1-2 months with no answers from the customer. Log a note on the Chatter explaining why the project is on hold (customer not responding to emails, doesn’t have time for the project in the foreseeable future, etc.). Also explain in this note the plan to keep this project as active as possible. Once the project is “On Hold”, it’s the Sales’ responsibility to relaunch the project as we will not take time on their Success Pack anymore to chase them. When the project is on Hold, it’s not considered as a project in your Pipe and it needs to be clear for the customer that we’ll evaluate what are our options in terms of re-assignation depending on the BA’s workload at that moment

Projects “On Hold” in the middle of the implementation are way more likely to churn in the future so avoid having too many projects on Hold and try to reduce the time the project will not be active.

Churn

This column is used for projects that have closed their subscription with us.