Akeneo PIM Project Recovery for a B2BEquipment Distributor

Context

In 2021 and 2022, before founding Doctor Project, I was the project manager on the agency side of an Akeneo PIM project for a B2B distributor of professional equipment. I coordinated the development team and the PIM expert of an integrator agency, and I was the day-to-day contact for the client's teams.

The PIM had one main job: feed the distributor's B2B e-commerce site with complete, consistent product data for a catalog of more than 50,000 products. For a professional buyer, that data does the work of a sales rep. Technical attributes, compatibility, units and documents decide whether an order is placed online or a phone call is made.

When I joined, the project had already consumed more than its planned budget, and the goal was still out of reach.

The challenge

Two things had pushed the project off course. First, the data model had been reworked while the build was already underway. Families, attributes and variants changed after imports, rules and exports had been built on the previous version, so finished work had to be done again. Second, the scope had never been pinned down. New needs arrived as tickets, nobody owned the decision to accept or refuse them, and the backlog grew faster than the team could deliver.

The result was hundreds of open tickets, many duplicated or outdated, and no shared view of what was left. Acceptance testing kept reopening topics because nobody had agreed on what "done" meant, and trust between the client and the delivery team was low. It was like a waiting room where every new patient takes a number, but nobody checks whether the earlier ones already went home.

What we did

• Counted what was really left. We cleaned more than 300 tickets: closed what was done or obsolete, merged duplicates, and rewrote what was still needed in plain language.
• Froze the data model. We validated one version of the families, attributes and variants with the client. After that, any change went through a written request showing its impact on the backlog, so the model stopped moving under the build.
• Prioritized with the client. We sorted the remaining backlog with the MoSCoW method: what must be there for the B2B site, what should, what could wait. Scope talks became a choice between items instead of an open list.
• Tested on reference products. We picked a set of real products covering the hard cases of the catalog and used them to validate the model, the imports and the export to the site before each delivery.
• Changed the acceptance strategy. Each delivery was tested against criteria agreed in advance, instead of being reopened open-endedly.
• Upgraded the platform. We framed and delivered the Akeneo version upgrade the platform needed.
• Reviewed remaining work together. Regular reviews meant both sides saw the same list and the same priorities.

Result

Within 6 to 12 months, the project was back on track. The Akeneo upgrade was completed, and the remaining backlog was reduced to a list that both the client and the agency had agreed on. Meetings moved from discussing who was at fault to deciding what came next.

What I took from it

Recovery starts with honest triage: before adding effort, you count what is really left. And a data model that keeps moving will consume any budget, so freezing it with the business is not a technical detail. It is a project decision. These are the first two things we check in a PIM audit today. If your PIM project is drifting, how to manage a PIM project without losing control covers the early signals.