How To Successfully Implement an Ecommerce Platform With Caspar Hardholt of Alumio

Guillaume: Hello everyone. Guillaume Le Tual here, host of the E-commerce Wizards Podcast where featured top leaders in e-commerce and business. Today’s guest is Caspar Hartholt, the CEO and founder of Alumio, which is the company doing system integration there with the platform, we’ll be discussing it in a moment. And formerly he was the founder and CEO of MediaCT, an agency with over 55 employees for something very similar to what I’m doing, specialized on Adobe Magento and so on. So a very interesting skill set here to discuss together as Magento agency owners, and the main topic will be secrets to a successful e-commerce and system integration project. So even though we’ll be focusing through that lens for a merchant or a company owner, or a company director, who wants to have a successful project or their system, it could also go all the way to IT projects and so on. So this is a very universal knowledge. But here, when we’re talking e-commerce and system integration, you can easily have, just for the system integration, several tens of thousands of dollars of budget, and then you add the e-commerce and depending how far you want to go, you could be talking, not just 100,000 dollars but a few hundreds of thousands of dollars. And this can be a very significant project and it’s totally worth spending the time on. How can I make those kinds of projects with such large investment to be a successful project? That’s what we’re going to be discussing today.

So, before we get started, our little sponsorship message. This episode is brought to you by MageMontreal. If a business wants a powerful e-commerce online store, to increase their sales or to move out piled up dormant inventory to free up cash reserves, or to automate business processes to gain efficiency and reduce human processing errors. Our company MageMontreal can do that. We’ve been helping e-commerce stores for over a decade. Here is the catch, we’re specialized and only work on the Adobe Magento e-commerce platform. If you know someone who needs something Magento, debugging, development, design maintenance, anything we got there back. Email our team, support@magemontreal.com or go to magemontreal.com. All right, Casper, thank you for being here today.

Caspar: Thank you very much for having me.

Guillaume: So you have a very interesting background. Can you tell us just a little bit more about yourself? Before we go to the main topic?

Caspar: Yes, of course. Well, my name is Casper and I’m from the Netherlands. I’ve been in IT e-commerce since 2002. And we basically accidentally rolled into the Magento domain back in 2009, with our agency back then. And that was a great fit with our background. And I think also, our good experience with e-commerce until then. And we wanted to create our own ecommerce platform. So we were designing the interface, we’re trying to build our own platform, and then we accidentally came across Magento. The analysis was a big uplift from that point. So we turned our entire agency to Magento only focused company, we were enterprise partners in the Netherlands. And within that company, which I founded, we also worked on a lot of integrations. And that’s basically the core reason why I founded Alumio.

I sold my previous company to focus fully on my integration platform called Alumio to help all kinds of agencies and companies across the world, solving integration challenges. So, that’s my background.

Guillaume: Hey, well, thank you. So integration challenges, there are plenty of those. That’s for sure.

Caspar: Yes.

Guillaume: There is no shortage of challenges to discuss about. So let’s start at a bit high level. Again, from the point of view of a business owner or project director on the client side who’s hiring providers here to do that integration work, what should he focus on to have a successful project, like what comes to mind first?

Caspar: I think people. You can talk about technology, you can talk about hiring the right company, but in essence it comes to the hiring of the right people and determining how you want to build up the e-commerce business unit. Because every project will be a failure or a success based on the people who lead the project basically, or the business unit. So the first thing that pops up is people.

Guillaume: Very good. Okay.

Caspar: That’s a bit abstract I know.

Guillaume: I know why it is very high level.

Caspar: Yes.

Guillaume: So, indeed people I agree. And like in a general way, if we put them in order, I would say people come first, then processes come second, and tools come last. Because if you have the right people, they can make an imperfect process and tool work. If you have good processes and limited tools it’s still going to work. But if you have the best tool and bad processes and bad people it’s not going to work.

Caspar: It will never work. No, I absolutely agree.

Guillaume: Yeah.

Caspar: And I think that having the right knowledge within the company really gives you the ability to hire an agency and be successful. Because if you lean too much on the agency, it will also potentially cause the wrong decision based on the gut feeling that you have as an agency. So I think having knowledge with your company is also very important and that goes together with people.

Guillaume: Okay. Well, while we’re talking about people a bit more than tactical or tangible, I believe the merchant who’s hiring the agency should have someone dedicated in-house to the project. That’s one of the key factors for success to actually have time for the project. We’re all busy running our companies, we have a million problems to solve.

Caspar: Yes.

Guillaume: But that’s one key factor that I’ve observed. And when the CEO or president wants to take on the project and be the main contact, for me that’s always a red flag.

Caspar: Right.

Guillaume: You know, in the sense that the guy will likely run out of time. Sometimes it’s not the case. I’ve seen a large enough and mature enough company, that I would say I was privileged enough to have that working relationship for like a year with the CEO. That was his top project. But that’s because the company was large enough in the eight figure business and that the president had nothing left to do if he wanted the company.

Caspar: Yeah.

Guillaume: So he decided that he was doing the website, that’s pretty much it.

Caspar: But those are like 98% of the time. It’s usually a company that is emerging that wants to start e-commerce or rebuild an ecommerce platform, and doesn’t want to allocate a budget to a person leading the project internally. So they think they actually save money by doing it themselves, in the end it will cost them money and time. Time is even more expensive.

Guillaume: So what I say is that the person assigned in the house of that company, it must be their number one priority to be this IT or web or system integration or e-commerce project, and anything else if they have free time comes second. So when we need approval for something or whatever, as the vendor, like they run with it, they get it and nothing blocks. So they are having that sort of overcapacity in a way of handling the project.

Caspar: Yeah.

Guillaume: That is one critical path.

Caspar: Yes. And I also think a lot of managers, while we have so many management styles, can lead a project in a very traditional way, or in a more modern way based on an agile project owner role. And I think the majority of the agencies are system integrators that are around, like to work on an agile kind of basis, whether it’s adapting the framework entirely, or just like, trying to use it in some parts of the agile framework. But I think to me, the best managers that I have seen were educated on the project, product owner domain, and also had the ability to do things within Magento Adobe themselves. Basically, understanding how to configure or how to tweak small things within the system itself, not on code level but on a user interface level.

Guillaume: So you meet a project manager that has a bit of hands-on capability, that is not a purely theoretical guy, he knows how stuff works on the platform he’s working on, let’s say in this case, let’s pretend it is Magento integration. He knows a bit about Magento. So that’s a criteria that you look for.

Caspar: Well, to me I think such a person knows how to bridge the gap between the business blow, the business case and also the business processes, but also how to implement that within the Magento platform. Because if you leverage the platform itself,

without knowing what kind of capabilities it has, allows you to deploy the platform much better and much more efficiently and much more cost effective than if someone doesn’t know that. So for me, I think that’s a very important aspect.

Guillaume: Okay. So if I sort of rephrase what you’re saying here is that on the vendor side, who’s providing the system integration and all that, the level of skill and knowledge of the architects of the solution in a way, because he has to analyze the business needs, and then he has to see what this solution has this capability, and then sort of come up with what’s the best solution to solve this from a technology point of view, and comparing the T option A versus option B for the cost, then upsides and downsides and all that.

Caspar: Yeah. Well, I’m not saying it should be like a solution architect, or someone who knows a solution thoroughly. But more of a person that understands it on a high level, understands how to, if you configure a payment, like for example, the payment integration, like a payment extension, if you understand how the refunds work, or credits, or how actually the payment process works, it helps you make better decisions. I’m not saying that you should know the entire solution, but understanding it from a high level allows you to make better decisions based on the recommendations of your system integrator.

Guillaume: Yeah, so what we used to call it in the magenta world, the solution specialist. So the high level business knowledge, but also a high level, technical knowledge of the platform to be able to merge those two together. The quality of the person who’s going to be making that kind of solution, the solution specialist at the vendor side, makes a huge impact on the product.

Caspar: Yeah, and I think nowadays, Adobe offers a lot of courses and training to become a solution specialist, at least at a high level. And I would really recommend that every product owner or person within a company, like a merchant, to do such a course.

Guillaume: Very good. So on the people side, maybe you have other ideas, but then I guess the rest of it would come more on the people side would be about the habits like and the processes that the vendor would follow. So, for example, we want to prevent scope creep on both sides. So the vendor wants to prevent scope creep to maintain profitability, but the merchant wants to prevent scope creep to not be billed extra, because

Caspar: Absolutely.

Guillaume: the vendor will try to bill it. So, one thing is, this is a really good project plan. When the whole thing starts, I see a lot of vendors, I see a lot of competitors’ quotes on the market and so on, that are just not detailed enough. They’re too high level, sometimes the industry proposal can be high level, fine. But then how is this feature really supposed to work when it connects with your ERP, your Enterprise Resource Planning system or your accounting system, there’s a lot of intricacies. You know we have 10 pricing levels and then we have other sub-divisions of how this works. But if you’re in this state or province that does not work the same price grid, then how does a credit note apply and all kinds of other rules like this?

We will not ship a partial batch. We’ll ship only full batches even if we have inventory, we cannot add batches together for your inventory control. All kinds of crazy little details like this that totally impacts the scope of work of doing integration, that need the proper level of detail in the proposal and the requirement document which we call the BRD, build requirement document. It could be called an SRS, software requirements specification, some may use other words, SOW or whatever. But you need a very detailed breakdown of the use cases of what it’s supposed to do when the vendor does not have the detail oriented mind enough to do all that breakdown, you’re going to run into issues and budget problems.

Caspar: Well, I absolutely agree and I see this many times. So this is actually something very relevant, I think. Because I also see a lot of system integrators and also merchants who are basically drafting the high level requirements and then they boil down to the user stories right away. So the actual no, this is what we’re going to do, but without clear acceptance criteria, you’re basically some kind of empty canvas. Like, this may go left or may go right, and this may be the end goal.

A lot of projects actually fail because a lot of Scrum following companies and system integrators are stepping over the death part too quickly. And indeed, the functional description of a project is actually a time consuming part. But its essence if you go to the actual development, because if you’re not doing that, you’re not leveraging the best features of Adobe, and you’re going to create a lot of things that the merchant does not really need. I think that’s the point where scope creeping starts. Yet nobody wants scope creeping, and it’s suddenly the big elephant in the room. It becomes like a thing and then after a couple of months, everybody’s like, what happened?

Guillaume: Yeah. Why does the project take twice longer and cost twice much more, and nobody’s happy.

Caspar: Nobody’s happy. And of course, the merchant is like pointing fingers, and then the agency is pointing fingers back. So yeah, it doesn’t benefit anyone.

Guillaume: Yeah. So it starts with a very quality project plan. So just in layman’s terms, if somebody is not used to the Agile lingo of the agile work. It starts with the project plan, and should have a good user story. So what does that mean? It’s just in plain terms, who’s doing what and why? That’s pretty much it. So let’s say as an administrator, I want to be able to create a credit note in my e-commerce system, and I must be able to receive it in my ERP, so that the two systems are synchronized, and I don’t have to do data entry twice. So that would be an example of a user story. And then you would have a definition of done. So the definition of done is the acceptance criteria, if you wish. So you could say that then, as an admin, I was able to create my credit note, and I was able to verify that it is received without flaws in the ERP, that’s an example. And then once you have your acceptance criteria, nobody can start arguing or having conflict, is there work done? Yes or no? Because it becomes more binary, black or white. Here is the work done. You say, when I go there can I create a credit note? Yes or No? And does it sync back to my ERP? Yes or No? So if the answer is yes, and there’s no problem, there is no bug. If it syncs correctly, you could say the work is done.

There’s more detail of course, in the user experience interactivity, and stuff like that. But that could also be considered a different budget. But the mechanic is there for the functionality and you should have a technical solution and a good project plan. Like, how will you do this? Well, this isn’t whatever API connection endpoint or something that the technician will write the technical solution there. And there should be a budget for this specific use case here, this user story that we’re talking about.

So you have a very detailed project plan like this with every single use case being listed. And then every acceptance criteria or definition of done for when the job is finished. And what is the technical solution for each of those things? And the technical solution if it changes, of course, it’s going to change the budget. I sometimes give as an example, if you decide to build a building with a wood structure or if you build it as a commercial building with a steel structure, the price is not the same at all. So if you change the technical solution, even though the size of the building is the same as what and whatever, you change the technical solution, the price won’t change. So the technical solution must be there. Otherwise, you cannot control the budget properly.

Caspar: The user story alone is not sufficient. I think that’s the core message and the main message. And I think a lot of the companies that started a decade ago, or like 50 years ago, were kind of like rebellions. We didn’t want to do it the same way as all of the large system integrators that were doing everything on waterfall and with principaux, and all kinds of traditional methods that cost a lot of documentation, a lot of painful processes and policies. So we were actually rebellious, we tried to do something different than the rest. And honestly, that also costs pitfalls. So I did the best scenario. The best examples are agencies, system integrators, who know that you should talk a lot about the business processes of the merchant before writing down but before writing a user story. Drawing it out, make it feasible for the merchant, so that they understand that if they send out a credit for an order

it doesn’t include partial credits. It doesn’t include partial refunds. How does the flow go? So yeah, I really see successful system integrators doing that very, very well.

Guillaume: I agree with you. Yes, start with the business requirements, the discovery process, documentation that typically to what’s called a BRD, build requirement document. And this document only has high level business requirements without any kind of user story and without technical solution. Because it’s universal, it could be built on any platform. The BRD is what you will use to receive quotes from vendors, basically, that can then quote from whichever platform on how to fulfill your build requirements to it. Which are business requirements, actually. So the BRD would typically be written by a business analyst, or business people, or business owner with a consultant, or if that’s not already done, in our case, we would help the merchant to write the BRD first, and then we’ll get into the more detailed project plan for large projects.

Caspar: Or even with integrations, where a platform gives the user the ability to configure integrations like between Adobe commerce and ERP systems or CRM, [Inaudible-00:21:11] and so on. Even with those kinds of projects it seems very attractive to start configuring right away, because you can. But you know if you don’t think about the integration itself, it will become a failure. And so the technology can be good. But yeah, if you don’t have the right process in place, it will fail.

Guillaume: Yeah. So you’re talking about Agile, so like everything else, Agile has positives and negatives. Do you want to talk a bit about that?

Caspar: Yeah, sure. I think the good thing is that it makes clear the roles and rules and responsibilities. So I think it has some very, very good components. Personally, what I dislike is that it sometimes becomes like a sort of religion, and a way to cover up things. And that’s not only my personal experience, I hear that more often in the market. Now people say, yeah, but it’s, it’s Agile, you know? No, we didn’t do that, or we did it differently than we were requested, because it’s Agile. So to me, those are the less positive parts of the framework. And when the framework is not being used as a framework, maybe a religion to [Inaudible-00:22:48]

Guillaume: Religion perhaps, the original blind faith on the methodology?

Caspar: Then there’s a reason why it’s called a framework, right? So I’ve seen some very successful projects being executed with Scrum, based on the Agile framework. But that would be my first thing that pops up. What about [Inaudible-00:23:15]?

Guillaume: Yeah, exactly my impression on that one is, the downside is sort of a downside of Agile because there are a lot of positives and in a general way, it’s a better way to go. But the downside is that there are lots of cowboys out there. So the Agile Cowboys, I call them, don’t want to spend the time to create a proper project plan and to write everything down and plan the work enough. So the positive of the other alternative, the traditional method called the waterfall, because of the cascade from the first task to the second task, the third task, and so on, is that they do a crazy lot of planning upfront. So you can benefit from the traditional way of doing things by doing a lot of planning upfront.

But then switching for the execution to the Agile style, with a duration because in the kind of project we’re doing, there are lots of unknown. And when it comes to project risk, risk management and unknowns, Agile is way better. And also, the waterfall project has one fundamentally flawed assumption, which is that at the beginning of the project, just ask yourself, do you know everything there is possibly to know about this project? You have 100% visibility all known? Of course not. But it’s assuming that you have not even started working, you have not written a single line of code. You have not done anything, but it assumes that you can make a perfect project. And I would go as far as saying that when there’s a difference between reality and the project plan. People tend to say that reality has a problem when they have their waterfall background.

Caspar: Yes.

Guillaume: Which is not the case and that’s where Agile comes in, in a very interesting way to say okay, the project plan is not going to be perfect. Let’s do sprints and let’s re-adjust the project plan at each sprint after every two weeks, three weeks or monthly if you do very big Sprint’s. So Agile is more aligned with reality for the execution for a project with lots of unknown. If you’re doing a very simple project, like going to the grocery, you don’t do Agile, you do the checklist and you do waterfall. But if you have unknown, uncertainty, complexity, risk, things to discover, you may do a first version, the first prototype and then the second version, you go Agile. And the other downside of this is, well, budget money, because how do you give a fixed price if the work scope is variable? Well, you can’t. That’s the simple truth.

Caspar: Correct. Well, and I think Agile tends to cause more scope creeping, without knowing it. I think when you fall away, when you first write down the actual plan, and then you spend a lot of time preparing things, and then you’re executing that plan. It’s like this blueprint of what you’re going to do, and it’s less prone to scope creeping. So you need educated people to prevent that. But I think it’s good what you mentioned as Agile Cowboys, I think that’s a nice term. Could be a company’s name, by the way.

Guillaume: I would not hire them.

Caspar: But what I want to point out is that merchants can do due diligence. No, they can have this conversation with system integrators asking how they approach the project, and basically, show the merchant how they do it. So not only telling them about Scrum and Agile and how grievous but also show them a previous run prep project. How was it actually prepared? How was it executed? How was it? And I think that’s what could really help merchants for not starting [Inaudible-00:27:05].

Guillaume: I agree with that, don’t tell the show, it’s like a confidential version, of course. They could just remove their clients name, or something like that, and show you that you can see what level of detail and management quality you can expect from this vendor.

Caspar: Yes, everybody makes mistakes but you know we all have successful brands, because we all have less successful projects. But in the end, I think how you act as a professional company is something that you could show to your merchants as well.

Guillaume: Great. Okay. What else in terms of having a successful project here? There are, of course, some technology choices. If we’re talking about integration, you have the difference between coding and no coding integration or low coding integration, you want to explain a bit what that is?

Caspar: Yes, of course. So when we were doing a lot of Magento projects back in 2009-2012, we needed to do a lot of integrations. And back then, we had a lot of traditional ERP systems, legacy ERP systems and we had Magento, who didn’t have proper web services, like stable, scalable web service. So there were a lot of performance issues. So what we did back then we created custom code within Magento.

Guillaume: Was that Magento One or Magento Two?

Caspar: That was Magento One. Yeah. So let me be clear, that was Magento One.

Guillaume: Right.

Caspar: And so we needed to create custom code to have to set up this connection, it is a point to point connection between Magento and the ERP system. But you know, when time passed, a lot of new solutions popped up. We started with two integrations and then the third integration came in a fourth and a fifth. And nowadays, like successful merges, they may have like six software systems, acting as a best of breed solution when it comes to information management, WNS, OMS, ERP and so on. So what really became a problem is that those kinds of integration, everything became like a spaghetti soup of health integration, it was a tangled IT landscape.

So that’s why we created Alumio as something that sits in the middle of all of these systems. We are the Data Broker, the data hub, there are a lot of terms, we call ourselves integration platform as a service. But it basically allows the user to not use code to set up these point to point integrations but set up an end to end integration via configurator. You don’t need to recreate or reinvent the wheel again. And if you look at Adobe, the platform, it’s a really functional rates platform. Yeah, I think it’s one of the most platform rich solutions out there. It really helps merchants to rapidly deploy their e-commerce site and to scale and run their business. But if you do all of these code changes, if you plug in a lot of extensions, and you’re creating this giant piece of software that makes it harder to maintain and hard to upgrade.

So I like to recommend merchants to stay lean and mean, and focus on codeless integrations. And that’s what we provide with Alumio: a way to connect to the API’s of Magento, connect to the web services of the other systems that may be a legacy system or a modern base system. And basically setting up this the central platform for the user to monitor integrations, to make changes, to add new car integrations, and so on. So yeah, if we’re talking about codeless vs coding, sometimes you need to change some things in Magento to tailor it to the business processes of a merchant, but I think there’s a pretty big shift towards keeping your Adobe Magento platform as lean and mean as possible.

Guillaume: Yeah.

Caspar: What’s your opinion about this?

Guillaume: Yeah, I agree with that. And of course, the main difference between the two systems is that one, you need to have a programmer to do all these integrations manually, those API codes, application programming interface codes between your e-commerce website and whatever system accounting system, ERP, enterprise resource planning, order management system, new IMS, and whatever else. But that’s a lot of risk of errors in the code, risk of maintenance, complications, and so on and managers have no visibility whatsoever into how this thing is built. So the benefits of the no code and low code approach is that you have a web interface that you pretty much just enter the login credential on both systems. And then you just choose click, drag and drop what it’s supposed to do, almost, if it was an automated marketing campaign, and MailChimp or active campaign, or some of those other software that you just drag and drop stuff. If this happens, this is the trigger, if a new order comes in, then send the order to the other system. And then you have something that’s visual that a manager or business analysts can visually review, if the business logic and the flow make sense. And you don’t need the programmer, as long as you’re in the no code approach like this in existence together, which is really, really interesting.

Caspar: You’re lowering the threshold for technical competence. And also for the system integrator, it’s much more convenient, because they have these lead developers, they used to do those kinds of integration, because you need those guys to set up this connection between Adobe and any kind of system. But if you can let them do the work that is so complex and interesting, and something special, then the lead developers are more happy. You’re not re-inventing the wheel, again, you’re removing repetitive work. You’re lowering the threshold for technical competence, because users can configure the integration. Of course you need technical use, and so that does not make it okay.

Guillaume: Yeah, it’s not magic. It’s not magic at all. It’s still there, even those click and drag kind of interface, you still need some technical knowledge that is a lot easier to handle [Inaudible-00:34:00] upon.

Caspar: Yeah, and as a system integrator, I think you can recall that when you deliver a project it goes into maintenance, and the integration stops working for what kind of like ERPs online or there’s something misconfigured whatever, you’re being the first ones to be called. Because the merchants don’t know what’s happening, because everything is connected like a black box. And so your support employees have been called and they are answering the phone, and they always need that developer to actually identify the issue and to resolve it. But if you can move that to a platform that shows logging information, displays monitoring, it will make it also much more convenient in the maintenance process.

Guillaume: Great.

Caspar: But do you also recognize that when there’s something going wrong with an integration that not the ERP vendor is being called, but you will always be called?

Guillaume: Most of the time, yes. It’s the case because they will call whoever did the integration and say, hey, my things are not synchronizing?

Caspar: Correct.

Guillaume: Most of the time, that’s when they’ll call unless they are able to diagnose more specifically.

Caspar: Well, at one time we had an SAP ECC integration and sometimes it failed. And it was a high performance website. So they processed around 2000 orders in the evening, between eight and 9pm. So they had these big moments during the day. And the SAP specialist, they were like no, the PAC is not down, and we were suspecting something like that. We didn’t know what was happening but sometimes the orders weren’t being processed. And the merchant was pointing the finger at us, and also the SAP partner was pointing the finger at us and it gave us headaches. And so we implemented the Alumio, and that gave us the ability to show the merchant that it was actually SAP ECC, underperforming and that it wasn’t available at certain times at the moment. And that gave us the ability to tweak the rate limit a bit.

Guillaume: That gave you visibility and traceability?

Caspar: Yeah, and that gave us a lot of confidence. And also the version by the way.

Guillaume: Yeah. Because otherwise, if you don’t have that traceability log system whenever it’s he said, she said, who knows which system was down or not responding or having rate limits issues.

Caspar: Right.

Guillaume: Okay. But I see a lot of benefits there knowing a project risks having a low code or no code platform, because you don’t get so much into the unknown, and you’re not dependent on just the knowledge of one programmer. Even if you hire a company, you typically have maybe two programmers who are still working on the project, unless it’s absolutely enormous. And like over a million dollars, you could just have like two guys working on this. So at that company, you will typically have two guys who know how your integration works, more or less. And that is if you have to, but then you might have only one. So that guy leaves that company, sometimes it could be loss of knowledge, and we want to prevent that.

So for sure, you will want to ask for documentation of everything in the project. That’s another thing to protect yourself. So in an e-commerce system, you want documentation for every module. So every module that exists, why does it exist, because sometimes just the name is not enough, it has repercussions elsewhere. You have full documentation of everything and the ERP documentation on a general scale, how it’s working, to which system it’s connecting, which system is pushing to, which system is pulling from, which system and which frequency, you want to have some kind of a reporting here a few pages of documentation of how the system works. That’s another important point to ask yourself in this kind of project.

Caspar: Also for merging because you know sometimes like an e-commerce manager, or a product owner, they leave the company, and the merchants hire a new product owner, a new e-commerce manager, and that happens quite often. And I had several conversations with new e-commerce managers or e-commerce directors telling me that, I have this list of user stories and I have no idea what actually has been delivered or what is happening right now. So for business continuity, and reducing risk, it’s also very important to have this documentation reporting at hand.

Guillaume: Great. So that sort of ties in with the initial project plan, we were talking about having an amazing project. But once the project plan is built, it needs to be kept up to like, what is the status for each of those tasks? Is it completed? I’ve heard some horror stories from other places there that, for example, the merchant and the provider wanted to part ways, but then it was unclear what percentage of the project was completed or which tasks were completed. They had sort of worked in a haphazard way, all across the thing without any clear structure. So proper management regardless if it’s Agile, or Waterfall hybrid, though, which is a mix of both, you would have planning as to what’s going to be worked on for the next phase or the next milestone or gateway of the project, or an Agile, we’ll call it the next sprint.

So let’s say for the next three weeks here is what we’re going to be working on, and this is communicated. And then when it’s done, there’s a status update. This task is completed pending client approval, let’s say completed and approved by client and so on. And you’d have a proper tutorial structure of all this that’s going on, very important. So you’ll also want to know the reporting frequency of the vendor. Ideally, you should have at least one status update per sprint at the minimum. The sprints can vary from one to four weeks more than four weeks, not a sprint anymore than in the Agile framework. That’s a minimum. If you can go to a weekly report, status updates and progress updates that is the best.

Caspar: I absolutely agree. It also prevents clarities that are not recognized in an early stage and over time, it becomes like a problem. So I absolutely agree. Although in practice, this tends to be quite difficult.

Guillaume: Yeah. And it tends not to be done and when the team is under pressure and they’re short on time, that’s typically one of the things they can start to skip. And then you lose the view on the project, one of the first things for sure is that the data is much, then you don’t know what’s the status with that stuff. They will skip the step of sending the reporting to the client or giving the visibility to the client, [Inaudible-00:41:09].

Caspar: Well and to give a little bit more context for the merchants, putting deadlines and time pressure on the projects, usually results in exceeding budgets.

Guillaume: True.

Caspar: And I think that’s something that a lot of merchants don’t realize, is that they set a clear goal. We want to have our new e-commerce website be deployed before Black Friday, four weeks before for just that example but two days before.

Guillaume: That’s a good example, it’s a realistic one. You want like one month before Black Friday.

Caspar: Fair enough. Fair enough. It’s actually quite relevant. So one month before Black Friday everybody is starting to push to that date. So the project manager tries to keep up that you can’t do the reporting. They’re trying to prevent scope creep, the wrong decisions are being made and usually it results in that you’re not going to reach that date, you’re going past the Black Friday, and that’s going to be spring, summer and this is just very, very relevant. And so it feels like, I think, strange and unusual for a company or an entrepreneur or Sealevel to have a more flexible date. But usually it results in a better project execution.

Guillaume: I agree with this. And let’s analyze this in a more fundamental way. Like what are the things that can change in a project? Let’s say you have the budget, you have the timeline, and you have the profit margin of the vendor, pretty much in three things that you have here. So if you know, the amount of work increases, the timeline needs to also change. If the timeline does not change, then it means the vendor needs to deploy additional resources, staff and effort to meet that timeline and that is not necessarily always possible. Very often it will be that the vendor will start eating in his margin. But there’s a limit to how much of this you will be willing to do, of course. So then you will start to do some pushback, and because there’s pressure, let’s say we have a case of exaggerated pressure for a specific date or deadline, you will have other issues that you cannot optimize for everything. You know, but I’ll just do a parenthesis, maybe to better illustrate this thought, you have this concept in business that, are you offering quality or low price or convenience slash fast service? So, which of those are you offering, you can only pick one hole, and then you can have a secondary, but you cannot have the third.

Caspar: You can’t be all three of them.

Guillaume: No, you cannot be the lowest price in the market with the highest quality and the fastest service. That’s impossible because somebody else will say, I will offer better quality, but my price is going to be higher. And I can therefore afford to scale the business with a higher quality product. The same is true for convenience or speed, the same is true for lower prices.

Caspar: It’s a magic triangle.

Guillaume: Exactly, so it’s the magic triangle. Again, it’s the same thing. So here you’re pushing and pulling on the timeline and budget. So if you want to use your budget in the most optimal way possible, it means that you need to have flexibility on the other aspects, you need to have flexibility on the time. You cannot have a variable work scope with a fixed budget and a fixed timeline that does not work, it tends to be an unrealistic expectation. So because there’s always scope creep is always last minute requests and new things and really work. And also, if there’s too much pressure, there are lots of time consuming validation that are just time consuming on the timeline but they’re not very long to do. So, oh let me just open this, wait for the result, wait for the other provider to give me a confirmation, for an expert to give me a confirmation. And then we will do the proper action based on our findings, but that will take a few days.

So if you’re stressed with the timeline, you cannot take your time to burn as little budget as possible, because you don’t have time to wait. So you just think of the best hypothesis and you run with it, even though it’s the wrong one. And then that causes rework and inefficiencies and all kinds of problems. So you cannot have everything basically. So you choose only one, which one do you want to optimize? Do you want to optimize the timeline? Or do you want to optimize the budget? So if you say, I want absolutely for that day, then this is firm, then either you start to plan a lot of events, and then maybe with a lot of padding and buffers and several months of buffers, then maybe you can focus on optimizing your budget for a long time. And then maybe if you’re lucky, you still have enough to plan long enough ahead, that you can meet your deadline comfortably without stress, because you’ve added yourself plenty on the timeline to meet your objectives.

Caspar: Yeah, so what I realized is we worked with minimal viable products. So because I think a lot of the time the scope can be downscaled easily when managers, directors and sea level can make realistic decisions, and quick decisions. So I really like minimal viable products, but usually that is not sufficient to launch a product. Usually, it’s odd to me. I had a lot of discussions with Scrum masters about that, that actually the customer should deploy a minimal viable product. And there are some ways to do it.

So for example, if a merchant is re-platforming, and they have like this main domain with a Magento site, and they’re going to re-platform or whatever they’re going to play with, but from another platform to Magento, you’re going to deploy a new domain with a subset of the products, with a subset of the marked target audience, and then you can launch a minimal viable product. But then you have the ultimate goal. But there’s a huge gap between the minimal viable product and the actual desirable product. So we introduced a new term, which was called minimal lovable product.

I really liked that one, because it was somewhere in between, and it made a very nice conversation about okay, this is the ultimate scope. But what is actually the right scope for you to have this thing that you can love?

Guillaume: Great.

Mchael: So I think, down-scoping, a lot of merchants find it very hard to do. And, by the way, a lot of system integrators as well. I really love to down scope, I love it, I do it in everything. Also in building up my business I down scope all the time, because it helps me accelerate and keep things maintainable and scalable and future proof.

Guillaume: Very good point and the minimum viable product, I’ve seen various definitions or confusion going on in the marketplace about this. So the official definition from the Agile world, if you do your Agile certifications as a scrum master product owner, it is a commercially viable product. So it’s not some kind of half baked prototype here that we’re talking about that can die. Don’t try to break something, it’s a commercially viable product that you’ve simply removed some features from. But whatever you’re building is a professional grade product and it’s complete in itself, you just have fewer bells and whistles.

Caspar: Let’s make it very concrete. Let’s say that a merchant has four payment options. If they would launch, like a specific site, a niche website for a certain target audience with a subset of his products. You can only have one payment option that will be sufficient for that specific website. That could be your minimum viable product. It doesn’t need all [Inaudible-00:49:29].

Guillaume: You’re operational, you don’t need the other one to go live. Most merchants will be firm on, ‘I want all four because I want to maximize’ but that’s the maximizers mindset rather than ‘let’s accelerate this project’ mindset.

Caspar: Correct.

Guillaume: And accelerating I believe is the correct mindset.

Caspar: Yes. I absolutely agree. So, yeah. It’s nice to share those ideas and experiences that I had over time with this subject.

Guillaume: Agreed, and there’s a lot that comes back again to the project plan I was talking about, than just the upkeep of it. For example, if you put the time and material type of project and not flat rate, or even if it’s flat rate will typically be flat rate per module and not globally, don’t buy a huge project with a global project plan price, that doesn’t make any sense whatsoever. It will end up in conflicts. So, it is a good idea to use time and material to track module per module, the actual versus the estimate. So both for the internal use of the merchant and for the internal use of the other provider. So this way we can have an honest conversation, then you can also see what’s the bias of the original estimate. Are you going to have some forecasting on the budget being exceeded or does it look like the estimates were reasonably realistic or they were off by let’s say, 20%, or something like that? And then you can have some discussion with your provider. Well, it seems like your estimates are about always 20% off, like, are you kidding me like a flat rate? Or do we remove a few scope items here and there? Or how do you manage that? You can [Inaudible: 00:51:40] see it and have that discussion ahead of time.

Caspar: I really like transparency. So we started with the first word that popped up, which was people and people need to collaborate, the merchant and the system integrator and the team. And being able to collaborate you need to become like an entire team, you need to understand each other, speak the same language. So if you’re transparent, and you allow the system integrator to exceed certain budgets, but also to learn and to perform better, then it really helps in ramping up the collaboration, when there’s trust. Because in the end, you need to trust the system integrator. And the system integrator needs to trust the merchant. And when there’s trust, you can allow exceeding a budget of a certain, like detail part of the project. But you can also help each other to perform better. Well, I think it’s increasing velocity. I think that’s the correct aspect.

Guillaume: You have to check that. Yeah, to increase the velocity you become more and more productive, but for sure, with this you need some kind of a safe environment for trust on both sides that you can speak and then discuss concerns and so on. And you can have some courageous conversations. It’s very important not to hide under the rug or any kind of problems there to have the courage to speak up, the vendor that has that you can see it in the trades. And the same thing for you as a merchant that you voice it up. But again, without creating a dark atmosphere here, that it stays a positive escalation, a positive discussion, a positive conversation in a building of trust in a safe zone for discussion.

Caspar: I think, yeah, I think positive escalation is one of the things when system integrators use the term escalation. It’s usually way past the point where you should have done the escalation. I used to call it proactive escalation. So I would rather call a customer to tell them that this may go wrong if you don’t do anything, than to wait until it happens, and then call him that it actually happened. We both know that it happened, of course. So I think positive escalation is also something that a system integrator can stimulate within the company. Help each other to speak up. If somebody sees something going wrong, internally, do escalate it. I always tell my colleagues to escalate to me. Let me know as soon as possible when things tend to or may go wrong, so we can change course.

Guillaume: Another point, I guess would be here, future proofing. So any tips or advice here on future proofing investment that you’re doing in [Inaudible-00:54:22]?

Caspar: Yes. So to me that’s trying to avoid unnecessary customizations. Get the best out of the core platform, create integrations and that’s what we try to tell. That’s always our story to explain that you can create integrations that are future proof, that allow you to connect with the ERP system, but also gives you the ability to change that ERP system into a new year, pieces small at a time without redoing the entire integration. So I think future proofing has a lot to do with making the right technology choices, implementing it the correct way. And, I think making sure that the knowledge is not disappearing.

Guillaume: Yeah, that’s a good point. For example, with Alumio here, as you’re saying, let’s say you have your e-commerce Magento system connected to Alumio, and now Alumio is connected to the ERP. If you were to change the ERP, your Magento connection stays all in place. And you just change the connection to the ERP, if you did not have a system like that, let’s say it was direct point to point integration Magento to the ERP, the whole thing goes to the trash usually. And then the new ERP needs to be connected and you sort of start over more or less on your full investment of VoIP connection. Sometimes there is a part that can be salvaged, but typically not that much in the point to point integration.

Caspar: Not every middleware solution, but a middleware like Alumio allows you to set like, agreement within the middleware platform. So, we call them entity schemas. It’s an agreement on a data structure. And if you commit to that data structure, it allows you to plug in a different ERP without needing to recreate the entire integration. There are a lot of middleware, while it’s not actually the middleware, if you misconfigure it, you’re still creating the integration and that’s not what we want. I think that would be my recommendation. Yeah. I forgot one thing, it’ll pop up later.

Guillaume: Well, here’s one more best practice in this case would be to schedule a recurring meeting cadency, that’s always happening at the same day at a time. So if that project is big enough to meet weekly, just for a weekly check in with a vendor like that. So you could say every Wednesday at 3pm, we’re meeting every week. This could be for five or 15 minutes, just to say hello, if there’s nothing for that week, and then we go back to work. But typically, there will be a few questions and instead of doing all kinds of interruptions, we can pile them up, clear them all up in one work session. And in this way, there’s a close connection with both provider and client there. In addition to all the status reporting and sprint planning for work and work demo.

Caspar: Yes, and what I would recommend is to also include other relevant parties. So well, since I left the agency as system integrator I would have started with the product business, with a middleware platform, you usually involve different vendors. Like the system integrator, the ERP partner, some kind of other services, three PL software, and of course, the merchant. But I think a lot of system integrators overlook that. So they are requesting these weekly meetings. But it’s without all of the stakeholders that are involved. All the companies and the people. So if it touches the ERP, you need to ERP guys in that meeting as well.

They may not say a word. But as soon as there’s like one thing that touches the processes of the ERP, you want that clarified right away. I would recommend involving as many parties as possible. It’s not always possible, but it benefits the progress.

Guillaume: Yeah, exactly. And, of course, you’ll have different meetings with different teams so that you don’t have to invite too many people on the table at the same time, and to be more efficient. But yes, you want to have multiple angles of view on the same problem. And the same thing if the city e-commerce for the planning of it, at one point, it is a good idea if the company is large enough to add a 500 employee company here. Good idea to have a meeting with the head of sales and the meeting with the head of marketing and the meeting with every department head like this, to be sure that everybody’s needs are covered in the plan. Because otherwise what tends to happen is okay, the vision came from let’s say one of the founders or whatever he was dedicated to the project, didn’t ask anybody’s opinion on what they needed for the project. We build the whole thing. And then when it’s built and it goes to quality control and for feedback for the merchant at the end of that, say a six month or one year project, whatever and then the sales rep says hey, when we do our sales, we need this and that. So I totally agree with these two, so proper discovery and planning at the beginning, even if some of those features don’t make it at least it was analyzed that this is not a business priority or it is a business priority is going to make it to the bill.

Caspar: Or if you’re setting up a new business unit, or you’re involving these business units, it will touch different departments within the company. So you need to have everybody involved in a certain way to get the best out of the project and out of the actual delivery. And when you want to change processes, you need to change people. And if you’re changing people, that takes a lot of time and effort, so the sooner you bring them in, the more effective it’ll be.

Guillaume: Right. Another best practice here is on both sides. So of course, the provider must do this, but the merchant should still keep an eye on it as well, because it’s a gauge for success is that any work that is done should be truly 100% done for this specific module or tasks that you don’t need to revisit later. Because then it will not be fresh in your mind anymore, you’re ready to get back into it is extremely inefficient. So if we’re talking again, your example of a payment method, maybe the project plan had up to four payment methods. If you’ve decided that it’s only going to have one payment method, well, this one should work completely flawlessly, and no more changes are needed to it, then you’re truly done with it.

Caspar: Back and forth.

Guillaume: Yeah, exactly before you move on. Or you just carry that to the next sprint, the changes needed to it and then you’re truly done with it into sprints. And then when you really build section by section like this for a whole project. It’s a way cleaner project. I sometimes give an analogy, it’s not perfect, but it’s good enough that if you’re doing renovation in your house, you don’t start with renovating a little bit the kitchen a little bit the living room a little bit your bedroom, and it’s gonna be messy all over the place. You start one section and you finish it.

Caspar: A lot of people do by the way, let’s be clear.

Guillaume: Well, that’s how most projects are built. So like start with one section and fully build it correctly to the scope that you decide. One payment method or four, you decide how far you go. And it’s going to affect the budget, of course, but fully finish with it first.

Caspar: That’s why phasing the project is very important, because a lot of times a phase includes multiple sub-projects. And if you’re, if you create correct phases, you also see that some may touch each other. So if you’re going to change something on the left, that may impact something on the right. And that’s where you want to create the right decisions and in creating phases of a project. And even with an integration project we usually phase, so we can really mark something as done. So this is tested, thoroughly tested, everything is 100% sure working as expected, we can leave that alone. Leave it as it is.

Guillaume: Exactly. And update the status of the project so they plan properly about it.

Caspar: Yes. And then mark it later.

Guillaume: Yeah.

Caspar: It’s nice to check things right?

Guillaume: That they have something solid there. Yeah, it’s pretty good coverage of the topic. Anything else that comes to mind?

Caspar: Well, I think we could talk about this topic all night, all day, for several hours. I think we covered a lot of valuable things. I hope that the merchants, the companies who do things with e-commerce, that it benefits them. So, I think we can wrap it up and hopefully, it helps them.

Guillaume: Yeah, it’s true, we could talk about it for a very long time, the specification to which you’re building something is one of the main elements that changes the price. Because when you look at it, yes, the website is beautiful. But once you’ve paid enough with a talented designer, they’re all beautiful at one point. Then it’s a question as to which specification is it built? For example, does it need to have accessibility for disabled people with the problem with sight or only blind people? Does it need PCI compliance and all those things? And okay, what about the loading speed on some platform like Shopify? It will be somewhat universal, but on a platform like Magento, you will have options for loading speed based on the template that you’re using, based on the technology. Do you want the classic build? Do you want the PW, a progressive web app builder, something that ‘s going to affect the price of the specification to which you’re building something? It changes the price tag a lot. So be careful when you’re comparing quotes. Okay, you’re going to do this but more details like which degree? Where are we going with this? What’s the security on this? and so on.

Caspar: Don’t go with fancy terms and new fancy technologies right away. It’s sometimes good to be a little bit conservative.

Guillaume: I like to be ahead of the curve, but not too ahead. I don’t want to be the first

Casar: Yeah.

Guillaume: The second batch of early adopters when they’ve reworked it a bit.

Caspar: It’s good to be progressive, but wait a little bit.

Guillaume: I agree. We do that a lot for versions of dates. That’s for later, was the website online? When the new version comes out, it often has bugs. So we wait for the next patch.

Caspar: For the 0.1 version.

Guillaume: 0.1 is the preferred version typically.

Caspar: Yeah.

Guillaume: Exactly. All right, Caspar, thank you for this great discussion, and very valuable insight here that can help merchants manage projects of several hundreds of millions, or hundreds of 1000s of dollars, the goal short of the million, and a small project as well like the 10k, and so on. So, it makes a huge difference, I believe people might not even realize the value of what is packed into this specific podcast episode.

Caspar: I hope they recognize it.

Guillaume: I hope they do because this is huge. All right. So thank you, Caspar, thanks for being here.

Caspar: Thanks for having me.