Plan van aanpak voorbeeld

Hoe groot of hoe klein moeten we een plan van aanpak maken? Welke onderdelen nemen we er in op en welke niet? Veel hangt ook af van de aard en de omvang van een project. Dit artikel geeft in een uitgebreide template aan hoe een plan van aanpak er uit kan zien. Haal er uit wat je nodig hebt. Het is wel het beste om alle onderdelen op te nemen zodat men weet dat wel er rekening is gehouden met deze onderdelen. Ook als je besluit om een onderdeel niet in te vullen beschrijf je dus waarom je het niet invult.

Zo kan je een plan van aanpak maken

Op de eerste pagina beginnen we met de historie van het plan, daarna volgen de andere hoofdstukken.

Historie Plan van Aanpak

versie	Actie	reactie ontvangen	verwerkt	Opmerking
Concept 1xx-xx-xxxx	Start conceptversie
Concept 2xx-xx-xxxx	Voor review naar ….
Concept 3xx-xx-xxxx	Verspreid voor gebruiker
Definitief 4xx-xx-xxxx	Tkn. MT

1. Inleiding deliverables

In de eerste paragraaf gaan we in op de achtergronden van het project. Wat was de aanleiding van het project en hoe positioneren we het project binnen de organisatie. Tevens wordt het probleem dat met het project aangepakt wordt kort geschetst.

De voorgeschiedenis stippen we aan zodat duidelijk is in welke context we naar het project moeten kijken. Hou tevens rekening met verschillende lezers. Dit kunnen zowel interne en externe medewerkers zijn, maar ook nog aan te stellen medewerkers zijn.

1.1 Doel Plan van Aanpak project

Doel van dit project is te komen tot …. In enkele korte zinnen omschrijven we het doel van het project. Het doel moeten we echter niet verwarren met de gewenste resultaten. De gewenste resultaten mogen we ook in deze paragraaf beschrijven maar dienen we wel als gewenst resultaat aan te duiden.

1.2 Afbakening Plan van Aanpak

De afbakening van een project kent twee kanten. Namelijk, wat hoort er nog wel bij het project en wat hoort er niet bij. Beide moeten we duidelijk omschrijven zodat er bij de opdrachtgever geen verkeerde verwachtingen kunnen ontstaan. Zodra we iets anders gaan doen of opleveren dan de opdrachtgever verwacht is het project eigenlijk al mislukt. Bij de afbakening hoort daarom ook een inventarisatie van elementen die het project al of niet raken.

De volgende elementen stippen we aan in de inventarisatie waarbij wordt aangegeven welke impact er van uit het project op is:

• Hardware.
• Systeemsoftware.
• Netwerk.
• Applicatiesoftware.
• Databases.
• Koppelingen met interne systemen.
• Koppelingen met externe systemen zoals SaaS.
• (kantoorautomatiserings) Bestanden.
• Embedded systemen (zoals het toegangssysteem, de faxen, de kopieerapparaten en de telefooncentrale).

1.3 Methodiek Plan van Aanpak

Veel organisaties maken gebruik van een generieke of eigen standaard ontwikkelmethodiek. Al bij de start van een project moeten we de keuze voor een methodiek maken. Het streven is bovendien om zoveel mogelijk de standaard methodiek van de organisatie te gebruiken. Eerdere ervaringen leiden dan tot versnelling. Tevens kunnen we op die manier ervaringscijfers verzamelen waardoor we later in staat bent om betere planningen te maken.

Als een externe leverancier de opdracht krijgt met daarbij de verantwoordelijk voor het eindresultaat zal hij er op aandringen om zijn eigen methodiek toe te passen. De kans van slagen is dan voor hem het grootst. In zo’n geval moeten we er echter op letten dat hij voor rapportage en dossiervorming vergelijkbare deliverables oplevert en anders of deze het minimum aan gewenste informatie verschaffen.

1.4 Project verantwoordelijkheid

Een gedecentraliseerde verantwoordelijkheid komt in veel organisatie voor. Dat wil zeggen dat afdelingen zelf verantwoordelijk zijn voor hun maatwerksystemen en onder eigen verantwoordelijkheid aangeschafte SaaS oplossingen. De afdelingsmanager is dan systeemeigenaar / opdrachtgever. De IT afdeling speelt in bepaalde projecten soms een sterk initiërende rol, vooral als het project technisch gedreven is. Daarbij moeten we bijvoorbeeld denken aan data conversies en systeem migraties naar andere platvormen. In zo’n geval zal de IT afdeling om een opdracht vragen aan het management. De meeste projecten kunnen we namelijk nooit zonder opdracht doorvoeren.

Om betrokkenen meer bewust te maken van het project organiseren we veel gevallen vooraf tevens een workshop.

Afdelingen die applicaties gebruiken die gekoppeld zijn aan het te veranderen systeem zijn zelf verantwoordelijk voor het aan brengen van de noodzakelijke modificaties. Aangezien het slagen van het project vaak afhangt van de juiste werking van deze koppelingen dient de voortgang en rapportage integraal onderdeel van dit project te zijn. De voortgang bewaken we dus binnen het project. Een en andere werken we daarom uit in de aan te leveren deliverables en de planning.

Als de infrastructuur in het project wordt geraaktm dan is de IT afdeling verantwoordelijk voor de hardware-infrastructuur en de besturingssoftware. Daaronder valt ook het netwerk. De verantwoordelijkheid voor de embedded systemen kan overal in de organisatie liggen bijvoorbeeld bij het facilitaire team.

Queries die niet onder het beheer van de leverancier of de IT afdeling vallen, zijn de verantwoordelijkheid van de eigenaar / functioneel applicatiebeheerder.

Voor de verschillende objecten stellen we in dit plan van aanpak vast welke deliverables we moeten opleveren in het kader van dit project. De projectleider is verantwoordelijk voor de voortgangsregistratie en rapportage en het melden van geconstateerde afhankelijkheden.

1.5 Einddatum project

Hier plaatsen we de deadline en geven we de hardheid daarvan aan. We beschrijven de externe factoren zoals de ingangsdatum van nieuwe regelgeving die deze deadline onderbouwen.

Het project is niet eerder afgerond tot dat alle deliverables gereed zijn of zijn ondergebracht in een vervolgproject. Pas dan kunnen we het projectteam ontbinden.

2. Projectorganisatie in het plan van aanpak

2.1 Schema project hiërarchie

In een schema wordt weergegeven hoe het project georganiseerd is. Wie rapporteert aan wie en wie zit in welke werkgroep namens welke afdeling.

Opdrachtgever:
Projectmanager:
Projectleider:
Werkgroepen:
Deelnemers:
Ondersteuning:

2.2 Project rapportage en overleg

Van onderstaande project rapportages noteren we de frequentie, plaats en tijdstip:

• De projectleider rapporteert periodiek aan de opdrachtgever.
• De werkgroepscoördinatoren stemmen periodiek af met de projectleider over de voortgang, (te verwachten) knelpunten en planning.
• Overleg tussen coördinatoren en werkgroepen.
• Overleg tussen projectgroep en eindgebruikers.
• Rapportage aan de accountants betreffende de impact van het project.
• Overleg met de beveiligingsfunctionaris betreffende de impact van het project.
• De lijst met geïnventariseerde en geanalyseerde objecten sturen we ter verificatie aan de beheerders.
• Reviews op de deliverables binnen de kaders van dit project zullen aan te wijzen medewerkers uitvoeren.

2.3 Project procedures

Voor het verdere verloop van de aan te brengen aanpassingen maken we veelal gebruik van de bestaande procedures. De organisatie kent vaak al een Change Management procedure. We moeten in het plan dus naar deze standaard procedures verwijzen. Tevens dienen we duidelijk te maken op welke locatie de projectorganisatie gevestigd is en hoe deze bereikbaar is.

2.4 Kwaliteitsbewaking project

Voor de bewaking van de kwaliteit van de deliverables is een aantal mechanismen te onderkennen. Dit kunnen zijn :

a.   Inspecties.
b.  Acceptatietesten.
c.   Reviews.
d.  Audits.

Niet al deze mechanismen passen we toe op ieder projectonderdeel. De toepassing is namelijk sterk afhankelijk van de omvang, het computerplatform en de aard van het projectonderdeel. De acceptatietest is echter een vast onderdeel van het project en is voor ieder projectonderdeel van toepassing. Tevens kunnen derden deliverable reviews op verzoek de gebruikersorganisatie uitvoeren. Het initiatief voor een projectaudit ligt echter meer op de weg van de opdrachtgever. Audits kennen een specifieke opdracht en worden meestal door een daarin gespecialiseerde organisatie uitgevoerd. Voor de kwaliteitsbewaking van embedded systemen kunnen we een aparte acceptatieprocedure opstellen.

3. Projectfasering in het plan van aanpak

3.1 Schema projectfasering

Een implementatieproject voeren we meestal uit in een aantal fases. In deze projectfases zijn dan meerdere (gebruikers)afdelingen en personen betrokken. De uitvoering van de aanpassingen is echter per onderdeel verschillend en afhankelijk van de systeemeigenaar (afdelingsmanager) die de opdrachten aan uitvoerenden verstrekt.

Voor de volledigheid brengen we de fasering van het totale project in beeld met behulp van een schema. Zo maken we de volgorde van de fasering duidelijk.

3.2 Beschrijving projectfases

Deze paragraaf beschrijft de verschillende fases en hun doel.

4. Activiteiten per gedefinieerde projectfase

De onderkende projectfases kennen een aantal activiteiten die per fase overeen komen. Het verschil zit in de diepgang en de aard van de werkzaamheden waar de activiteiten betrekking op hebben. Het doel van de activiteiten is de realisatie van de deliverables zoals die in paragraaf 6 zijn beschreven. De volgende activiteiten zijn per fase onderkend:

• Afstemmen plan van aanpak van het project.
• Actualiteit vaststellen van de inventarisatie.
• Bespreken projectvoortgang van volgens de projectplanning te nemen stappen.
• Aanpassen strategie n.a.v. geboekte voortgang.
• Aanpassen strategie n.a.v. geïnventariseerde projectrisico’s.
• Rapportage van projectvoortgang aan de opdrachtgever.
• Review op deliverables per fase.

5. Benodigde en besteedbare capaciteit van het project

5.1 Benodigd

Aangezien de omvang van een project bij de start vaak nog niet duidelijk is, is het vaak moeilijk om de benodigde inzet in te schatten. De benodigde hoeveelheid tijd schatten we daarom in op basis van de inventarisatie. Naarmate het project vordert kunnen we de benodigde tijd echter steeds beter bepalen. De beschikbare hoeveelheid tijd of de einddatum van het vooronderzoek kan je dan zo nodig bijstellen.

5.2 Besteedbaar t/m einddatum

Aangegeven wordt wie voor hoe lang voor hoeveel tijd voor dit project wordt vrijgesteld. Daarbij wordt tevens de rol van deze personen aangegeven.

6. Projectplanning en deliverables in het plan van aanpak

Bij omvangrijke projecten gebruiken we meestal een planningstool. Bij kleinere projecten volstaat echter het te werken met een lijstje. In beide gevallen dienen we een beschrijving in het plan van aanpak op te nemen.

6.1 Fase 1 t/m X

	Deliverable	Op te leveren op	Afgerond op

6.2 Korte omschrijving per deliverable

Fase 1
6.1.1     Eerste identificatie van projectonderdelen
Ingevulde inventarisatie lijst
6.1.2     Rapportage t.b.v. …
Opgesteld rapport van …

6.1.3     Plan van aanpak
6.1.4     Voortgangsrapportage project
6.1.X     Eindrapport per projectfase
In een kort verslag geven we weer hoe de activiteiten zijn verlopen en bovendien welke beslissingen binnen de fase zijn genomen.

7. Projectrisico’s en maatregelen in het plan van aanpak

Opsomming van denkbare risico’s. Ze kunnen van project tot project verschillen.

	Projectrisico	Maatregel
1.	Niet alle projectonderdelen worden gedetecteerd	– Tijdens de testfase moeten we alle kritische systemen testen.
2.	Tempo van geplande activiteiten is niet in overeenstemming met het tempo dat de gebruikersorganisatie aan kan. Een gevolg van andere spoedeisende werkzaamheden of capaciteitsproblemen.	– Potentiële problemen worden ruimer gepland voor de betreffende applicatie. Voortgang wordt aan MT gerapporteerd.- Capaciteit vergroten.
3.	Geen / onvoldoende medewerking beheerders/ medewerkers.	– Potentiële problemen worden ruimer gepland voor de betreffende applicatie. Voortgang wordt aan MT gerapporteerd.- D.m.v. workshop zal bewustwording moeten plaatsvinden.
4.	De inventarisatie is een momentopname, mogelijk dat er zich na de inventarisatie nieuwe problemen voordoen.	– Alle nieuwe programmatuur en onderhoud dient aan de nieuwe eisen te voldoen.
5.	Er worden vele onverwachte problemen gevonden, zodat de planning niet gehaald kan worden en/of onvoldoende kwaliteit kan worden gegarandeerd.	– Evalueren en bijstellen prioriteiten en strategieën (bijvoorbeeld minder belangrijke software later aanpassen of juist uitfaseren).- Capaciteit vergroten.  – Tevens noodscenario ontwikkelen.
6.	Een systeem zal worden uitgefaseerd en het alternatief bestaat nog niet.	– Signaleren en overleg met leveranciers. – Tevens noodscenario ontwikkelen.
7.	Er wordt te weinig onderhoudsbudget vrij gemaakt om het informatiesysteem aan te passen.	– Applicatie-eigenaren moeten van de ernst en noodzaak worden doordrongen en het onderhoud ruim voldoende inplannen.
8.	Er is onvoldoende documentatie.	– Rekening mee houden in de projectplanning.
9.	Buitenwereld sluit nog niet aan.	– Tijdelijke interface bouwen.- Wijzen op gevolgen.
10.	Er is geen sourcecode meer beschikbaar	– Nieuwbouw of SaaS selecteren.  Tevens rekening houden met beschikbare capaciteit.

Discussieer mee op LinkedIn.