Steps and Strategies for a Seamless Implementation Process

HÉLOÏSE: 0:01

What's in your business is a must have and what And so it's super important also to tell our client that they have to use the system in order to really understand, okay, what is really something that I need to have to be able to work or something that is nice to have, but I could live without it for some time or maybe forever. The second thing that is important is to show that you or the team have the skills, so that you can bring the skills on the project.

TOM: 0:29

Hello viewers, welcome back to another episode of I'm Tom, your host for today, working as Digital Advisor here at Odoo. Today's topic will be about implementation and methodology. Every project has it's lot of challenges and having the good tools, Having the good approach the good methodology is not only an option, it's a must. This is the reason why for every customer, you will have to have a tailor made solution to their specific needs to provide you with expert insight. I'm excited to be joined by two experienced Odoo colleagues, Eloise Limauge and Dorian Allard, that will guide us through the implementation methodology. Ready? Let's jump in. Hello, guys. How are you today?

HÉLOÏSE: 1:14

Hey, Tom. Nice to see you.

DORIAN: 1:16

Very good. And you?

TOM: 1:17

Yeah, I'm also really, really good, actually, um, bit, Louis, if you want to start.

HÉLOÏSE: 1:24

Yes. Uh, so my name is Eloise. Uh, I've been working at Odoo for a bit more than three years now. Uh, I'm also in the consultant team. I work as a digital advisor, and I'm also a team leader in that team.

TOM: 1:38

Well, welcome then.

HÉLOÏSE: 1:39

Thank you.

TOM: 1:40

And you Dorian?

DORIAN: 1:41

Uh, I'm Dorian. I'm quite like, uh, Eloise. Uh, I've been a digital advisor for two years here at Odoo. I'm also a coach.

TOM: 1:49

Well, welcome, guys, and thank you for joining us methodology. Let's just have a little picture in our head to begin. Uh, an aftertaste will well speak about different topics. Here, let's just say that we have to implement a manufacturing sector or manufacturing company in which we have complex manufacturing production, and they want to optimize their processes, but also to facilitate the communication between different departments. This is the picture okay. And so now we'll just dive into one topic and another. And I will just ask you random questions. Uh, I will actually more especially ask you to well give us example that you have, uh, got through during the whole implementation. Let's dive into it with the first team that is goals. Let's establish the primary goal. When you start here, a project here, defining digitalization strategy is really the key to ensure a smooth execution within the predefined time and budget. So here guys, according to your experience, what are the key elements and goals to keep in mind when starting a new implementation project? If you want to start? Eloise.

HÉLOÏSE: 3:08

Sure. Um, I would say that one. Uh, according to my experience, of course, one of the key aspects is really to be able to build a trust relationship with the clients. I think once you have the trust of your clients, you can have almost everything and you can achieve also everything. Of course, you can acquire this trust from in different ways, and I think we'll talk about that afterwards. But I do think that trust is essential. Um, and why? Because also it's important that you are able to build a long terme relationship with your client. Uh, we are not just Odoo implementers, so we don't just implement Odoo and then. Okay. We're done. Next client. That's not our goal. Our goal is really to become really partner with, uh, with our clients in order to help them really through their digital transformation. And for example, uh, I don't know if one day let's take back the, uh, manufacturing company we're talking about. Imagine this company, for example, in five years, we would like to launch a new website or a new e-commerce strategy. We really have the objective that, okay, they will launch that. Well, they think about Odoo in the first place so that we really become their main partners in their digital transformation.

TOM: 4:25

So here, if I have to paraphrase you, uh, two, long terme relationship actually with your customer, you want to build trust. How do you do it? How do you build actually trust with your customer?

HÉLOÏSE: 4:40

That's a good question. And actually, it's true that it can be a challenge, but I would say that trust is mainly based on three different pillars. First, of course, you have to show that you care about your client so that you care about your client, you care about his projects, and that you are there for them. I think that's the first thing that is important. The second thing that is important is to show that you or the team have the skills so that you can bring the skills on the project. Of course, you as Odoo implementer, you don't know everything about Odoo because Odoo is huge, but you have to show your client that you can find solutions for him or her, um, that you can find solutions, or that you can have people helping you find solution that is essential. And then I would say the last, the last pillar of trust is really the integrity. So show that you are integer. Uh, it means that do what you say and say what you do. If you say that you will challenge your client, you need to challenge your client. Otherwise your client might think, well, Eloise, she told me like one month ago that she would challenge me, but she never does it. So I can do pretty much what I want. So that's really, um, yeah, I would say that, uh, caring, showing integrity and also showing that you have skills is really important to gain the trust of your clients.

TOM: 5:59

Okay. What do you think about it, uh, Dorian.

DORIAN: 6:01

I think it's really important to to show your Um, and also, it brings to the project, like the, the the authority. Um. And there's something that also that can.

TOM: 6:13

Build trust.

DORIAN: 6:14

I think that in most of my projects, maybe I can everything, but at some point, I think saying no also can bring more authority. And you know what you're talking about as an expert. And at the end it will be better for the trust.

TOM: 6:31

And actually I will go into this direction. For me, saying a no is the beginning of a good discussion because, uh, you will actually by saying no, uh, force the customer to rethink the process, to rethink his, well, uh, how he will build things. So, yeah, it can definitely improve. And as you say, it gives you authority. Well, good authority. We are speaking here.

HÉLOÏSE: 6:59

Healthy authority.

TOM: 6:59

Healthy authority. Yeah. Thank you. Uh, okay. Um, yeah. So here we have, uh, one of the key goal that is trust. Uh, do you Dorian have one other key elements that you have in mind while starting a new project?

DORIAN: 7:15

Um, I think that something that's really especially, is to have a clear structure of the project. And I think in the methodology that we, um, use at Odoo is like having different steps into the project. So I think that currently what we're doing at the, um, at the beginning of the project is first doing and starting the kickoff. The kickoff phase is like three parts you have, like presenting the methodology. So how we're going to work with, uh, the, the client, the analysis part and at the end, like the digital advisory. And after this phase, it's really important to like plan the project, um, to take into account like the musthave, the nice waves, uh, to separate them into MVP's. Maybe we're going to talk about it. And of course, until the end of the project, uh, which is normally, uh, the support phase.

TOM: 8:07

So here you are speaking about the kickoff phase. Uh, uh, it's a meeting. If I, uh, yes, one or several meeting. It depends or more phase. Okay. Yeah, it's more phases, um, that you just will have three different areas. Uh, the first one, presenting the methodology aftertaste, is more the customer that speaks with, uh, explaining his whole process. Do you dive into all of his, uh, flaws?

DORIAN: 8:33

I think it depends of the time and the budget Um, let's say that you have like a strict budget, so you cannot like have like a big overview of the project and dive into every details of the business flow. I think you have to prioritize, uh, what are the main goals of the of the project? And then to ask the question directly regarding those, uh, priorities. Um, but at the end, when you have the priorities, uh, what we do is like the top down, we ask question about the overview of the priorities, and then we go more into details.

TOM: 9:11

Okay. Do you want to react about something here?

HÉLOÏSE: 9:13

No I well well yes I reacted. So yes. Um, I do think that one of our main concept is to things, keep things simple and to go as fast as possible. That's really what we aim to do in the quick start team. And that's why also we are called quick start. It's because we want to be our client to be able to start quickly. Um, and this is why, as Dorian said, that we need to plan things super well and that we need to structure the implementation because we don't have all the time that we want, we don't have all the resources that we want, and maybe the customer doesn't have all the money that he wants to. So we have limited resources and we need to take the most out of those resources. So we need to make the most out of it.

TOM: 10:01

So here actually taking a little bit of the time

HÉLOÏSE: 10:06

Exactly. So uh, I always, uh, um, say that to rather take more time in the beginning of a project to really make sure that the project is well structured and that the phases are well defined. I prefer to take more time than than ending up with a project that is not well structured. We are going in all directions and we've seen with experience that it can. It can lead to to churn so it can lead to to failure sometimes. Well, actually.

TOM: 10:37

Do you have examples of projects in which you methodology before diving into.

DORIAN: 10:45

It. And we say that I think in most of the cases But, uh, I think that what is really important in this case is really to identify the risk of project is that that moment that you identify what you should put the focus on. And I remembered I had a client who wanted to adapt the online appointment at Odoo, and we knew that he wanted like essential features that were not implemented yet. And by asking questions and go deeper into the analysis, we went to the conclusion that we needed a development. And so based on the analysis and by asking a lot of questions and understand what is the need behind, we plan the project accordingly. And, uh, we prepare like a phase of development by taking into account this, uh, future risk. That could be also a risk of failure because, as you know, development can cost a lot and also, um, delay the project.

TOM: 11:41

Perfect. So here to summarize, the goals that you with actually, well, really caring about your project and being showing integrity, having a structure that is well, well defined and diving actually into the the flows by asking why by really understanding what your customer wants. Well, let's continue with the other topic because of course it's linked with the twin pillars of the implementation time and budget. We have already a little bit spoke about this. It's the fact that when you implement, you have to make to have a deadline, of course, and to split it into several phases. Two process step by step and to have a roadmap. Of course, to help with this, we have different principles like, uh, simplicity or just standardization. And of course we have already spoke about this focusing on long Terme view here. My question is kind of simple. Why are developing customer features upselling or customer satisfaction not the priorities during an implementation? I don't know who wants to start with this.

HÉLOÏSE: 12:54

Go ahead. Dorian. You're the boss in that topic.

DORIAN: 12:58

So, yes. Uh, something that you need to keep in mind is satisfaction should not be like the focus on, um. You have to make sure that you focus on long terme objectives, such as the project success, which is the most important that you have to take into account. Why? Because if you focus too much on customer satisfaction by, for example, saying yes, you could delay the project because you will add a lot of different features, or maybe you will do all the development that the customer wants and at the end, just delay the project and maybe implement just a few things that are part of the global company. So it's really important also just to make sure that, um, relationship with the customer is good, but it should not be like the main objective. The main objective is always the project success.

TOM: 13:47

Do you have examples of, uh, customers of cases Yeah, customizations. And that was actually a big risk of the project.

HÉLOÏSE: 14:00

Uh, yeah, we have a lot of a lot of examples. I think it's also a bit part of our job is to manage that the client and to manage the client expectations. Also, um, I'm thinking about an example that I had recently. So I have this, uh, this client who, um, wanted to basically have beautiful reports. Um, so he wanted to customize, uh, the reports, uh, which I did consider, uh, not as a top priority in the beginning. Um, and so I started to discuss with the client and trying to understand, okay, why did he want it, those beautiful reports. Because, of course, we needed a development to do that. And we didn't have the time and the customer didn't really have the money, so I had to to challenge him. And in the end, I proposed him a deal. I said, okay, you know what? We are going to implement the the main requirements first and then you, you work a bit on the database so you get used to the database. And if at the end you tell me, okay, I really want those reports okay. We can think about doing development. And so the customer he started working on a database and he even forgot to remind me about the reports because actually while working on the system, getting used to it, it actually turned from a priority to something that was okay, maybe nice to have, but not a must have. And so it's super important also to, um, to tell our client that they have to use the system in order to really understand, okay, what is really something that I need to have to be able to work or something that is nice to have, but I could live without it for some time or maybe forever.

TOM: 15:39

Yeah, actually, I do agree with you. What is one of the biggest challenge is when a customer come with comes with a new need or a desire. The level of priority is never the good one. Because actually, because it's new, they do think it has a high level of priority here. In your example, it's because he thought about the reports that he was like, yeah, it's really important, etc. but it didn't change the flow. It didn't block the flow, actually. And this is something that we always have to deal with when we are speaking about, well, customizations about all those things. So yeah, I agree.

HÉLOÏSE: 16:16

It's true that it's a big part of our job to it really a must have? So what feature could my customer not live without. And what is a nice to have? That is really something that we need to do on a daily basis. Because as I said before, we have limited resources. So we need to focus on things that have the most added value. And things that do have the most added value are the must have. And so a big part of our job in the beginning of a project is to define, of course, in agreement with the customer, okay, what in your business is a must have and what is a nice to have that is super, super, super important.

TOM: 16:56

And actually what is also important is not saying It's actually you have to say your customer has to know that you have listened to him. So as you said, we'll just take this part and set it for later. So it will actually helps building the trust. Because you are an active listener, you are just, well, prioritize things that you want to do. Also want to add something about customizations.

DORIAN: 17:21

Not especially about customization, but maybe bell to every customer that will listen to, uh, this podcast is about like a historical invoices. I know that we have all of of us, uh, deal with this kind of issue is for them, always the most important to do is like import all the historical invoices and especially, uh, you have to take into account what would be the most safe in this situation. That would be the next wave, for example, as you said, by asking why and is it blocking if you don't do it? So I did it for one of my customer and we had a discussion, and he told me that at the end he wanted like all the historical invoices for. Like the legal part of his business. But at the end it was not really necessary. It was not blocking him. So what we did is we just, like, stored all the necessary invoices into an external storage. And that's it. And maybe the only thing that we did at the end was just importing the current open invoices because it was needed. It was a must have for the accounting. And we save a lot of time by doing this and by challenging this customer between the must have and the next wave.

TOM: 18:35

By actually having a good conversation with the

DORIAN: 18:38

Yes, exactly.

TOM: 18:39

And actually it will help me jump into the next Wow. Yeah I know, thank you, thank you. Um, well, here effective communication is really, really important to bring the whole implementation. And one of the first part is identifying the key stakeholders, what we here call a spark, a single point of contact. There are two different things that we have to understand when speaking about the spark. The first is single and single point of contact. By shredding the number of canal communication, you will really help, not waste time or information, and you will dive faster into every well, different flows into the whole implementation. And the other part is that you have to have a spark that has a strong decision making power, but also have a good overview of the whole company, but also can see the daily life of the company. I can explain it and of course he she needs to be available. Another common communication challenge will be and we have already a little bit discussed about this, about, well, the different needs to have and need to have. It's always difficult for customer to see the difference between both of them. This is the reason why I, well, often say that we are like doctors. When a customer speak about all their needs, they speak about their symptoms and we will actually find the cure to the illness. We will find the best way to implement the project. This is really something that you have to keep in mind when you are speaking with your customer. They are giving symptoms and you are giving the solutions. If they are giving the solutions, well, they don't have all the tools that you have. So this is a trap that yeah, a lot of people are falling into it. And so here's my question. How do you distinguish needs from desires. Mm.

HÉLOÏSE: 20:34

That's a good question. How we distinguish it. First, uh I think it starts with a good conversation with your client. Uh, what do I mean with a good conversation? Um, is, as you said, speaking to the right person. So, for example, imagine you have to find, um, I mean, you have to implement, for example, a commercial flow. Um, so you need to talk to the person that do those commercial operation on a daily basis in order to be able to really find, okay, how do those person work? What do they do on a daily basis when they arrive to work? What is their task? What is the the first priority? And I think by having that conversation, um, you will little by little find, okay, what is really their core, uh, I would say their core activity, like what do they do on a daily basis and what is really super important for them? What could they what could they not live without. That's really I would say the key is to communicate with the right user in order to determine the right priorities. That is really essential to find a must have, I would say.

TOM: 21:41

Do you have a concrete example that you had in which you had like a spark and I will say, a key user, someone that is using it on a daily basis. And did you see the difference? Can you have a concrete example of this guys in your head?

HÉLOÏSE: 21:57

I do have a concrete example was, I think a few I had a spark and I was asking so much questions. But. The answers that I got were super weird and not really into the context and not super like clear to me. Like it was super blurry. And so I told him, okay, but what is actually like, I mean, are you doing those tasks on a daily basis? And the person answered me, no, I'm not really responsible for that. I arrived a few months ago. I'm still learning. And then I told him, okay, but I think that if we want to reach something here, we need to include, I would say, the correct, the right, uh, stakeholders or the right, uh, yeah, the right speakers. And we need to have the people that do work on the field. And so we organize several meetings with those person, and it became way easier to determine, okay, what are really your pain points? That's also super important is what are your pain points today. And it's important to focus on those pain points and to solve those pain points. Because if we solve the pain points, then it will allow the users to really see the added value of using Odoo also.

TOM: 23:10

Yeah, and you're right actually, and it will not are speaking it is stakeholder key user is necessarily the spark. Actually a spark is just a person of contact that will help the implementation. I will come back here with a personal experience in which I had to make this wall analyze of a company that was actually making transports of raw materials around the world. And for this I had like six different departments. I had my spark that knew globally how all of this work. But he was not able to explain every parts of this. And actually, during the analysis phase with each department, my spark was there. Why? Because he also wanted to learn everything about what the department in order for for next to be able to implement it with me. And so to be the best spark ever for the whole company. So this is always important to distinguish a stakeholder and a spark it can be. Of course it's better if they are both the same person, but it can be split. And I will ask you the same question. Or maybe you want to react to what we said.

DORIAN: 24:24

Well, I think that the same for all the projects, front of you and make sure that you're talking to the right person.

TOM: 24:32

Perfect. Then. And I will ask you then, let's say Here we are speaking about real needs, about different flow. How do you prioritize them?

DORIAN: 24:41

I think it will depend of basically also the And maybe something that sometimes you forgot is about the common sense. At some point you are an expert and when you're talking with the customer. You have, like the feeling that maybe you have to go to a specific direction. And sometimes it's not always the direction that the customer wants. So it's also about challenges. But yeah, common sense should be a good tool to make sure that you have to prioritize, like the flow you're gonna implement, and also by the deadlines or the budget and the timeline.

HÉLOÏSE: 25:16

Yeah. And if I can add something here, I also the company that you have in front of you. I will not implement the same flow for a startup than for a company that has been in 20 years in business for 20 years. For example, if we take the example of a startup, maybe a startup would need, I mean, in the first place, what they would need is cash. They would need money in order to survive. So they might be more eager, for example, to implement their commercial flow. First, for a company that has been in business for 20 years, they might be more interested in, uh, reshaping their brand image, uh, because it's a bit getting a bit old and so on. And so here they might want to focus more on marketing, for example. So it really depends of the company that you have in front of you of the size of the company. Also the the IT affinity of the Spock or the key user. You might have a user that have never used an ERP, so you might need to start with simple flows. For example, I'm thinking about a CRM flow might be easier to use in the Fairplay in the first place. Sorry than um, than a manufacturing flow. So it really, really depends of the customer, the company, the context and so on.

TOM: 26:28

Okay. Like okay. And actually let's dive a little bit further into communication into here the spark because we are speaking about a world company when you are implementing. And so sometimes we have people management and change management. As you may know, coaching and supporting the spark during the wall project is really important. The reason behind this is because he will after the this be the ambassador of Odoo for the company. He will really teach well how to work to everyone in the company. But sometimes and it's normal. We have people that are resistant because we have to go from an old software to a new software, from an old habits to new ones, actually. So how do you handle resistance to change management? How do you do it? Actually.

DORIAN: 27:19

I think the first step is just to understand why you can have like for the user, the fear of maybe lost their jobs because the digitalization, or maybe they are afraid to work even more by learning new processes. So first is asking why to the end users, when you have the reason, I think you can maybe plan online meeting as an expert. You can go on site and try to handle the challenges that they're facing. Um, you can also maybe advise, uh, to the spark to do like workshop so you can maybe bring different use case to the end users and make it playful. Uh, I think that's something I advise a lot, um, in my project is to make everything playful, because when you try to learn hard things or new things, it's always better when you play it.

HÉLOÏSE: 28:12

Yeah, I totally agree. And also never, never take for granted the fact that maybe one user doesn't want to use the system for a reason in another user, it might be for another reason. So don't take, uh, don't think that there might be only one reason, uh, for, uh, I would say, uh, resistant to change. Uh, it also, of course, depend of the, the end user. Uh, it depends of how the end user will use the system. When will you use the system? So, as Dorian said, I think never hesitate if you have the possibility to go on site to meet the users and to have a real conversation with them and telling them, okay, let's be honest. Like what prevents you from using the system? Is it a lack of training? Is it because you see Odoo as a black box and you don't understand anything? Or is it because you don't see the added value of the system? These are different reasons, and you don't have to. I mean, you cannot handle those reasons the same way. So yeah.

TOM: 29:10

And actually change management can be really a I will take you an example of I had this complex manufacturing process, which was actually a eight step manufacturing process. And when we did implement it, there was kind of big resistance in change management when we dived into it, when we discussed with the end users the reason of this was because actually three of the eight steps didn't actually need to be in Odoo because you were not tracking datas and it was just a little quick step. And so by listening to the change to the key users, we just deleting two. Taps into Odoo because it was not necessary. So it really helped the project because thanks to them. So yeah, for me it can be a strength.

HÉLOÏSE: 30:04

Yeah. And if I can add something here, I think don't replicate it. And it's super important that the key users are the users. They have to understand that Odoo will not replicate their whole system, or will not replicate exactly the way they were working before. And that's not the goal at all. The goal is to improve. The goal is to go faster, is to be more efficient. So we will replace the system, but we will not replicate it. And yes, the users, they might need to adapt sometimes, but if they really understand the added value behind and if they see where they will save time or save money or save energy, I really think they will be more keen on using the system. So the yeah, that's super important. Replace don't replicate. It's a tip that I give here.

TOM: 30:55

Well actually let's continue with little tips Well at most almost at the end of the podcast, uh, we have one final uh, subject which is monitoring. So when we have finished the implementation, you have to keep actually milestones, measurable milestones to be sure of the success of the implementation. So here what are for you milestone or how do you monitor actually projects that is implemented.

DORIAN: 31:26

I think, and maybe I like to use this metaphor in It's like a project are like trains that are traveling from station to another until the final destination. And I think as if we train that traveling, you have to keep track of the pace and where are we going to and here to do what we are using to monitor those things is like the project reports. The project is just to. Check if the project is on track based on the budget you define and the planning and deadlines you define as well. So that's the moment at the end of each phase where you monitor the project, you bring what could be improved and what was good for the project.

HÉLOÏSE: 32:06

Yeah, I think a successful project is a project also where you really were able to build that long, firm relationship and you know that your customer will call you back in several months or years because he will need you to make his business grow. I would say that's a successful project for me.

TOM: 32:26

I also believe in this. Well, thank you guys for your time. Do you have here a last tip, an off topic tip that you are thinking about implementation and methodology.

HÉLOÏSE: 32:37

I already gave the replace don't replicate. That's the first one.

TOM: 32:41

Um, that's your sentence?

HÉLOÏSE: 32:43

No. And also I would say really that this That's really my tip here.

DORIAN: 32:50

Maybe for me one of my tip could be like Uh, sometimes we like, uh, thinking about implementing, but it's also about co-creation. So you collaborating with your customer and so you brainstorming also on the processes. So make sure that also the solution can come from the client.

TOM: 33:09

Well perfect guys here in well a half hour we how to actually build trust with your customer, how to structure everything in order to have a good project. Thank you very much for your time. Thank you for your expertise, guys. Uh, I hope that we will see you in other podcasts. I wish you a nice day and see you next time.

HÉLOÏSE: 33:35

Thank you, thank you. Bye bye bye.

TOM: 33:37

Well, that's it for today. We hope you enjoyed this episode about implementation and methodology. If you would like to see other episodes you can see it on Odoo FM. It was a pleasure to be here with you and we hope that you will enjoy the other topics. See you.