Implementation

Methodology

You have the autonomy to transform how companies operate

but this autonomy comes with a huge responsibility.
We expect you to simplify complex businesses.
 Implementation
Methodology

You have the autonomy to transform how companies operate

but this autonomy comes with a huge responsibility.
We expect you to simplify complex businesses.

1
 Table of Contents
Introduction 5

1. Key Concepts 6

2. What is a Successful Project?  8

3. RolesRoles.  14
Odoo: Project Leader 15
Odoo: Project Director 16
Odoo: App Expert 18
Odoo: Developer 18
Customer: Single Point of Contact (SPoC) 18
Customer: Extra Roles 19
Impl
4. Implementation Phases 22
GAP Analysis 24
Project Kick-off 26
Implementation 30
Go-Live 32
Second Deployment 34
Impl
5. Implementation Challenges 36
How to encourage users to embrace Odoo 37
How to deal with resistant people 37
How to keep things simple 39
How to manage customer expectations 40
How to write a good specification 41
Avoid importing data history 41
Avoid writing documentation for your customer 43
How to deal with customers' specific demands 43
Why should you minimize custom development? 48
How to deal with internal politics 50
How to deal with different people's dynamics 52
Why should young Project Leaders feel confident? 51

6. Quiz 54

7. Measure your progress 58

8. Extra References 62
2 3
 Introduction
As Project Leaders, our job is amazing: we have the opportunity to improve
people’s lives at work by automating boring tasks and making companies
more productive. Rare are the solutions that have such an impact on the people
using it.

But implementing a management software is as difficult as it is impactful.

Odoo connects all departments, which means a lot of changes and a lot of
users relying on you to improve their workflows.

It’s hard to be a great Project Leader... very hard. More than 50% of proprietary
ERP implementations fail and only 18% of SME's have deployed an integrated
management software, because it’s too complex and too expensive for them.
But the constant failures to deliver are actually our opportunity to thrive.

By making implementation projects smooth, predictable and affordable, Odoo

is transforming the market and fulfills a huge demand. Over the past 5 years,
more than 95% of our implementations have been successful, which stands in
stark contrast with other solution providers.

To reach to that point, we had a critical look at the approach and at the role of
our 80 Project Leaders. We fine-tuned our methodology, analyzed how the top
performers behave and realized what makes some projects more successful
than others. This guide summarizes our best practices and all the tricks we’ve
learned.

Alexis at the "Go-Live Day" at LCT Togo.

First ship berthed in the terminal.

4 5
 Responsibilities
• As Project Leaders, our top priority is to ensure the project stays on
time, and on budget.
• The customer defines their business' needs (why and what) and the
way to satisfy these is defined by the product through us (how).
• Odoo challenges customer demand to ensure the benefit is worth the
cost.

Keeping It Simple

01
• Fewer meetings, less paperwork, faster decisions.
• Limit the number of stakeholders to accelerate decision cycle.
• Limit custom development to the minimum necessary.
• Working on site is inefficient to get things done, but efficient for change
management and training. Go on site only when needed.

Key Concepts People

• Project Leaders must be problem solvers, as well as product & business
experts.
• Avoid intermediaries who are not decision makers.
• Train the key-users early on in the project. They should be confident in
the product and be committed to the project.

Project Managers
• The key success factor of any implementation is the Project Manager
(aka Project Leader at Odoo1).
• Recruit & train the best talent. Retain only the top performers.
• Even the best Project Leaders miss critical details. To limit risk, Odoo
Experts should challenge their work at critical steps in the project.

But never forget:

Common sense always prevails any rule!

1 See chapter 3. Role definition

6 7
 As a Project Leader, it’s difficult to find the right balance between satisfying the
customer, accepting more change requests, keeping the budget low, sticking
strictly to agreements, spending more or less time in analysis, respecting the
timing, etc.

The key priority for a successful project is to onboard users in Odoo, and to do
this on time and within budget. When a project fails, it’s always because it took
too much time or cost.

Timing and budget are the key elements to structure your methodology. The

02
rest is secondary:

• developing custom features is not a priority.

• customer satisfaction during the implementation is not a priority.
• early service upsell is not important.

What is a Developing specific features does not

help the project

Successful Custom development always creates additional costs and drags out the
implementation project, sometimes to the point of putting the project at risk2.
In addition, custom development leads to technical debt that the customer will

Project?
have to pay for within the coming years in the form of more maintenance and
upgrade costs.

Each customization may seem simple and affordable. But the complexity of a
project grows with the square of the number of customizations, not linearly.

A project is successful if it’s delivered on time and on budget. Developing for

the customer's specific needs doesn’t make the project successful, but it is
sometimes necessary in order to support customer’s core business.

2 See article on https://news.ycombinator.com/item?id=17541092

8 9
Customer satisfaction is not a useful KPI Selling extra services before "Go-Live" is
not a priority
The customer satisfaction is not a good measure of the success of a project.
First, it evolves constantly during the different phases of a project. Second,
Service companies want to bill the customer as much as possible. It’s their core
each person working for the customer might have different expectations, for
business after all! Large service companies even have complex methodologies
example: a key-user wants additional features, but the CEO wants the project
that lead to needing more services, like large analysis phases in the name of
on time and on budget.
limiting the risk on a project.

Focusing on customer satisfaction distracts the Project Leader from the

We believe that selling more should never be an initial objective. Our companies'
project’s main objectives. We definitely prefer our customer to be temporarily
growth should be the result of a quality service or of happy customers. We
dissatisfied (because they had a harsh discussion about a complex decision)
actually think it’s better to deploy customers in fewer days of work. Not only
than missing the implementation deadline. Dissatisfaction is inherent in any
does it reduce the risk of project failure, but it makes us more competitive on
project.
the market.

Even though customer satisfaction is not a goal during the implementation, it’s
Having a good pace throughout the project is a huge competitive advantage to
still a good way to evaluate the motivation of key-users.
acquire new customers. And, as you build your customer base, it becomes very
easy to sell extra services to existing customers:
Therefore, we use periodical customer ratings to know which customers require
more attention (and not to assess the quality of a Project Leader).
• It’s 7x easier to upsell existing users rather than acquiring a new
customer.
• You can always divide the project into phases and sell non-mandatory
features after the “Go-Live”. This way, you will never need to squeeze
your margins because the budget is consumed.

Long story short; to achieve sustainable growth, focus on the project’s

success. If you have successful projects, customers will buy more services
later on. Every time you upsell before the "Go-Live", you weaken customer’s
trust; they might think twice before buying extra services in the future.

Customer satisfaction evolution throughout the project.

10 11
 A few years ago, I interviewed 15 customers to gather feedback about
our implementation methodology and services. A customer told me
this: “During the first 3 months, I didn’t like working with Frédéric [the
Project Leader]. He was constantly questioning everything I asked for,
to the point that I had the feeling of wasting my time. It was a bit
frustrating.

But, later on, I understood it was for the good of the project. He often
found better solutions than what I asked for during the implementation.
Now, even though we are in production, everytime I have a business "Go-Live" at Industrial Taylor: Michaël, Project Leader
process decision to make, I call him first to get his advice.” with warehouse operators.

This story perfectly illustrates our approach: by prioritizing the success

of the project over the short term customer satisfaction, we actually
make customers happy in the long term. Frédéric could have agreed to
develop every custom feature the customer had asked for to make him
happy at first, but the project would have cost more and been delayed,
at the risk of losing the customer.

- Fabien, Odoo Founder

12 13
 Traditional ERP vendors define different roles for analyzing business flows:
Project Managers, Junior Business Analysts, Senior Business Analysts, Testers,
Trainers, etc. But too many cooks spoil the broth!

Making the right decision always involve a trade-off between specific business
needs and existing product features. If you split the role of business analyst and
product expert, you might make inefficient decisions.

Odoo, as a product, is much easier to use than traditional ERPs. This allows
for one-single person to know both the business and the product - something

03
competitors can't do.

Odoo: Project Leader

The Project Leaders are the main decision makers of the project. However,
Project Leaders wear many hats - at the same time, they play the role of project

Roles
manager, business analyst and product expert.

As project manager, we lead the project by:

• defining the project plan and following it up,
• focusing on the main objectives,
• onboarding the SPoC (Single Point of Contact) on the project,
• using the right resources and anticipating the risks.

As business analyst and product expert, we keep things simple by:

• deciding how to implement specific needs,
• challenging the customer’s demands and managing their expectations,
• configuring Odoo,
• migrating the required data,
• writing the specifications (if any development is required).

The Odoo Project Leader has to be considered as the key point of contact by
the customer during their implementation.

14 15
Odoo: Project Director
On larger projects or highly political environment, a Project Director is assigned
in addition to the Project Leader. While the Project Leader focuses on the
implementation, the Project Director helps to present the project and to manage
executives' expectations, with a higher view on the project. For a large publicly traded company we had a mission to deploy a full
scope ERP for 3000+ users, in the middle of a complex fusion of two
Their role is to keep decision makers informed and committed to the project companies.
by:
• reporting project progress to the steering committee, We started by following their way of doing project. Being an experienced
• tracking the efficiency of the project, service company they wanted to teach us how to do things. But after a
• offering solutions to fix inefficiencies on how the project is handled (on few months, the project started to slip.
both sides).
I suggested a new approach to the steering committee, closer to our
As opposed to the Project Leader, the Project Director does not work full time methodology, with less time wasted. We changed the mechanics in
on a project, but overseas it from start to finish. On smaller projects, this role is place to do it the Odoo way:
usually done by the Project Leader directly. • Working using a SPoC and giving a weekly demo (only one person
decides, no more committee).
• Challenging every request to see if it can be dropped or done in
another way (stick to the standard environment as much as possible).
• Saying No! to non-rational time consuming requests.
• Bypassing most of the project team members to get the decision
makers involved directly (avoid wasting time in validation cycles).

At first, the customer was frustrated (afterall we, a young team,

challenged the way a big and experienced company was doing projects),
but as the project moved forward, the executives were very happy and
we met the deadlines!

- Grégory, Project Director, Odoo BE

At C.E. Info Systems Private Limited the

project onboarded 133 Odoo only users.

16 17
Odoo: App Expert Acting as "super key-user", the SPoC has a 360° understanding of the project
requirements by:
• gathering and assessing the project requirements,
For key apps (finance, inventory, marketing, manufacturing, website), the most
• training the end-users with the support of the Project Leader (there is
knowledgeable person of the app plays the role of an Odoo App Expert. They
no better trainer than a colleague who knows your internal processes),
have developed a deep functional knowledge in industry-specific Odoo features
and have acquired solid business experience. • becoming an internal Odoo expert and ensuring the first level of support
for their colleagues.
The App Experts are not part of the project. They do peer-reviews, working
across all projects of the company. They usually get involved in GAP analyses to Sharing the project success responsibility with the Project Leader, we expect
perform peer reviews. They especially do this for more complex projects if the the SPoC to get involved in every project step. Therefore, we need the SPoC to:
level of complexity requires it. • be available for the project,
• have the power to make decisions,
• be legitimate.
Odoo: Developer
Not all projects require developers. Most small companies (<50 users) use Odoo
out-of-the-box and do not require custom development. They’ll be involved if,
Customer: Extra Roles
and only if, the business requires development.
On large projects, extra roles might be defined:

Customer: Single Point of Contact

• Steering committee: decision makers of the customers and the Odoo
Project Director / Leader, who are in charge of the methodologies, and
(SPoC) tracking the success of the project.
• Key-users: in addition to the SPoC, the key-users act as experts in
To make the implementation as fast, simple and affordable as possible, we also their specific domain and will help the customer SPoC to define the
need to have a strong ally on the customer’s side. To do so, the Odoo Project requirements. They also test and validate deliverables.
Leader will need an equivalent profile in front of them. • Sponsors: usually the CEO or CFO, who pays for the project and who
has high level objectives. They’re usually part of the Steering Committee
As project manager, the SPoC works closely with the Odoo Project Leader by: as well.
• following up with the project,
• being an ambassador who convince the end-users (Change
Management),
• making sure that the project planning fits in the company’s agenda and
constraints.

18 19
 Two years ago, I started two projects with two manufacturing companies
with similar flows and owned by the same person. At the beginning of
the project, we had two SPoC: the first was the operational manager of
one of the companies, and the second was the CEO of the group.

The first implementation went very well. In a few months, we went

full scope into production. It was due to a good collaboration with the
SPoC. On the contrary, the second implementation, where the CEO was
the SPoC, was really difficult to manage due to his unavailability.

We decided to change the SPoC, but the CEO didn’t trust this new
person. Every decision had to be validated by the CEO, which was adding
days to the process. Discussions with the new SPoC were good, but he
had no authority. The project was a nightmare and it took months to
implement the first phase.

After the first production launch, we decided to change the SPoC again.
The person responsible for the implementation in the first company
took over the responsibility to implement the second company for the
next phases. The CEO trusted the decisions he would make and no
validation was needed. Things started to move forward much faster.
Just by improving the decision making process, we increased efficiency.

- Benjamin, Project Leader, Odoo BE

20 21
 The phases of an implementation project and their relative durations are:

Phase Duration Goals

GAP Analysis 10% Business analysis, gap analysis, phasing &
budget.
Kick-Off 5% Align stakeholders on methodology + standard
training.
Implementation 80% Series of cycles: analysis, development,
validation, key-user training.

04
Go-Live 5%3 End-user training, bug fixes.
Second variable Broaden scope or add custom features.
deployment

Implementation
Phases

Classic Project Journey

3 The Go-Live might require more time in larger projects (from 10% to 15%) due to heavier
change management.

22 23
GAP Analysis Analysis Tips

On large projects, the GAP Analysis is sold before the customer commits on the During interviews:
whole project and budget. According to the size of the project, it can take from
a few hours to 30 days. On very small projects (<4 months), the GAP analysis is • Be a salesperson, as the project is not sold yet! At this stage, your goal
not a distinct phase, but performed during the Kick-Off phase4. is to reassure people and motivate them: do demos of key features.
• After reassuring key-users on the project, observe how they currently
work: ask for demos of their current software and get a copy of each
The GAP analysis allows the customers to: document they use. The current situation is more important than their
• adapt their specifications to the software, future goals, as it defines the minimal scope to cover. If you perfectly
• clear their doubts about the feasibility of the project, understand how they work today, you’ll be able to better challenge their
• assess the Project Leader, requirements.

• get a clear planning and budget. • Find solutions for each problem, try to stick to standard solutions as
much as possible. It’s not required to do everything key-users ask for,
their demands should be challenged.
The Project Leader delivers:
• a mapping between the business needs & product features, and budget. • Never present different options to the customer: as Project Leader,
you have to suggest the best one and make the decisions yourself. The
• a project plan.
customer’s role is to challenge what you offer, not to decide what to do.
→ Both are built-in with the GAP-Analysis Tool (Appendix C) and
presented in the GAP-Closing presentation (Appendix D) • Avoid having the customer decide whether a feature is “necessary”
or “optional”. If you do this, everything will become mandatory. Make
• a proof of concept (POC): demos of key business flows.
the decision for them by classifying items as “optional”, when you think
they should be excluded from the scope.
The phases of the GAP Analysis:
• Ask key-users, “what’s your biggest pain point today?”. The answer
1. Meet stakeholders, define the objectives, motivations, and risks in the
will be useful in the later stages of the project to reassure people. In
GAP Kick-off (Appendix A) mindmap.
case of doubt during the implementation, remind them what their
2. Meet with key-users per department using the GAP Key-user Interview
priorities are.
(Appendix B) mindmap:
• Understand the current situation
After the interviews:
• Define what should be done
3. Document the GAP Analysis & phasing.
• A peer-review is organized with an Odoo Expert who is external to the
4. Peer-review it by Odoo Experts and developers to challenge suggested
project. They are not influenced by the customer and can easily make
solutions.
harsh decisions and provide criticism.
5. Present the results to the customer by using the GAP Closing presentation
• The goal of the peer-review is to assess if custom development is really
(Appendix D) and make a product demo.
needed and if so, to prioritize it in order to reduce the budget and
planning period.
4 We use the templates provided in chapter "8 Extra Reference" only for actual
GAP Analysis (larger projects)

24 25
 • All necessary development should be divided into two categories:
1. Development that is absolutely necessary before going into
production (i.e. you cannot operate the business without them).
2. Development that can be rolled out in the second deployment
phase, after the project goes live (i.e. you can operate the business
I once was assigned a project, "Electronics123". The message from
without them, but it’s not optimal).
the salesperson went along these lines: "This customer ABSOLUTELY
NEEDS his Warehouse, Manufacturing, Purchase, Sales Management
At the end of the mission:
and Website/eCommerce up and running in 2 weeks. His Netsuite
contract ends then and he will be left without a system." I had only
• Summarize your analysis (functional and business coverage, resources
12 calendar days to migrate his full ERP into production.
required on both sides, planning and risks).
• Organize specific demos to reassure the stakeholders and point out
Here is what I told Johan, the CEO, during the kick-off meeting: "First,
the benefits they will get from using Odoo.
the project is impossible. We will fail. We usually need 2 weeks per
app. But if there is only one tiny little chance to make it work, we have
to do this: 1/ We go full standard, 2/ You do what I say and you don't
Project Kick-Off ask questions, since I won't have time to explain every single decision
I make". He agreed.
We need to get people on board. That’s what the Project Kick-Off is about.
Generate buy-in within our customer’s company, manage expectations, make We worked night and day together for the next 9 days. He explained his
them agreeing on our approach and, above all, build a solid plan! business processes, and I made all the decisions myself while I was
configuring the system. The company went into production 9 days later
You should know how critical this step is. The whole project’s success depends during the night, on all apps. One of the best projects and customer I
on the way you will carry it out. That’s why you will spend at least 10% of the ever had.
project on it.
I can never stress enough on the importance of the kick-off meeting.
The goals of the kick-off are to: This 'impossible' project has been made possible only because the
• onboard the SPoC on the methodology, and align visions, expectations were set right during the kick-off. Also keep in mind that
• do a quick Gap Analysis to validate the project's feasibility (if not done project managers should not be afraid to make decisions on behalf of
yet), the customer, it makes the process much easier. The customer's role
• finalize the project plan, should not be to decide what to do, but to approve what you suggest.

• onboard the SPoC and make sure they invest time in learning Odoo.
- Laurence, Project Leader, Odoo SF

26 27
Kick-Off Tips I have 2 stories illustrating the importance of followng these rules.

• Tackle issues directly: if you think the planning is too short, negotiate
Case 1: Failed implementation
a delay and ask to push the deadlines asap. Similarly, if you detect
My customer knew exactly what he wanted. Instead of challenging them
misunderstanding about feasibility, mindset or features, discuss these
from the beginning, I accepted everything because he could afford it.
ASAP, rather than delaying the conversation. Inexperienced Project
Big mistake.
Managers tend to avoid difficult discussions, which is a common
mistake.
Today, the maintenance costs have started to burden the customer.
• Check the customer’s involvement: ensure the right people are
He keeps asking for additional development. Hey doesn’t understand
involved on the customer's side. Ensure they have enough time and
why I started saying no and now he's not open to alternative (standard)
knowledge to fulfill their duties.
solutions.
• Invest time in training the SPoC. Introduce them to the eLearning
platform, the online documentation, and train them on key business As a result, the project has been delayed for several months and I have
flows. They won’t be able to perform their duties if they don’t become to admit that the level of satisfaction is not good.
an expert in the product themselves.
• Managing customer expectations is a key skill of any Project Leader. Case 2: Successful implementation
Don’t set deadlines that are too short, don’t promise complex features, I began the project the other way around by setting the right expectations.
don’t say the change will be easy, don’t say yes to everything. In short, if I explained to the customer that I will say no to any development
you promise less, you can over deliver. requests unless the need is a justified "must have" and there is no
appropriate workaround.

Doing this changed everything. The customer is really open to my

suggestions and we saved 100 hours of development by using standard
workarounds.

- Audric, Project Leader, Odoo BE

Renee deployed 7 Odoo apps to organize the

28 production of branded products at Inproma. 29
Implementation Specific development
The Project Leader is responsible for the success of the project. Thus, they
No matter the level of complexity, the project must constantly move forward. are responsible for deciding if custom development (which risks delaying the
Keeping a steady pace is a key success factor. The best way to maintain a high project) is worth it or not. It’s never too late to question if a specific development
level of involvement, is to keep the SPoC engaged in everything. is a must have. Remember: the more you cut the amount of development, the
better.
After the Kick-Off phase, the designed solution has been demonstrated to key-
users. It’s now time to make it come to life! At this stage, the Project Leader approves what should be developed; usually
that which is necessary to operate the business, not the things that are simply
Within each phase, the project team works in short cycles in order to deliver "nice-to-have" (you can operate the business without them, but it’s not ideal).
functionalities every week. The solution is shaped progressively throughout the
phase and validated by the Project Leader and the SPoC. The configuration, The Project Leader writes the specifications, including the scenarios to be tested,
data import and specific development are handled in parallel by the Project and the SPoC attests the conformity with the business requirements. Then, the
Leader and the developer, if required. developer takes over the task and completes it. They are also responsible for
automated tests.
The Project Leader tests the new features and they integrate with other features
Configuration
or apps. Once the development is validated they train the SPoC and key-users.
The Project Leader configures the software themselves, including customization The SPoC also has the responsibility to test and validate the development. If
with the Studio app, but no custom development. Once the apps are configured, issues are detected, they inform the Project Leader who processes the feedback
the Project Leader involves the SPoC and key-users through a series of training with the developer to fix the bugs and makes the necessary changes.
sessions, in order to validate the setup.

Validation & End-Users Training

Data import
Once all the requirements of a phase have been completed, the SPoC is
Depending on the volume and complexity of data to import, the job is handled by responsible for all the final tests and gives the green light to go live.
either the Project Leader or a developer. Following the Project Leader’s instructions,
the SPoC and the key-users gather the data and prepare the file to import. As internal Odoo experts, the SPoC and/or the key-users organize and train all
the end-users.
The data migration from the current software to Odoo can generate delays and
requires making the right decisions: Similarly, writing the user manual is the responsibility of the customer as good
• Don’t delay the production launch due to data quality: Importing the documentation should match customer’s internal processes and terminology.
cleanest data possible is optimal, but not at the cost of delaying the Additionally, having the customer write the user manual is a good way to ensure
project. So, if your customer didn’t clean it on time and was already they have fully tested the software in "standard practice" before going into
using their data in this state, don’t delay a production launch to clean it. production. Besides, our services are too expensive for that kind of thing.
Some cleaning can be done directly in Odoo in post-production.
• Import master data, but avoid the full history (if possible): it costs a
lot of time/money, for very low value added.

30 31
Implementation Tips Go-Live Tips
• Ask the SPoC to do the business flow themselves. They will learn • A training is not a conference. Encourage the SPoC to have key-users
faster. You can guide them, but they must drive the mouse and keyboard. perform the flow themselves, with their guidance.
It changes everything for training efficiency and their involvement. You • Key-users are not professional testers. Quality testing is hard, so they
will also quickly sense if they don’t understand some key concepts. are likely to miss issues. Cross check risky parts with them.
• Transform your project plan into a series of quick wins: To keep your • React quickly. It’s ok to have issues, if you fix them quickly.
customer involved in the project, deliver regularly. If users start to use
• Avoid pushing back the Go-Live date. Although it may feel like the
the system, even if it’s on a small scope, their knowledge of the system
best choice at the time, a lot of things can change in 2 months: people
will improve quickly.
can loos motivation, new change requests will appear, data import may
• Keep challenging your customer: It’s not because we have a list of need to be done again, etc. Pushing back deadlines exposes the project
requirements that your customer will stop having new ideas. Generally, to extra-risks and costs. It’s usually better to Go-Live fast, even if it’s
you don’t accept changes in an ongoing cycle except if the deadline and not perfect.
budget are not impacted. If a change has to be implemented, it will be
• Be on-site the first days of the deployment if there is resistance to
completed in a later cycle. If the change impacts a requirement to be
change amongst the users. You will coach them.
completed in a later phase/cycle, accept it only if another requirement
• After a few days, check if they really went live. Sometimes they
is dropped to compensate.
continue using their old software: habits are difficult to change!
• Don’t do something you are not convinced of: the salesperson’s
promise can be rediscussed. A contract is less important than the
project’s success. You can always convince a CEO to not implement an
idea (even if it was in the initial contract).
• Conduct face to face meetings. It’s a good way to unlock complex
situations: fear of change, need for reassurance or lack of involvement.

Go-Live
When it’s time to turn on the switch, there might be unexpected issues. Most
often, they are due to two causes:
• The database is not fully tested: ensure the key-users have fully
tested all business flows.
• The users are not well trained: if the training was completed months
ago, they might have forgotten. If they did not practice themselves
during the training, they might have missed critical steps.

Antoine doing a team work

with a customer in Quatar.

32 33
Second Deployment
A month after the initial deployment, the Project Leader reviews the list of the
remaining development that was not launched during Phase 1 (i.e. development
scheduled at a subsequent phase: you can operate the business without it, but
it's not ideal).

With the users' feedback, the prioritization of specific development will usually
change (typically we notice that 50% of development was not necessary and
new development have been requested).

34 35
 How to encourage users to embrace
Odoo
Humans are deeply resistant to change. There is no small change. It is never just
a small detail. From the newest employee to the founder, change is a big deal!

To implement a new management software consists of not only replacing a tool

used by most employees, but also creating buy-in from the end-users in order
to achieve the company's vision. It’s definitely a big deal. As you will never use

05
chopsticks to peel a carrot, employees in the company need to be convinced
that the new management software is the best peeler ever!

To do this, the Project Leader has these resources:

• The product itself: once users are convinced by the features and
benefits, the overall acceptance increases. Train unconvinced users on
key features that they will benefit from.

Implementation
• The SPoC support and the key-users: Their role in the company and
positivity about the project in front of the employees will ease the
change management.

Challenges
• The project sponsors (ex: CEO) supporting the project.

The most successful projects generally benefit from large acceptance from
end-users, making the onboarding in Odoo smoother.

How to deal with resistant people

A common mistake is to put aside those who are not convinced (afterall, we
all prefer working with people who agree with what we are saying). If someone
is not convinced, do the opposite: invest time explaining to them the why/how,
and “sell” them the solution with a training.

A change is always perceived as a cost and a risk for the impacted users. And
a cost/risk is always worth taking if the benefit you get is much higher. While
trying to convince people, don’t say it’s not risky, or not a big deal. A change is
a big deal.

36 37
Instead, you have to “sell” the benefits of using the new solution. Organize
demos of the product, check how we can solve their pain points, and explain
How to keep things simple
to them why we work that way. If they can see the benefit of the solution, they
Customers have a tendency to make things more complex than they are.
will accept the risk.
• Avoid giving several options to the customer and letting them
choose what they prefer. Instead, propose the best solutions, and don’t
show the other options unless the customer is not satisfied with your
proposition.

During an implementation with Casual Cushions, the accountant was • Avoid delaying decisions, force people to decide, even if they are
the most resistant person in the company. The production teamwas unsure. Prevent them from saying, “we will ask key-users what they
happy about moving away from the previous system and were think” and “I have to ask a manager about their opinion”.
extremely optimistic about the project. Months later, the accountant
kept challenging me in every training and discussion - we went over Even if you think you simplified everything, we can always do better:
each workflow to exhaustion (bank reconciliation was probably the • Involve an app expert at critical phases (e.g. GAP Analysis) for a peer-
worst one). On the other hand, the production team was liking every review. As they’re not involved in the project, they can easily make tough
training, and they never really had many questions. decisions and provide you with another point of view.

Finally, when we went live, everything changed. The accountant

accepted the change - and since she gave a lot of thought about Odoo
and its features, she was ready for it. She knew where to go, what to
do, and all her corner cases and possible entries were covered.

On the other side, the production team had a much harder time. They
kept forgetting the training, and they presented me with a lot of corner
cases on production that were never addressed before. They worked
overnight to get caught up on production and were frustrated.

I talked to the accountant last week, and she mentioned how much
better the bank reconciliation in Odoo is and that she is happy to be
moving forward. When a customer is inquisitive and willing to test and
discuss the process (essentially involved in the project), the project is
much more likely to be a success.

- Mateus, Project Leader - Odoo SF

This subcontractor does machine work on windmill parts.

The production floor uses Odoo to manage their machining operations.

38 39
How to manage customer expectations How to write a good specification
A good specification is short, visual and structured as follows:
1. Business need: The use case (what) and its justification explaining why the
A few years ago, the CEO of a prospect asked me to meet before signing customer specifically needs that feature (max 2 or 3 paragraphs).
the contract. She told me “this project is life or death for my company, 2. Functional specification: The suggested solution using Odoo (how) illustrated,
please tell me everything will go smoothly”. I replied something like if possible, by a series of screenshots, or mockups with notes.
this: “No. Such a project is really difficult. We’ll have a lot of issues. 3. Technical hints: Things the developer will have to take care of.
But at the end, your company will be better. And I need you, as a CEO (See Appendix E).
to support the project when your teams complain, to get over these
difficulties.”
Avoid importing data history
I didn’t hear back from this customer until two years later when the
CEO phoned me. The project was seriously delayed and the key-users In addition to master data, customers often ask to import the full data history,
lost trust about the product. One of the first things the CEO told me like quotations and sales of the past 7 years. But it takes a lot of time, and it
was: “This project is a nightmare, we are 12 months late, and I don’t will eat a large part of the budget. As it adds risks to the project's success, we
see the end. But I did what you asked me for: I always supported the should do it only when it’s really justified.
project, I never criticised your product in front of the team, and always
motivated key-users who wanted to drop the project. But, now, we are Ask the following questions to check if it’s really necessary:
reaching the limit, I need you to do something for me…” • Is possible to keep that information in the old software, or an export
file?
So, these two minutes with the CEO before signing the contract have • How often will your customer consult that information? For which
actually saved the project. If the CEO would have taken the key-users purpose?
side, the project would have been aborted months ago. Because she
• What strategic impact might it have in 2, 3 or 4 years?
took her role to support the project seriously, the project has been
saved, and deployed in production two months after.
Just like any other request, as long as the customer can’t convince you, the
import request should be refused, or delayed until after the Go-Live.
- Fabien - Odoo’s founder, about the first customer who purchased the
Point of Sale app.

This story perfectly illustrates the power of managing customer expectations.

If Fabien would have said “don’t worry, the project is easy”, the CEO would have
lost trust in the project and probably followed key-users advice a long time ago
when the tension escalated seriously.

40 41
 A few months ago, I implemented Odoo Accounting for Ibbeo
Cosmetiques, a pharmaceutical group of three companies in France.
Avoid writing documentation for your
During the Kick-Off, my SPoC told me that taking over all historic data customer
from Sage was a must. She needed it all in Odoo to check it when
needed. I explained to her that taking over historic data was a risk to When implementing Odoo, you might be driven to create specific documentation
delay the project, and that it will take days of consultancy for very little to ease the end-users’ onboarding. Even if it seems to be a good idea, you will
added value. realize that the value you can bring isn't worth the time invested. As a Project
Leader, you should focus on tasks that only you can deliver.
I made her a deal: we start the accounting for all three companies in
only three weeks, with very little effort from her side. If we do it my In other words, Project Leaders should not waste time on repeating explanations
way, we will have several hours left on the service pack to use in the already given throughout the project. The customer should be responsible for
future. And if, later on, she decides it was still necessary to import the building their own documentation, based on their own business cases and
history in Odoo, we could do it in a second phase. She agreed. terminology.

One week later we had our first call and I imported opening balances In addition, the SPoC is the person who has the widest business knowledge
and master data. Finally, after the training, the project went live for all among all the Odoo implementation stakeholders.
three companies after just 2,5 weeks, with 9 hours left on the service
pack. Moreover, letting the client write their own documentation guarantees that the
configured Odoo workflows are properly understood and handled by the SPoC.
A month ago, she sent me an email in order to thank me for the quick This eases the change management process as the end-users have direct
startup and that Odoo was so much more user friendly than the previous access to a reliable source of knowledge in their own company.
ERP she was working with. She also told me that in the last 3 months
she did not need to check a previous accounting entry once and that Of course, most standard flows are already covered by existing documentation,
she was in contact with her sales advisor to add more modules and Odoo shares all knowledge online5. Small projects usually do not require a
take over all her activities in Odoo. specific documentation.

As we get more accounting firms joining Odoo, I often have requests to

take over accounting entries from the past 5 years. Everytime I use this How to deal with customers' specific
project as an example and let them decide. Either to deploy the project
demands
in only 2 weeks with little effort and few hours of consultancy or to
deploy in, potentially, 2 months and pay 4 times more for something
When dealing with customers, remember that there is a difference between
they will use once a year.
the stakeholders’ objectives, and the key-user's needs. Most decision makers’
priorities are time and budget, while key-users will mostly ask for specific
- Wynand, Project Leader, Odoo BE
features. As these objectives contradict each other, you’ll have to decide: who
do you want to please?

5 https://www.odoo.com/slides

42 43
You should always do what you think is best for the project; this means A key-user asked me to reproduce a complex report that they built every
challenging what key-users request, to the point of refusing to do it if you think week in Excel. According to the user, this report was very important for
it’s not worthwhile for the project. Use the following tactics to deal with custom the CEO. However, I challenged the user with the aim to know which
development requests: KPI was relevant for the CEO.
1. Is it really necessary?
2. Is it worth supporting the cost (of developing and maintaining it)? It appeared that the CEO only checked a few amounts, which were
the balance of some analytic accounts. Instead of going forward with
3. Is the gain significant enough?
development, I showed the CEO how to check these balances directly
4. Can we serve the same objective with a different approach?
in Odoo, and they were happy about it.

If you come to the conclusion that developing a specific feature is not worthwhile, Challenging the customer not only reduces custom development and
you should try harder to convince the customer. There are different tactics for risks of delay, it also brings a lot of business value.
this: explain the “Why”, phase it after the "Go-Live" date, escalate to a manager
(while not ideal, it’s sometimes necessary). - Cédric, Project Leader, Odoo BE

Tactic 1: Is it really necessary?

Let's say you have a request for the following custom development:

The customer has a website developed with Magento Commerce and does
not want to change their website since they already invested a lot in it. Tactic 2: Is it worth supporting the cost?
But they would like Odoo to be completely integrated with their Magento You need to evaluate the benefit: how many man-days per month will the
website (including products, coupons, follow-ups on abandoned carts, etc.) customer save because of this feature? Often, the customer only accounts for
how much time they spend on this kind of task currently, and how much they
The best way to assess if it’s necessary is to check if the customer already think they will save in the future. In reality, they will still have to record all data
has this feature in their old software, or not. If the customer records all necessary for the computation, deal with exceptions manually, etc. (Example:
orders manually in their old software, they can do it the same way with Odoo. Even if the customer develops a Magento connector, they will still have to
We would then recommend first going into production without developing an solve all conflicts, record price discounts in both software solutions, deal with
integration with Magento, use Odoo for a few months, and then decide if it’s inventory conflicts as the synchronization is not real-time, etc.)
worth it. Remember, customer’s priorities change when they go into production.
Then, you need to evaluate the cost efficiently. Often, the customer only sees
In terms of change management, it’s easier to roll out business process the "one-shot development cost". In reality, you can multiply this cost by 2 or 3
changes progressively, rather than everything at once. With the modularity of for the future maintenance and upgrades over the next 5 years.
Odoo, it makes sense to deploy in several phases: First, with what the customer
absolutely needs to operate the business, and only after moving to the second Note that using a community module allows you to save time in the initial
phase, other features to improve efficiencies. development, but you'll still have the testing, maintenance, project delays and
upgrade to account for in the cost. A community module is a technical debt too.

44 45
Tactic 3: Is the gain significant enough? A couple of years ago I did an implementation for a Belgian wine
producer. The SPoC of the project was passionate, but he was convinced
Let's say you have a request for the following custom development:
that his way of working was the most efficient and that everyone in the
company should work like him.
When we confirm a sale order for a construction project, we want to create
a series of tasks based on a set of rules that depend on the products,
We didn’t do a good job since we compromised and accepted some of
customers and locations.
his requests. We had date-fields that were almost never used, selection-
fields that filled up screens for no good reason, menu items that were
When you have a request for customization, you should first question the
not user friendly, etc. After a couple of months with the system, we
volume: “How many construction projects do you win per month?” Let's say
noticed that a lot of employees just did not use it, they were reverting
the customer wins 10 of these projects per month. It probably takes 10 minutes
back to their old software without telling the management.
to create and update tasks by duplicating and updating project templates.
When we realized that, we suggest the following: "let's revert back to
how the system works in full standard and let's talk to the team to see
Is it worth launching a complex development to save under 2 hours of work per
what they want to get out of the system". In other words, we asked
month? Surely not, this feature will cost around 10 days of development, plus
people what they wanted, instead of forcing a specific way of working.
25% of this every year.
We organized demos fully based on the standard with the objectives of
the team in mind.
Tactic 4: Can we serve the same objective, with a different
approach? They could not believe how easy it was to use the system and, when
Let's say you have the following customer request: going live again, the entire team adopted Odoo and dropped their old
habits. I learned to always challenge the SPoC's requirements, and
I want to synchronize our Outlook calendar with Odoo CRM. keep focusing on the business objectives. Often, customers know their
business, but not how to implement it.
Odoo has a connector with Google Calendar in standard, but not with Outlook.
But developing and maintaining a connector might cost a lot of money. However, - Cédric, Project Leader, Odoo BE & SF
there are plenty of services that synchronize Google Calendar with Outlook
(such as IFTTT). So, a solution would be to subscribe and setup such a service
for every employee.

It's not perfect as you will have to modify your setup every time you recruit
a new employee. But the solution is ready in 2 hours, and it will only take 10
minutes per new employee. It's still much less than a new development, if the
company has less than 100 employees.

Odoo is implemented in Lab Society,

a factory of laboratory equipments.

46 47
Why should you minimize custom
development?
For customers, a custom development creates additional cost and timeline
delays, sometimes to the point of putting the project at risk. In addition, custom Mecatis is an engineering company specialized in conception, production
development leads to technical debt that the customer will have to pay for and maintenance of manufacturing machines. They started using Odoo
within the coming years in the form of maintenance and upgrade costs. Such community in 2013 and were stuck with a very old version. In 2017, they
a technical debt costs around 25% of the development cost EVERY YEAR (~17% contacted us to upgrade to Odoo 11. We discovered 4 custom modules,
in maintenance + ~8% in upgrades). and 55 community modules on their database.
They spent tens of thousands of EUR in development and maintenance,
Each development may seem simple and affordable. But, as already which is not normal for a company of 10 employees. That was a huge
explained, the complexity of a project grows with the square of the number of technical debt, and the cost to upgrade these modules would have
customizations, not linearly. Customer’s probably want to solve what they didn’t been astronomical.
like in their previous software, but wouldn't it be better to standardize their
business processes and implement the project two times faster and cheaper? Instead of upgrading these modules, we challenged every single one:
some modules could be replaced by existing features in Odoo 11, some
For implementation service companies, custom development usually comes features were not used, and for the rest, the customer did not even
at a high cost, for low customer value. This is the typical scenario: you estimated know what these modules did. So, instead of upgrading their custom
10 days to develop a feature; the customer thinks it's too much for such a basic modules, we trained them on the standard, and helped them change
feature so you charge for only 8 days, but in the end, you spent 12 days on it. the way they worked. In only 100 hours of service, we moved them to
We later discover issues/changes needed because you had to do it in a hurry Odoo Online, without a single development. Their monthly cost has
and the customer won't pay for the extra day since it's your fault. What should been reduced by a 10x factor.
have been a 35% margin service is now a 6% loss on service!
I am sure that during the implementation, Mecatis, or their partner,
To grow, it's easier to focus on valuable services with better margins, and thought they needed these community modules. But in the end, it
decreasing the risk of non-billable hours. Such services include: project turns out that was more beneficial for a small company to stick to
management, business analysis, customizations without development, change what is standard in order to avoid being stuck in old versions. After the
management, and training. move to Odoo Online, the customer was so happy that we won a good
sponsor; they subscribed as partners to resell Odoo Online to their own
Service companies who build a mindset on reducing custom development, customers, delegating the service to our teams.
sooner or later, will be more competitive than the others. Companies who better
manage customers expectations will have lower project implementation costs. - Fabien, Odoo’s founder
Of course, custom development is sometimes necessary to run a business.
But, from our experience, the majority of customer requests are either not
worth the cost and not relevant once they start to use Odoo, or they can get by
without it as it’s not part of their core usage.

48 49
How to deal with internal politics Minirex is a company that buys different building materials from the
USA, then imports and distributes them within Mexico. Their offices are
all based in Mexico. Before 2016, they were using SAP to manage their
When something goes wrong, people try to find someone responsible and
business.
build excuses to defend themselves. This often happens when several service
companies are involved in the project. In the case of a failure, they will claim
The owners of Minirex were living in the US (Jacksonville, FL). They
they are not at fault and say it was the other's responsibility.
decided to implement Odoo, but they were not involved in the company
operations. They were not aware of the different processes, business
Internal politics is a game where everyone loses. The best way to deal with this
documents used by the company, etc. The company was effectively
is to avoid playing the game. When a project fails, it’s usually everyone’s fault.
operated by the employees at the Mexico office.
So, when shit happens, don’t waste your time arguing about who is responsible.
Don’t waste your time building a defence either.
And this was a recipe for failure. Why?

Instead, focus on moving forward and solving the issue (whether the issue is
The decision to implement Odoo was made by the owners, without
yours or not; we don’t care who is responsible, we care about the project’s
having the buy-in from anyone from the Mexico office. So, since the
success).
Kick-Off call, it was evident that none of the Mexico employees were
looking forward to implement Odoo. Since no one had asked their
opinion about it, they saw Odoo as something that was being imposed
onto them (i.e. "the owners are just trying to save money, dumping
this cheap erp software onto us"). Throughout the implementation,
they were very resistant to change: everything was slow moving,
implementation was low priority for them, etc.

Initially, we were not aware of this situation. As soon as we figured

it out, we had a conversation with the owners. Both the owners and
the consultant travelled to Mexico, in order to gain buy-in from the
Mexico office. We showed them what Odoo was capable of, and how
it would be able to handle their processes, better than their current
AP. It wasn't until that moment that the implementation started really
moving forward.

In conclusion, make sure that the key-users are on board before

jumping into an implementation. In the end, it will be these key-users
that will use Odoo, and collaborate with you during the implementation
process.
Project at a manufacturer and service provider
of tracking and navigation devices.
- Miquel, Head of Project Leaders, Odoo San Francisco

50 51
How to deal with different people's ideas per minute and change their mind as often. Your action:
• Make the rules crystal clear: The SPoC express the business needs
dynamics (What & Why) and you make decisions on the use of Odoo (How).

Managing many projects at once is not easy and having to adapt your speech
to every single person working with you makes it impossible. However, it
Why should young Project Leaders
sometimes helps to detect different personality profiles:
should feel confident?
“Do it now” gets right to the point.
Your SPoC will generally not invest enough time in their learning process and We have seen too many young Project Leaders thinking they are not "worth" or
might go too fast for the end-users to be correctly onboarded in Odoo. Your "good enough" in front of experienced people and, thus, they don’t stand up for
actions: what they think.
• Make sure that the SPoC knows Odoo properly (triple check).
Experience is overrated. Business decisions should always be supported
• Make sure that the SPoC communicates enough internally about the
by common sense, not (only) on past experiences. You don’t need to be
project (check that they take the time to prepare the speech they are
experienced to be rational. Sometimes, experience is a liability more than a
going to give to the end-users).
proof of knowledge: people do things “by experience” (habits), and not because
• Make sure the resistant people get involved in the project (greater
it’s the most rational decision to do according to the context.
involvement in the key-users selection).
• Get involved in the final-users training (train in tandem). For that reason, young Project Leaders should not be afraid to defend their
point of view, and challenge experienced people. This will force experienced
“Do it right” respects the rules to the smallest details. people to explain why they think so. If they are rational, their experience will
Your SPoC might be resistant to any change “because we’ve always worked like convince you. If not, feel free to defend your point of view.
that” and question your legitimacy in suggesting a new approach. Your actions:
• Skillfully challenge your customer’s requirements (focus more on the
added value than on the fact that it’s standard).
• Involve App Experts faster to strengthen the legitimacy of your I have hired more than 60 Project Leaders over the last few years and
suggestions. most of them were fresh graduates. These juniors are open minded,
motivated, full of energy and want to prove themselves.
“Do it harmoniously” has a good overview on their business and expect the
same in their project. Your SPoC might want to have full control on any situation Our project implementation methodology combined with the constant
(from the smallest details to the big picture). Your actions: evolution of the product, make our “newbies” learning curve almost
• Make sure key-users attend courses on https://odoo.com/slides. vertical in their first months as Project Leader. Rather than experience,
good onboarding gives them the right tools when convincing customers.
• Make sure that they reach a high level of knowledge about Odoo (extra
The crucial message I pass on to my newbies is always the same:
training if required).
no matter the knowledge and experience, the most important skill to
succeed as a Project Leader is having a strong mindset.
“Do it together” is highly flexible, solution oriented. Your SPoC will have 1000

-Catherine, Head of Project Leaders, Odoo Belgium

52 53
 Use Case 1
During the implementation of a 9-month project, a key-user requests a change
that will save them 4 hours of work every week. The user tells you that it’s the
main reason why they want to change their software. Unfortunately, the feature
is not standard, and it is estimated to take 2 weeks of extra development.

What will you do?

A If the customer is ready to pay; it’s ok to develop what will satisfy their
need.

06
B Try to convince the customer to avoid the development, but ultimately
accept if they really want it.
C Add this feature to the backlog of development to do after the Go-Live.

Answer: C. Since the user is not using such a feature in their current software,
they can live without it for a few extra months. Avoid an extra delay to the
project: an extra 2 weeks doesn’t seem a lot, but you never know how many

Quiz
decisions like this one you’ll have to face during the course of the project.

Use Case 2
The Project Manager of a company with 20 employees wants to add an additional
validation step on employees' expenses: any expense higher than 500€ should
have a second approval by the CFO. You estimate 2 days of extra development.

What will you do?

A Add the new validation steps in order to fit with the company’s
constraints.
B Define an internal policy (ask your manager and CFO for >500€ expenses)
and ask employees to send an email to both of them.
C Refuse to consider it as an acceptable need.

Answer B: Small companies often change the way they operate. Thus, it’s usually
better to define a policy, rather than developing a custom feature. All you have
to do is to send the procedure by email to employees: ask your manager and
your CFO by sending an email. As opposed to a rigid development, policies can
be adjusted easily and still allow common sense to prevail (e.g. if your manager
is on holiday, you can only ask the CFO to validate).
54 55
Use case 3 Use Case 4
During a remote weekly delivery validation session, you are demo-ing your work For a project status meeting, the customer invited stakeholders of each of the
(configuration and minimal customisations) on the customer’s billing cycle. All 7 departments. They have 10 representatives in the meeting. How many project
of a sudden, the CFO reveals himself in the audience by strongly indicating leaders of Odoo should attend this meeting?
that a mass invoicing validation feature is missing and that (overall) your demo
is a fiasco. The key-user for this area turns silent and refuses to react to your A 1 or 2, more would be a waste of time.
inquiries, in spite of the fact that the latter actively participated in all previous B 4, to feel ‘serious’ compared to the 10 of the customer.
sessions. How do you get disentangled?
C 7, one for each department to integrate.
D 10, as much as the customer.
A You apologize, shut down your computer & go home… tomorrow is a
new day.
Answer A: The most efficient is with only experienced project managers. If the
B You continue repeating that everything has been done according to the
project manager is not experienced enough to cover all topics themself, another
key-user.
project manager, or an expert is useful.
C You apologize, agree with the CFO and promise to get it fixed.
D You remind him the bases by referring to the GAP analysis.
Use Case 5

Answer D: Recall the GAP analysis by sharing it on your screen. You pinpoint that Imagine the following situation:
project success is defined by the responsible ownership of the key-user for that
area as explicitly agreed with all stakeholders at project start. You are willing Before the Go-Live, you have a meeting with the CEO. You have had a lot of
to address the CFO together with the key-user to circumscribe his worries in a issues during the project, they are not confident about your solution anymore,
separate session, noting that (if assessed appropriately) the need will be put in and they are scared about the Go-Live. The CEO is thinking about pushing back
the project parking lot for everyone’s post Go-Live requests. Escalation might the Go-Live another 6 months. They meet with you and say “My company can’t
be appropriate since an alternative could be dropping existing backlog content afford more issues. To accept the Go-Live, I need you to tell me everything will
to be replaced by their needs. be smooth.”

What will you answer:

A Pushing back the deadline is actually a good idea to reduce risks.

B Don’t worry, everything is under-control; we tested everything.
C A go-live is always difficult, but we will fix issues quickly.

Answer C: A go live is always difficult: shit will happen, even if we push the
deadline by 6 months. That’s normal. And I need you to support the project
when the team complains. On our side, we will fix issues quickly as they rise.
Pushing back the deadline by 6 months will add a lot of costs and risks on the
project (so many things can change in 6 months). It’s ok to tell the bad news. If
the CEO sees you know exactly what you do, they will trust you.
56 57
 Measure your progress
Here are milestones that most of Odoo’s Project Leaders reach as they move
forward in their career. Use them to assess yourself.

Novices

▫ Have a project on time & on budget 1 Point

Deploy a customer in production within

07
the initial timing and budget.

▫ Receive a gift from a satisfied customer 1 Point

Have a customer so satisfied that they
offer you a gift.

Measure your
▫ Deploy min 4 apps, in 2 weeks per app 1 Point
Example: Sales, Purchase, Inventory,
CRM, Invoicing in less than 10 weeks.

Progress ▫ Deliver a project at 80% of initial budget

Deploy a customer in production in 80%
less hours/days than the initial quote.
1 Point

▫ Deploy a company of 25 users, alone 1 Point

Put in production with no help from
another expert.

58 59
Experienced Your Results

▫ Pass Odoo’s certification with 70%+ 2 Points

▫ Go-Live within 70% of the initial budget 2 Points

Deploy in production in less than 70% of
the initial time estimated.

▫ Success in 3 different industries 2 Points

Have succeeded project in 3 different
industries.

▫ Migration from a traditional ERP in 2 Points

2 months
Move from Netsuite, Dynamics, SAP to
Odoo is less than 2 months before the
Go-Live.

# Points / Years of Experience @Odoo

▫ Have 3 projects in a row on budget 2 Points
Deploy 3 projects in production, without
extra success pack.

Experts

▫ Implement 500 users in production 3 Points

▫ Save a customer from bankruptcy 3 Points

Have a customer who tells you that you
saved their company from bankruptcy.

▫ Have 10 projects on budget 3 Points

▫ Did a migration of a traditional ERP in 3 Points

4 weeks.
Migrate a traditional ERP (Netsuite, MS.
Dynamics) to Odoo in less than 4 weeks.

60 61
 Appendices

Appendix A: GAP - Kick-Off

Use XMind1 to take notes during the GAP Kick-off meeting with the SPoC and
the decision makers. With this template, start from the top right element
“Introduction” and move clockwise during the interview (the left nodes are for
notes taken during discussions).

08.
Download the template: GAP Kick-off:
https://www.odoo.com/r/gap_kickoff

Extra
References

GAP Kick-off Template

1 https://www.xmind.net/

62 63
Appendix B: GAP - Key-users Interview Appendix C: GAP - Analysis Tool
Use XMind2 to take notes during meetings with the key-users. With this Use a Google Spreadsheet to document your GAP Analysis.
template, start from the top right element “People” and move clockwise during
the interview (the left nodes are for notes taken during discussions). Download the template: GAP Analysis Tool:
https://www.odoo.com/r/gap_analysis_tool
Download the template: GAP Key-user Interview:
https://www.odoo.com/r/gap_key_user

GAP Key-user Interview Template

GAP Analysis Tool Template - Tab Items

2 https://www.xmind.net/

64 65
 GAP Analysis Tool Template - Tab Conclusion

GAP Analysis Tool Template - Tab Planning

GAP Analysis Tool Template - Tab Data GAP Analysis Tool Template - Tab Summary

66 67
Appendix D: GAP - Closing Presentation
Use Google Presentation to document your GAP Analysis. Link all your graphs and
tables with the GAP Analysis Tool for an automated update of the information.

When it comes to submitting the results of your analysis to your customer,

it’s important to give a clear and clean overview of the coming project to the
decision makers.

Download the template: GAP Closing Presentation:

https://www.odoo.com/r/gap_closing

Appendix E: Specification Example

How to write a good specification: https://www.odoo.com/r/Spec_example

Extra References
• Odoo Blog Article: "The key to Implementation Projects: Manage
Customers Expectations." by Fabien Pinckaers1.

1 https://www.odoo.com/r/blog_implementation

68