Bijlage 1: Top 11 van de grootste vertragers van ICT projecten

In deze bijlage staan de 11 grootste factoren van vertraging van projecten beschreven. Voor een uitgebreide analyse van deze en andere vertragingsfactoren zie McConnell en Goldratt (McConnell, 1996, Goldratt, 2002).

  1. Functionaliteitenaanwas
    Functionaliteiten aanwas is het fenomeen dat naarmate het project vordert, er steeds nieuwe functionaliteiten bij bedacht en gevraagd worden. Hierdoor komt de software nooit af. Andere term hiervoor is “Feature creep”.
  2. Goudranden
    Goudranden is het fenomeen dat programmeurs en designers allerlei details van de software of ontwerpen te mooi willen maken. Er wordt veel tijd gestoken in het verbeteren van details, terwijl die verbeteringen niet gevraagd zijn door de klant of opdrachtgever. Vaak voegen de details weinig toe aan het gewenste resultaat.
  3. Kwaliteitscontroles overslaan
    Door tijdsdruk komen programmeurs of projectteams wel eens in de verleiding om het testen over te slaan. Dit leidt vaak tot meer vertraging dan de tijd die bespaard is met het overslaan van de test. Hoe langer het duurt dat een fout wordt gevonden in software, des te exponentieel meer tijd het kost om hem te herstellen.
  4. Te optimistische planningen
    Een te optimistische planning leidt tot veel druk op het projectteam. Het team zal aanvankelijk trachten de (niet reële) deadlines te halen. Hierdoor wordt er slordig gewerkt en zullen er meer fouten gemaakt worden, die weer tot vertragingen leiden.
    Wees in dit kader vooral beducht op het van bovenaf opleggen van planningen. Soms wordt de wens een project snel(ler) af te ronden vooral ingegeven door strategische motieven, maar als dat niet redelijkerwijs kan, moet dat ook niet geprobeerd worden. Het zal er niet sneller door gaan en het uiteindelijke product zal er niet beter van worden.
  5. Werken aan veel projecten tegelijk
    Door het werk te versnipperen over veel verschillende projecten (of andere taken), ontstaan er wachttijden waardoor projecten veel vertraging oplopen.
  6. Slechte ontwerpen
    Het ontbreken van, of slecht uitgevoerde ontwerpen, leidt tot vertragingen omdat er dan in een later stadium veel revisies nodig zijn.
  7. Het ‘oplossing-voor-alles’ syndroom
    Het gebruiken van de juiste software voor een project is belangrijk. Het ene softwareplatform is beter geschikt voor bepaalde toepassingen dan het andere. Het is echter een valkuil om te denken dat het gebruiken van bepaalde software tot hele grote productiviteitsverbeteringen leidt.
  8. Onderzoeksgeoriënteerde projecten
    Projecten waarbij software gemaakt moet worden én onderzoek gedaan wordt, zijn moeilijk te managen. De onzekerheden van het onderzoek zijn heel groot. Onduidelijk is wanneer en of er voortgang geboekt zal worden bij het onderzoek. Wanneer de software ontwikkeling afhankelijk is van onderzoeksresultaten, komt deze regelmatig stil te liggen.
  9. Matig personeel
    Personeel dat onvoldoende bekwaam is, zal het project vertragen. Daarbij speelt niet alleen de technisch inhoudelijke kennis over het projectonderwerp een rol, maar ook de kennis en vaardigheid om met elkaar het spel van het project te spelen.
  10. Klant komt afspraken niet na
    Klanten realiseren zich niet altijd dat van hen een behoorlijke bijdrage gevraagd wordt als ze een project laten uitvoeren. Waneer een klant niet of niet op tijd reageert op de onderwerpen waar hij bij moet meedenken, komt het project stil te liggen. Of erger, het team gaat verder zonder dat er goed meegedacht is door de klant, wat later weer tot conflicten kan leiden.
  11. Spanning tussen klant en ontwikkelaars
    De spanning die kan ontstaan tussen klant en ontwikkelaars, bijvoorbeeld omdat het project niet snel genoeg verloopt, leidt zelf ook tot meer vertraging omdat de benodigde vertrouwensbasis en werksfeer verstoord is.zie ook de FAQ over projectmatig werken en projectmanagement

Bijlage 2: Rollen binnen een project

In deze bijlage worden de verschillende rollen gedefinieerd van mensen die deel uitmaken van een project.

  1. Projectleden/projectteam
    De projectleden zijn de teamleden in het project. De mensen die het project daadwerkelijk uitvoeren en die taken hebben binnen het project. Vaak hebben teamleden verschillende expertisegebieden. Teamleden kunnen intern zijn (eigen personeel) en/of extern (van projectpartners, klanten, gebruikers of ingehuurd personeel).
  2. Projectleider
    De projectleider is diegene die het projectteam aanstuurt en de eindverantwoordelijkheid heeft over het projectresultaat. Afhankelijk van hoe het wordt afgesproken, kan het natuurlijk zo zijn dat de projectleider verantwoordelijkheden delegeert aan teamleden en/of dat externe managers de verantwoordelijkheid hebben over een onderdeel van het project.
    Binnen cyclische projecten behartigt de projectleider zowel de belangen van de klant als de programmeurs. Hij zorgt ervoor dat de klant voldoende technische uitleg krijgt en helpt de klant met het kiezen en prioriteren van functionaliteiten.
  3. Projectmanager
    De termen projectleider en projectmanager worden vaak door elkaar gebruikt. Gebruikelijk is dat een projectmanager meerdere projecten leidt en een projectleider vaak maar één. De projectleider bevindt zich dan ook vaak ‘dichter op de werkvloer’ dan een projectmanager, die zich doorgaans meer met sturing en cijfers bezighoudt. Andere betekenissen en afbakeningen komen ook voor en de termen worden vaak door elkaar gebruikt.
  4. Programmamanager
    De programmamanager is diegene die een aantal projecten in een organisatie beoordeelt. Aan hem rapporteert de projectleider/projectmanager als een programmamanager aanwezig is in een organisatie tenminste, veel kleinere organisaties hebben geen programmamanager. Vaak is de programmamanager lid van het management team. Als er geen programmamanager is dan wordt die rol vaak door iemand van het MT ingenomen.
  5. Klant
    De klant is de partij die het projectresultaat besteld heeft. Hij of zij kan actief in het project deelnemen of meer afstand houden. De klant is soms ook de gebruiker van het projectresultaat maar dat is niet altijd het geval. Stel dat een universiteit een webapplicatie wenst voor zijn medewerkers en studenten, dan is de universiteit de klant en zijn de medewerkers en studenten de gebruikers.
  6. Gebruikers
    De gebruikers zijn diegenen die het projectresultaat gaan gebruiken.
    Het is belangrijk om deze mensen te betrekken in de definitiefase, ontwerpfase en bij het testen van het project.
  7. Projectpartner
    De projectpartner is een derde partij (persoon of organisatie) waarmee het project wordt uitgevoerd. Wanneer er meerdere partijen deelnemen aan het project is het uiteraard belangrijk om de verantwoordelijkheden en taken goed af te bakenen.
  8. Opdrachtgever/klant/sponsor
    De partij(en) die het project financieel mogelijk maakt. Dit is vaak (maar niet altijd) ook de partij die het projectresultaat gaat gebruiken. De opdrachtgever zorgt voor de financiering van het project en is derhalve ook de partij aan wie verantwoording wordt afgelegd over het projectresultaat.

     

    De verschillende rollen, hun taken en verantwoordelijkheden worden nader toegelicht in onze training voor projectleiders.

Bijlage 3: Nuttige hulpmiddelen voor projectmanagement

In deze bijlage worden de verschillende rollen gedefinieerd van mensen die deel uitmaken van een project.

  1. http://sourceforge.net/
    Website waar Open Source Software te vinden is, waaronder software voor het managen van projecten. Onderstaande open source software kan hier gedownload worden.
  2. Xplanner
    Xplanner is een open source software tool voor het administreren en managen van de cycli door middel van storycards (volgens de eXtreme Programming werkwijze).
  3. Open source CVS (Current Version System)
    beheersapplicaties die veel gebruikt worden zijn: CVS, Subversion en Gnu arch.
  4. MS Project, Fasttrack en andere
    MS project is het meest bekende programma voor het voeren van de administratie van een project en het maken van een Gant chart (balkenschema). U kunt bij ons een cursus MS project volgen.
    Fasttrack is een ander bekend pakket en daarnaast zijn er vele open source pakketten. Deze programma’s zijn eigenlijk alleen nuttig bij projecten die worden uitgevoerd volgens de watervalmethode.
  5. http://www.bugzilla.org/
    Bugzilla is een open source programma voor het registreren, bewaken en archiveren van issues en bugs. Wordt met name binnen softwareontwikkeling gebruikt.

     

    zie ook onze lijst met software voor projecten

Bijlage 4: Licentie van dit handboek

De Creative Commons Attribution-NonCommercial-ShareAlike 2.5 Licentie is van toepassing op dit werk. Ga naar http://creativecommons.org/licenses/by-nc-sa/2.5/ of stuur een brief naar Creative Commons, 559 Nathan Abbott Way, Stanford, Californië 94305, VS om deze licentie te bekijken.
Kort samengevat komt het hier op neer:

De gebruiker mag:

  • het werk kopiëren, verspreiden, tonen en op- en uitvoeren
  • afgeleide werken maken

Onder de volgende voorwaarden:

  • Naamsvermelding. De gebruiker dient bij het werk de naam Wouter Baars, http://www.wouterbaars.nethttps://www.projectmanagement-training.net en Dans, http://www.dans.knaw.nl/ als oorspronkelijke auteurs aan te geven. Bovendien moet er bij de naamsvermelding een link gemaakt worden naar www.projectmanagement-training.nl.
  • Niet-commercieel. De gebruiker mag het werk niet voor commerciële doeleinden gebruiken
  • Gelijk delen. Indien de gebruiker het werk bewerkt kan het daaruit ontstane werk uitsluitend krachtens dezelfde licentie als de onderhavige licentie worden verspreid.
  • Bij hergebruik of verspreiding dient de gebruiker de licentievoorwaarden van dit werk kenbaar te maken aan derden.
  • De gebruiker mag uitsluitend afstand doen van een of meerdere van deze voorwaarden met voorafgaande toestemming van de rechthebbende.

Bijlage 5: Over DANS en de makers van dit handboek

DANS is de nationale organisatie die zorgt voor de opslag en blijvende toegankelijkheid van onderzoeksgegevens in de alfa- en gammawetenschappen. DANS werkt daartoe samen met onderzoekers en bevordert samenwerking tussen hen onderling. DANS heeft de vorm van een netwerk, met een centrum dat verantwoordelijk is voor de organisatie van de data-infrastructuur. Dat centrum bestaat uit een team van ca. vijftien mensen die werken op het DANS-kantoor in Den Haag of bij één van de onderzoekcentra in het land, zie http://www.dans.knaw.nl

Auteur:
Ir. Wouter Baars is ontwikkelaar van software en educatie. Hij studeerde bedrijfskunde aan de Technische Universiteit van Eindhoven. Na zijn studie heeft hij in diverse projecten op het gebied van oude en nieuwe media gewerkt. Hij werkte als projectleider voor onder andere Waag Society, KPN, De Digitale Universiteit, de Hogeschool van Amsterdam, Noterik multimedia en de Europese Commissie. Naast zijn werk als ontwikkelaar geeft hij les in projectmanagement. Meer informatie over zijn werk is te vinden op: http://www.wouterbaars.net

Adviseurs:
Dr. Henk Harmsen is adjunct directeur van DANS (Data Archiving & Networked Services), een nieuw initiatief van KNAW en NWO op het gebied van het archiveren en beschikbaarstellen van onderzoeksdata in Nederland. Henk studeerde alfa-informatica aan de Universiteit van Amsterdam en promoveerde aan de Vrije universiteit van Amsterdam. Hij heeft als bibliothecaris, hoofd van automatisering en hoofd bedrijfsvoering op een breed vlak ervaring opgedaan. Meer informatie is te vinden op:http://www.dans.knaw.nl/nl/over_dans/organisatie/henk_harmsen/

Ir. Rutger Kramer heeft Technische Informatica gestudeerd aan de Technische Universiteit Delft. Tijdens zijn afstudeerwerk was hij betrokken bij het ECPA Sepia project waarvoor hij bij het Nederlands Instituut voor Wetenschappelijke Informatiediensten (NIWI – KNAW) meewerkte aan een metadata invoer applicatie.
Na zijn afstudeerstage bleef hij bij het NIWI als Technisch Wetenschappelijk Programmeur. In die hoedanigheid werkte hij aan verschillende projecten, zoals EVAMP en XPAST, waarbij ontsluiting van digitaal erfgoed materiaal centraal stond.
Als Informatiekundige bij DANS houdt hij zich bezig als IT liaison en projectmanager voor interne en externe R&D projecten. Hij is betrokken bij het Easy Store DMS project voor DANS en het verzorgen van database ontsluiting voor de afdeling Kunstgeschiedenis van de Letterenfaculteit van de Universiteit Utrecht
http://www.dans.knaw.nl/nl/over_dans/organisatie/rutger_kramer/

Drs. Laurents Sesink is informatiekundige bij de afdeling Acquisitie en Ontwikkeling van DANS (Data Archiving & Networked Services). Laurents studeerde geschiedenis aan de Universiteit Utrecht en historische informatiekunde aan de Universiteit Leiden.
Hij heeft als voormalig senior specialist digitaliseringsdiensten, technisch wetenschappelijk programmeur, coördinator ontwikkelgroep, senior consultant/projectleider en beleidsmedewerker een brede achtergrond op het terrein van wetenschappelijke en bestuurlijke informatievoorziening.
http://www.dans.knaw.nl/nl/over_dans/organisatie/laurents_sesink/

Drs. Joris van Zundert is onderzoeker en ontwikkelaar bij het Huygens Instituut, onderdeel van de Koninklijke Akademie van Wetenschappen (KNAW). Hij studeerde Nederlandse Taal en Cultuur aan de Universiteit Utrecht. Naast en na zijn studie ontwikkelde hij een professionele loopbaan als zelfstandig ontwerper en ontwikkelaar van internetapplicaties. Opleiding en praktijkervaring combineerde hij later in dienst van Stichting Wetenschap en Techniek Nederland, het Nederlands Instituut voor Wetenschappelijk Informatievoorziening en het Huygens Instituut.
Joris van Zundert ontwikkelt in diverse projecten internettoepassingen en digitale gereedschappen speciaal gericht op (literair historisch) wetenschappelijk gebruik en onderzoek.http://www.huygensinstituut.knaw.nl/index.php?option=com_content&task=view&id=131&Itemid=57&lang=du

Bijlage 6: Voorbeeld actie- en besluitenlijst


Projectnaam: <vul hier de projectnaam in>
Datum: <vul hier de datum in van bijwerken>
Eigenaar: <vul hier de naam in van de persoon die dit document beheert>
Fase: <vul hier in: initiatiefase, definitiefase, ontwerpfase, voorbereidingsfase, realisatiefase of nazorgfase>


Actielijst

Nr.OnderwerpEigenaarDatum geplandDatum gereedStatus
1Hier komen de taken die uitgevoerd moeten worden in een bepaalde periode te staanNaam verantwoordelijke5-1-20063-1-2006🙂
2    🙁
3     
4     
      
      
      
      
      

Besluitenlijst

Nr.OmschrijvingDatum
1Hier komen de besluiten te staan die genomen zijn tijdens het overlegDatum van het besluit
2  
3  
   
   
   
   
   
   

Bijlage 7: Voorbeeld issuelog


Projectnaam: <vul hier de projectnaam in>
Datum: <vul hier de datum in van bijwerken>
Eigenaar: <vul hier de naam in van de persoon die dit document beheert>


Nr. Type Omschrijving Issue Naam Datum Prioriteit Beslissing Status
1 RFC Hier een korte omschrijving van het issue dat is ontstaan 1= hoog 3= laag Hier de beslissing beschrijven ok
AS T = toegewezen
V A = afgewezen
Z U = Uitgesteld tot…
R

 

Type Prioriteit Beslissing Status
RFC= Request for change (algemeen) 1 = direct actie nemen T = toegewezen ok = issue is afgehandeld
AS = afwijking van specificatie (t.o.v. ontwerp) 2 = later actie nemen A = afgewezen open = openstaand
V = vraag 3 = geen actie U = Uitgesteld tot…(datum/gebeurtenis)
&Z = Zorg
R = Risico

Bijlage 8: Voorbeeld risicolog


Projectnaam: <vul hier de projectnaam in>
Datum: <vul hier de datum in van bijwerken>
Eigenaar: <vul hier de naam in van de persoon die dit document beheert>


Nr.Omschrijving risicoPrioriteitMaatregelStatus
1Hier komt een korte omschrijving van het risico dat men denkt of denkt te hebben1= hoog 3= laagHier de maatregel beschrijvenok
     
     
     
     
     
     
     
     
PrioriteitStatus
1 = direct actie nemenok = risico is afgehandeld
2 = later actie nemenopen = openstaand
3 = geen actie 

Bijlage 9: Voorbeeld gespreksverslag


Notulen van Projectnaam: <vul hier de projectnaam in> Datum: <vul hier de datum in van het gesprek/ de vergadering> Notulist <vul hier de naam in van de persoon die dit document heeft opgesteld> Aanwezig: <vul hier de namen in van de aanwezigen bij het overleg> Afwezig met kennisgeving: <vul hier de namen in van diegenen die afwezig waren met kennisgeving> Afwezig zonder kennisgeving: <vul hier de namen in van diegenen die afwezig waren zonder kennisgeving>


Agenda

  1. Goedkeuring gespreksverslag vorige vergadering
  2. Bespreken actielijst
  3. Bespreken besluitenlijst
  4. Bespreken issuelog
  5. Bespreken risicolog (nieuwe risico’s en knelpunten)
  6. Voortgang project
  7. Aanpassing planning
  8. Overleg met management
  9. Rondvraag
  1. Goedkeuring gespreksverslag vorige vergadering Piet heeft aangegeven dat in het verslag zijn opmerkingen over de ontwikkelingen van nieuwe software bij de concurrent niet goed zijn opgenomen. Hij zal een korte email sturen naar de notulist met een correcte weergave van zijn ideeën. De overige aanwezigen geven aan dat ze akkoord gaan met het verslag.
  2. Actielijst Er zijn acties afgemeld en nieuwe acties aangemeld. zie het aparte document ActieEnBesluiten.doc
  3. Besluitenlijst Zie de aparte actie- en besluitenlijst voor de genomen beslissingen. zie het aparte document ActieEnBesluiten.doc
  4. Issuelog Zie de aparte issuelog voor de issues welke nog openstaan. Er zijn deze week geen nieuwe issues aangemeld.
  5. Risicolog Henk heeft een nieuw risico gesignaleerd dat we over het hoofd hebben gezien. Wat moeten we doen als onze leverancier van software failliet gaat? Dit risico is opgenomen in de risicoloos. Klaas gaat er over nadenken en kijken wat de contracten met de leverancier daarover zeggen. Zie verder de risicolog.
  6. Voortgang projectPartner 1 In de Java straat wordt hard gewerkt aan de realisatie van de software. In totaal zijn er nu drie engineers toegewezen aan het project De testers zijn nu bezig met de voorbereiding van de testscripts. Henk heeft gevraagd aan Marie of hij dit heeft opgestuurd aan Floor. Kees geeft aan dat de detailtest plannen geen deliverables zijn. De testscripts wel. Indien de partner inzicht in de voor genoemde plannen wil. Dan kan dat uiteraard altijd.Partner 2Floor heeft aangegeven dat ze nog druk bezig zijn met een nieuwe naam voor het product. Henk zal alvast een wijzigingsvoorstel op zetten waardoor de impact op het project inzichtelijk wordt. De offerte van Leverancier voor de Licenties is nu binnen. Betreffende de rapportage aan de financier heeft Floor aangegeven dat ze begin oktober weer een rapportage willen doen aan de financier. We hebben afgesproken dat we vijf werkdagen na de afsluiting van September de rapportage aanleveren aan de partner.

    Deelnemers afgelopen periode

    Naam Functie
    Piet Pieterse Uitvoeringsmanager
    Jan Jansen Projectleider
    Enz. Lead Engineer CLient PRODUCT
    Technisch Architect
    Lead Engineer Server PRODUCT
    Java Engineer
    Kwaliteits/Testmanager
    Test Coördinator

    Deelnemers komende periode

    Naam Functie
    Klaas Klaaszoon Uitvoeringsmanager
    Marie de Boer Projectleider
    Enz. Lead Engineer CLient PRODUCT
    Technisch Architect
    Lead Engineer Server PRODUCT
    Java Engineer
    Kwaliteits/Testmanager
    Test Coördinator
  7. Aanpassen planning Hieronder staat de nieuwe planning waarvan de partners nu in het project hebben aangegeven dat hij realistisch is op dit moment
    Fase / Mijlpaal Startdatum / Mijlpaaldatum Einddatum Wie
    Voorbereiding 7-4-03 6-6-2003 Partner1
    Ontwerp 7-4-03 6-6-2003 Partner1 + partner2
    Besluitvorming 10-6-2003 13-6-2003 Partner1 + partner2
    Accorderen ontwerp 13-6-2003 13-6-2003 Partner2
    Realisatie / Test uitvoering 30-6-2003 28-11-2003 Partner1
    Oplevering 1e versie 28-11-2003 28-11-2003 Partner1
    Acceptatietest 1-12-2003 2-01-2004 Partner2
    Ondersteuning bij acceptatietest 1-12-2003 2-01-2004 Partner1
    Acceptatie 2-01-2004 2-01-2004 Partner2
    Substantiële gebruikerstest 2-01-2004 25-06-2003 Partner2
    Ondersteuning bij substantiële gebruikerstest 2-01-2004 25-06-2003 Partner1
    Optimalisering 28-06-2003 27-08-2003 Partner1
    Oplevering 2e versie 27-08-2003 27-08-2003 Partner1
    Garantie 27-08-2003 26-11-2004 Partner1
  8. Overleg met het management Klaas heeft in zijn rol als projectleider overleg gehad met het management. Hij management wil dat het project binnen 1, uiterlijk 2 maanden afgerond is. Klaas heeft aangegeven dat hij denkt dat het niet haalbaar is, maar dat het team toch zijn best zal doen om het (on)mogelijke te doen.
  9. Rondvraag Marie geeft aan dat de vergadering nu alweer 2 uur heeft geduurd, terwijl de doelstelling was om dat te beperken tot maximaal 3 kwartier. Graag een ieders inzet om kort te vergaderen.Henk geeft aan dat hij niet bij de volgende bijeenkomst kan zijn.

Volgende bijeenkomst(en)

Project voortgangsoverlegWekelijks.Dinsdag 19 augustus 200613:00 uurPartner 1 kantoor RotterdamKlaas, Henk, Floor, MarieHenk

Voorlopige agenda:

  1. Gespreksverslag vorige vergadering
  2. Actielijst
  3. Besluitenlijst
  4. Afwijkingen van Specificatie
  5. Voortgang project
  6. Planning (mijlpalen/wijzigingen)
  7. Meer/Minderwerk
  8. Issuelog
  9. Risico’s en knelpunten.
  10. Overige/Rondvraag

Bijlage 10: Voorbeeld projectplan

Projectnaam: <vul hier de projectnaam in> Datum: <vul hier de datum in van bijwerken> Projectleider: <vul hier de naam in van de projectleider(s)> Fase: <vul hier in: initiatiefase, definitiefase, ontwerpfase, voorbereidingsfase, realisatiefase of nazorgfase>

Voor akkoord:

Datum:

Voor akkoord:

Datum:


Inleiding:

Dit document is een korte handleiding voor het opstellen van een projectplan. Het eerste projectplan wordt gemaakt na de initiatiefase en dient als goedkeuringsdocument voor het hele project. Na elke fase moet dit document bijgesteld worden. De eerstvolgende fase moet een plan voor worden opgesteld in detail. Voor de verder liggende fases is het projectplan meer globaal. Na elke fase vindt ook evaluatie van dit document plaats.

Algemene informatie over het project

  1. Situatieschets en probleemstelling project
    • Geef een beschrijving van de organisatie waar dit project in plaatsvindt
    • Geef een beschrijving van de afdeling(en) waarbinnen dit project plaatsvindt
    • Geef eventueel een beschrijving van relaties van dit project met andere projecten
    • Geef een beschrijving voor de geschiedenis van dit project
    • Geef een beschrijving van de aanleiding van dit project
    • Geef aan wie de opdrachtgever(s) is/zijn voor dit project
    • Geef aan wie de opdrachtnemer is voor dit project
  2. Projectopdracht
    • Leg uit waarom dit project gedaan wordt, doe dit zo SMART mogelijk (SMART=specifiek, meetbaar, aanwijsbaar, realistisch, tijdgebonden)
    • Geef aan wat er opgeleverd gaat worden
    • Geef de belangrijkste grenzen aan van het project (wat gebeurt er niet)
  3. Risicoanalyse
    • Geef aan welke risico’s bekend zijn bij dit project
    • Geef aan hoe omgegaan wordt met deze risico’s (vermijden, bestrijden, verzekeren, accepteren)
  4. Inrichting van het project
    In dit deel van het projectplan wordt een beschrijving gegeven van de fases, de activiteiten per fase en de bijbehorende GOKIT factoren van het project. Het plan wordt van globaal voor de verder liggende fases uitgewerkt en concreet en specifiek voor de eerstvolgende fase. In dit voorbeeld is uitgegaan van het opstellen van het eerste projectplan dus na de initiatiefase. Na elke fase moet dit deel van het projectplan worden bijgesteld.

     

    1. Uitleg gebruikt projectmanagementmodel
      Dit projectplan is gebaseerd op de watervalmethode/DANS-methode welke is beschreven in het handboek projectmanagement van DANS. Het handboek is bijgevoegd bij dit projectplan.

       

      1. Initiatiefase Het resultaat van de initiatiefase is dit projectplan. Deze fase hoeft niet verder uitvoerig beschreven te worden. Eventueel kan een opsomming gegeven worden van de activiteiten welke hebben plaatsgevonden in de voorbereiding.
      2. Definitiefase Geplande startdatum: <datum> Geplande einddatum: <datum>Beschrijving van het resultaat van de definitiefase:In de definitiefase zal een eisen- en wensenlijst worden opgesteld over het te bereiken projectresultaat.Belangrijkste mijlpalen: <(bijvoorbeeld)>
        • Functionele eisen- en wensenlijst
        • Onderzoek wettelijke eisen
        • Eisen en wensen van eindgebruikers interviews
        • Eisen en wensen van eindgebruikers testonderzoek
        • Technische eisen en wensenrapport
        • Goedkeuring door opdrachtgever van eisen- en wensenlijst
        <Geef per mijlpaal aan wanneer die bereikt moet zijn en wie er verantwoordelijk voor is. Geef aan welke kwaliteit een bepaalde mijlpaal (= tussenproduct) moet hebben.> Activiteiten in de definitiefase: Geef een lijst van activiteiten die moeten plaatsvinden om de mijlpalen te bereiken. Geef aan wie ze uitvoeren, wanneer en door wie de resultaten van de activiteiten worden goedgekeurd (eindverantwoordelijke). Tijdpad: Zet hier de lijst van activiteiten uit in de tijd, bijvoorbeeld door gebruik te maken van een balkenschema. Markeer de mijlpalen duidelijk in de tijd. Vergeet niet om marges in te bouwen. Begroting: Geef hier een begroting van de kosten per activiteit in deze fase. Geef daarnaast de kosten voor materiaal en materieel en eventuele overige kosten aan. Verwijs eventueel naar een extern document met daarin de kosten (zie ook het aparte model voor begroten). Informatie Intern: Geef aan hoe de informatie uit deze fase geregistreerd en gearchiveerd wordt. Geef aan welke hulpmiddelen eventueel gebruikt worden en indien nodig wie er wel of niet de beschikking heeft over de informatie. Informatie Extern: Een belangrijk informatiemoment is de goedkeuring van deze fase door de opdrachtgever/klant. Geef aan welke rapportages na deze fase opgeleverd worden aan de opdrachtgever, klant en of extern management.
      3. Ontwerpfase Geplande startdatum: <datum> Geplande einddatum: <datum>Beschrijving van het resultaat van de ontwerpfase: In de ontwerpfase zal een ontwerp / aantal ontwerpen gemaakt worden voor het te bereiken projectresultaat.Belangrijkste mijlpalen: <(bijvoorbeeld)> Een of meerdere dummy’s Schermontwerpen Foto-impressies/schetsen<Geef per mijlpaal aan wanneer die bereikt moet zijn en wie er verantwoordelijk voor is. Geef aan welke kwaliteit een bepaalde mijlpaal (= tussenproduct) moet hebben.> Activiteiten in de ontwerpfase: Geef een lijst van activiteiten die moeten plaatsvinden om de mijlpalen te bereiken. Geef aan wie ze uitvoeren, wanneer en door wie de resultaten van de activiteiten worden goedgekeurd (eindverantwoordelijke).Tijdpad: Zet hier de lijst van activiteiten uit in de tijd, bijvoorbeeld door gebruik te maken van een balkenschema. Markeer de mijlpalen duidelijk in het overzicht. Vergeet niet om marges in te bouwen.
      4. Begroting kosten: Geef hier een begroting van de kosten per activiteit in deze fase. Geef daarnaast de kosten voor materiaal en materieel en eventuele overige kosten aan. Vergeet niet een post ‘onvoorzien’ op te nemen en de kosten voor het projectmanagement zelf. Verwijs eventueel naar een extern document met daarin de kosten (zie ook het aparte model voor begroten).Informatie Intern: Geef aan hoe de informatie uit deze fase geregistreerd en gearchiveerd wordt. Geef aan welke hulpmiddelen eventueel gebruikt worden en indien nodig wie er wel of niet de beschikking heeft over de informatie. Informatie Extern: Een belangrijk informatiemoment is de goedkeuring van deze fase door de opdrachtgever/klant. Geef aan welke rapportages tijdens en na deze fase opgeleverd worden aan de opdrachtgever, klant en of extern management. Na de ontwerpfase gaat de watervalmethode verder met de voorbereidingsfase, de DANS-methode voor software ontwikkeling gaat verder met het cyclische deel. De verschillende mogelijkheden worden hieronder na elkaar beschreven. Voor het schrijven van een projectplan moet een van de twee mogelijkheden gekozen worden.
      5. Voorbereidingsfase <(alleen waterval)> Geplande startdatum: <datum> Geplande einddatum: <datum>Beschrijving van het resultaat van de voorbereidingsfase: In de voorbereidingsfase zal een draaiboek opgesteld worden ter voorbereiding van de realisatiefase. <NB. Deze fase is niet altijd nodig bij projecten en kan dus bij met name wat kleinere projecten eventueel komen te vervallen>Belangrijkste mijlpalen: <(bijvoorbeeld)> Draaiboek deel 1 Draaiboek deel 2 enz.<Geef per mijlpaal aan wanneer die bereikt moet zijn en wie er verantwoordelijk voor is. Geef aan welke kwaliteit een bepaalde mijlpaal (= tussenproduct) moet hebben.>Activiteiten in de voorbereidingsfase: Geef een lijst van activiteiten die moeten plaatsvinden om de mijlpalen te bereiken. Geef aan wie ze uitvoeren, wanneer en door wie de resultaten van de activiteiten worden goedgekeurd (eindverantwoordelijke).Tijdpad: Zet hier de lijst van activiteiten uit in de tijd, bijvoorbeeld door gebruik te maken van een balkenschema. Markeer de mijlpalen duidelijk in de tijd. Vergeet niet om marges in te bouwen.Begroting kosten: Geef hier een begroting van de kosten per activiteit in deze fase. Verwijs eventueel naar een extern document met daarin de kosten. Vergeet niet een post ‘onvoorzien’ op te nemen en de kosten voor het projectmanagement zelf (zie ook het aparte model voor begroten). Informatie Intern: Geef aan hoe de informatie uit deze fase geregistreerd en gearchiveerd wordt. Geef aan welke hulpmiddelen eventueel gebruikt worden en indien nodig wie er wel of niet de beschikking heeft over de informatie. Informatie Extern: Een belangrijk informatiemoment is de goedkeuring van deze fase door de opdrachtgever/klant. Geef aan welke rapportages tijdens en na deze fase opgeleverd worden aan de opdrachtgever, klant en of extern management.
      6. Realisatiefase <(alleen waterval)> Geplande startdatum: <datum> Geplande einddatum: <datum>Beschrijving van het resultaat van de realisatiefase: In de realisatiefase zal het projectresultaat gebouwd worden.Belangrijkste mijlpalen: <(bijvoorbeeld)> Element 1 van de realisatie Element 2 van de realisatie enz.<Geef per mijlpaal aan wanneer die bereikt moet zijn en wie er verantwoordelijk voor is. Geef aan welke kwaliteit een bepaalde mijlpaal (= tussenproduct) moet hebben.>Activiteiten in de realisatiefase: Geef een lijst van activiteiten die moeten plaatsvinden om de mijlpalen te bereiken. Geef aan wie ze uitvoeren, wanneer en door wie de resultaten van de activiteiten worden goedgekeurd (eindverantwoordelijke).Tijdpad: Zet hier de lijst van activiteiten uit in de tijd, bijvoorbeeld door gebruik te maken van een balkenschema. Markeer de mijlpalen duidelijk in de tijd. Vergeet niet om marges in te bouwen.Begroting kosten: Geef hier een begroting van de kosten per activiteit in deze fase. Geef daarnaast de kosten voor materiaal en materieel en eventuele overige kosten aan. Vergeet niet een post ‘onvoorzien’ op te nemen en de kosten voor het projectmanagement zelf. Verwijs eventueel naar een extern document met daarin de kosten (zie ook het aparte model voor begroten). Informatie Intern: Geef aan hoe de informatie uit deze fase geregistreerd en gearchiveerd wordt. Geef aan welke hulpmiddelen eventueel gebruikt worden en indien nodig wie er wel of niet de beschikking heeft over de informatie. Informatie Extern: Een belangrijk informatiemoment is de goedkeuring van deze fase door de opdrachtgever/klant. Geef aan welke rapportages tijdens en na deze fase opgeleverd worden aan de opdrachtgever, klant en of extern management.
      7. Cyclische fase <(alleen DANS-methode voor software ontwikkeling)> Geplande startdatum: <datum> Geplande einddatum: <datum>Beschrijving van het resultaat van de realisatiefase: In de cyclische fase zal het projectresultaat nader onderzocht, gespecificeerd en gebouwd worden.Beschikbaar aantal uren voor de cyclische fase: Geef hier aan hoeveel uur er beschikbaar is voor de cyclische fase, eventueel verdeeld over de verschillende teamleden, als die verdeling niet gelijkmatig is.Eerste inschatting de het aantal cycli en hun producten <(bijvoorbeeld)> cyclus 1: basisarchitectuur cyclus 2: interactie tussen servers cyclus 3: interactie met klant enz.Dit deel is voornamelijk van belang bij het opstellen van het eerste projectplan. Naarmate de cyclische fase dichterbij komt, wordt overgestapt op het planningssysteem met storycards (zie handboek DANS projectmanagement).Deelnemers in de cyclische fase: Geef een lijst van de deelnemers in de cyclische fase en hun verantwoordelijkheden: <bijvoorbeeld>Jan Jansen: programmeur Piet Pietersen: programmeur Marie Pedro Del Mar: programmeur Kees Keeszoon: Ontwerper (interactie en grafisch) Klant: procesinformatie en testen enz. Begroting kosten: Geef hier een begroting van de kosten van de cyclische fase. Geef daarnaast de kosten voor materiaal en materieel en eventuele overige kosten aan. Vergeet niet een post ‘onvoorzien’ op te nemen en de kosten voor het projectmanagement zelf. Verwijs eventueel naar een extern document met daarin de kosten (zie ook het aparte model voor begroten). Informatie Intern: Geef aan hoe de informatie uit deze fase geregistreerd en gearchiveerd wordt. Geef aan welke hulpmiddelen eventueel gebruikt worden en indien nodig wie er wel of niet de beschikking heeft over de informatie. <Er zal met storycards gewerkt worden, evt. Aangevuld met een projectlog, CVS systeem, bugtracker en tools zoals Xplanner>. Informatie Extern: Een belangrijk informatiemoment is de goedkeuring van deze fase door de opdrachtgever/klant. Geef aan welke rapportages tijdens en na deze fase opgeleverd worden aan de opdrachtgever, klant en of extern management
      8. Nazorgfase <(waterval en DANS-methode voor softwareontwikkeling)> Geplande startdatum: <datum> Geplande einddatum: <datum>NB: geef duidelijk aan wanneer de nazorg stopt vanuit het projectteam.Beschrijving van het resultaat van de nazorgfase: In de nazorgfase wordt het project afgerond. Geef hier aan wat er wel en niet onder de afronding valt.Belangrijkste mijlpalen: <(bijvoorbeeld)> Projectverslag Overdrachtsdocument naar beheersorganisatie Projectwebsite met gebruikersinformatie enz.<Geef per mijlpaal aan wanneer die bereikt moet zijn en wie er verantwoordelijk voor is. Geef aan welke kwaliteit een bepaalde mijlpaal (= tussenproduct) moet hebben.>Activiteiten in de nazorgfase: Geef een lijst van activiteiten die moeten plaatsvinden om de mijlpalen te bereiken. Geef aan wie ze uitvoeren, wanneer en door wie de resultaten van de activiteiten worden goedgekeurd (eindverantwoordelijke).Tijdpad: Zet hier de lijst van activiteiten uit in de tijd, bijvoorbeeld door gebruik te maken van een balkenschema. Markeer de mijlpalen duidelijk in de tijd. Vergeet niet om marges in te bouwen. Begroting kosten: Geef hier een begroting van de kosten per activiteit in deze fase. Geef daarnaast de kosten voor materiaal en materieel en eventuele overige kosten aan. Vergeet niet een post ‘onvoorzien’ op te nemen en de kosten voor het projectmanagement zelf. Verwijs eventueel naar een extern document met daarin de kosten (zie ook het aparte model voor begroten). Informatie Intern: Geef aan hoe de informatie uit deze fase geregistreerd en gearchiveerd wordt. Geef aan welke hulpmiddelen eventueel gebruikt worden en indien nodig wie er wel of niet de beschikking heeft over de informatie. Informatie Extern: Een belangrijk informatiemoment is de goedkeuring van deze fase door de opdrachtgever/klant. Geef aan welke rapportages tijdens en na deze fase opgeleverd worden aan de opdrachtgever, klant en of extern management.

Overzicht

In het laatste deel van het project plan staat een overzicht van de kosten en tijdpad van het hele project.

tabel-overizcht-projectmanagement