Het gaat hier meestal mis doordat de planning alleen de uren van de partner telt, niet die van jou.
Jouw data, jouw besluiten en jouw testweek staan zelden ingepland, en precies daar valt elk traject stil. Plan de klantkant net zo expliciet als de bouwkant.
Doorlooptijd is geen werktijd
Een implementatie van veertig werkuren duurt geen week. De uren verspreiden zich over gesprekken, bouwrondes, wachttijd op jouw aanleveringen en de agenda's van iedereen die iets moet beslissen. Dat is normaal. Het wordt pas een probleem als niemand het vooraf heeft gezegd en de livegang steeds opschuift.
Vraag je partner daarom niet alleen "hoeveel uur kost dit", maar ook "hoeveel kalenderweken duurt dit, en waar zitten de wachtmomenten". Het antwoord op die tweede vraag laat zien of de partner vaker een traject heeft gepland of alleen gebouwd. De vaste fases van intake tot nazorg staan in hoe een traject verloopt.
Reële doorlooptijden per omvang
Als vuistregel, met de kanttekening dat migraties en koppelingen de grootste variabelen zijn. Vijf gebruikers, basisinrichting: twee tot vier weken. Tien gebruikers met een migratie en een koppeling: vier tot acht weken. Vijfentwintig gebruikers met meerdere teams en pijplijnen: acht tot twaalf weken. Vijftig of meer gebruikers: drie tot zes maanden, vrijwel altijd gefaseerd per team of land.
Wat de bijbehorende budgetten zijn, staat per omvang uitgewerkt, bijvoorbeeld in de kosten bij tien gebruikers. Tijd en geld schuiven samen: wie de doorlooptijd kunstmatig indrukt, betaalt dat in spoedtarief of in overgeslagen stappen.
Zo hoort een projectplanning eruit te zien.
Elke week heeft een eigenaar: de partner bouwt, of jij levert. Vertraging is dan altijd herleidbaar en bespreekbaar.
Dit kan alleen door testen en training te schrappen.
Je gaat dan live met ongeteste data en een onvoorbereid team. De weken die je nu wint, betaal je dubbel terug in hersteltijd en adoptieverlies.
Wat parallel kan en wat echt na elkaar moet
Er valt tijd te winnen zonder stappen te schrappen. Terwijl de partner het ontwerp maakt, kan jouw team de data alvast opschonen. Terwijl er gebouwd wordt, kun je de training voorbereiden en testscenario's schrijven. Die parallellie haalt zomaar twee weken uit een middelgroot traject.
Andersom zijn er volgordes waar je niet aan morrelt. Eerst ontwerp, dan bouw: bouwen zonder ontwerp betekent verbouwen. Eerst een proefmigratie, dan de echte: je wilt datafouten in een oefenronde vinden. En eerst testen door jouw team, dan pas live.
De drie klassieke vertragers
Vertrager één: de data. Opschonen duurt altijd langer dan gedacht, zeker als het naast het gewone werk moet. Begin ermee op dag één. Wat je precies moet aanleveren, staat in de volgende stap, wat je zelf moet aanleveren.
Vertrager twee: besluiten. Elke openstaande keuze, van veldnamen tot pijplijnfases, blokkeert een stuk bouw. Plan een vast wekelijks overleg van een half uur waarin besluiten vallen. Vertrager drie: agenda's. Trainingen en testweken concurreren met het verkoopwerk van je team. Zet ze nu in de agenda's, niet twee weken van tevoren.
Dit is de meest voorspelbare uitloop van allemaal.
Reserveer de testweek nu, inclusief de uren van je teamleden. Een testweek die wijken moet voor drukte, kost je de livegangsdatum.
Toets de planning van je partner op één ding
Vraag in de planning naar jouw regels, niet naar die van de partner. Een serieuze projectplanning bevat aanlevermomenten met jouw naam erop: week twee, data aangeleverd; week vijf, testweek team. Staat er alleen bouwwerk van de partner in, dan is het geen planning maar een werkschema. Precies het verschil tussen een partij die trajecten leidt en een partij die uren maakt.
Buffer en livegangsmoment
Plan tien tot twintig procent buffer tussen de laatste bouwweek en de livegang. Niet omdat het traject slecht gepland is, maar omdat er altijd iets uit de testweek komt. Een buffer die je niet nodig hebt, geeft een ontspannen livegang. Een buffer die ontbreekt, geeft een uitgestelde.
Kies het livegangsmoment bewust: begin van een rustige week, ruim voor een piekseizoen, nooit vlak voor vakanties. En koppel de planning aan de afspraken uit het contract: wat gebeurt er met de planning en de kosten als een van beide kanten een mijlpaal mist? Zo wordt de planning een afspraak in plaats van een hoop.
Veelgestelde vragen
Hoe lang duurt een Pipedrive implementatie gemiddeld?
Een kleine inrichting voor vijf gebruikers: twee tot vier weken. Tien gebruikers met migratie en koppeling: vier tot acht weken. Vijfentwintig gebruikers: acht tot twaalf weken. Boven de vijftig gebruikers plan je in fases van enkele maanden.
Waarom duurt het langer dan het aantal gefactureerde uren?
Omdat doorlooptijd uit wachten bestaat. De partner wacht op jouw data en besluiten, jij wacht op bouwblokken, en agenda's van beslissers moeten matchen. Veertig uur werk verspreidt zich zo makkelijk over zes weken.
Kan een implementatie in één week?
Een basisinrichting zonder migratie kan snel, maar één week voor een compleet traject betekent dat testen en training worden overgeslagen. Juist die stappen bepalen of je team het systeem gaat gebruiken.
Welke stappen kunnen parallel lopen?
Data opschonen kan naast het ontwerp, en trainingsvoorbereiding naast de bouw. De migratie zelf en het testen horen na elkaar. Een goede partner laat in zijn planning zien wat parallel loopt.
Wat is de meest gemiste post in de planning?
De testweek van jouw eigen team. Partners plannen hun bouwtijd strak in, maar de week waarin jouw mensen alles doorlopen, staat zelden ingepland. Zonder die week verschuift de livegang of ga je ongetest live.
Wanneer plan je de livegang het best?
Aan het begin van een rustige week, nooit vlak voor een piekperiode of vakantie. Je wilt de eerste dagen ruimte hebben voor vragen en herstel. Maandag live gaan geeft een hele week begeleide start.