Plan van aanpak voorbeeld

Hoe groot of hoe klein moet je een plan van aanpak maken? Welke onderdelen neem je er in op en welke niet? Het hangt af van de aard en de omvang van een project. In deze bijdrage wordt in een uitgebreid voorbeeld aangegeven hoe je een plan van aanpak moet schrijven. Haal er uit wat je nodig hebt, maar beter is het om alle elementen te beschrijven zodat men weet dat er rekening is gehouden met deze elementen. 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

Historie Plan van Aanpak        

versieActiereactie ontvangenverwerktOpmerking
Concept 1xx-xx-xxxxStart conceptversie
Concept 2xx-xx-xxxxVoor review naar ….
Concept 3xx-xx-xxxxVerspreid voor gebruiker
Definitief 4xx-xx-xxxxTkn. MT

1. Inleiding Plan van Aanpak

In de eerste paragraaf wordt ingegaan 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 wordt aangestipt zodat duidelijk wordt in welke context het project moet worden gezien. Hou rekening met verschillende lezers. Dit kunnen zowel interne medewerkers als externe, 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 wordt het doel omschreven. Het doel moet niet verward worden met de gewenste resultaten. De gewenste resultaten mogen ook in deze paragraaf worden beschreven maar dienen wel als gewenst resultaat aangeduid te worden.

1.2 Afbakening Plan van Aaanpak

De afbakening van een project kent twee kanten. Wat hoort er nog wel bij het project en wat hoort er niet bij. Beide moeten duidelijk worden omschreven zodat er bij de opdrachtgever geen verkeerde verwachtingen kunnen ontstaan. Zodra je iets anders gaat doen of oplevert dan de opdrachtgever verwacht is het project eigenlijk al mislukt. Bij de afbakening hoort daarom ook een inventarisatie van elementen die door het project al of niet worden geraakt.

De volgende elementen worden aangestipt in de inventarisatie waarbij wordt aangegeven welke impact er van uit het project op is:

  • hardware
  • systeemsoftware
  • netwerk
  • applicatiesoftware
  • databases
  • (kantoorautomatiserings)bestanden
  • Embedded systemen (zoals het toegangssysteem, de faxen, de kopieerapparaten en de telefooncentrale.)

1.3 Methodiek Plan van Aanpak

Veel organisaties kennen een generieke of eigen standaard ontwikkelmethodiek. Bij de start van een project moet de keuze voor een methodiek worden gemaakt. Het streven is om zoveel mogelijk de eigen methodiek toe te passen. De eerder gedane ervaring leidt dan tot versnelling. Tevens worden op die manier ervaringscijfers verzameld waardoor men later in staat is om betere planningen te maken.

Als een externe leverancier de opdracht krijgt en daarbij 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 moet er op worden gelet dat voor rapportage en dossiervorming vergelijkbare mijlpaalproducten worden opgeleverd en of die het minimum aan gewenste informatie verschaffen.

1.4 Project verantwoordelijkheid

Veel organisaties kennen een gedecentraliseerde verantwoordelijkheid, d.w.z. dat afdelingen zelf verantwoordelijk zijn voor hun maatwerksystemen en onder eigen verantwoordelijkheid aangeschafte systemen. Het afdelingshoofd is dan systeemeigenaar / opdrachtgever. De ICT afdeling speelt in bepaalde projecten soms een sterk initiërende rol, vooral als het project technisch gedreven is. Daarbij moet worden gedacht aan data conversies en system migraties naar andere platvormen. In zo’n geval zal de ICT afdeling om een opdracht vragen aan de systeemeigenaar. Aanpassingen kunnen feitelijk nooit zonder opdracht worden doorgevoerd.

Om betrokkenen meer bewust te maken van het project wordt in veel gevallen vooraf een workshop georganiseerd.

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 bij dit project mee te lopen. De voortgang wordt wel binnen het project bewaakt. Een en andere vindt zijn uitwerking in de aan te leveren mijlpaalproducten en de planning.

De ICT afdeling is verantwoordelijk voor de hardware-infrastructuur en de besturingssoftware waaronder het netwerk, de verantwoordelijkheid voor de embedded systemen kan overal in de organisatie liggen b.v. bij de huishoudelijke dienst.

Queries die niet onder het beheer van een onderhoudsteam vallen, zijn de verantwoordelijkheid van de eigenaar / functioneel applicatiebeheerder.

Voor de verschillende objecten zal in dit plan van aanpak worden vastgesteld welke mijlpaalproducten moeten worden opgeleverd 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 de deadline en de hardheid daarvan, beschreven eventueel onderbouwd met externe factoren zoals de ingangsdatum van nieuwe regelgeving.

Het project is niet eerder afgerond tot dat alle mijlpaalproducten gereed zijn of zijn ondergebracht in een vervolgproject. Pas dan kan het projectteam worden ontbonden.

2 Projectorganisatie

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 dienen frequentie, plaats en tijdstip genoteerd te worden.

  • 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.
  • Overleg met de accountantsdienst betreffende de impact van het project.
  • Overleg met de beveiligingsfunctionaris betreffende de impact van het project.
  • De lijst met geïnventariseerde en geanalyseerde objecten wordt ter verificatie aan de beheerders aangeboden.
  • Reviews op de mijlpaalproducten binnen de kaders van dit project zullen door aan te wijzen medewerkers.

2.3 Project procedures

Voor het verdere verloop van de aan te brengen aanpassingen kan veelal gebruik worden gemaakt van de geldende procedures. De organisatie kent vaak al een Change Management procedure. Naar deze toe te passen standaard procedures dient te worden verwezen. Tevens dient duidelijk gemaakt te worden op welke locatie de projectorganisatie gevestigd is en hoe deze bereikbaar is.

2.4 Kwaliteitsbewaking project

Voor de bewaking van de kwaliteit van de mijlpaalproducten worden een aantal mechanismen onderkend. Dit kunnen zijn :

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

Niet al deze mechanismen zullen voor ieder projectonderdeel worden toegepast. De toepassing is sterk afhankelijk van de omvang, het computerplatform en de aard van het projectonderdeel. De acceptatietest is echter een vast onderdeel van de projectfasering en zal meestal wel voor ieder projectonderdeel van toepassing zijn. Mijlpaalreviews worden op verzoek de gebruikersorganisatie door derden uitgevoerd, terwijl het initiatief voor een projectaudit meer op de weg van de opdrachtgever ligt. Audits kennen een specifieke opdracht en worden meestal door een daarin gespecialiseerde organisatie uitgevoerd. Voor de kwaliteitsbewaking van  embedded systemen kan een aparte acceptatieprocedure worden opgesteld.

3. Projectfasering

3.1 Schema projectfasering

Een project wordt meestal in een aantal fases uitgevoerd. In deze projectfases zijn meerdere (gebruikers)afdelingen en personen betrokken. De uitvoering van de aanpassingen is per onderdeel verschillend en afhankelijk van de systeemeigenaar (afdelingshoofd) die de opdrachten aan uitvoerenden verstrekt.

Voor de volledigheid wordt de fasering van het totale project in beeld ingebracht met behulp van een schema. Zo wordt de volgorde van de fasering duidelijk.

3.2 Beschrijving projectfases

In deze paragraaf worden de verschillende fases en hun doel beschreven.

4. Activiteiten per gedefinieerde projectfase

De onderkende projectfases kennen een aantal activiteiten die per fase gelijk zijn. 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 mijlpaalproducten zoals die in 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 mijlpaalproducten 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 zal worden ingeschat op basis van de inventarisatie. Naarmate het project vordert kan de benodigde tijd steeds beter worden bepaald. De beschikbare hoeveelheid tijd of de einddatum van het vooronderzoek kunnen dan zo nodig worden bijgesteld.

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 mijlpalen

Bij omvangrijke projecten wordt meestal een planningstool gebruikt. Bij kleinere projecten volstaat het te werken met een lijstje. In beide gevallen dient een beschrijving in het plan van aanpak te worden opgenomen.

6.1 Fase 1 t/m X

MijlpaalproductOp te leveren opAfgerond op

6.2 Korte omschrijving per mijlpaalproduct

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 wordt weergegeven hoe de activiteiten zijn verlopen en welke beslissingen binnen de fase zijn genomen.

7. Projectrisico’s en maatregelen

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

 ProjectrisicoMaatregel
 1.Niet alle projectonderdelen worden gedetecteerd– Tijdens de testfase moeten alle kritischesystemen worden getest.
 2.Tempo van geplande activiteiten is niet in overeenstemming met het tempo dat de gebruikersorganisatie aan kan a.g.v. 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.

– Noodscenario ontwikkelen.

 6.Een systeem zal worden uitgefaseerd en het alternatief bestaat nog niet.– Signaleren en overleg met leveranciers.
– 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 pakket selecteren.  Rekening houden met beschikbare capaciteit.

Boeken over dit onderwerp

PMC Compact

Auteur: Jo Bos
Vele malen kwam het verzoek om de belangrijkste principes en werkvormen van de methode Projectmatig Creeëren in een compacte uitgave samen te brengen. In ‘PMC Compact’, een handzame gids voor projectmanagers, opdrachtgevers en teamleden, vindt u de werkvormen van Projectmatig Creëren in overzichtelijke stappen uitgelegd, voorzien van veel tips uit de praktijk.
Europrijs: 18,95
Bestellen

Projectmanagement op basis van PRINCE2, Editie 2009

Auteur: Bert Hedeman
Ten eerste is dit boek bedoeld voor iedereen die zich op een degelijke wijze wil voorbereiden op het PRINCE2 Foundation examen. Ten tweede is het een praktisch gebruikersboek.
Europrijs: 31,75
Bestellen

Meer boeken over plan van aanpak vinden.

Summary
Plan van aanpak voorbeeld
Article Name
Plan van aanpak voorbeeld
Description
Welke onderdelen neem je op in een plan van aanpak en welke niet? Het hangt af van de aard en de omvang van een project. In dit artikel wordt in een uitgebreid voorbeeld aangegeven hoe je een plan van aanpak moet schrijven.
Author
Publisher Name
ITpedia
Publisher Logo

-- Printbare PDF-versie --


No votes yet.
Please wait...

Aanvullingen

Geef zelf een aanvulling.

Geef een aanvulling

Licentie: Creative Commons (Naamsvermelding/Gelijkdelen)

Checklisten:
Planning Business analyse 10 vragen.
Planning Vooronderzoek 25 vragen.
Planning Informatie analyse 21 vragen.
Planning Ontwerp 24 vragen.
Planning Realisatie 45 vragen.
Planning Invoering 29 vragen.
Sidebar