Samenvatting PPF
1. Project Definitie
Werkvormen binnen organisaties:
1) Improviserend:
- geschikt voor het bedenken van iets nieuws
- ongeschikt als iets op een bepaald tijdstip aan bepaalde eisen moet voldoen.
2) Routinematig:
- geschikt voor dingen die in procedures zijn vastgelegd, dus voor werk dat vaak herhaald wordt.
- ongeschikt als je met meerdere mensen aan het product moet werken
3) Projectmatig:
- geschikt voor een groepsproduct waarin weinig geimproviseerd hoeft te worden en waarbij geen uitgewerkte procedures voorhanden zijn.
1.1. Kenmerken van een project.
Een project en het resultaat van een project voldoet aan de volgende kenmerken:
1) eenmalig: dus wel de ontwikkeling van een nieuw informatiesysteem, maar niet het beheer van het nieuwe informatiesysteem.
2) multidisciplinair: want wanneer het binnen één afdeling zou plaatsvinden, kan het in de reguliere organisatie worden gecoordineerd. Bij de betrokkenheid van meerdere disciplines kan de projectorganisatie een oplossing bieden.
3) begrensd in tijd: van te voren wordt bepaald hoe de verhouding tussen de totale kosten van het project en hoeveel er met het resultaat verdient kan worden afgewogen. Op basis daarvan (kosten die je wil maken) is de tijd beperkt. Hoe langer een project duurt, hoe duurder het is. Verder hebben de meeste mensen die in een project werken ook nog hun reguliere taken, en zijn dus niet onbeperkt inzetbaar. Dus de uit te voeren taken moeten begrensd zijn in tijd om geschikt te zijn voor een projectmatige aanpak.
4) resultaatgericht: er moet een duidelijk gedefineerd resultaat zijn zodat tijdens het project regelmatig gekeken kan worden of je op de juiste weg bent, hoever je bent en of het oorspronkelijke doel nog haalbaar is. De projectmanager houdt dit in de gaten.
5) organisatorische consequenties: een project vraag veel van een organisatie (tijd en geld investeren in nieuwe systemen). Dat kan alleen als het management erachter staat, en die zullen dat alleen doen als de consequenties voor de organisatie gewenst zijn. Deze consequenties zullen duidelijk gemaakt moeten worden (denk aan verwachte besparingen en volgen of voorblijven van de concurrentie).
Voordelen van projectmatig werken (mist werkzaamheden voldoen aan bovengenoemde kenmerken)
1) Goede beheersing: er wordt veel tijd besteed aan planning (welke werkzaamheden en hoeveel tijd kosten die, en welke afhankelijkheden zijn er tussen werkzaamheden)
2) Heldere afspraken: er wordt nauwkeurig vastgelegd wat we willen bereiken en wie daarvoor verantwoordelijk is; een goed projectplan heeft de goedkeuring van alle betrokkenen.
3) Verbetering samenwerking: door mensen vanuit verschillende disciplines formeel aan een project toe te wijzen wordt de onderlinge communicatie gestimuleerd en dit kan een positief effect hebben op de mate waarin mensen samenwerken.
4) Zelfstandig functioneren: In het projectplan worden taken aan mensen toegewezen. De projectmedewerkers moegen deze binnen de grenzen van het project (tijd en geld) zelfstandig uitvoeren. Ze zijn zelf verantwoordelijk en rapporteren aan de projectleider.
5) Grotere betrokkenheid: duidelijk is wie waarvoor verantwoordelijk is en welke vervolgtaken afhankelijk zijn van het door de projectleden opgeleverde resultaten. Hierdooor voelen mensen zich betrokken bij het project.
Nadelen van projectmatig werken (in sommige situaties):
1) (Te) duur: er is veel tijd nodig voor plannen en vergaderen en de betrokkenheid van verschillende disciplines is duur.
2) Bureaucratisch: de projectleider moet duidelijk inzicht hebben in de voortgang, dus moeten er veel rapportages worden vastgelegd, veel documenteren, rapporteren en accorderen.
3) Onderschatting van de rol van de projectleider: de projectleider is de spil in de projectorganisatie. Deze moet dus voldoende tijd ter beschikking hebben, en genoeg kennis en ervaring hebben.
4) Spanning bestaande organisatie: spanning kan veroorzaakt worden doordat de lijnmanager iemand aan een project toewijst, maar geen oplossing geeft voor de normale taken of doordat door plotselinge verschuiving van prioriteiten een project ineens als minder belangrijk kan worden gezien.
1.2. Succes en succesfactoren van een project.
Ook al wegen de voordelen van projecten op tegen hun nadelen, dan wil dat nog niet zeggen dat het projecten ook altijd succesvol zijn.
Voorwaarden voor succes zijn:
1) Het project heeft een duidelijk begin en eind: alleen dan kan de projectleider goed plannen en kan de lijnmanager de herverdeling van het reguliere werk goed regelen.
2) Het project moet een belangrijk,noodzakelijk resultaat opleveren: bij het begin van het project moet duidelijk zijn dat het project niet halverwege afgeblazen moet worden omdat er onvoldoende middelen beschikbaar zijn gesteld en dat het project voldoende steun van de organisatie heeft. Dat krijg je alleen als het resultaat als belangrijk of noodzakelijk wordt ervaren door de organisatie.
3) Het project moet een zekere mate van tijdsdruk en beperking van middelen hebben: uitstel leidt tot afstel, beschikken over te veel geld en/of te veel tijd of andere middelen draagt het risico in zich te vrijblijvend te zijn.
4) Het project ken maar één opdrachtgever: deze heeft de beslissende stem voor het nemen van beslissingen over bijvoorbeeld het bijstellen van tijdslijnen, prioriteiten of resultaten.
5) De beschikbaarheid van mensen voor het project moet afdwingbaar zijn: de projectleider moet een beslissende stem (mandaat) hebben over de tijd dat mensen aan een project zijn toegewezen.
6) Binnen het project moet een bereidheid tot samenwerken zijn: iedereen die betrokken is bij het project moet bereid zijn tot samenwerken. Beste middel om dat te verkrijgen: duidelijkheid over het belang van het resultaat. Een goed projectleider heeft inzicht in de factoren die een rol spelen bij de bereidheid tot samenwerken en probeert daar goed mee om te gaan.
Specifieke succesfactoren bij projectmatig werken:
1) Organisatie: Noodzakelijk zijn een goede projectleider en een duidelijk geformuleerde projectopdracht. Taken, verantwoordelijkheden en hierarchie moeten helder zijn.
2) Werkwijze: Er moeten duidelijke afspraken worden gemaakt over hoe er gewerkt wordt; hoe en wat rapporteren (o.a. tijdregistratie) en conflicthantering.
3) Medewerkers: De projectleden moeten kennis van zaken hebben over datgene waarvoor zij verantwoordelijk zijn, zij moeten een representatieve rol naar bijvoorbeeld de afdeling hebben (en bij voorkeur hierbinnen mandaat hebben) en zij moeten beschikbaar zijn voor de tijd van het project.
4) Omgeving: De haalbaarheid en het belang van het project moet voor iedereen in de directe omgeving van het project duidelijk zijn. Dit moet dan ook duidelijk gecommuniceerd en gedocumenteerd worden. Dit is een aandachtspunt voor en tijdens de looptijd van het project.
2. Project Techniek
Project techniek heeft betrekking op het leiden, beheersen en (bij)sturen van projecten.
Binnen een project zijn twee soorten activiteiten te onderscheiden:
1) inhoudelijke activiteiten: afhankelijk van het project.
2) beheersmatige activiteiten: onafhankelijk van het project.
Voordat een project van start gaat wordt een plan van aanpak opgesteld en hierin worden de afspraken rondom het project vastgelegd.
Doel plan van aanpak:
Het voor alle betrokkenen eenduidig maken van wat er wanneer en hoe gaat gebeuren.
Vooronderzoek:
Voordat je een plan van aanpak kunt opstellen wordt in het vooronderzoek in kaart gebracht wat het probleem nu precies is. Op basis van het vooronderzoek beslist men ook of het project haalbaar is.
Acceptatie:
Tijdens het vooronderzoek kunnen er acceptatieproblemen aan het licht komen.
Deze varieren van:
- geen heil zien in het project
- weerstanden tegen veranderingen die het gevolg zijn van het uitvoeren van het project
- enthousiasme slaat om naar tegenzin als het project te lang duurt.
Als deze acceptatieproblemen optreden, zal het moeilijk zijn om project en het projectresultaat geaccepteerde te krijgen.
Strategie t.a.v. acceptatieproblemen
Drietraps raket van maatregelen die je kunt nemen voordat het project van staart gaat (analyse, benadering en communicatie):
(I) Analyse:
Analyseren van de veranderingen die het gevolg zijn van het uitvoeren van het project op 5 punten:
a) De aard van de veranderingen:
- structuur: individuele en groepsbelangen spelen een rol => gebruik een top-down benadering
- cultuur: gebruik een bottom-up benadering
- werkwijze: een verandering in werkwijze zit tussen een verandering in structuur en cultuur in, dus gebruik de center-out benadering.
b) De aanleiding van het project: als dit een externe factor was, dan kun je de nadruk leggen op het als organisatie samen werken om de klus te klaren.
c) Het bredere kader: het werkt bevorderend voor de acceptatie als de medewerkers goede uitleg krijgen over de oorzaak, de reden en de achtergrond van de noodzakelijke veranderingen.
d) Het toekomstperspectief van de organisatie: is het een éénmalige verandering of maakt deze deel uit van een reeks veranderingen.
e) Het perspectief van de medewerkers: welke bezwaren leven er , hoe ingrijpend zijn de veranderingen voor de medewerkers en wat kan er gedaan worden om de bezwaren weg te nemen.
(II) Benadering:
Twee soorten benadering om veranderingen doorgevoerd te krijgen:
a) Organisatie gericht:
Uitgangspunt zijn de veranderingen. Deze worden als model ontwikkeld, bekend gemaakt en uitgevoerd (top-down communicatie).
Hierbij voelen medewerkers zich vaak weinig betrokken en moeten ze actief gemotiveerde worden.
b) Mensgerichte benadering:
Nadruk ligt op de medewerkers. Of deze benadering mogelijk is hangt mogelijk af van het soort veranderingen. De uitvoering en ontwikkeling wordt afgestemd met de medewerkers en in samenwerking met hen gedaan. (meestal bottom-up communicatie)
Hierbij is de acceptatiegraad veel hoger, maar een nadeel is dat vooral in het begin niet helemaal helder is naar welk doel wordt gestreefd.
(III) Communicatie:
Acceptatie valt of staat met een goede communicatie en geen afstandelijke managementstijl.
De activiteiten die in het kader van communicatie moeten worden uitgevoerd zijn:
a) Aankondigen van de veranderingen: goede uitleg over de achtergronden van de verandering
b) Handhaven van de betrokkenheid bij de organisatie: medewerkers moeten zich betrokken blijven voelen.
c) Bevorderen van het veranderingsproces: informatie tijdig, betrouwbaar en duidelijk verschaffen (info moet rechtstreeks, regelmatig en tussentijds en discreet komen).
2.1. De elementen van een plan van aanpak.
De volgende elementen zijn meestal terug te vinden in het plan van aanpak:
1) Situatieschets:
In wat voor omgeving gaat het probleem zich afspelen? Wat is de reden voor het project? Wat beoogt de opdrachtgever te bereiken?
2) Doelstelling(en):
Bij onderzoeksproject => Waarom wil men iets bereiken? De doelstelling moet de zin en/of relevantie van het onderzoek weergeven.
Bij ontwikkelproject => Wat is het gewenste eindresultaat? En eventueel een lijst van op te leveren producten.
3) Probleemstelling/onderzoeksvragen:
Wat is het doel dat men met het project wil bereiken? Dat kan zijn, het oplossen van een probleem, een vraag waarop een antwoord gevonden moet worden of iets dat geproduceerd moet worden.
In ontwikkelprojecten kan de probleemstelling vervangen worden door de businesscase.
De probleemstelling moet:
- zo concreet mogelijk zijn (geen algemene vragen)
- geen normatieve vraag zijn (dus niet subjectief)
- geen beleidsvraag zijn
- geen ja/nee vraag zijn.
4) Business case:
Dit is vaak het resultaat van een studie naar de haalbaarheid van het project.
In de business case wordt beschreven wat de reden is dat het project wordt uitgevoerd. De business case moet een goed beeld opleveren van de reikwijdte, de benodigde mensen en middelen, de tijdsplanning en de door het project te realiseren kwalitatieve en kwantitatieve baten.
Als de business case een apart document is moet het de situatieschets bevatten en in een plan van aanpak komt het business plan direct nade situatieschets.
Op basis van de verwachte kosten en baten wordt de go/no go beslissing genomen (dat kan het beste worden ingeschat door de gebruikers van het te ontwikkelen systeem).
5) Werkwijze en middelen:
a) project en organisatie: wel en niet betrokken organisatieonderdelen, relaties met andere projecten, projectstructuur en -besturing, fasering en werkmethoden.
b) verantwoording: afstemming met de opdrachtgever, rapportage.
c) activiteiten en planning: mensen, taken, tijd, geld, overige middelen (werkplekken, software etc.).
6) Uitgangspunten en randvoorwaarden:
Uitgangspunten:
- grondslagen waarop het project berust, zoals het informatiebeleid of de bij de organisatie gebruikte standaarden op het gebied van systeemontwikkeling.
Randvoorwaarden:
- openlijke en duidelijk betrokkenheid van de directie (commitment)
- voldoende inzet (tijd en houding) van medewerkers
- aanschaf ontwikkeltools
- voldoende werkplekken
- voldoende budget
- inhuur van externe expertise etc.
7) Tijdsplanning:
- d.m.v. strokenplanning ofwel balkensysteem waarin wordt aangegeven hoe lang een bepaalde fase/activiteit duurt en hoe die zich verhoudt tot de andere fasen/activiteiten.
8) Bronnen:
Bij gebruik van externe bronnen m.n. (voornamelijk bij onderzoeksprojecten) is het noodzakelijk een zorgvuldige bronvermelding te hanteren. Hoe je dat doet (welke conventie je gebruikt) is niet belangrijk, maar het moet wel consequent zijn.
9) Akkoordverklaring:
Betrokken partijen dienen het plan van aanpak te ondertekenen, waarmee zij aangeven akkoord te gaan met het daarin gestelde. Als gaande het project het inzicht wijzigt, moeten deze wijzigingen in het plan van aanpak worden opgenomen en dient hiervoor opnieuw getekend te worden.
2.2. GOKIT- Geld: De soorten kosten die een rol spelen in ICT-projecten.
Kosten op ICT gebied worden onderscheiden in 3 categorieen:
1) Ontwikkelingskosten (gemaakt tijdens de ontwikkeling):
a) personeel: tijd van medewerkers die aan het project besteed wordt en kosten voor het inhuren van externen.
b) apparatuur: werkplek voor externe projectmedewerkers, werkplek voor interne projectmedewerkers (naast bestaande werkplek wellicht), servertijd voor het maken en testen van programma's en beamers, laptops, pc's etc.
c) software: projectbeheersingsprogrammatuur, ontwikkeltools, databasemanagementsystemen.
Soms kan software die aangeschaft wordt in het kader van het project ook als investering worden gezien (geheel of gedeeltelijk). Een investering wordt afgeschreven onser verwerkingskosten, projectkosten vallen direct onder (het budget van) het project.
d) huisvesting: werkruimte, vergaderruimte, opslagruimte etc.
e) invoering: conversie van gegevens, opleiden van gebruikers, schrijven van handleidingen etc.
2) Exploitaitekosten (kosten voor gebruik):
a) verwerkingskosten:
- eigen apparatuur: afschrijvingen op de investeringen van computers, randapparatuur, netwerk, huisvesting, beveiliging, energievoorziening, kosten voor energie en koeling, dus alles om het informatiesysteem te kunnen gebruiken.
- gehuurde/geleasde apparatuur: huur/lease kosten, verwerkingskosten en energie en koeling.
- verwerking bij derden: overeengekomen bedrag voor de job.
b) materiaalkosten: kosten voor gegevensdragers (CD's, DVD's, externe harde schijven, USB sticks etc), papier, toner, inktcartridges etc.
c) personeelskosten:
- gegevensverwerking in eigen huis: kosten voor medewerkers die de gegevensverwerking uitvoeren en andere bij de verwerking betrokkenen.
- gegevensverwerking bij derden: personeelskosten die gedeclareerd worden en kosten van betrokkenen aan gebruikerszijde.
3) Onderhoudskosten:
Twee soorten onderhoud:
a) onderhoud t.b.v. ongestoorde gegevensverwerking
- preventief onderhoud: onderhoudscontracten
- terugval bij uitwijkcentra bij uitval: abonnement op uitwijkcentra
- verhelpen programmeerfouten: onderhoudscontracten software of eigen afdeling Technisch Beheer
b) onderhoud t.b.v. informatie leveren waar behoefte aan is
- informatiebehoefte kan veranderen door interne of extern oorzaken: informatiesysteem moet dan aangepast worden.
- gewijzigde wensen op gebied van snelheid en doelmatigheid: informatiesysteem aanpassen.
Investeringsbeslissingen: of een project bedrijfseconomisch verantwoord is hangt af van de (geschatte) te verwachten kosten en baten.
1) Kosten in bedrijfseconomische visie zijn:
a) ontwikkelkosten: schatting op basis van tijdsplanning. Dit verandert gedurende het project, als het veel afwijkt van de oorspronkelijke planning, moet de afweging opnieuw worden gemaakt.
b) onderhoudskosten: schatting op basis van een percentage van de ontwikkelkosten: hoe stabiel worden de specificaties ingeschat, hoe stabieler, hoe lager het percentage.
c) meerkosten van de verwerking: het verschil tussen de geschatte verwerkingskosten van het nieuwe informatiesysteem en de verwerkingskosten van het bestaande informatiesysteem. Als kosten van het nieuwe systeem lager zijn dan van het oude systeem, dan is het verschil één van de baten van het nieuwe systeem.
2) Baten:
a) kwantificeerbare baten: bijv. goedkopere verwerkingskosten, besparing op menskracht.
b) niet of moeilijk kwantificeerbare baten: bijv. kwaliteitsverhoging, terugdringen tijdsduur en hoogte van openstaande vorderingen (dit is moeilijk, maar niet onmogelijk om te kwantificeren)
3) Pay back tijd:
Hoe lang duurt het voordat de baten opwegen tegen de kosten?
Zodra de jaarlijkse besparingen opwegen tegen de ontwikkelkosten wordt de verstreken tijdsduur pay back tijd genoemd.
2.3. GOKIT- Organisatie: De opbouw van een organisatiestructuur.
Projectstructuur: hoe deze is opgebouwd is zaak van de organisatie zelf, maar in het algemeen is de volgende hierarchische opbouw te onderscheiden (van hoog naar laag):
- een beleidsgroep (overstijgt het niveau van één project)
- een of meer stuurgroepen (overstijgen het niveau van één project)
- een of meer projectgroepen (één project per groep)
- een of meer werkgroepen ( meerdere werkgroepen per project mogelijk)
Waarbij een projectgroep het enige element is dat we altijd bij een project tegenkomen.
1) Projectgroep: hier speelt het project zich daadwerkelijk af.
Een projectgroep heeft de vorm van een matrix: alle projectgroepleden hebben een operationele relatie met de projectleider en de projectgroepleden die uit de reguliere organisatie komen hebben tevens hun hierarchische functie.
Wie projectleider wordt, is afhankelijk van de aard van het project:
- als het project grotendeels ten behoeve van één afdeling komt, dan moet de projectleider bij voorkeur uit die afdeling komen.
- als het project over een aantal afdelingen heen loopt, dan moet de projectleider boven de partijen staan en bij voorkeur iemand zijn die ervaring heeft in het leiden van projecten (het kan ook iemand van buiten de organisatie zijn).
Als er een stuurgroep is, heeft de projectleider daar meestal ook zitting in => linking pin principe: een deelnemer van een groep op een bepaald bestuursniveau (meestal de leidinggevende van de groep) heeft zitting in de groep op het daarbovengelegen bestuursniveau.
Belangrijkste taken van de projectgroep:
- uitvoeren van projectactiviteiten
- bewaken van de voortgang van de werkgroepen
2) Werkgroep:
Als er werkzaamheden moeten worden uitgevoerd waarbij niet de hele projectgroep bij betrokken hoeft te zijn, kan daarvoor een werkgroep in het leven worden geroepen (er worden ook vaak externe experts bij betrokken vanwege het specialistische karakter van de werkzaamheden). Bijvoorbeel een werkgroep voor het schrijven van handleidingen of het opzetten van opleidingen.
3) Stuurgroep: overzicht over project, autoriteit om beslissingen te nemen.
Projectleiders moeten normaliter regelmatig bilateraal overleg hebben met opdrachtgevers en leidinggevenden in de lijnorganisatie. Als een groot deel van de reguliere organisatie bij projecten betrokken is, is het instellen van een stuurgroep effectiever en efficienter.
Belangrijkste taken van de stuurgroep:
- bewaken van de voortgang van projecten
- beslissen of een project wel of niet doorgaat
- toekennen van een budget aan projecten.
De taken van de stuurgroep kunnen echter ook door een individueel persoon worden uitgevoerd.
4) Beleidsgroep:
Als er meerdere projecten tegelijk lopen en je hebt niet voldoende menskracht om alles uit te voeren, moeten er prioriteiten worden gesteld (welk project krijgt voorrang).
Dit gebeurd door de hoogste leiding van de organisatie en die wordt geadviseerd door een beleidsgroep (in die beleidsgroep zitten zij meestal zelf en ook de stuurgroepen zijn erin vertegenwoordigd => linking pin).
De belangrijkste taken van de beleidsgroep:
- stellen van prioriteiten voor de uitvoering van projecten.
- toewijzen van capaciteit en inzet aan projecten.
De taken van de beleidsgroep kunnen echter ook door een individueel persoon worden uitgevoerd.
De communicatie tussen de groepen vindt plaats door zogenaamde linking pins die als volwaardig lid van de groep een functie kunnen uitoefenen zorgen ervoor dat informatie over alle niveaus op beheerste wijze verspreid wordt.
Rol en taken van de opdrachtgever:
De opdrachtgever is verantwoordelijk om te zorgen dat aan alle voorwaarden, om het project te doen slagen, voldaan wordt.
Taken:
- project resultaat (laten) beschrijven
- het ter beschikking stellen van mensen en middelen
- aan de voorwaarden voldoen die nodig zijn voor het slagen van het project
- de voortgang bewaken
- sturing geven en beslissingen nemen
- draagvlak in de organisatie creeren
- waarnodig het project beschermen en afschermen
- projectresultaat accepteren
Aanspreekpunt voor de opdrachtgever is de projectleider. Een goede verstandhouding tussen hen is cruciaal voor het slagen van het project.
Rol en taken van de projectleider:
De projectleider leidt het project en heeft daarin twee rollen:
- inhoudelijke rol: gericht op het behalen vah het resultaat van het project, waarbij vaktechnische kennis en vaardigheden nodig zijn
- procesmatige rol: gericht op de besturing van de uitvoering van het project, deze rol vergt managementvaardigheden.
Bij welke rol het zwaartepunt ligt, hangt af van het project:
- routinematige projecten => vaktechnische vaardigheden
- nieuw project, onbekend terrein => managementvaardigheden.
2.4. GOKIT- Kwaliteit: De RADAR-methode als kwaliteitsinstrument.
Er zijn drie factoren waarop projecten worden gestuurd: Tijd, Geld en Kwaliteit.
Deze staan in verbinding met elkaar, beinvloeden elkaar.
kwaliteit
^
/ \
/ \
/ \
/ \
/_________\
tijd geld
Tijd en geld kun je managen, maar kwaliteit is lastiger.
RADAR is een methode ten behoeve van de invulling en bewaking van de factor kwaliteit en kan in combinatie met elke systeemontwikkelingsmethode (SDM, RAD etc) gebruikt worden.
RADAR is gericht op kwaliteit en heeft als doel om kwaliteit binnen een project zodanig hanteerbaar te maken dat deze beheersbaar is en er ook op kwaliteit gestuurd kan worden.
In een projectomgeving heb je twee soorten kwaliteit:
1) kwaliteit van het product: het te ontwikkelen informatiesysteem moet doen wat ervan verwacht wordt.
2) kwaliteit van het proces: het product moet op tijd klaar en niet te duur worden opgeleverd (en dat lukt niet als de kwaliteit van het proces te kort schiet)
Product kwaliteit (product is het informatiesysteem dat gebouwd wordt)
Twee risicogebieden:
a) functionaliteit (gewenste ondersteuning van het bedrijfsproces) is onvoldoende
b) hoedanigheid (wijze waarop de functionaliteit wordt aangeboden) deugt niet (systeem is te traag, te moeilijk te bedienen, zit onlogisch in elkaar etc.)
Beide aspecten (functionaliteit en hoedanigheid) moeten goed zijn wil het systeem geslaagd zijn.
Invloeden op productkwaliteit zijn:
a) de vertaalslagen / transformaties die plaatsvinden:
- van de opdrachtgevers en gebruikers naar de automatiseerders
- van de automatiseerders naar het informatiesysteem
Het kan voorkomen dat de uiteindelijke informatie niet (meer) overeenstemt met de oorspronkelijke informatie.
b) veranderende verwachtingen van de opdrachtgever en gebruikers in de loop van de tijd.
Daarvoor moet je verwachtingen bijsturen of het informatiesysteem bijsturen tijdens het project.
Proces kwaliteit:
Twee risicogebieden:
a) de plannen (interne factoren)
- de inrichting van het project: het projectplan is ontworpen om risicogebieden te beheersen.
b) de omgeving (externe factoren)
- is lastig of niet te beinvloeden: hopelijk wordt je tijdig op de hoogte gebracht zodat je hierop bedacht kunt zijn en een strategie kunt uitstippelen hoe er mee om te gaan.
Stappenmatrix RADAR
Kwaliteitszorg is meten en bijsturen:
- wat moet je meten?
- hoe moet je bijsturen?
Hoe sneller je kunt ingrijpen/bijsturen, hoe minder impact problemen hebben op de kwaliteit.
Om te kunnen bepalen waar de grootste risico's zitten moet het duidelijk zijn wat de doelstellingen van het project zijn, zowel t.a.v. het product als t.a.v. het proces.
RADAR onderkent hiervoor 5 stappen in de stappenmatrix:
1) identificeren van de projectdoelstellingen (product en proces)
2) waarderen van de projectdoelstellingen (prioriteiten bij de doelstellingen)
3) specificeren van de projectdoelstellingen (vooral die met de hoogste prioriteit)
4) taxeren van de risico's (welke risico's loopt het project)
5) elimineren van de risico's (maatregelen treffen tegen de grootste risico's)
Deze 5 stappen kunnen worden afgezet tegen de 4 risicogebieden van proces en product kwaliteit: functionaliteit, hoedanigheid, plannen en omgeving.
Zo wordt een matrix gevormd die de basisstructuur is van RADAR.
RADAR geeft dan per hokje in de matrix aan wat de bedoeling van de stap is en hoe de stap moet worden uitgevoerd (dit valt buiten het bestek van de module).
2.5. GOKIT - Informatie: Drie veel gebruikte projectrapporten.
Voor, tijdens en na de uitvoering van een project moeten niet alleen de producten wordenop geleverd die horen bij een bepaalde fase van het project, maar moet ook informatie over het project worden verschaft:
- informeel: gesprekken bij de koffieautomaat
- formeel: rapportage.
Er zijn drie (veel gebruikte) verschillende rapportages die op verschillende momenten tijdens de projectuitvoering worden opgesteld:
1) Vooronderzoeksrapport:
Doel: duidelijk maken van de probleemstelling
Wanneer: voordat plan van aanpak wordt opgesteld
Onderwerpen:
a) Inleiding: reden vooronderzoek, korte situatieschets, probleemstelling en doelstellingen
b) Methoden: op welke manier is het (voor)onderzoek uitgevoerd (bijv. raadplegen van documentatie, observatie, interviews etc.)
c) Resultaten en conclusies: wat zijn de bevindingen en tot welke conclusies gekomen
d) Aanbevelingen: wat moet er op basis van de resultaten en conclusies gebeuren.
2) Voorgangsrapporten:
Doel: inzicht geven over de voortgang en eventuele problemen. Op basis hiervan moet de opdrachtgever of stuurgroep beslissingen kunnen nemen.
Wanneer: bijvoorbeel bij het behalen van een mijlpaal of het einde van een fase.
Opmerking: er moet een balans gevonden worden tussen voldoende informatie en bondigheid; grote rapporten worden niet (goed) gelezen.
Mogelijke onderwerpen:
a) Inleiding: welke periode, opzet rapport, en bij het eerste rapport ook nog doel en aanleiding van het project, opdrachtgever en opdrachtnemer etc.
b) Algemene stand van zaken: samenvatting van wat is bereikt, welke activiteiten zijn uitgevoerd en een overzicht van de kosten.
c) Problemen en knelpunten:
- welke tegenslagen zijn er en welke problemen komen daaruit voort?
- moet er iets gedaan worden dat buiten de opdracht valt? (dat moet de opdrachtgever dan oplossen)
d) Lijst met beslispunten:
Bijvoorbeeld:
- goedkeuring resultaten tot dusver
- akkoord voor de volgende fase
- continueren, aanpassen of opheffen van de projectgroep of werkgroep(en)
e) Te ondernemen stappen: acties die door mensen buiten de projectgroep gedaan moeten worden zoals bijvoorbeeld een aangepaste prognose van planning en budget.
f) Eventuele bijlagen: bijvoorbeeld tijdschema en/of gedetailleerd overzicht van kosten en baten.
3) Projectevaluatierapport:
Doel:
- informatie verschaffen voor de toekomst: waar ging het goed / fout en wat hebben we ervan geleerd?
- vastleggen van ideeen die niet gebruikt zijn, maar wellicht in de toekomst handig zijn.
Wanneer: na afloop van het project als het product is opgeleverd.
Opmerking: projectevaluatie vindt plaats door de projectleider en de projectgroep. De projectleider schrijft het rapport.
Onderwerpen: inhoud/ opzet van het rapport is afhankelijk van het project en van de wensen van de opdrachtgever.
Twee voorbeelden:
- chronologisch: hoe is het project verlopen, welke problemen zijn we tegengekomen en welke oplossingen hebben we daarvoor ingezet?
- procesgericht: welk resultaat was als doel gesteld, en welk resultaat is behaald? Hoe was de projectorganisatie, welke methoden zijn gebruikt, wat ging goed en wat niet? Hoe was de samenwerking? Wat ging goed/fout bij het projectmanagement?
Voor al deze punten geldt: welke lessen leren we hieruit en hoe kan het in de toekomst beter worden gedaan?
Omdat alle projectrapportage nuttig kan zijn voor volgende projecten, is het aan te bevelen deze documentatie in een projectdossier te bewaren.
2.6. GOKIT - Tijd/planning: Het belang van het beheersen van een projectplanning.
De inspanningen zijn erop gericht dat het projectresultaat op het afgesproken tijdstip wordt opgeleverd.
Om dat te kunnen doen moet je inzicht hebben in:
- de uit te voeren werkzaamheden
- de onderlinge afhankelijkheden van de werkzaamheden
- de hiervoor benodigde capaciteit
- de bschikbare capaciteit
- de meetpunten waarop de voortgang wordt vastgesteld
- de voortgang van de werkzaamheden.
Activiteiten vor het beheersen van tijd:
1) opstellen van een planning
2) bewaken van de voortgang (voortgangsrapportage)
3) bijsturen van de uitvoering
Balkenschema (of strokenplanning of GANTT diagram)= veel gebruikt tijdschema voor het weergeven van het beoogde verloop van een project.
In het schema staan vertikaal de fasen, horizontaal de tijd.
Dit tijdschema is de norm waarop de bewaking en de bijsturing van het project plaatsvindt en moet worden bijgesteld bij veranderingen in de planning.
Tijdschema's kunnen op verschillende niveau's binnen het project worden toegepast:
- hoogste niveau (overall niveau): de fasen aangeven van de weg die moet leiden tot het eindresultaat.
- per fase: doorlooptijden van de hoofd activiteiten van die fase.
- per hoofdactiviteit: de activiteiten binnen een hoofdactiviteit.
Het balken schema kan met allerlei zaken worden uitgebreid:
- kolom met naam van de medewerkers die de activiteit uitvoeren
- kolom met de werkelijke duur van een activiteit
- afwijkende kleuren van activiteiten die zijn afgerond
- relaties en/of afhankelijkheden tussen activiteiten met pijlen aangeven
- afwijkende kleur voor activiteiten die op het kritieke pad liggen.
Relaties tussen activiteiten:
vaak kan met een bepaalde activiteit pas begonnen worden als een andere activiteit gereed is.
Kritieke pad:
verzameling activiteiten waarvoor geldt dat elke vertraging in één van die activiteiten ook vertraging betekent voor het geplande eindresultaat.
De activiteiten buiten het kritieke pad kunnen, binnen bepaalde grenzen, naar voor of achter worden geschoven.
Vaak worden activiteiten op het kritieke pad met een afwijkende balkkleur weergegeven en dan wordt er ook nog vaak de "schuifruimte" van de activiteiten buiten het kritieke pad weergegeven.
(Het uitrekenen van het kritieke pad valt buiten de scope van de module).
2.7. De elementen van risicomanagement.
Risicomanagement is het geheel van activiteiten en maatregelen gericht op het omgaan met risico's en het beheersen ervan.
Risico is de kans dat een bedreiging optreedt en leidt tot schade van het beoogde eindresultaat.
Bedreigingen zijn alle gebeurtenissen die een verstorende invloed hebben op de voortgang van het project en het projectresultaat
=> Je moet de oorzaak van de bedreigingen proberen op te sporen om deze te kunnen wegnemen zodat voorkomen kan worden dat er schade aan het projectresultaat optreedt.
Binnen het begrip risico hangen oorzaak, bedreiging en schade met elkaar samen:
_________ ____________ ________
| | | | | |
| oorzaak |----->| bedreiging |----->| schade |
|_________| |____________| |________|
Projectrisico's die vaak optreden zijn:
- het is onduidelijk wie de opdrachtgever is
- de reden van het project is onduidelijk
- het doel van het project is onduidelijk
- er is geen goed projectplan
- de planning is slecht
- de eisen van de gebruikers veranderen tijden het project
- er is gebrek aan controle op de voortgang
- er zijn onvoldoende meet- en beslispunten
- er is weinig controle op de kwaliteit
- er is beperkte capaciteit
- er is beperkt budget
- de deelnemers werken niet samen (onderlinge strijd)
Schadeaspecten: schade kan betrekking hebben op een of meerder van de drie aspecten waarop een project wordt gestuurd:
- tijd: project loopt uit
- geld: project wordt duurder dan gepland
- kwaliteit: eindresultaat is minder dan verwacht
Doel en hoofdactiviteiten van risicomanagent
Doel: risicomanagement is een combinatie van analyserende en structurerende activiteiten met als doel in een vroegtijdig stadium risico's te identificeren en vervolgens zodanige maatregelen te ontwerpen en in te voeren dat de risico's tot een acceptabel niveau worden teruggebracht en de kans op succes zoveel mogelijk wordt gewaarborgd.
Drie hoofdactiviteiten:
1) opsporen en taxeren van de risico's: risicoanalyse
2) ontwerpen van tegenmaatregelen: vastleggen in projectplan en ook wat ervoor nodig is
3) invoeren van de maatregelen en ervoor zorgen dat ze worden uitgevoerd: op basis van rapportage over de invoering kan de projectleider besluiten bepaalde maatregelen aan te scherpen of te verzwakken.
Risicoanalyse:
- wat kan er precies misgaan en wat is dan precies het probleem dat optreedt?
- hoe groot is het risico (kans dat het probleem optreedt en grootte van de schade als het probleem optreedt)?
- welke activiteiten kunnen worden ondernomen om te voorkomen dat de bedreiging optreedt (preventieve acties) en in hoeverre kunnen de preventieve acties het risico reduceren?
- welke alternatieven en noodoplossingen zijn er?
3. Methodieken Projectfasering
3.1. Drie methoden van projectfasering
1) Watervalmethode
- iedere fase wordt afgesloten met een deliverable; deze zijn basis voor de volgende fase.
- als fase is geaccordeerd, wordt de overstap naar een volgende fase gemaakt en kan men niet meer terug naar een vorige fase
De fasen zijn: Verkenning, analyse, ontwerp, realisatie en gebruik en beheer
1) Verkenning: beoordelen van de haalbaarheid en of het informatiesysteem past in de visie van de organisatie.
vooronderzoek = beperkte verkenning
informatieplanning = uitgebreide verkenning
Het is de bedoeling dat de informatiebehoefte van de gebruikers boven tafel komt en de kosten en baten van het te bouwen informatiesysteem.
Eindresultaat is rapport waarin ook deelsystemen en hun prioriteitstelling worden beschreven.
2) Analyse of definitiestudie: beslissen of het te ontwikkelen systeem op sociaal, technisch, organisatorisch, economisch en politiek opzicht haalbaar is.
Activiteiten:
- analyse van de huidige informatieverzorging
- bepalen van de veranderingsbehoefte
- globale beschrijving van de systeemeisen: user-interface, verwerking, opslag en besturing
- bepalen van de acceptatieprocedure
Eindresultaat is een rapport met daarin de onderzoeken en bevindingen
3) Ontwerp
a) functioneel ontwerp: exact beschrijven wat het systeem moet doen voor de gebruiker(s)
Activiteiten zijn :
- het ontwerpen van de functiestructuur van het systeem
- het ontwerpen van de gegevensstructuur
- het ontwerpen van dialogen tussen de gebruikers en het systeem
- het ontwerpen van de interfaces met andere systemen
b) technisch ontwerp: beschrijven hoe het systeem de functies gaat uitvoeren
Activiteiten:
- het ontwerpen van programmaspecificaties
- het ontwerpen van de gegevensopslagstructuur
- het ontwerpen van beeldschermindelingen
- het ontwerpen van formulieren
- het specificeren van procedures
- het specificeren van de systeemtest
Eindresultaat is afhankelijk van de gekozen methoden en methodieken. bijv ISAC methode: componenten schema (ofwel C-schema) en Yourdon: dataflowdiagrammen.
4) Realisatie: bouwen, testen en invoeren van de in de ontwerpfase gedefineerde functionele en technische eisen.
a) Bouw: het bouwen van het systeem volgens de gegeven specificaties
Activiteiten:
- programmeren
- creeeren van bestanden
- uitwerken van procedures, gebruikershandleidingen en systeemdocumentatie
- systeemtest (door IT medewerkers)
- opleidingen (vlak voor invoering, als systeem helemaal klaar is)
b) Acceptatietest: verkrijgen van zekerheid of het systeem voldoet aan de door de gebruiker gestelde eisen.
Activiteiten:
- controleren op juistheid door de gebruiker.
c) Invoering: systeem en organisatie zo inrichten dat het nieuwe informatiesysteem kan worden gebruikt.
Activiteiten:
- inrichten van de organisatie
- conversie (definitieve overgang van de data)
- installatie (v.h. informatiesysteem in de productieomgeving.
Eindresultaten: oplevering werkend en getest informatiesystem en oplevering documentatie (gebruikershandleidingen, systeemdocumentatie, acceptatietest en systeemtest documentatie).
5) Gebruik en beheer: het blijvend laten functioneren van de opgeleverde informatiesystemen conform de gebruikerseisen.
Activiteiten:
- zorgen voor beschikbaarheid (beheer)
- zorgen voor blijvend functioneren (onderhoud)
Vijf typen onderhoud:
- correctief: bug fixing
- perfectief: verbeteringen die leiden tot effectiever of efficienter gebruik
- adaptief: aanpassen aan nieuwe externe eisen
- additief: vergroten van de capaciteit/mogelijkheden
- preventief: problemen voorkomen
Nabeschouwing watervalmethode
De waterval methode is een "big bang" methode, gebruikers moeten wachten tot op het einde van het project om de totale functionaliteit van het systeem te kunnen zien. Gebruikers eisen worden alleen aan het begin van het project betrokken.
Voordelen:
- vooraf is precies duidelijk wat de eisen zijn voor het systeem
- het is bekend welke deliverables iedere fase moet opleveren
Nadelen:
- corrigeren van fouten uit eerdere fasen is moeilijk en kostbaar: hoe later de fout ontdekt wordt, hoe duurder het oplossen ervan wordt.
- lange ontwikkeltrajecten: er kan veel veranderen in die tijd, wat tot gevolg kan hebben dat het systeem niet of in verouderde toestand wordt opgeleverd.
Een voorbeeld van de watervalmethode is SDM (System Development Methodology)
Fasen van SDM naast de algemene watervalmethode
Algemeen | SDM
-------------------------------------|----------------------------------
Verkenning | Informatieplanning
Analyse | Definitiestudie
Ontwerp | Basisontwerp
| Detailontwerp
Realisatie | Realisatie
| Implementatie
Gebruik en beheer | Gebruik en beheer
2) Rapid Application Development (RAD)
RAD was het antwoord op de watervalmethode; gebruikersparticipatie is cruciaal voor de onwikkeling van het systeem
RAD is een snel, flexibel en incrementeel software ontwikkelingsproces.
Fasen:
(1) Joint Requirements Planning (opzetten van de scope)
(2) Joint Application Design (bepalen van de specificaties): hybride teams van gebruikers en IT'ers stellen een ruwe lijst van requirements op
(3) Construction: op basis van de ruwe specificaties wordt door de ontwikkelaars, samen met de gebruikers een eerste prototype gebouwd en getest.
Door middel van iteraties worden de specificaties iteratief aangescherpt door gebruikers en ontwikkelaars
(a) ontwikkelen (re-design)
(b) evalueren (re-evaluate)
(c) opnieuw specificeren (re-specify)
Het systeem wordt incrementeel (in delen) opgeleverd, d.w.z. er wordt gedurende ht project telkens meer functionaliteit toegevoegd.
(3) Cutover: gebruikers opleiden, systeem implementeren
Nabeschouwing RAD
Voordelen:
- gebruiker heeft al snel overzicht van de functionaliteit en kan dus al snel zien of het programma doet wat hij ervan verwacht
- sturing meer op tijd dan op functionaliteit omsta functionaliteit in het begin nog niet vaststaat.
Nadelen/Gevaren:
- niet inzetten om kostenoverschrijdingen en/of uitlopende schema's te vermijden
- eindgebruikers moeten beslissingen nemen om eventueel met minder functionaliteit genoegen te nemen als de tijd gaat dringen.
Voorwaarden aan het ontwikkelen van informatiesystemen m.b.v. RAD:
- de eindresultaten moeten passen in het bedrijfsconcept: door snelheid van ontwikkelen kunnen niet alle details uitgewerkt worden:
MoSCoW- principt: must have, should have, could have, would have (vereist, gewenst, luxe en extra functionaliteit)
- in het ontwikkelteam moeten alle disciplines vertegenwoordigd zijn
- gebruikers, ontwikkelaars en management moeten genoegen nemen met informele documentatie: snelheid is van belang, dus geen tijd voor uitgebreide rapportage
- de ontwikkelteams moeten knopen kunnen doorhakken
- de managers moeten eerst kopen voordat er wordt ontwikkeld (de manager ondertekent voor iets waarvan de details nog onbekend zijN)
- de prototypes moeten zich snel kunnen aanpassen aan de evoluerende specificaties
- beschikbaarheid van middelen, zoals CASE tools.
Twee soorten RAD methodes:
- activiteitgericht, bijv. CDM Fast Track of MAD
- resultaatgericht, bijv. DSDM en EVO methode
3) Evolutionaire methode (EVO)
EVO is een resultaatgerichte RAD methode die uitgaat van vele korte cycli (elke cyclus is een complete waterval) met snelle en veelvuldige terugkoppelingen.
Twee niveaus van terugkoppeling:
1) taakcyclus (verbeteren van schatten, plannen en opvolgen van werk)
2) opleveringscyclus (optimaliseren van requirements en aannames controleren)
Bij de EVO methode wordt niet meer gedaan dan nodig is, alleen het resultaat telt.
Essenties van de EVO methode:
- stellen van prioriteiten: functionaliteit wordt pas gebouwd als er geen requirements zijn met een hogere prioriteit.
- als het budget op is, zijn wellicht nog niet alle requirements ook opgeleverd. De klant beslist of andere requirements ook nog moeten worden uitgewerkt, maar de requirements met de hoogste prioriteit zijn in ieder geval uitgewerkt.
- dus einddatum is heilig: het hele project is een timebox (dit i.t.t. waterval of MDI methode: dat zijn feature boxen)
- door voortdurend met kleine timeboxen te werken leer je echt schatten, echt afronden en focus houden.
- het is beter je targets bijna te halen in de geplande tijd, dan je targets helemaal halen, maar de tijd overschrijden.
Nabeschouwing EVO
Het voortdurend plannen, uitvoeren, controleren en daarna aanpassen is gebaseerd op de Deming Cyclus (Plan, Act, Check Do.
EVO is een combinatie van RAD en de waterval methode
Voordelen:
- sneller resultaat => we maken alleen wat nodig is
- betere kwaliteit => we voldoen altijd aan de requirements
- tevreden klanten => voldoen aan de requirements en de klant is altijd op de hoogte van de status
- meer winst => betere producten op kortere tijd en de tussenproducten kunnen gebruikt worden.
Voorwaarden om EVO te kunnen toepassen:
- kleinere projecten
- eisen en wensen zijn onduidelijk
- flexibiliteit gedurende het project is belangrijk
- veel gebruikersparticipatie
- snel resultaat gewenst
- systeem kan en mag evolueren.
3.2. Fasering Projectmanagement
Er zijn een drietal werkvormen:
1) Improviserend werken:
- inspelen op onverwachte ontwikkelingen
- kosten in tijd en geld zijn onvoorspelbaar
Voordelen:
* flexibel
* inspelen op veranderingen
* snel inspelen op de vraag
* geen voorschriften
Nadelen:
* weinig beheersing
* veel onzekerheid
* weinig stabiliteit
* geen richtlijnen
* opnieuw het wiel uitvinden
2) Routinematig werken
- voor herhalenden werkzaamheden
- exacte kosten bekend
- handelingen hebben een permanent karakter
Voordelen:
* efficient
* kwaliteit neemt toe
* gelijke prestaties over een lange periode
Nadelen:
* niet flexibel
* niet kunnen inspelen op veranderende vraag
3) Projectmatig werken
- combinatie van routinematige aanpak met nieuwe elementen
Voordelen:
* effectief
* resultaatgericht
* grote betrokkenheid medewerkers
* goede beheersing
* verbeterde samenwerking
* werknemers kunnen zelfstandig functioneren
Nadelen:
* kostbare aanloopfase
* bureaucratisering, doordat alles wordt vastgelegd
* zware taak projectleider
* spanningen binnen de organisatie door tegengestelde belangen (bijvoorbeeld afdelingsbelangen versus projectbelangen)
Om projecten beter te kunnen beheersen (projectmanagement) is een project opgedeeld in fasen:
1) Initiatie (idee):
Kan het idee in projectvorm worden aangepakt? Zo ja: projectopdracht maken voor de opdrachtgevere waarin de achtergronden, het projectdoel, het globale resultaat en de randvoorwaarden worden beschreven.
2) Definitie (wat):
De projectleider formeert (in overleg met de opdrachtgever) een voorlopig projectteam
Tijdens een kick-off meeting waarin energie en commitment wordt gegenereerd, wordt het projectplan verder uitgewerkt en omgezet naar een projectcontract of projectprogramma.
Een eventuele wijziging van het projectteam kan nodig zijn, dat wordt dan geschreven in het projectcontract.
Onderdelen van een projectcontract:
- projectdefinitie (probleem, aanleiding, doelstelling, resultaten, afbakening, effect(en) en randvoorwaarden)
- activiteitenplan (deelresultaten, activiteiten, fasering, projectstructuur)
- beheersplan (tijd, geld, kwaliteit, informatie, communicatie en organisatie)
Als het projectocntract akkoord is door de opdrachtgever kan worden gestart met de ontwikkelfase.
3) Ontwikkeling (uitvoeren)
Drie deelfasen:
a) Ontwerp: hoe
b) Voorbereiding: hoe te doen (werkinstructies, bestellen onderdelen etc in realisatieplan)
c) Realisatie (doen)
- uitvoer en realisatie
- acceptatietest
- na akkoord invoer
- nazorgprogrammadocument (wat is opgeleverd en wat zijn de beheeractiviteiten)
4) Nazorg (beheren)
De beheergroep zorgt voor het onderhoud van het eindproduct.
Meestal wordt het project afgerond met een evaluatie, zodat ervaringen bij volgende projecten kunnen worden gebruikt.
Projectplan (door stuurgroep gebruikt om projectvoortgang te volgen).
Aan het begin van het project wordt een projectplan gemaakt en gedurende het project bijgehouden.
In het projectplan de volgende onderwerpen:
- de belangrijkste eindresultaten
- opleverdata
- beslismomenten (meestal de fase overgangen)
PRoject IN Controlled Environments (PRINCE): meest gebruikte p;rojectmanagement methode voor IT projecten.
PRINCE is ontwikkeld door het Office of Government Commerce door de Britse overheid.
Het is ontwikkeld op basis van best practices op het gebied van projectmanagement, informatietechnologie en risicomanagement.
PRINCE2 is een verbeterde en algemenere versie die publiekelijk is uitgebracht.
PRINCE2 bestaat uit een 8-tal fasen:
1) Opstarten van een project (gaat vooraf aan de initiatiefase): beschrijven van het werk dat moet worden verricht in de initiatiefase
- idee
- vezoek om project te mogen starten (project mandaat)
- projectmanager en stuurgroep benoemen
- projectmanager stelt op basis van mandaat een voorstel op en legt dat ter goedkeuring voor aan de stuurgroep
- stuurgroep beoordeelt het nut voor het bedrijf
2) Initieren van een project: opstellen van een PID
PID staat voor Project Initiatie Document, wat een overeenkomst is tussen de projectleider en de stuurgroep en daarin wordt beschreven het wie, wat, waar, waarom en wanneer van het project en welke producten moeten worden opgeleverd en aan welke kwaliteitseisen die producten moeten voldoen.
3) Dirigeren van een project: beschrijven van de rol van de stuurgroep.
Afhankelijk van de voortgang en de toleranties van het project kan de stuurgroep bepalen om ad hoc adviezen en richtlijnen te geven aan de projectmanager)
(Toleranties geven projectleider wat ruimte om zelf te kunnen corrigeren/beslissen)
De stuurgroep neemt aan het eind van elke fase een go/no go beslissing.
4) Beheersen van een fase: beschrijven dagelijkse werkzaamheden van de projectmanager:
- projectvoortgang bewaken
- bepalen welke werkzaamheden worden uitgevoerd
- waar nodig bijsturen
Hulpmiddel kan zijn een PRINCE2 techniek: wijzigingsbeheer: wijzigingen kunnen door deze techniek gecontroleerd worden uitgevoerd.
5) Managen van productoplevering: managen van geplande producten door teamleden afgeleverd binnen de gestelde eisen van tijd, budget, kwaliteit en
functionaliteit)
In deze fase wordt de voortgang en kwaliteit gecontroleerd en wordt goedkeuring gegeven aan producten die klaar zijn.
6) Managen van faseovergangen: in dit proces is de projectmanager verantwoordelijk voor het verzorgen van informatie aan de stuurgroep.
De stuurgroep kan op basis van die informatie go/no go beslissingen nemen
De projectmanager moet afwijkingen buiten de toleranties rapporteren en voorstellen doen voor de vervolgfase. Hoe groter de tolerantie, hoe meer vrijheid/speelruimte de projectmanager heeft.
7)Plannen maken: gedurende het hele project worden plannen gemaakt en bijgewerkt; globale projectplan en gedetailleerde faseplannen worden continu door dit proces bijgewerkt.
Het proces is ook actief bij het opstellen van de productiedecompositiestructuur (lijst met alle op te leveren producten)
Tijdens het project wordt ook het risicologboek bijgehouden (waarin mogelijke risico's worden beschreven die het project kan lopen).
Risico = kans (%) * schade (?)
8)Afsluiten van een project
- Dit moet gecontroleerd gebeuren
- Projectresultaten moeten worden geaccepteerd door de gebruikers en overgedragen aan de opdrachtgever
- Voor vervolgprojecten wordt door de projectmanager een leerpuntenrapport opgesteld en aanbevelingen voor vervolgtrajecten.
Doel is het informeren van de stuurgroep en daarvan toestemming krijgen om het project te beeindigen.
Zelfs als het project eerder eindigd dan gepland, wordt deze fase netjes doorlopen.