projectmanagement

Gebruik de 522 IT checklisten van ITpedia, met in totaal 22028 vragen.

Zoek in de omschrijvingenOmschrijvingAantal vragen
IT projectfaseringBestaat uit meerdere checklisten
Application Services Library (ASL)Bestaat uit meerdere checklisten
ContinuïteitBestaat uit meerdere checklisten
KwaliteitsattributenBestaat uit meerdere checklisten
Functies in de automatiseringBestaat uit meerdere checklisten
WebdesignBestaat uit meerdere checklisten
Of zoek naar een woord: Fulltekst

Laatst gebruikt: Continuiteitsbeheer op: 2017-02-26 09:32 Checklist
Toezenden van eerdere beoordelingen per e-mail.
E-mailadres:

Opdrachtgeverschap met programma’s en projecten

De conclusies die de Rekenkamer trok in haar rapport “Lessen uit ICT-projecten bij de overheid” waren niet mals. Volgens de Rekenkamer zouden de ministers hun verschillende rollen (o.a. bestuurlijk verantwoordelijk voor de uitvoering, ambtelijk opdrachtgever) beter kunnen invullen wanneer zij meer realistisch zouden zijn in hun ambities en wanneer zij meer grip zouden houden op […]

Project Management Office (PMO) Assessment Checklist

De functies van een PMO volgens de Wikipedia De Wikipedia meent dat het artikel over PMO’s te weinig referenties bevat. Het is daarom onvolledig. Over het PMO staat er (de vertaling is van mij): De minimale PMO functies zijn standaarden en methodologie. Ook functies als Strategisch Project Management zowel als facilitator of als eigenaar van […]

Van Hans Lodder op 3 februari 2011 | Methoden | 2 aanvullingen
Tags:, ,
Checklisten: 4

Het plan van aanpak, een hele klus

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.  [Klik op de titel voor het gehele artikel]

Minimale taakverdeling bij Automatiseringsprojecten is essentieel.

Automatiseringsprojecten wijken niet af van andere project. Specifiek is wel dat deze zich afspelen op een snijvlak van complexe techniek, wisselende prioriteiten en formele procedures. De ervaring leert dat het vele malen effectiever is om in een vroeg stadium duidelijkheid te hebben, op basis waarvan alle partijen zich kunnen binden, dan om dit te doen nadat er al veel is geïnvesteerd in een project. [Klik op de titel voor het gehele artikel]


De projectorganisatie: stuurgroep, projectgroep, werkgroep

Project organisatieDe fase Informatie Analyse aan het begin van een project is de belangrijkste fase. Veel gebruikers beseffen dit echter niet omdat de opleverdatum nog ver weg is en er slechts enkele personen met de Informatie Analyse bezig zijn die voornamelijk lastige vragen stellen. Tenslotte komen van deze personen allerlei fraaie documenten over zaken die de gebruiker gezegd zou hebben en een ruwe schets van een systeem dat wel Science  Fiction lijkt waarvan nauwelijks is voor te stellen dat het ooit zal werken.

Begrijpelijk dat men slechts een paar aanvullende vragen stelt en het verder wel goed vindt.

Deze fout moet men dus vooral niet maken. In de Informatie Analyse worden namelijk zeer belangrijke beslissingen genomen die bepalend zijn voor het welslagen van het project en de levensduur van het informatiesysteem, beslissingen die alleen met zeer veel moeite en kosten zijn terug te draaien. In deze fase worden de verwachtingen van de gebruiker omgezet in eisen. Aan het einde van deze fase mogen er geen onbeschreven vanzelfspreken­de behoeften meer zijn.

Het is daarom van het grootste belang om de rapporten van de Informatie Analyse kritisch te beoordelen.

Instelling projectorganisatie.

Stuurgroep, Projectgroep, Werkgroep

De kans van slagen van een project is in hoge mate afhankelijk van de acceptatie van het uiteindelijke informatiesysteem. Dit is één van de belangrijkste risicofactoren die bij automatiseringsprojecten spelen. Dit risico is te vermijden door de gebruikers belangrijke taken in het project te laten vervullen. Hierdoor komt een groot deel van de kijk en de beleving van de gebruiker in het informatiesysteem terecht terwijl er geen afstand bestaat tussen gebruiker en ontwikkelaar. De gebruiker is medeplichtig aan het eindpro­duct en weet waarom bepaalde wensen niet in het systeem zijn opgenomen. Om dit te benadrukken wordt in veel gevallen een gebruiker als projectleider aangesteld.

Bij de start van het project is sprake van een groep materiedeskundige gebruikers die weinig van automatisering weten en een groep automatiseerders die weinig materieken­nis heeft. Het is de taak van de projectleider dat deze groepen elkaars taal gaan spreken en samen een hecht team gaan vormen. Om deze communicatie in goede banen te leiden bestaan beproefde organisatievormen.

Elke ontwikkelfase begint met activiteiten die een rapport opleveren genaamd “Uit­gangspunten/Plan van aanpak”. In dit rapport beschrijft de projectleider van die fase hoe hij de komende fase denkt te realiseren. Per fase worden een planning en een begroting gemaakt zodat de stuurgroep de voortgang en de kosten van de fase kan bewaken. Hiervoor bepaalt de projectleider met welke producten deze fase moet opleveren, welke middelen hij daarvoor nodig heeft en welke functionarissen hij daarvoor wil inzetten. Als dit bekend is kan de organisatie per fase worden vastge­steld.

Bij de checklisten is de activiteit “bepaal uitgangspunten en maak plan van aanpak” altijd als eerste bij een fase opgenomen. Bij een keuze voor deze activiteit kan een checklist worden gekozen die betrekking heeft op de organisatie.

Binnen een project kunnen de meest uitgebreide checklisten voor de organisatie worden gevonden bij “Informatie Analyse”. in veel gevallen wordt namelijk bij de start van de Informatie Analyse de organisatie voor het gehele project al bepaald.

Afhankelijk van de omvang van het project worden een stuurgroep, een projectgroep en een aantal werkgroepen ingesteld. Bij kleine projecten is meestal alleen sprake van een project­groep.

De taakverdeling van deze groepen is als volgt :

1. De stuurgroep heeft de hoogste leiding over het project terwijl de stuurgroepleden zich niet met de dagelijkse werkzaamheden voor het project bezig houden. Zij komen dan ook één of twee maal per maand bijeen. Aan de stuurgroep wordt gerapporteerd over de voortgang van het project terwijl de stuurgroep de voorwaar­den schept in tijd en geld om deze voortgang te realiseren. Dit gebeurt na goedkeu­ring van aan de stuurgroep voorgelegde rapporten waarin de projectgroep de beslissingen heeft voorbereid.

De stuurgroep bestaat doorgaans uit slechts een klein aantal personen zoals bijvoorbeeld een directielid, de accountant, de ICT manager en de projectleider.

2. De projectgroep vormt de dagelijkse leiding over het project en komt vaak, minimaal eens per week, bijeen. De voorzitter van de projectgroep is meestal de projectleider. De andere projectgroepleden zijn verantwoordelijk voor de producten die het project moet opleveren of voor de controle op de inhoud van die producten. Zo zal de systeemontwerper de ontwerpen maken terwijl het hoofd van de auditorgroep bijvoorbeeld controleert of de functiescheiding wel gewaarborgd blijft. De perso­neelsfunctionaris zal op zijn beurt weer letten op de personele consequenties binnen de organisatie van het ontwerp.

Naast de projectleider kunnen de volgende functionarissen in de projectgroep zitting hebben:
Automatiseerders;
Materiedeskundigen (eindgebruikers);
Controle functionarissen;
Personeelsfunctionarissen;
Technische systeembeheerders;
Applicatiebeheerders;
Organisatie adviseurs;
Enzovoort.
De samenstelling is afhankelijk van de aard van het project.

3. De werkgroep. Bij omvangrijke projecten kan de projectgroep het werk niet alleen tenzij er een enorm grote groep zou ontstaan. Bij zo’n grote groep zouden de vergaderingen chao­tisch worden en de projectleider zou geen zicht meer hebben op de verschillen­de producten. Daarom worden vaak werkgroepen in het leven geroepen die ieder belast zijn met één aspect van het project.

Deze werkgroepen zijn verantwoordelijk voor hun eigen resultaten en verantwoor­ding verschul­digd aan de projectgroep.

De volgende werkgroepen zijn bijvoorbeeld denkbaar :
– Werkgroepen voor de ontwikkeling van de diverse deelsystemen.
– Een werkgroep Opleiding.
– Een Testwerkgroep.
– Een werkgroep Administratieve Organisatie.
– Een werkgroep Conversie.
– Een werkgroep Invoering.
– Een werkgroep Nazorg.
– Een werkgroep Juridische aspecten (Wet Persoons Registratie).

Juist in deze werkgroepen kunnen gebruikers goede diensten verlenen.

Automatiseringsprojecten met meer dan veertig personen in de diverse werkgroepen komen regelmatig voor terwijl projecten met meer dan honderd personen ook voorko­men. In deze situaties is het van het grootste belang dat de informatie-uitwisseling tussen de diverse groepen goed is geregeld. Misverstan­den kunnen de voortgang en de sfeer binnen een project namelijk goed dwars zitten. Bij de organisatie van de groepen wordt daarom het linking-pin principe geadviseerd. Dat wil zeggen dat de voorzitters van de werkgroepen lid zijn van de projectgroep en dat de voorzitter van de projectgroep lid is van de stuurgroep. Daarnaast moet worden gelet op de vergadermomenten van de groepen. Deze moeten goed op elkaar zijn afgestemd zodat dat er niet veel tijd zit tussen het moment dat een product klaar is en het moment waarop het in een andere groep wordt behandeld.

Bijzondere aandacht gaat uit naar de werkgroepleden die niet volledig voor het project worden vrijgesteld. Zij moeten voldoende ondersteuning krijgen zodat beide taken tot een goed einde kunnen komen.


-- Printbare PDF-versie --