Odoo specification: what it should contain, and how to write yours in ten minutes

An Odoo project that goes off the rails almost never does so because of the software. It goes off the rails because nobody wrote down, in black and white, what the company expected. The quote was priced on one idea. The configuration started on another. And the gap shows up at go-live, when it costs the most.

The remedy is well known: the specification. But in an SME, it is intimidating. People picture an 80-page document, reserved for large corporations and their calls for tenders. So they skip it, or ask the integrator to write it for them, which amounts to asking them to guess.

This article shows what an Odoo specification really needs to contain, how to phrase a requirement so that it is useful, and the mistakes we see coming back from one project to the next. At the end, you will find our free tool, which produces a first version in about ten minutes.

Why does a specification change everything in an Odoo project?

Odoo covers sales, invoicing, accounting, purchasing, inventory, manufacturing, the website, and dozens of other apps. This breadth is a trap: everything seems possible, so nothing is defined. Without a reference document, every meeting reopens the scope, and every new idea becomes an emergency.

“On average, large IT projects run 45% over budget and 7% over schedule, while delivering 56% less value than predicted.” That is the finding of McKinsey and the University of Oxford, after studying more than 5,400 IT projects.

These figures concern projects of more than $15 million. An SME is not at that scale, but the mechanism is the same, on a smaller scale: a vague objective at the start is paid for in back-and-forth, configuration rework and contract amendments. The authors of the study also stress one point: staying focused on business objectives, from the start to the end of the project. That is exactly the role of the specification.

a) It gives the estimate a concrete basis

Nobody can seriously price “manage inventory”. You can price “vendor receipts update the stock, with a check of the quantities received”. The more precise the requirement, the more reliable the quote, and the fewer surprises it holds when the invoice arrives.

b) It protects the schedule

Every requirement discovered along the way pushes back everything else: configuration, testing, training. A requirement written before the start can be planned. A requirement discovered in the third month has to be negotiated.

c) It makes the company speak with one voice

The business owner, the accountant and the workshop manager do not expect the same tool. The specification forces them to agree before the first configuration, not during it. It is often the first time the company writes down how it really works.

What should an Odoo specification contain?

Forget the 80 pages. For an SME with 10 to 50 people, a good specification fits in a few pages, as long as it covers six blocks.

1. The company on one page

Business activity, headcount, expected number of users, current software, target date. Each piece of information weighs on the project:

• The number of users sets a good part of the license cost.
• The split between office and field tells you whether you will need shared workstations in the workshop, tablets in the warehouse or phone entry for technicians.
• Current software tells you what will need to be replaced, connected or dropped, and where the data will come from.
• The target date tells you whether the project needs to be split into phases.

2. The scope, app by app

In Odoo, Invoicing and Accounting are two different apps, just like CRM and Sales, or Website and eCommerce. Mixing them up means underestimating the project. The specification lists the apps involved and, for each one, what it needs to do in your company.

3. Requirements, phrased as outcomes

This is the heart of the document, and the part most often botched. We come back to it right after.

4. Priorities

Each requirement has a level: essential, important or later. Without priorities, there is no way to make trade-offs when the budget or the schedule gets tight.

5. Data to migrate

Which files, extracted by whom, and validated by whom. It is the number one risk of a project, and we devote a whole section to it below.

6. What the project asks of your company

An available point person, decisions made on time, users freed up for testing and training. An Odoo project is done with you, not for you. Writing it down from the start avoids discovering it when the team is swamped.

How do you phrase a requirement that is truly useful?

The rule fits in one sentence: describe the expected outcome, not the screen or the button. An outcome can be verified. On acceptance testing day, you go through each line and test it. “A quote module”, on the other hand, cannot be tested: it either exists or it does not.

This requirement is not a matter of form. It is what determines whether the project succeeds:

“When a project fails to meet its original goals, poor requirements management is the main cause almost half the time (47%).” That is the conclusion of the Project Management Institute in its Pulse of the Profession study on requirements management.

The “same as before” trap. Describing your old software screen by screen amounts to ordering a copy. Odoo often does better through simple configuration, provided you start from your outcomes and not from your habits. Demanding an identical copy pushes you toward custom development, which is more expensive to build and to maintain with every new version.

Your integrator, reading “it has to work like before, but better”.

Why rank your requirements into three priorities?

If everything is essential, nothing is. A specification without priorities reads like a shopping list: there is no way to know where to start, or what can be postponed when the budget or the schedule gets tight.

We use three levels, inspired by the MoSCoW method:

• Essential: without it, the tool cannot replace the existing system. It is the foundation of the go-live.
• Important: useful from the start, without blocking the launch. It is delivered if the schedule allows, otherwise right after.
• Later: to plan for a following phase. Writing it down now avoids rediscovering it as an emergency.

A balanced specification is shaped like a pyramid: a broad base of clearly identified essentials, some important items, a few “later” ones. If your pyramid is upside down, everything was ranked essential out of caution. Go through each line again with a single question: on launch day, can we work without it?

In our tool, each requirement gets its priority, and each section accepts your own lines.

Why is data the number one risk of the project?

A perfectly configured Odoo is useless if the customers, products and stock it contains are wrong. Data migration is the most underestimated part of a project, and the one that most often delays a go-live.

The specification needs to say which data to migrate: customer and vendor contacts, products and prices, opening stock, open orders and invoices, sales history, accounting balances. And above all, who does what:

• Your current software stays with you. The export is done by you, or by its vendor. Your integrator has neither the access nor control over software that is not theirs.
• The last file sent is the reference. Each dated delivery replaces the previous one.
• No value invented or corrected. An empty cell stays empty, and any doubt is flagged to you.
• Validation is up to you. In every case, you are the one who checks and validates the migration.

Two tips from the field. Limit the history: five years of lost quotes help nobody work on Monday morning. And set a cutover date: after the final extraction, anything entered in the old software has to be re-entered in Odoo. A file delivered late pushes back the go-live by the same amount: the data schedule is part of the project schedule.

What are the 6 mistakes that ruin a specification?

1. Copying the existing system

The document describes the old software menu by menu. The result: you rebuild its flaws with a new tool. Start from expected outcomes, not from today's screens.

2. Ranking everything as essential

For fear of forgetting something, everything goes to top priority. When the time comes to make trade-offs, nobody knows what really matters anymore.

3. Writing solutions instead of requirements

“A button that sends the invoice to the accountant” is a solution. “The accountant accesses the documents without us sending them anything” is a requirement. The second leaves the integrator free to choose the best configuration, and it is often simpler than the button you imagined.

4. Forgetting the field

The specification is written at the office. Yet the people who pick orders, manufacture or work on site at customers' premises have very concrete needs: entering data quickly, on a tablet, sometimes standing between two machines. Ask them before writing, not at training time.

5. Putting off the data question

“We'll deal with the files at the end.” That is the sentence that costs the most weeks. Who extracts, when, in what format: these three answers belong in the specification.

6. Aiming for perfection on the first draft

A specification is not a contract set in stone from its first version. It is completed and validated during the audit. A document of a few pages today is better than a perfect document in six months.

You in the third month of the project, when nobody had written down what “manage inventory” meant.

How do you get a first version in ten minutes?

We built a free tool based on our own specifications: the Quick specification builder. It asks one question at a time and requires no writing.

You, wrapping up your specification before finishing your coffee.

1. Your company: business activity, split between office and field, number of users, current software (just type the first few letters), target date.
2. Your apps: one section per Odoo app, fifteen in all, from CRM to Accounting, including Manufacturing, Quality and Point of Sale.
3. Your requirements: for each app, requirements already phrased as outcomes, drawn from our integration projects. You give each one a priority and add your own.
4. Your data: what you want to find in Odoo at launch.

At the end, your specification can be downloaded as a PDF and is also sent to you by email: a one-page summary with your priority pyramid, your requirements sorted by app, the data migration rules, and our integration method in two pages. Your answers stay in your browser: you can take a break and pick up later.

What happens after the specification?

A first version is not an end. It is the starting point of the audit, the stage where each requirement is tested against Odoo's configuration and your real data, to sort out:

• what Odoo does through simple configuration;
• what requires adapting a work habit;
• what justifies, more rarely, custom development.

At the end of the audit, the specification is completed and validated with you, line by line. The project then starts on an agreed scope, phase by phase.

Where should you start?

If you only remember one thing: a short, honest, prioritized specification is better than no specification at all. Describe outcomes, rank them, name the data to migrate and who is in charge of it. The rest is built with your integrator.

The simplest thing is to start now: create your first Odoo specification, then keep it handy for your discussions with your integrator. And if you would rather talk it through, call us at 04 28 29 14 84.

Article written by Billy Felicie

Founder of Hors du Commun, an Odoo integrator in Lyon. For more than 3 years, I have been helping SMEs implement Odoo, from audit to go-live: about twenty projects, most often for companies with 10 to 50 users.