Kort antwoord
Een PIM-projectplan legt zes onderdelen vast: de scope van de eerste release, een fasering met mijlpalen, het team met rollen en inzet, een risicoregister, een budget met reserve en een communicatieritme. Prioriteer de scope met MoSCoW, plan een middelgroot project indicatief op 20 weken tot go-live en koppel elke mijlpaal aan een meetbaar opleverresultaat.
Een goed PIM-projectplan maakt in één document duidelijk wat de eerste release oplevert, wanneer, door wie, tegen welk budget en met welke risico's. Stel het op in de eerste twee weken na de kick-off, laat de stuurgroep het goedkeuren en gebruik het daarna als toetssteen voor elk besluit over scope of planning.
Het plan bestaat uit zes onderdelen: scope, fasering, team, risico's, budget en communicatie. Dit artikel geeft per onderdeel wat u vastlegt, met een indicatieve weekplanning die u kunt aanpassen aan uw eigen project. Het overzicht van alle fasen staat in de gids voor PIM-implementatie.
Wat valt binnen de scope van de eerste release?
De scope is het belangrijkste onderdeel van het plan. Beschrijf wat release één oplevert en, even expliciet, wat naar release twee gaat. Prioriteer met MoSCoW: Must, Should, Could en Won't have this time.
Het Agile Business Consortium, de beheerder van de DSDM-methode, adviseert om Must haves op typisch niet meer dan 60% van de totale inspanning te houden en circa 20% Could haves te reserveren als buffer. Bij tegenvallers schrapt u eerst Could haves, zodat de go-live-datum blijft staan.
| Prioriteit | Typische onderdelen in een PIM-project |
|---|---|
| Must | Datamodel voor de belangrijkste productfamilies, ERP-koppeling voor stamdata, webshopkoppeling, basisworkflow voor verrijking en goedkeuring, migratie van de actieve catalogus |
| Should | Importtemplates voor de grootste leveranciers, dashboards voor volledigheid, tweede taal |
| Could | Extra kanaalfeeds, AI-ondersteunde tekstsuggesties, uitgebreide rapportages |
| Won't (release 1) | Marktplaatsintegraties, printpublicatie, koppeling met een apart DAM-systeem, volledige meertaligheid tenzij bedrijfskritisch |
Leg de eisen uit uw programma van eisen naast deze indeling. Elke eis krijgt een prioriteit en een release, zodat de implementatiepartner precies weet wat in welke sprint valt.
Hoe ziet de planning eruit?
De weekplanning hieronder is indicatief voor een middelgroot project met één ERP-systeem, één webshop en twee tot drie talen. De fasen overlappen bewust. Configuratie verloopt in sprints van twee tot drie weken; de Scrum Guide (november 2020) schrijft sprints voor van een maand of korter.
| Weken (indicatief) | Activiteiten | Mijlpaal en opleverresultaat |
|---|---|---|
| 1 tot 2 | Kick-off, scope, team, risico's, ontwerp op hoofdlijnen | Goedgekeurd projectplan |
| 2 tot 4 | Datamodel, workflows, rollen en interfacecontracten ontwerpen; brondata profileren | Functioneel en technisch ontwerp |
| 4 tot 12 | Configuratie in sprints, integraties bouwen, importtemplates opzetten | Geconfigureerde testomgeving met werkende koppelingen |
| 4 tot 16 | Opschonen, mappen, proefmigratie 1 en 2 | Gevalideerde dataset in de testomgeving |
| 12 tot 15 | Eindgebruikerstraining | Getrainde gebruikers vóór de UAT |
| 13 tot 18 | Functionele tests, integratietests, performancetest, UAT | Go/no-go-advies |
| 19 tot 20 | Cutover, definitieve migratie, livegang | Operationeel PIM |
| 20 tot 24 | Hypercare en overdracht naar beheer | Getekende overdracht |
De werkelijke doorlooptijd hangt af van het aantal integraties, het datavolume, de datakwaliteit en de beschikbare interne capaciteit. Herzie de planning na de eerste dataprofilering in week drie of vier. Dat is het eerste moment waarop u ziet hoeveel opschoonwerk er werkelijk ligt.
Welke rollen heeft het projectteam?
Leg per rol vast wie het is, wat de verantwoordelijkheid is en hoeveel tijd de persoon beschikbaar heeft. Zonder vastgelegde inzet lopen interne mensen achter zodra het dagelijkse werk voorrang krijgt.
| Rol | Verantwoordelijkheid | Indicatieve inzet |
|---|---|---|
| Business sponsor | Mandaat, budget, beslissen over escalaties en het go/no-go-besluit | Stuurgroep elke twee weken |
| Projectmanager | Planning, budget, risico's, rapportage, coördinatie met de partner | 50 tot 100% |
| Functioneel lead of product owner | Datamodel, workflows, rechten, kanaalconfiguratie, backlog | 50 tot 100% |
| Technisch lead | Integraties, migratie, omgevingen, beveiliging | 30 tot 80% |
| Data stewards | Domeinkennis, validatie van het datamodel, opschonen, testen | 20 tot 50% per persoon |
| Implementatiepartner en leverancier | Configuratie, bouw, productadvies, escalatie bij de leverancier | Volgens contract |
Bij kleinere projecten combineert één persoon de rollen projectmanager en functioneel lead. Combineer de rol van business sponsor nooit met die van projectmanager: de sponsor moet onafhankelijk kunnen beslissen over scope en budget.
Hoe beheert u de risico's?
Neem een risicoregister op met per risico de kans, de impact, een preventieve maatregel, een maatregel bij optreden en een eigenaar. Bespreek het register elke twee weken in de stuurgroep. De vijf risico's die in vrijwel elk PIM-project terugkeren:
- Scope creep. Maatregel: elke nieuwe wens via een wijzigingsverzoek met effect op planning en budget.
- Slechtere datakwaliteit dan verwacht. Maatregel: profileer de brondata in week twee tot vier en reserveer opschooncapaciteit. Zie productdata migreren.
- Integratievertraging. Maatregel: leg interfacecontracten vroeg vast en bouw de ERP-koppeling als eerste.
- Capaciteitstekort bij interne mensen. Maatregel: leg inzet vast in het plan en regel vervanging voor dagelijks werk.
- Lage adoptie. Maatregel: betrek key users vanaf het ontwerp en meet na go-live het gebruik.
Microsoft waarschuwt in zijn governancerichtlijnen voor Dynamics 365 dat training bij druk op planning of budget een van de eerste onderdelen is die sneuvelen. Neem daarom ook het inkorten van test- en trainingstijd als risico op.
Hoe stelt u het budget op?
Splits het budget per kostensoort en per fase. Gangbare kostensoorten zijn de PIM-licentie of het abonnement, de implementatiepartner, interne capaciteit, connectoren of middleware, training en een reserve voor onvoorziene kosten. Een indicatieve reserve is 10 tot 20% van het implementatiebudget; neem meer op bij meerdere databronnen van wisselende kwaliteit.
Vergelijk de werkelijke besteding elke twee weken met het budget. Koppel het budget aan de verwachte baten uit uw business case voor PIM, zodat de stuurgroep bij elke wijziging ziet wat die doet met de terugverdientijd.
Welk communicatieritme werkt?
Leg vast wie wat wanneer hoort. Een werkbaar ritme:
- Wekelijks: statusoverleg van het projectteam met de implementatiepartner.
- Elke twee weken: sprintreview met key users en stuurgroeprapportage met voortgang, risico's en besluiten.
- Maandelijks: korte update aan de bredere organisatie over de planning en wat er voor medewerkers verandert.
- Bij mijlpalen: gerichte berichten bij ontwerpakkoord, start van de UAT, go-live-datum en einde hypercare.
Koppel de communicatie aan het change-managementplan, zodat de boodschap over het waarom van het project vanaf de eerste week consistent is.
Belangrijkste punten
- Een PIM-projectplan bevat zes onderdelen: scope, fasering, team, risico's, budget en communicatie, en wordt binnen twee weken na de kick-off goedgekeurd.
- Prioriteer de eerste release met MoSCoW en houd volgens de DSDM-richtlijn ruimte in de Could haves om tegenvallers op te vangen.
- Een middelgroot project plant u indicatief op 20 weken tot go-live, plus hypercare; herzie de planning na de eerste dataprofilering.
- Leg per teamlid de inzet vast en neem capaciteitstekort, ingekorte testtijd en lage adoptie op in het risicoregister.
Veelgestelde vragen
Wat staat er in een PIM-projectplan?
Een PIM-projectplan bevat de scope van de eerste release en wat expliciet buiten scope valt, een fasering met mijlpalen en opleverresultaten, de teamrollen met inzet in uren of percentages, een risicoregister met eigenaren, een budget per kostensoort met reserve, het communicatieritme en de acceptatiecriteria waarop het go/no-go-besluit wordt genomen.
Hoeveel mensen heeft een PIM-project intern nodig?
Indicatief drie tot acht mensen: een projectmanager, een functioneel lead of product owner, een technisch lead, een tot drie data stewards en eventueel een developer of integratiespecialist. Daarnaast is een business sponsor nodig met mandaat over budget en scope. De implementatiepartner en de PIM-leverancier leveren aanvullende capaciteit volgens contract.
Hoe voorkom ik scope creep in een PIM-project?
Leg de eerste release vast met MoSCoW en houd Must haves volgens de DSDM-richtlijn op typisch niet meer dan 60% van de inspanning. Laat elke nieuwe wens via een wijzigingsverzoek naar de stuurgroep gaan, met effect op planning en budget. Wensen die niet kritiek zijn voor go-live gaan naar de backlog van release twee.
Hoeveel reserve neem ik op in het PIM-budget?
Een gangbare, indicatieve reserve is 10 tot 20% van het implementatiebudget, afhankelijk van de onzekerheid in datakwaliteit en integraties. Neem meer reserve op bij meerdere bronnen van wisselende kwaliteit of koppelingen met maatwerksystemen. Leg vast wie over het aanspreken van de reserve beslist, bij voorkeur de stuurgroep.