A transformation only succeeds if business, technology and data move forward together

A conversation with Vincent Delamarre and Remi Poujeaux, co-founders of Pelago. Interview by Sylvain Melchior (Boldo).

Pelago works with mid-market companies and large enterprises. On the other side are the people who drive transformations: Chief Transformation Officers, programme directors, heads of a new offering. What they have in common is that they are accountable for success. We spoke with the two co-founders about their journey and about how they get teams that usually communicate little to work together.

Hello Vincent, hello Remi, thank you for your time. Could you introduce yourselves and tell us how you met?

Remi: With pleasure. I am the technical director and co-founder of Pelago. I started out as IT manager at Schneider. My role was to integrate the companies the group acquired in Japan, so a lot of management-system projects. I then moved to the global CRM project, and that is where I met Vincent.

Vincent: For my part, I am the co-founder in charge of business. Engineer by training, but I handle sales and strategy. We met in 2009, when Remi had chosen Salesforce over SAP for Schneider's global CRM. We ran that deployment together, twenty times faster than the group's other entities. From that time on, we were convinced of one thing, which has since become Pelago's DNA: a project only succeeds if business, technology and data progress at the same pace. As soon as one of the three falls behind, the whole thing seizes up.

Twenty times faster, that is considerable. What was the method?

Vincent: Four principles, in fact.

The first is always coming back to the question "why are we doing this?". Not the technology, not the tool: the business objective.

The second, reasoning from the point of view of the people who will live through the change, whether employees, customers or suppliers.

The third, breaking a large problem into steps that can be delivered one by one, rather than aiming for a single deployment that never arrives. And a monolithic architecture into autonomous units.

The fourth, not siloing the teams. Rather than a large technical team on one side and a large business team on the other, for each topic we form a small team that brings the two together.

Remi: For this to hold, everyone must know at all times who does what and which systems talk to each other. We had built an internal tool for this at Schneider. The difficulty is that this mapping work is often seen as an IT matter, theoretical and far from the field. We connected it to the business on one side and to projects on the other. That is exactly what we implemented in Pelago, with our Transformation360 model.

How would you explain Pelago to someone discovering it?

Vincent: The most telling thing is people's reaction. An IT architect looks at Pelago and says "it is an architecture tool". A project manager looks at the same thing and says "it is a project management tool". In reality, Pelago sits precisely between the two, where these roles rarely communicate. Today, to make that link, everyone builds a PowerPoint or an Excel by hand whenever they need to explain where a project stands. We pull the information directly from the source and keep it up to date automatically. As a result, everyone sees where they stand in the overall project, without redoing the presentation at every meeting.

And where do you go to find that information?

Remi: Three main sources. The tools that describe the company's systems. Data catalogues, which often exist but that no one opens, when all you need is to know who is responsible for customer data and where it is. And project-tracking tools like Jira. In a large company, one team works in Jira, another in a different tool, and the deployment teams manage everything in Excel. We bring it all together in one place, with a common vocabulary. And when a piece of information exists nowhere, you enter it directly in Pelago: it is never an obstacle.

You place a lot of importance on managing AI agents. What is at stake?

Vincent: At first, we treated an AI agent like an employee, exactly like a human agent in a call centre. We quickly found that this model did not fit. An AI agent is not quite a person, nor a project, nor a system. It is a new kind of entity, that must be managed in its own right.

Remi: Its lifecycle resembles that of a piece of software: you test it, you launch a pilot, you deploy it, and sometimes you shut it down because it is no longer useful. The difficulty is that today agents are multiplying: each department has created its own in isolation. So the first step is to draw up an inventory. Then, for each agent, we answer four simple questions: what is it for on the business side, which project delivered it, what technology does it run on, and what data does it access? That is precisely what we built with Agentic360.

Vincent: And above all, we assess it continuously: what it brings, what it costs and the risks it creates. A leader already manages budgets and teams; tomorrow, they will have to manage a portfolio of agents in the same way. The underlying questions are real. The cost of using AI changes constantly. Geopolitical issues also arise: am I allowed to use a given AI or not? You then wonder, for example, about what happens if you can no longer rely on a model and have to switch to another. You have to keep control, while keeping up with AI's very fast pace.

How do you manage to get such different profiles to talk to each other?

Vincent: We build a living representation of the project, which shows four dimensions at the same time: the business (with its personas and processes), projects, technology and data. Each person views it from the angle that concerns them. The project manager wants to see the risks. The data owner wants to know what they must make reliable so the agents work. The business owner wants to know what will improve customer satisfaction. It is the same representation, but each finds their answer in it.

Vincent: It also flags difficulties on its own. It can indicate that a project is at risk, or that another is purely technical and disconnected from the business, which is a warning sign. Architects tell us that, for the first time, their work becomes visible. Above all, it saves them from being called in urgently, the day before a launch, to validate a topic they are discovering.

Do you have concrete examples of situations where you step in?

Vincent: The most frequent case is a manager who tells us: "I have launched a large project, my teams are already exhausted while we are still defining the requirements, and a one-shot deployment worries me." Another situation: a group IT director who observes that his teams, country by country, do not apply the same best practices. We also work on the shift to online sales, on CRM projects and, of course, on AI-related projects.

Remi: The platform is very flexible. One client even uses it to manage its technical schedules and arbitrate calendar conflicts between projects. That was not the original intended use, but it works very well.

Remi: Fundamentally, we act as a reference source for AI on everything related to transformation. AI sometimes struggles to keep the thread and stay consistent. We give it a reliable base from which to draw the right information.

A final word: any new developments for the coming months?

Vincent: We avoid big announcements in advance. The platform is solid, it is the fruit of our first two years. We now evolve it at the pace of our clients' real needs, and not according to a theoretical plan.

Thank you both for this conversation.

To find out more about Pelago and Boldo: https://pelagosoftware.com/