Het plan van aanpak, een hele klus

Transcriptie

1 Het plan van aanpak, een hele klus door Wim Hoe groot of hoe klein maak je een plan van aanpak? 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 een uitgebreid concept voor een plan van aanpak beschreven. 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. Historie Plan van Aanpak versie Actie reactie ontvangen verwerkt Opmerking Concept Start conceptversie 1xx-xx-xxxx Concept 2xx-xx-xxxx Voor review naar. Concept Verspreid voor gebruiker 3xx-xx-xxxx Definitief Tkn. MT 4xx-xx-xxxx Inleiding In deze paragraaf wordt ingegaan op de achtergronden van het project. Wat was de aanleiding en hoe positioneren we het binnen de organisatie. Tevens wordt het probleem dat met het project aangepakt moet worden 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 Doel 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. 2 Afbakening page 1 / 6

2 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.) 3 Methodiek 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. 4 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 conversies en 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/applicatiebeheerder. page 2 / 6

3 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. 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 vervolg project. Pas dan kan het projectteam worden ontbonden. 2 Projectorganisatie 2.1 Schema 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 Rapportage en overleg Van onderstaande 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 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 de toe te passen procedures dient te worden verwezen. Tevens dient duidelijk gemaakt te worden op welke locatie de projectorganisatie gevestigd is. 2.4 Kwaliteitsbewaking Voor de bewaking van de kwaliteit van de mijlpaalproducten worden een aantal mechanismen onderkend. Dit kunnen zijn : page 3 / 6

4 a. Inspecties b. Acceptatietesten c. Reviews en d. Audits Niet al deze mechanismen zullen voor ieder onderdeel worden toegepast. De toepassing is sterk afhankelijk van de omvang, het platform en de aard van het onderdeel. De acceptatietest is echter een vast onderdeel van de fasering en zal meestal wel voor ieder onderdeel van toepassing zijn. Reviews worden op verzoek van de gebruikersorganisatie door derden uitgevoerd, terwijl het initiatief voor een audit 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. Fasering 3.1 Schema Een project wordt meestal in een aantal fases uitgevoerd. In deze fases zijn meerdere 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 fases In deze paragraaf worden de verschillende fases en hun doel beschreven. 4. Activiteiten per gedefinieerde fase De onderkende fases 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 Actualiteit vaststellen van de inventarisatie Bespreken voortgang van volgens planning te nemen stappen Aanpassen strategie n.a.v. geboekte voortgang Aanpassen strategie n.a.v. geïnventariseerde risico s Rapportage van voortgang aan de opdrachtgever Review op mijlpaalproducten per fase 5. Benodigde en besteedbare capaciteit 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. page 4 / 6

5 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. Planning 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 Mijlpaalproduct Op te leveren op Afgerond op page 5 / 6

6 6.2 Korte omschrijving per mijlpaalproduct Fase Eerste identificatie van onderdelen Ingevulde inventarisatie lijst 6.2 Rapportage t.b.v. Opgesteld rapport van 6.3 Plan van aanpak 6.4 Voortgangsrapportage 6.X Eindrapport per fase. In een kort verslag wordt weergegeven hoe de activiteiten zijn verlopen en welke beslissingen binnen de fase zijn genomen. 7. Risico s en maatregelen Opsomming van denkbare risico s. Ze kunnen van project tot project verschillen. Risico Niet alle onderdelen worden gedetecteerd Maatregel - Tijdens de testfase moeten alle kritischesystemen w getest. Tempo van geplande activiteiten is niet in overeenstemming met het tempo dat de gebruikersorganisatie aan kan a.g.v. andere spoedeisende werkzaamheden. -Potentiële problemen worden ruimer gepland voor de applicatie. Voortgang wordt aan MT gerapporteerd.- C vergroten. Geen / onvoldoende medewerking beheerders/ medewerkers. -Potentiële problemen worden ruimer gepland voor de applicatie. Voortgang wordt aan MT gerapporteerd.- D workshop zal bewustwording moeten plaatsvinden. De inventarisatie is een momentopname, mogelijk dat er zich na de inventarisatie nieuwe problemen voordoen. - Alle nieuwe programmatuur en onderhoud dient aan eisen te voldoen. Er worden vele onverwachte problemen gevonden, zodat de planning niet gehaald kan worden en/of onvoldoende kwaliteit kan worden gegarandeerd. page 6 / 6