Categorie: Bijlagen

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.
  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.

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 beoordeeld. Aan hem rapporteert de projectleider/projectmanager. Vaak is de programmamanager lid van het management team.
  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 (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.

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).
    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.

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.
  • 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 (https://www.projectmanagement-training.net) .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 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 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.TypeOmschrijving IssueNaamDatumPrioriteitBeslissingStatus
1RFCHier een korte omschrijving van het issue dat is ontstaan1= hoog 3= laagHier de beslissing beschrijvenok
AST = toegewezen
VA = afgewezen
ZU = Uitgesteld tot…
R

 

TypePrioriteitBeslissingStatus
RFC= Request for change (algemeen)1 = direct actie nemenT = toegewezenok = issue is afgehandeld
AS = afwijking van specificatie (t.o.v. ontwerp)2 = later actie nemenA = afgewezenopen = openstaand
V = vraag3 = geen actieU = Uitgesteld tot…(datum/gebeurtenis)
&Z = Zorg
R = Risico

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

<Hier komt de lijst van de zaken zoals die op de agenda stonden tijdens het overleg, bijvoorbeeld:>

  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

    NaamFunctie
    Piet PieterseUitvoeringsmanager
    Jan JansenProjectleider
    Enz.Lead Engineer CLient PRODUCT
    Technisch Architect
    Lead Engineer Server PRODUCT
    Java Engineer
    Kwaliteits/Testmanager
    Test Coördinator

    Deelnemers komende periode

    NaamFunctie
    Klaas KlaaszoonUitvoeringsmanager
    Marie de BoerProjectleider
    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 / MijlpaalStartdatum / MijlpaaldatumEinddatumWie
    Voorbereiding7-4-036-6-2003Partner1
    Ontwerp7-4-036-6-2003Partner1 + partner2
    Besluitvorming10-6-200313-6-2003Partner1 + partner2
    Accorderen ontwerp13-6-200313-6-2003Partner2
    Realisatie / Test uitvoering30-6-200328-11-2003Partner1
    Oplevering 1e versie28-11-200328-11-2003Partner1
    Acceptatietest1-12-20032-01-2004Partner2
    Ondersteuning bij acceptatietest1-12-20032-01-2004Partner1
    Acceptatie2-01-20042-01-2004Partner2
    Substantiële gebruikerstest2-01-200425-06-2003Partner2
    Ondersteuning bij substantiële gebruikerstest2-01-200425-06-2003Partner1
    Optimalisering28-06-200327-08-2003Partner1
    Oplevering 2e versie27-08-200327-08-2003Partner1
    Garantie27-08-200326-11-2004Partner1
  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

<naam project>

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: <naam + handtekening projectleider>

Datum:

AVoor akkoord: <naam + handtekening opdrachtgever>

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.

        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.

      4. 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.

      5. 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.

      6. 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

      7. 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-overzicht-projectmanagement

Bijlage 11: Voorbeeld begroting

Begroting
<Projectnaam>
<fase van het project: initiatiefase – nazorg>
<Naam opsteller dit document>
<datum>
bedragen in Euro
Initiatiefasewie?urentarieftotaal
Onderzoek conceptprojectleider20751500
Overleg partnersprojectleider1075750
Projectaanvraag schrijvenhoofd afdeling40803200
Vormgeving aanvraaggrafisch design1050500
Inkoop kennis10001000
subtotaal initiatiefase:6950
Definitiefase
Overleg eindgebruikersprojectleider1075750
functioneel ontwerper1065650
Overleg expertsprojectleider20751500
functioneel ontwerper30651950
interne experts301003000
Inkoop kennis2500
Catering bijeenkomsten250
Projectmanagement2575250
subtotaal definitiefase:10850
Ontwerpfase
Reiskostenteamleden1000
Ontwerpschetsenontwerper60603600
Presentatie ontwerpenontwerper20601200
Materialen2000
Webpresentatie
contenttekstschrijver20601200
htmlprogrammeur20651300
vormgevingontwerper30601800
Projectmanagement15751125
subtotaal ontwerpfase:13225
Voorbereidingsfase
Reiskosten2000
Materiaalkosten15000
Uitwerken draaiboekenprojectleider40753000
Projectmanagement15751125
subtotaal voorbereidingfase:22125
Realisatiefase
Reiskosten personeel2000
Kosten vervoer materiaal3000
Uitvoering eigen personeeltimmermannen160457200
loodgieters160508000
vormgevers80655200
Uitzendkrachten25000
Gas, water, licht3000
Projectmanagement80756000
subtotaal realisatiefase:59400
Nazorgfase
Reiskosten personeel2000
Afvoer materialen3000
Opruimen materialenprojectteam40602400
Eindrapportageprojectleider40753000
Accountantsverklaring1000
Projectmanagement40753000
subtotaal nazorg:15900
Resumé
subtotaal initiatiefase:6950
subtotaal definitiefase:10850
subtotaal ontwerpfase:13225
subtotaal voorbereidingfase:22125
subtotaal realisatiefase:59400
subtotaal nazorg:15900
subtotaal:128450
onvoorzien 10%13495
Totaal:141945
Deze begroting is de globale begroting van het gehele project <projectnaam>. Aan het begin van elke nieuwe fase zal een gedetailleerde begroting aangeleverd worden van die fase.

Bijlage 12: Voorbeeld financiële verantwoording

Financiële rapportage
<Projectnaam>
<Naam opsteller dit document>
<datum>
bedragen in Euro
Initiatiefasewie?uren begrooturen ge-
realiseerd
tarieftotaal begroottotaal ge-
realiseerd
Onderzoek conceptprojectleider20237515001725
Overleg partnersprojectleider101275750900
Projectaanvraag schrijvenhoofd afdeling40358032002800
Vormgeving aanvraaggrafisch design1020505001000
Inkoop kennis10001000980
Onvoorzien861
subtotaal initiatiefase:69507405
Definitiefase
Overleg eindgebruikersprojectleider101075750750
functioneel ontwerper101065650650
Overleg expertsprojectleider20187515001350
functioneel ontwerper30356519502275
interne experts304010030004000
Inkoop kennis25002700
Catering bijeenkomsten250247
Projectmanagement2541752503075
subtotaal definitiefase:1085015167
Ontwerpfase
Reiskostenteamleden10001221
Ontwerpschetsenontwerper60636036003780
Presentatie ontwerpenontwerper20196012001140
Materialen20001873
Webpresentatie
contenttekstschrijver20186012001080
htmlprogrammeur20326513002080
vormgevingontwerper30186018001080
Projectmanagement1512751125900
Onvoorzien120
subtotaal ontwerpfase:1322514399
Voorbereidingsfase
Reiskosten20001200
Materiaalkosten1500013981
Uitwerken draaiboekenprojectleider40457530003375
Projectmanagement15227511251650
subtotaal voorbereidingfase:2212531209
Realisatiefase
Reiskosten personeel20002100
Kosten vervoer materiaal30002850
Uitvoering eigen personeeltimmermannen1602004572009000
loodgieters1601655080008250
vormgevers80756552004875
Uitzendkrachten2500024560
Gas, water, licht30003800
Projectmanagement80807560006000
Onvoorzien231
subtotaal realisatiefase:5940057316
Nazorgfase
Reiskosten personeel20001642
Afvoer materialen30003500
Opruimen materialenprojectteam40456024002700
Eindrapportageprojectleider40407530003000
Accountantsverklaring1000981
Projectmanagement40627530004650
Onvoorzien861
subtotaal nazorg:1590017334
Resumé
subtotaal initiatiefase:69507405
subtotaal definitiefase:1085015167
subtotaal ontwerpfase:1322514399
subtotaal voorbereidingfase:2212531209
subtotaal realisatiefase:5940057316
subtotaal nazorg:1590017334
onvoorzien 10%1349514321
Totaal:141945157151
Bij deze financiële rapportage hoort een korte analyse van de grootste verschillen tussen begroting en realisatie.

Literatuur

Chromatic and Diaz, T. Apandi (Ed.) (2003). Extreme Programming Pocket Guide. Sebastopol, CA: O’Reilly & Associates.
Goldratt, E.M. (2002). De zwakste schakel. Utrecht: Het Spectrum.
Kor, R. and Wijnen, G. (2002). 50 checklisten voor project- en programmamanagement. Deventer: Kluwer. Kroll, P. and Kruchten, Ph. (2004). The Rational Unified Process Made Easy: A practitioner’s Guide to the RUP. Boston: Addison Wesley.
McConnell, S. (1996). Rapid Development: Taming Wild Software Schedules. Redmond, Washington: Microsoft Press.
Stapleton, J. (2002). DSDM Dynamic Systems Development Method: De methode in de praktijk. Schoonhoven: Academic Service.
Wijnen, G., Renes, W. and Storm, P. (2004). Projectmatig werken. Utrecht: Het Spectrum.

Internet bronnen

[i] Spolsky, J. (2000). Painless Functional Specifications – Part 1: Why Bother? Geraadpleegd 31 mei 2006 via http://www.joelonsoftware.com/articles/fog0000000036.html
[ii] Why power your site with XP? (z.j.). Geraadpleegd 31 mei 2006 via http://www.XP.com/
[iii] Extreme Programming: A gentle introduction (Last modified February 17, 2006). Geraadpleegd 31 mei 2006 via http://www.extremeprogramming.org/
[iv] Spolsky, J. (2000). WhatTimeIsIt.com. Functional Specification. Geraadpleegd 31 mei 2006 via http://www.joelonsoftware.com/articles/WhatTimeIsIt.html
[v] Spolsky, J. (2002). Fire And Motion. Geraadpleegd 31 mei 2006 via http://www.joelonsoftware.com/articles/fog0000000339.html
[vi] Pair Programming successes and failures (2001-2003). Geraadpleegd 31 mei 2006 via http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=2058