IT-projecten mislukken vaker dan elk ander type—meestal omdat de scope onduidelijk is, afhankelijkheden worden gemist of de communicatie zwak is. Met Trupeer kun je uren besparen op planning door te starten met een gratis IT-projectplanningsjabloon, dit aan te passen met je brand identity en de planning om te zetten in video-updates die technische en zakelijke stakeholders op één lijn houden.

Wat een IT-projectplan is, en waarom generieke sjablonen tekortschieten

Een projectplan is het document waarin staat wat er wordt opgeleverd, wanneer, door wie en wat daarvoor waar moet zijn. Elk sjabloon dat hoog scoort voor deze zoekopdracht geeft je dat, meestal als een taaklijst met startdatums, einddatums, eigenaren en een Gantt-balk.

De taaklijst is niet het probleem. Het probleem is de volgorde waarin je hem invult.

Generieke sjablonen beginnen bij jouw werk. Zet de taken op een rij, schat de doorlooptijden, zet ze in volgorde, voeg eigenaren toe en de einddatum valt onderaan. Afhankelijkheden worden daarna toegevoegd, in een kolom, als een notitie.

IT-projecten lopen zelden uit omdat die schattingen fout waren. Ze lopen uit omdat er iets binnenkomt dat nooit in het plan stond en waar je niet tegenin kunt gaan: een change freeze die de go-liveweek dekt, een security review met een wachtrij van zes weken, een leverancier waarvan de implementatieconsultants tot het einde van het kwartaal volgeboekt zijn, een licentie die verlengt voordat de vervanging klaar is, een audit die de omgeving een maand vergrendelt.

Geen van die dingen zijn risico’s. Een risico is iets dat mogelijk gebeurt. Dit zijn al feiten op de dag dat je begint met plannen, en elk ervan is in de eerste week te achterhalen als iemand ernaar vraagt.

Daarom draait dit sjabloon de volgorde om. Je tekent eerst de datums die je niet kunt verplaatsen. Vervolgens ontdek je hoe breed het resterende venster werkelijk is. Daarna plan je het werk erin. De taaklijst bestaat nog steeds, maar stopt met het eerste te zijn wat je opschrijft.

Zo pas je dit sjabloon aan in Trupeer

Stap 1: Open de sectie Templates

Ga naar de sectie Templates in het hoofdmenu.

Stap 2: Selecteer en open een sjabloon

Klik op een willekeurig sjabloon waarmee je wilt werken om het te openen.

Stap 3: Breid de sjabloonweergave uit

Als dat nodig is, breid je de sjabloonweergave uit om de volledige indeling en details duidelijk te zien.

Stap 4: Bewerk het sjabloon

Klik op Edit om te beginnen met het aanpassen van het geselecteerde sjabloon.

In de editor kun je:

• Nieuwe secties toevoegen

• Opmaakregels definiëren of bijwerken

• Een logo toevoegen en de positie en bijbehorende instellingen aanpassen

Stap 5: Sla je aangepaste sjabloon op

Nadat je alle noodzakelijke wijzigingen hebt doorgevoerd, klik je op Save om het bijgewerkte sjabloon als je eigen sjabloon op te slaan.

Stap 6: Bekijk en verfijn het sjabloon

Als je wilt zien hoe je aangepaste sjabloon eruitziet, open je de Preview.

Vanaf het preview-scherm kun je, indien nodig, direct doorgaan met het maken van aanpassingen, zodat het sjabloon precies verschijnt zoals jij het wilt.

Met een IT-projectplanningsjabloon kun je:

• Uren besparen op planning: Sla de lege pagina over met een structuur die is gebouwd voor IT-initiatieven.

• Technische complexiteit beheren: Ingebouwde secties voor architectuur, afhankelijkheden en risico’s.

• In lijn blijven met je merk: Pas je logo, fonts en kleuren toe met de brand kit van Trupeer.

• Zakelijk en IT op één lijn brengen: Zet technische plannen om in video-updates die zakelijke stakeholders kunnen begrijpen.

• Standaardiseren over projecten: Gebruik hetzelfde sjabloon voor elk IT-initiatief.

• Werken met globale teams: Vertaal plannen en updates naar 65+ talen met één klik.

De niet-verplaatsbaren, en waar je ze vindt

Een niet-verplaatsbare is elke datum of duur die is vastgesteld door iemand die niet rapporteert aan het project. Je kunt het niet binnen het project onderhandelen, en als je het laat ontdekt, verandert het van een beperking in een crisis.

Dit is de inventaris om in week één te draaien. Stel elke eigenaar twee vragen: wat is je datum en wat is je doorlooptijd?

Twee van deze punten verdienen speciale aandacht, omdat ze het vaakst worden gemist. Opzegtermijnen in contracten zijn niet-verplaatsbare datums die vóór de verlengingsdatum liggen, wat betekent dat de echte deadline eerder is dan die in de agenda. En datakwaliteit in het bronsysteem is de enige niet-verplaatsbare waarvan je de omvang niet kunt opzoeken. Je moet het opmeten, daarom hoort het profileren van brondata bij week één en niet bij de migratiefase.

Teken deze op één enkele kalender voordat je iets inschat. Waar je naar zoekt is de vorm van de opening. Heel vaak is de opening veel smaller dan de projectduur, en het eerlijke gesprek over scope vindt plaats in week twee in plaats van in maand zeven.

Wat er in het plan gaat

Zodra de niet-verplaatsbaren zijn getekend, heeft het plan zelf twaalf secties. Kopieer de koppen, vul ze in deze volgorde in.

1. Samenvatting. Eén zin: wat verandert, voor wie, en wat daarna niet meer waar is.

2. Resultaat en succescriteria. Meetbaar en gedateerd. Neem minstens één criterium op over het onderdeel dat wordt vervangen, bijvoorbeeld dat het legacy-systeem op een opgegeven datum geen verkeer en geen licentiekosten heeft. Plannen die eindigen bij go-live zijn hoe bedrijven uiteindelijk betalen voor twee systemen.

3. Beperkingenkalender. De tabel met niet-verplaatsbaren hierboven, ingevuld, met het resulterende levervenster als een datumbereik in gewone woorden.

4. Scope. Drie lijsten: in, out en deferred. De deferred-lijst is de nuttige, omdat daar de scope terechtkomt wanneer die wordt ingekort, en het voorkomt dat hetzelfde gesprek vier keer opnieuw plaatsvindt.

5. Fases en mijlpalen. Mijlpalen zijn gebeurtenissen met een waarneembant antwoord, bijvoorbeeld "security review geslaagd" of "eerste winkel live", niet "ontwerpfase afgerond".

6. Werkverdeling. Taken, eigenaren, schattingen, volgorde. Dit is het onderdeel waarmee elk ander sjabloon begint.

7. Afhankelijkheden. Splits intern van extern. Elke externe afhankelijkheid krijgt een benoemde persoon bij de andere organisatie en een datum waarop ze het hebben afgesproken, niet een datum die jij hebt aangenomen.

8. Omgevingen en data. Welke omgevingen bestaan er, welke data zit er in elk, hoe productiedata wordt beschermd in test, en het resultaat van het profileren van brondata.

9. Cutover en rollback. De uur-voor-uur volgorde voor de switch, het beslismoment waarop je stopt, wie die beslissing neemt en hoe je terugkomt. Schrijf dit als een uitvoerbare procedure, waar een method of procedure template bij hoort.

10. Risico’s met triggers. Geen kans- en impactmatrix. Elk risico krijgt een waarneembare trigger en de actie die afgaat wanneer de trigger wordt gezien. "Vendor consultant niet bevestigd op 12 mei" is een trigger. "Vendor kan te laat zijn" is dat niet.

11. Communicatie, training en adoptie. Wie wordt wanneer geïnformeerd en wat gebruikers op dag één geacht worden te kunnen doen.

12. Governance en afsluiting. Wie beslist, wie escaleert, hoe een beslisdocument eruitziet en onder welke voorwaarden het project als afgerond wordt verklaard en wordt overgedragen om te runnen.

Een uitgewerkt voorbeeld, en wat het kostte

Ashmore Retail, vierentachtig winkels en drie distributiecentra, zette in februari uiteen om het warehouse management system in alle drie DC’s te vervangen. Negen maanden werk, go-live gepland voor medio november, beschreven in de kickoff deck als comfortabel vooruitlopend op de piek.

Op de dag van die kickoff bestonden er twee niet-verplaatsbaren. Beide waren gepubliceerd. Geen van beide stond in het plan.

De eerste was de change freeze. Retail operations publiceert die elke januari en hij loopt van 1 november tot 15 januari, waarmee de piekperiode wordt gedekt. Gedurende die elf weken gaat er geen enkele productiechange van welke aard dan ook door.

De tweede was het legacy-contract. Dat verlengde op 31 december voor nog eens twaalf maanden tegen honderd en zesentachtigduizend pond, met een vereiste opzegtermijn van negentig dagen, waardoor de echte deadline op 2 oktober uitkwam.

Het project liep in de lente volgens plan. Security review duurde vier weken tegen een opgegeven SLA van twee. De implementatieconsultants van de leverancier waren pas beschikbaar in oktober, omdat ze in juli waren gevraagd. Beide uitloopmomenten werden opgevangen door de go-live te verplaatsen van medio november naar eind november, wat niemand opmerkte omdat niemand naar de freeze-kalender keek.

De freeze kwam boven in een change advisory board meeting in begin september. Go-live in november was niet mogelijk en het volgende bruikbare venster ging open op 16 januari.

Dat liet één keuze om te maken vóór 2 oktober. Geef opzegging op het legacy-contract en ga van 1 januari door zonder support op het systeem waar de hele organisatie van afhankelijk was, of laat het verlengen en betaal een jaar voor een systeem dat ze in november van plan waren uit te schakelen.

Ze lieten het verlengen. Het nieuwe systeem ging live op 4 maart. Het legacy-contract werd gebruikt voor negen weken van de tweeënvijftig weken durende looptijd, wat ongeveer tweeëndertigduizend pond aan waarde opleverde tegenover een factuur van honderd en zesentachtigduizend pond. Ruwweg honderd en vijftigduizend pond kocht niets.

Het leerzame deel is dat het project nooit te laat was op de manier waarop mensen bedoelen wanneer ze zeggen dat het te laat is. Het werk werd uitgevoerd met een redelijke standaard in een redelijk tempo. Wat er misging is dat het venster zes weken smaller was dan iemand had getekend, en de twee datums die het definieerden al in een gepubliceerde kalender en een ondertekend contract stonden voordat het project bestond.

Als de beperkingenkalender in februari was getekend, was de volgorde vanzelfsprekend geweest. Go-live vóór 1 november, terugwerkend via een security review van vier weken die in werkelijkheid zes was, een inkooptraject van zes weken en consultants die een kwartaal opzegtermijn nodig hadden, betekende dat het leverancierscontract vóór medio april moest worden ondertekend. Het werd ondertekend in juli. Het project hoefde niet sneller te gaan. Het moest zijn niet-verplaatsbare afhankelijkheden elf weken eerder starten.

Vijf vormen van IT-project, en welke secties het gewicht dragen

Lijsten met twintig IT-projecttemplates komen vaak voor in deze zoekopdracht, van ITSM-implementatie tot infrastructuur-upgrades tot het opzetten van een PMO. In de praktijk vallen ze terug tot vijf vormen, en de vorm vertelt je welke secties hierboven de details verdienen.

Vervanging. Een draaiend systeem vervangen door een ander. Inclusief WMS, ERP, ITSM-tooling, helpdeskplatforms, HR-systemen. Secties 3, 9 en 2 dragen het gewicht, omdat de lastige onderdelen het venster zijn, de cutover en aantonen dat het oude systeem echt uit staat.

Implementatie. Iets nieuws zonder voorganger. Inclusief SLA-management, IT-governance en complianceprogramma’s, asset management, knowledge management. Secties 11 en 2 dragen het gewicht, omdat er niets kapot was gegaan voordat, dus alleen adoptie maakt het echt. Onze digital adoption implementation guide gaat dieper op dit onderwerp in.

Migratie of upgrade op locatie. Zelfde systeem, nieuwe versie, nieuwe host of nieuwe regio. Inclusief virtualisatie, consolidatie, cloudmigratie, database-upgrades. Secties 8 en 9 dragen het gewicht, omdat rollback het hele spel is.

Build. Softwareontwikkeling en procesautomatisering. Sectie 4 draagt het gewicht, omdat scope de variabele is die verschuift en acceptatiecriteria zijn wat voorkomt dat het stilletjes verschuift.

Programma en assurance. Opzetten van een PMO, IT-audits, portfolio management, risicomanagement, security compliance. Sectie 12 draagt het gewicht, omdat het op te leveren resultaat bewijs en sign-off is in plaats van een werkend systeem, en de mijlpalen reviewdatums zijn die door iemand anders zijn vastgesteld.

Als je project niet netjes in één van deze vormen past, zijn het meestal twee projecten die één naam hebben gekregen.

Het plan in één dag bouwen

Ochtend: teken de niet-verplaatsbaren. Stuur de twee vragen naar elke eigenaar in de tabel, jaag eerst op de antwoorden van leverancier en security, omdat die de langste doorlooptijden hebben, en zet elke datum die je terugkrijgt op één kalender. Formuleer het resulterende venster in één zin.

Middag: schrijf secties 1, 2 en 4, en daarna de mijlpalen. Laat de gedetailleerde werkverdeling over aan het delivery team om die in te vullen tijdens de week. Een plan is nuttig zodra het venster en de scope zijn afgesproken, en het is niet nuttiger met vierhonderd rijen erin.

Beoordeel het bij elke governance meeting tegen het venster. De enige vraag die de moeite waard is om te stellen is niet "lopen we op schema" maar "is er een niet-verplaatsbare verschoven". Freezes worden verlengd, audits worden opnieuw ingepland en leveranciers verliezen consultants. Die wijzigingen herschikken het plan op een manier die een uitgelopen taak nooit doet.

Wat je moet weglaten

Een Gantt-grafiek van elke taak hoort niet in het plandocument. Die hoort in de tool waarmee je plant, en door die te dupliceren in een document ontstaan twee versies die binnen een paar weken niet meer met elkaar overeenkomen.

Ook een volledig risicoregister met scores hoort hier niet. Houd de risico’s over met triggers en datums, en zet de rest in het register.

Gedetailleerde procedures voor hoe het werk wordt uitgevoerd horen in een IT SOP, en de beschrijving van wat je hebt gebouwd hoort in IT documentation in plaats van in het plan. Een overdracht aan het run-team is het waard om goed te plannen, en dat is waar een knowledge transfer SOP voor is.

Wanneer je moet stoppen met een document en software gebruiken

Een document is de juiste container zolang er over het plan wordt gediscussieerd, wat meestal de eerste maand is. Het is niet langer de juiste container wanneer drie dingen tegelijk waar worden: er zijn meer dan ongeveer dertig taken live, meer dan vier mensen updaten status en afhankelijkheden tussen taken beginnen wekelijks te veranderen.

Op dat moment verplaats je de werkverdeling naar planningssoftware en houd je het document voor secties 1 tot 5 en 12, dat zijn de onderdelen die worden gelezen door mensen die nooit de tool zullen openen. Het document bevat de afspraak. De tool bevat het schema.

Het plan omzetten in iets dat het delivery team echt volgt

Het plan wordt gelezen bij de kickoff en bij de stuurgroepmeeting. Het cutover-runbook wordt om twee uur ’s nachts gelezen door iemand die bij geen van beide aanwezig was.

Trupeer AI zet een schermopname om in een gedocumenteerd proces, zodat de cutover-stappen in sectie 9 en de taken op dag één in sectie 11 walkthroughs worden van je echte systemen in plaats van paragrafen die ze beschrijven. Leg de volgorde één keer vast en je krijgt een stapsgewijze handleiding, een video en een document in je knowledge base, in je eigen branding.

Leg het vast. Branded het. Vertaal het. Trupeer it.

Voor het adoptiewerk in sectie 11 behandelen change management en training videos de uitrolkant, en documentation houdt het plan, het runbook en het overdrachtsmateriaal samen. Setup-instructies staan in de document template setup guide.

Veelgestelde vragen

Is er een gratis IT-projectplanningsjabloon in Excel?

Niet als bestand van ons, en het is de moeite waard om daar eerlijk over te zijn. Excel is echt de betere container voor de werkverdeling in sectie 6, omdat datums, afhankelijkheden en totalen in cellen horen. Bouw dat sheet zelf met kolommen voor taak, eigenaar, start, eind, afhankelijkheid, status en niet-verplaatsbaar-vlag. Houd secties 1 tot 5, 9 en 12 als een document, omdat die worden bediscussieerd in tekst en niemand scope onderhandelt in een spreadsheet.

Is er een Word-versie, of een Word-doc gratis download?

De twaalf sectiestructuur hierboven is geschreven om direct te kopiëren naar Word of Google Docs. Plak de koppen, behoud de nummering en vul ze in de volgorde in die is gegeven. Er is geen gated download, wat ook betekent dat er geen formulier tussen jou en de structuur zit.

Is er een PDF-versie?

Plak de secties in je editor en exporteer naar PDF wanneer het plan is afgesproken. Een plan is het waard om als PDF te bevriezen op het moment dat het is goedgekeurd, en het is het waard om vóór dat moment bewerkbaar te houden, dus je eigen kopie exporteren op het juiste moment is beter dan starten vanuit een vast bestand.

Is er een PPT-versie voor de kickoff deck?

De deck is een ander document met een andere taak. Zes slides is meestal goed: het resultaat, het levervenster uit je beperkingenkalender, scope in en out, mijlpalen, de benoemde externe afhankelijkheden en wie beslist wat. Zet de werkverdeling niet in de deck. Niemand leest een Gantt-balk op een projector.

Kan ik het gratis downloaden?

De structuur, de tabel met niet-verplaatsbaren en het uitgewerkte voorbeeld zijn gratis en onbeperkt te gebruiken. Gebruik ze, bewerk ze en zet ze in je eigen templatebibliotheek onder je eigen naam.

Is een project delivery plan hetzelfde als een project plan?

Zover genoeg dat het onderscheid zelden zijn waarde bewijst. Als organisaties ze scheiden, dekt het projectplan de volledige levenscyclus van het project, inclusief business case en afsluiting, en het delivery plan dekt alleen het build- en release-gedeelte. Als je governance om beide vraagt, schrijf dan het plan hierboven en behandel secties 5 tot 9 als het delivery plan.

Heb ik ook een apart projectmanagementrapport-sjabloon nodig?

Ja, en houd het veel korter dan je verwacht. Een statusrapport dat het plan herhaalt, wordt binnen een maand genegeerd. Rapporteer vier dingen: is er een niet-verplaatsbare verschoven, is het venster nog breed genoeg, welke beslissing heb je vandaag van deze groep nodig en wat is er uit de risicolijst gekomen sinds de vorige keer.

Hoe gedetailleerd moet een IT-projectplan zijn?

Zó gedetailleerd dat een nieuwe collega kan zien wat er hierna gebeurt, en niet meer. In de praktijk loopt het plandocument voor een project van negen maanden meestal uit op ongeveer acht tot vijftien pagina’s, waarvan het grootste deel secties 8 en 9 zijn. Als het document langer is dan het cutover-runbook, klopt de balans niet.

Hoe vaak moet het plan worden bijgewerkt?

Secties 6 en 7 veranderen wekelijks en horen waar je team al werkt. Secties 1 tot 5 moeten zelden veranderen en elke wijziging daaraan is een beslissing die iemand moet goedkeuren. Als je scope-sectie elke week stilletjes wordt bewerkt, heb je geen plan; je hebt een dagboek.