Aan het begin van een project zijn jij en je klant allebei enthousiast over wat jullie voor ogen hebben. Er zijn mooie plannen en we willen aan de slag. En wel nu! Maar het is belangrijk om éérst de afspraken goed op papier te zetten in een projectplan. Dat voorkomt namelijk – aan beide kanten – veel gezeur tijdens de uitvoer.

Als je niet (of onvoldoende) documenteert wat jullie hebben afgesproken kunnen er allerlei nare dingen gaan gebeuren. De scope van het project kan bijvoorbeeld gaan schuiven, waardoor je opeens veel meer werk moet verzetten dan je aan het begin van het project (toen je je offerte opstelde) dacht. Of iemand denkt dat jij een bepaald onderdeel van het project gaat uitvoeren terwijl je dat helemaal niet jouw taak vindt, of erger nog, dat je het zelf niet kunt. Of je krijgt extra werk te doen doordat de planning verschuift, en je je bijvoorbeeld telkens opnieuw in een project moet verdiepen dat een tijd heeft stilgelegen.

Voor je het weet verlies je geld of tijd of komt er mot in de tent, en dat wil je natuurlijk niet. Zowel voor je klant als voor jou is het belangrijk om aan het begin van het project een aantal dingen op papier te zetten. En daar samen voor te tekenen.

Wanneer ga je dat doen?

In de offertefase, zou je misschien op het eerste gezicht denken. Maar dat is bij nader inzien niet zo handig, omdat je al veel kennis van het project moet hebben om alle relevante afspraken goed vast te kunnen leggen. Idealiter heb je dat ook al in de offertefase, maar de realiteit is dat je in nadere gesprekken toch weer meer te weten komt en meer kunt (en moet) vastleggen.

Maar je offerte is toch je offerte, dat is toch je aanbieding? Ja, en je moet er wel voldoende tijd instoppen om er een goed voorstel van te maken. Maar dan nog is het een goed idee om in een projectplan (nogmaals) dit soort dingen op te schrijven en af te stemmen of de verwachtingen met elkaar in overeenstemming zijn.

Is dat niet overdreven?

Als je denkt aan een projectplan voel je misschien direct weerstand opkomen tegen het idee dat je zo’n document moet gaan schrijven. Documentatie wordt toch nooit gelezen en het is gewoon ballast. En als je elkaar vertrouwt heb je het niet nodig om alles vast te leggen, dan werkt het alleen maar tegen je in de relatie met je klant. En zo’n ellenlang document, daar heeft niemand iets aan.

Ellenlang hoeft het zeker niet te zijn. Je mag de lengte van het document gerust aanpassen aan de omvang van het project. Sommige projecten hebben een uitgebreid projectplan nodig van wel vijftig pagina’s of nog meer, en sommige projecten kunnen het af met een ruim A4’tje. Maar in alle gevallen is het verstandig om wél iets op papier te zetten, al is het maar om zeker te weten dat jij en je klant de zelfde uitgangspunten hebben.

Welke onderwerpen horen in het projectplan?

Ongeacht de omvang van je project zijn er een aantal onderwerpen waar je in iedere geval aan gedacht moet hebben bij het schrijven van een projectplan, voor deze gelegenheid samengevat in een gemakkelijk te onthouden rijtje: wie, wat, wanneer, waarom, hoe, hoe veel, handtekening. Ik zou nu deskundig kunnen doen en zeggen ‘de 4 w’s en de 3 h’s’, maar het is hier geen marketingboek, dus gaan we gewoon eens rustig bekijken wat we bij elk van die onderwerpen tegen kunnen komen.

De volgorde van het rijtje is overigens niet echt logisch voor de opbouw van je projectplan. Je zou dan waarschijnlijk eerder uitkomen op wat, waarom, wanneer, wie, hoe, hoe veel, handtekening. Maar dat is niet makkelijk te onthouden, dus ik bespreek het nu toch aan de hand van de eerste volgorde.

Het belangrijkste om voor ogen te houden is dat je aannames boven tafel krijgt en beschrijft, dat je helder de verwachtingen van beide partijen formuleert. Vooral dingen ‘die toch altijd zo gaan’ of ‘toch logisch zijn’ leiden namelijk tot onduidelijkheid en daardoor tot frictie.

Wie

Elk project bestaat uit een aantal activiteiten of taken die uitgevoerd moeten gaan worden. Het is bijzonder belangrijk om vast te leggen wie welke taak voor zijn rekening neemt. En om ook alvast stil te staan bij wat er gebeurt als er onverhoopt dingen niet helemaal gaan zoals gepland.

Laat ik dat uitleggen met een voorbeeld. Je spreekt bijvoorbeeld af dat jij het ontwerp en de bouw van de site doet, maar dat de klant er voor zorgt dat de teksten aangeleverd worden. Schrijven we netjes op.

Maar dan... Als de teksten bij jou aangeleverd worden blijkt dat er nog allerlei spelfouten inzitten en onleesbare gedeelten. Wat doe je dan? Als je het terugstuurt naar je opdrachtgever wordt de deadline verschoven. Als je niets doet heeft de klant lelijke tekst op zijn website staan en maakt hij een slechte indruk bij zijn klanten. Als je het zelf gaat aanpassen kost dat jou tijd, plus je loopt het risico dat je iets verkeerd verandert. Als je klant het nog een keertje nakijkt komt hij met ‘even een paar kleine verbeteringetjes, maakt toch niet uit, hè?’ en voor je het weet ben je weer een paar uur verder die je niet op je factuur kunt zetten.

Als je in het projectplan vermeldt: ‘de klant levert tekst in definitieve versie aan op de afgesproken datum, correcties in de teksten na de eerste aanleverdatum vallen onder het meerwerk en hebben invloed op de planning’, dan weet iedereen waar hij aan toe is.

Hetzelfde geldt voor cruciale afspraken voor de voortgang. De klant heeft bijvoorbeeld als het project begint nog geen hostingpartij geselecteerd en nog geen account afgesloten. Dan moeten we goed afspreken wie dat gaat doen en voor welke datum – het maakt niet uit wie het regelt, als het maar op tijd geregeld wordt. Anders heb jij de website af en kan hij nog niet live omdat de klant er van uit was gegaan dat jij ook de hosting zou regelen. De klant denkt ‘dat is toch iets technisch, dat zullen zij wel regelen’, terwijl jij uit ervaring weet dat het van belang is dat de klant rechtstreeks contact heeft met de hostingpartij, zodat ook de facturen naar hem gaan.

Wat

Wat moet er gemaakt worden? Voor een klein project is het misschien al direct duidelijk welke pagina’s geproduceerd moeten worden: home, contact, over ons, product x, product y en product z. Je kunt per pagina zelfs al beschrijven wat er op moet komen. Dan kun je het als zodanig vastleggen in je beschrijving.

Misschien weet je alleen ongeveer hoe veel pagina’s er in de site komen. Dan kun je een range opnemen in je documentatie: bijvoorbeeld ‘site zal tussen de 15 en de 20 pagina’s bevatten, alles wat daar boven komt valt buiten deze overeenkomst’. Als de klant dan opeens allerlei onderwerpen erbij bedenkt of in plaats van 8 projecten waar hij iets over wil vertellen 14 projecten heeft, kun je wijzen op de eerdere overeenkomst. Het is geen probleem om het uit te breiden, maar het is wel extra werk, werk wat bewijsbaar niet onder jullie eerdere afspraken valt.

Maak ook een duidelijk overzicht van de functionaliteiten die onder de afspraak vallen. Komt er een databasekoppeling? Zijn er contactformulieren gepland? Moeten er nieuwsberichten geplaatst kunnen worden en hoe gebeurt dat dan?

Als je met je klant over functionaliteiten hebt gesproken die jullie uiteindelijk niet hebben gepland voor de website, is het ook een goed idee om daar melding van te maken. Bijvoorbeeld: ‘het forum voor de leden wordt in de eerste fase van de website nog niet gemaakt. Na oplevering van de site bespreken we of we in een tweede fase wel een forum gaan opzetten.’

Wanneer

Uiteraard moet ook de planning van het project goed vastgelegd worden. Al is het maar dat je vastlegt dat je tot een bepaalde datum weet wat er gaat gebeuren en dat je na die datum nadere afspraken maakt. Schrijf de stappen op waarvan je weet dat ze moeten gebeuren, ook wanneer je nog geen precieze datum hebt op het moment van schrijven.

Bijvoorbeeld:

• eerste overleg: 1 december
• opleveren sitestructuur voor overleg met de klant: 15 december
• begin ontwerpen: 20 december
• ontwerppresentatie: 2 januari
• beslissing over content management-leverancier en templatebouwer: 15 januari
• aanleveren ontwerpen bij templatebouwer: NTB
• CMS gereed: NTB

Waarom

Waarom voeren we dit project eigenlijk uit? Een korte beschrijving van de doelen van de nieuwe website is in het projectplan zeker op zijn plaats. Dit geeft jou en je klant namelijk aanknopingspunten om na afloop van het project te bepalen of jullie bereikt hebben wat je wilde bereiken. Wat zijn de meetpunten die we aan kunnen brengen in het proces? Willen we meer naamsbekendheid, meer bezoekers, meer verkopen door de website? Misschien is de klant wel heel tevreden als er in plaats van 50 mensen 100 mensen per dag op de site komen, of misschien wil hij juist veel beter gevonden worden in zoekmachines.

Klanten vinden het vaak erg moeilijk om hun doelen helder te formuleren en op papier te zetten. Dat is natuurlijk ook eng, want het is iets waar anderen (de baas van je klant bijvoorbeeld) ze ook weer op kunnen wijzen en zeggen, “Eh, Jansen, waarom hebben we die 1.000 bezoekers per dag van jou nou nog steeds niet?” Aan de andere kant is het wel een heldere situatie als je samen bepaalde doelen tot de belangrijkste hebt bestempeld. Als Jansen bijvoorbeeld samen met jou (en met goedkeuring van zijn baas) heeft vastgelegd dat de verkopen via internet met 20% omhoog moeten gaan in de eerste 6 maanden na oplevering van de website, heeft hij ook iets om op terug te vallen op het moment dat zijn baas bedenkt dat die 20% toegenomen verkopen wel leuk zijn, maar dat hij eigenlijk 50% meer bezoekers in het eerste jaar wilde. Het staat op papier dat we die doelstelling niet gedefinieerd hebben, en dan kunnen we wel aan een nieuwe doelstelling gaan werken, maar dat is dan een nieuw project, niet een doel wat nu al gehaald zou moeten zijn door deze website.

Hoe

In het onderdeel ‘hoe’ maak je bijvoorbeeld afspraken over de techniek die gebruikt gaat worden. Stel je op de hoogte van wat de klant verwacht, en bekijk of je daaraan kunt voldoen.

Als jij met PHP gaat werken is het prettig als de klant ook een hostingpartij regelt die daarmee werkt. Als de klant verwacht dat er stukjes in Java geprogrammeerd gaan worden omdat zijn backend-systemen daar mee werken en jij bent een ontwerper die wel een beetje kan HTML’en maar niet zo technisch is ingesteld, is het goed dat probleem direct boven water te krijgen. Dan kunnen jullie beslissen hoe dat opgelost gaat worden: volg jij razendsnel een cursus, huur je iemand in die dat gedeelte voor zijn rekening neemt, huurt de klant iemand in om dat werk te doen, of (en dat hoop je natuurlijk niet) besluiten jullie samen dat jij toch niet de aangewezen persoon bent om dat project te doen, hoe leuk je ideeën voor het ontwerp ook waren. Beter dat je er aan het begin van het traject achter komt in plaats van maanden van slapeloze nachten en uitgetrokken haren later.

Heeft de klant nog specifieke wensen op het gebied van toegankelijkheid, browserversies (zijn moeder heeft IE4.5, en die wil hij niet teleur stellen), schermgroottes? Vraag het na en neem het op in de documentatie.

Hoeveel

Schrijf de kosten duidelijk op, en vermeld ook of het fixed price is (je doet het voor die prijs, ongeacht hoeveel uur er van jou uiteindelijk in gaat zitten) of op nacalculatiebasis. Dat maakt nogal verschil! Fixed price is overzichtelijk voor de klant, maar het betekent wel dat je heel goed de vinger aan de pols moet houden met de bestede uren. Jij gaat namelijk het schip in als je er meer uren aan besteedt dan afgesproken, en dat kost je geld. Bij deze vorm van contract is het dubbel belangrijk dat je alle extra werk, alles wat buiten de originele afspraken valt, direct kenbaar maakt aan je klant en er aanvullende opdrachten voor regelt. En dat kan alleen als je – juist: de afspraken goed hebt vastgelegd.

En spreek ook af wie bepaalde externe kosten betaalt. Als jij de fotograaf regelt voor een site, wil dat nog niet zeggen dat jij ook de fotograaf gaat betalen. Misschien is het veel handiger als hij zijn factuur rechtstreeks aan de klant stuurt, zodat de situatie helder blijft en de klant niet het idee kan krijgen dat jij er nog geld op zit te verdienen. Of misschien is het voor jouw cashflow helemaal niet handig als je het bedrag voor de fotografie moet voorschieten. Hetzelfde geldt voor hostingkosten, tekstschrijvers, rechten op audio/video die in de site gebruikt wordt: het maakt niet uit wie het betaalt, als er maar iemand betaalt en als iedereen maar weet wie dat is.

Handtekening

Laat je klant een handtekening zetten onder het projectplan. Liefst nadat je het samen punt voor punt hebt doorgesproken, zodat je zeker weet dat je allebei hetzelfde bedoelt als je het over het zelfde hebt. ‘Aanleveren teksten’ is niet het inleveren van een aantal velletjes papier met daarop wat snelle krabbels en losse kreten: het is aanleveren van Word-documenten met daarin netjes gegroepeerde teksten per afgesproken pagina, gecontroleerd en geaccordeerd door de klant.

Dit document tekenen jullie in tweevoud: één voor jou en één voor de klant. Zo kunnen jullie het er beiden weer bij pakken als één van jullie even niet meer weet wat ook al weer de bedoeling was. Berg het document vervolgens goed op, zodat je het ook inderdaad à la minute kunt terugvinden! Als er extra afspraken zijn die je in de loop van het project maakt (vooral als dat afspraken over geld zijn): zet ze ook op papier, laat ze tekenen door je klant en berg ze in dezelfde map op. Dan heb je, wanneer je alles opgeleverd hebt en met een zucht van verlichting je factuur typt, alle gegevens bij de hand!

Tot slot

Een projectplan lijkt misschien overdreven en veel gezeur op een moment waarop je liever iets ‘echts’ zou gaan doen. Maar je klant zal onder de indruk zijn van je georganiseerdheid en vooruitziende blik, en aan het einde van het project zullen jullie allebei zien dat het duidelijke plan veel stress heeft voorkomen. Veel succes ermee!

Meer lezen

Web Redesign 2.0 – Workflow that Works van Kelly Goto en Emily Cotler is het zeer toegankelijke en vooral zeer complete boek van de koninginnen van het documenteren. Onmisbaar voor projectmanagers, en het lezen waard als je je eigen projectmanager moet zijn.

• Home
• Artikelen
• Colofon