Het Projectplan

Projectplan inleiding

Het Projectplan is de belangrijkste deliverable voor de start van een project. Stel je een project zonder plan voor de start van een project. Waar leidt dat naartoe? Een plan geeft houvast maar het moet aan minimale eisen voldoen.
In het vervolg van de implementatie maken we per fase ook plannen maar het projectplan is duidelijk anders van aard. In het Projectplan leggen we belangrijke zaken vast en het fungeert als contract voor de loop van het project. Zaken we vastleggen zijn:

• De opdracht, korte maar duidelijke omschrijving van de doelstelling van het project.
• De projectorganisatie, welke teams stellen we in voor specifieke taken.
• De fasering van het project; bij kleine projecten kan de projectgroep besluiten om (delen van) fases over te slaan.
• De afbakening – scope; welke processen, systemen, afdelingen en functionaliteiten behoren tot het project?
• Vergaderfrequentie.
• Resources. De beschikbare middelen. Gaat in veel gevallen dus over tijd en geld.
• Reviewers. Welke deskundigen zullen de opgeleverde producten beoordelen?
• Risico analyse van het project.
• Communicatie plan.

Projectplan: Opdracht moet helder zijn

Officieel komt de opdracht van de opdrachtgever. Om tot een juiste formulering te komen vindt vaak vooraf echter overleg plaats over de inhoud. De opdracht is bij voorkeur in één zin te vatten. Bijvoorbeeld:
“Selecteer en implementeer een SaaS oplossing waarmee een geïntegreerd boekhoudsysteem voor de financiële administratie kan worden opgezet.”
Deze opdracht is echter niet voldoende om de scope van het project helder in beeld te brengen. Voor een goeie afbakening is daarom meer overleg nodig.

Projectplan: Projectorganisatie in kaart

De omvang van de projectorganisatie is afhankelijk van de omvang van het project. Minimaal is er een opdrachtgever en een projectgroep. In veel gevallen is dat al voldoende om het project uit te voeren. Bij een groot project maakt de opdrachtgever ook deel uit van de opdrachtgeversgroep. De projectgroep stuurt meerdere teams aan.

Bij projecten van een maximale grootte wordt voor iedere fase een apart deelteam samengesteld op het moment dat de betreffende fase start.

• Requirementsteam
• Selectieteam
• Livinglab team
• Voorbereidingsteam
• Implementatieteam
• Beheerteam
• Communicatieteam
  Dit team zorgt voor de communicatie naar de belanghebbenden die niet bij het project zijn betrokken en de communicatie binnen het project. Hierdoor is het Communicatieteam het meest aangewezen team om de projectadministratie bij te houden.

Projectplan: fasering in het agile tijdperk

• Een team is specifiek gekoppeld aan een taak binnen het project en rapporteert aan de projectgroep. Gedurende het project kunnen teams starten en eindigen afhankelijk van welke taken op dat moment nodig zijn.
• De projectgroep blijft echter van begin tot eind verantwoordelijk.
• Tijdens de projectinitiatie in het begin, is inhoudelijk nog niet veel bekend over de oplossing die we zullen kiezen en is het aantal teams minimaal.
• Bij grote projecten kan het voorkomen dat de projectgroep besluit om de teams Communicatie en Requirements al te laten starten voordat het projectplan definitief is opgeleverd (en de initiatie is afgerond) Het Communicatieteam start dan met het maken van het communicatieplan en informeert de organisatie over de start van het project. Het Requirementsteam start met het inventariseren van de bedrijfsprocessen die door het project geraakt zullen worden.
• Naarmate de omvang van een project toeneemt kan de behoefte ontstaan om specifieke taken van de projectgroep te delegeren aan speciale teams. Denk bijvoorbeeld aan een kwaliteitsteam of een juridisch-team.
• De omvang van de projectorganisatie is dynamisch en groeit en krimpt naarmate het project vordert.

Projectplan: Afbakening – Scope

Heb jij de scope van ons project ook helder voor ogen?

Een belangrijk onderdeel van het projectplan is de afbakening –  scope. Hierin beschrijven we wat allemaal tot het project behoort. Dit kunnen zijn:

• Bedrijfsprocessen, welke bedrijfsprocessen zal de software gaan ondersteunen.
• Organisatie onderdelen, welke afdelingen zijn hierbij betrokken.
• Functionaliteiten, zijn er specifieke functionaliteiten die we in ieder geval moeten invullen?
• Systemen, welke systemen zijn betrokken. Misschien zijn er koppelingen voorzien met relatiegegevens of financiële systemen.

Hier geven we ook aan wanneer het project klaar is en kan worden afgesloten. Soms kan het zinvol zijn om ook aan te geven wat nadrukkelijk niet tot het project behoort. 
In de afbakening nemen we het overzicht met project randvoorwaarden op. De afbakening is namelijk een belangrijke basis voor de planning en het zorgt voor helderheid tijdens het verloop van het project.

Projectplan: Resources, wat hebben we nodig om het project af te ronden?

De opdrachtgever moet middelen beschikbaar stellen aan de projectleider die daar vrij over kan beschikken om het project uit te voeren.

• Tijd.
• Geld.
• Infrastructuur.

In deze fase van het project is er nog maar weinig bekend over een mogelijke eindoplossing en moet we schatten op basis van aannames.
Er zit daarom wrijving tussen de opdrachtgever en de projectleider in deze fase. De laatste heeft namelijk duidelijke behoefte aan een behoorlijk budget om een kwalitatief goede oplossing neer te kunnen zetten. De opdrachtgever zal de kosten echter zo laag mogelijk willen houden.
Het budget en de planning zullen we na de derde fase (wanneer een oplossing  is geselecteerd) moeten bijstellen.

Projectplan: Reviews, laat de producten toetsen

Om de kwaliteit van een project te borgen stellen we reviewers aan. Ieder deliverable zal worden getoetst. Deze toetsing bepaalt welke review kan worden gedaan door projectleden, opdrachtgever of materiedeskundigen. In het projectplan nemen we vervolgens op wie welke producten gaat reviewen.

Projectplan: Communicatieplan

Communiceer je wel genoeg? Als medewerkers zich niet betrokken voelen zullen ze de software niet accepteren.

Een grote faalfactor van ieder project is een slechte communicatie. Dit kan komen door te weinig overleg binnen het projectteam. Dit heeft mogelijk een negatieve invloed op de kwaliteit en doorlooptijd. De communicatie buiten de projectorganisatie is echter van een nog groter belang. Tijdige en gerichte communicatie naar de organisatie, gebruikers en klanten verhogen namelijk de acceptatie van de nieuwe software. We bouwen er krediet mee op voor als het in het begin niet helemaal lekker loopt.
Binnen deze aanpak wordt aan het projectplan altijd een communicatieplan gekoppeld en zal daarom binnen iedere fase een communicatie activiteit plaatsvinden. Dus ook bij kleinere projecten, die geen apart communicatieteam kennen.

Hoe zet je de communicatie op?

In het communicatieplan wordt beschreven met wie (doelgroepen – sub doelgroepen) wordt gecommuniceerd (de boodschap die wil je delen) en ook op welke manier (middelen; mail, nieuwsbrief, intranet, workshops etc.) dit zal plaatsvinden.
Een goede communicatie dus kan een grote invloed hebben. Gericht, volgens een vooraf vastgestelde strategie communiceren in een vroeg stadium, kan bijdragen in de acceptatie van de verandering die een invoering van een nieuw systeem hoe dan ook teweeg brengt.

Projectplan: Startup meeting

Als eerste projectbijeenkomst organiseren we een kickoff meeting. Hierbij kunnen naast de opdrachtgever, projectleider en alle projectleden ook mogelijke gebruikers – klanten worden uitgenodigd om elkaar leren kennen.
Aan de hand van het concept projectplan wordt het doel en beoogde resultaat van het project bediscussieerd. Het is dus mogelijk dat tijdens de startup de inhoud van het projectplan nog verder wordt aangescherpt.
Het resultaat van deze bijeenkomst verwerken we na afloop in het projectplan en deze maken we (na nog een leesrondje) definitief.

Het project kan beginnen!

Discussieer mee op LinkedIn.