Home » Handboek projectmanagement » boek

Categorie: boek

Inleiding

Het handboek voor projectmanagement is bedoeld voor een ieder die te maken heeft of te maken krijgt met projecten bij of met DANS. De tekst is echter zo opgesteld dat andere organisaties die projectmatig werken er ook gebruik van kunnen maken. Dit geldt met name voor organisaties in de non-profit sector.
Het boek is opgebouwd uit een aantal delen. Het eerste deel, hoofdstuk 1 tot en met hoofdstuk 4 is een uiteenzetting van de basis van projectmanagement. Dat deel behandelt de theorie van de watervalmethode die geschikt is voor de meeste projecten.

Het tweede deel van dit boek, vanaf hoofdstuk 5, behandelt zogenaamde cyclische vormen van projectmanagement die beter geschikt zijn voor ICT-gerelateerde projecten. Deze methoden zijn met name geschikt voor creatieve ICT-projecten zoals softwareontwikkeling. In het voorlaatste hoofdstuk komt de werkwijze van DANS bij softwareontwikkeling aan de orde. Deze methode is een combinatie van elementen uit de watervalmethode en cyclische methoden.

Tenslotte wordt in het laatste hoofdstuk besproken hoe organisaties de dynamiek van het uitvoeren van meerdere projecten tegelijkertijd kunnen beheersen. De belangrijkste knelpunten worden besproken en de daarbij behorende strategieën voor de aanpak van deze knelpunten.

Bij dit handboek hoort een aantal standaarddocumenten die gebruikt kunnen worden om een project te sturen. Daarnaast zijn er verwijzingen opgenomen naar (open source) projectmanagementinstrumenten van derden. Verder is er een literatuurlijst voor diegene die zich verder wil verdiepen in het brede veld van projectmanagement.

Woord vooraf

Belangrijke noot van de auteur:
In dit boek over projectmanagement komen veel ICT gerelateerde voorbeelden voor. Dit is omdat de oorspronkelijke klant (DANS) waarvoor dit boek is geschreven een ICT organisatie is. De cursussen projectmanagement die www.projectmanagement-training.nl aanbiedt zijn veel breder en gaan over algemeen projectmanagement en niet uitsluitend over ICT projectmanagement.

Voorwoord

Dit handboek is ontstaan tijdens de invoering van projectmanagement bij DANS (KNAW). Bij de invoering van projectmanagement binnen die organisaties en latere andere organisaties, bleek al snel dat de traditionele ‘watervalmethode’ van projectmanagement maar voor een deel van hun projecten geschikt was. Met name voor software projecten en creatieve projecten bleek deze methodiek van projectmanagement te rigide. Een formele projectmanagement methodiek als Prince 2 viel al snel af als optie omdat die veel te zwaar is voor de relatief kleine tot middelgrote projecten die deze organisaties doen. De agile projectmanagement methoden RUP, DSDM blijkt ook te formeel en ingewikkeld voor veel organisaties. De zoektocht was dus naar een informele structuur voor projectmanagement die te gebruiken is bij kleine tot middelgrote projecten. Uiteindelijk bleek extreme programming geschikt, maar dan wel met enkele toevoegingen. In dit handboek wordt deze aanpak beschreven, naast de traditionele manier van projectmanagement.

In dit handboek wordt uit de doeken gedaan hoe projecten met een waterval aanpak of met een agile aanpak gerealiseerd kunnen worden.

1. De zes fasen van projectmanagement

In dit hoofdstuk wordt de traditionele wijze van projectmanagement geschetst. Het model dat hier besproken wordt, vormt de basis voor veel projectmanagementmethodes. In latere hoofdstukken zal nader ingegaan worden op een model dat speciaal geschikt is voor ICT gerelateerde projecten.

Om een project in zo goed mogelijke banen te leiden, is het nuttig het project op te delen in fasen. Door het faseren van het project, wordt het totale werk opgedeeld in kleinere delen, die daardoor makkelijker te overzien zijn. Hieronder wordt een faseringsmodel gegeven dat in de praktijk zijn nut heeft bewezen. Het werkt met zes fases:

  1. Initiatiefase
  2. Definitiefase
  3. Ontwerpfase
  4. Voorbereidingsfase
  5. Realisatiefase
  6. Nazorgfase

Projectmanagement zes fasen

Figuur 1: Projectmanagement in zes fasen met per fase het centrale thema

 

Initiatiefase

De initiatiefase is het begin van het project. In deze fase wordt een idee voor een project nader onderzocht en uitgewerkt. Doel van deze fase is te onderzoeken of het project wel haalbaar is. Verder wordt er gekeken wie het project zou kunnen uitvoeren, welke partij(en) betrokken zouden moeten zijn bij het project en of er voldoende draagvlak is voor het project (bij betrokkenen).

De (beoogde) projectleider maakt in deze fase een projectvoorstel waarin hij bovenstaande zaken beschrijft. Een businessplan of subsidieverzoeken zijn voorbeelden van dergelijke projectvoorstellen. Diegenen die het project sponsoren zullen het projectvoorstel beoordelen en bij goedkeuring de financiering verzorgen. Vanaf die goedkeuring is het project officieel gestart.

De vragen die beantwoord moeten worden in de initiatiefase zijn:

Waarom dit project?
Is het project haalbaar?
Wie zijn eventuele partners in dit project
Wat moet het resultaat zijn?
Waar liggen de grenzen van het project (wat hoort er niet meer bij het project?
Een belangrijke kwaliteit van een projectleider is dat hij goed ‘nee’ kan zeggen. Als mensen eenmaal enthousiast worden voor een project heeft dat de neiging steeds groter te worden. ‘Als we nu toch bezig zijn, dan kunnen we net zo goed er ook voor zorgen dat…’, is dan de gedachtegang. Een project waarbij men steeds meer wil en dat zich steeds uitbreidt, zal vrijwel zeker uit de planning lopen en waarschijnlijk nooit het doel bereiken.

In de initiatiefase gaan de projectpartners een (tijdelijke) relatie met elkaar aan. Om te voorkomen dat er verkeerde verwachtingen over de resultaten van een project ontstaan is het verstandig om expliciet af te spreken wat voor een soort project er gestart wordt:

een research & development project
een project om een prototype of ‘proof of concept’ te leveren
een project dat een werkend product op gaat leveren
De keuze voor een project bepaald in hoge mate het resultaat van een project. Een research & development project levert bijvoorbeeld een rapport op waarin onderzocht wordt of een toepassing technisch haalbaar is. Een project waarin een prototype ontwikkeld wordt levert alle functionaliteit van een applicatie maar hoeft nog niet geschikt te zijn voor bijvoorbeeld honderden gebruikers. Een project wat een werkend product oplevert dient ook rekening te houden met het regelen van onderhoud, handleidingen en het functionele beheer van een applicatie.

Veel misverstanden en/of conflicten ontstaan omdat de partijen over en weer dit niet helder voor ogen hebben. De klant verwacht een werkend product terwijl het projectteam denkt een prototype te moeten leveren. De financier denkt dat het project een werkend stuk software oplevert, terwijl het projectteam eerst moet onderzoeken of het überhaupt technisch kan.

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. 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 (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. Onderwerp Eigenaar Datum gepland Datum gereed Status
1 Hier komen de taken die uitgevoerd moeten worden in een bepaalde periode te staan Naam verantwoordelijke 5-1-2006 3-1-2006 :)
2 :(
3
4

Besluitenlijst

Nr. Omschrijving Datum
1 Hier komen de besluiten te staan die genomen zijn tijdens het overleg Datum 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 risico Prioriteit Maatregel Status
1 Hier komt een korte omschrijving van het risico dat men denkt of denkt te hebben 1= hoog 3= laag Hier de maatregel beschrijven ok

 

Prioriteit Status
1 = direct actie nemen ok = risico is afgehandeld
2 = later actie nemen open = 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. 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 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

    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

<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-overizcht-projectmanagement

Bijlage 11: Voorbeeld begroting

Begroting
<Projectnaam>
<fase van het project: initiatiefase – nazorg>
<Naam opsteller dit document>
<datum>
bedragen in Euro
Initiatiefase wie? uren tarief totaal
Onderzoek concept projectleider 20 75 1500
Overleg partners projectleider 10 75 750
Projectaanvraag schrijven hoofd afdeling 40 80 3200
Vormgeving aanvraag grafisch design 10 50 500
Inkoop kennis 1000 1000
subtotaal initiatiefase: 6950
Definitiefase
Overleg eindgebruikers projectleider 10 75 750
functioneel ontwerper 10 65 650
Overleg experts projectleider 20 75 1500
functioneel ontwerper 30 65 1950
interne experts 30 100 3000
Inkoop kennis 2500
Catering bijeenkomsten 250
Projectmanagement 25 75 250
subtotaal definitiefase: 10850
Ontwerpfase
Reiskosten teamleden 1000
Ontwerpschetsen ontwerper 60 60 3600
Presentatie ontwerpen ontwerper 20 60 1200
Materialen 2000
Webpresentatie
content tekstschrijver 20 60 1200
html programmeur 20 65 1300
vormgeving ontwerper 30 60 1800
Projectmanagement 15 75 1125
subtotaal ontwerpfase: 13225
Voorbereidingsfase
Reiskosten 2000
Materiaalkosten 15000
Uitwerken draaiboeken projectleider 40 75 3000
Projectmanagement 15 75 1125
subtotaal voorbereidingfase: 22125
Realisatiefase
Reiskosten personeel 2000
Kosten vervoer materiaal 3000
Uitvoering eigen personeel timmermannen 160 45 7200
loodgieters 160 50 8000
vormgevers 80 65 5200
Uitzendkrachten 25000
Gas, water, licht 3000
Projectmanagement 80 75 6000
subtotaal realisatiefase: 59400
Nazorgfase
Reiskosten personeel 2000
Afvoer materialen 3000
Opruimen materialen projectteam 40 60 2400
Eindrapportage projectleider 40 75 3000
Accountantsverklaring 1000
Projectmanagement 40 75 3000
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
Initiatiefase wie? uren begroot uren ge-
realiseerd
tarief totaal begroot totaal ge-
realiseerd
Onderzoek concept projectleider 20 23 75 1500 1725
Overleg partners projectleider 10 12 75 750 900
Projectaanvraag schrijven hoofd afdeling 40 35 80 3200 2800
Vormgeving aanvraag grafisch design 10 20 50 500 1000
Inkoop kennis 1000 1000 980
Onvoorzien 861
subtotaal initiatiefase: 6950 7405
Definitiefase
Overleg eindgebruikers projectleider 10 10 75 750 750
functioneel ontwerper 10 10 65 650 650
Overleg experts projectleider 20 18 75 1500 1350
functioneel ontwerper 30 35 65 1950 2275
interne experts 30 40 100 3000 4000
Inkoop kennis 2500 2700
Catering bijeenkomsten 250 247
Projectmanagement 25 41 75 250 3075
subtotaal definitiefase: 10850 15167
Ontwerpfase
Reiskosten teamleden 1000 1221
Ontwerpschetsen ontwerper 60 63 60 3600 3780
Presentatie ontwerpen ontwerper 20 19 60 1200 1140
Materialen 2000 1873
Webpresentatie
content tekstschrijver 20 18 60 1200 1080
html programmeur 20 32 65 1300 2080
vormgeving ontwerper 30 18 60 1800 1080
Projectmanagement 15 12 75 1125 900
Onvoorzien 120
subtotaal ontwerpfase: 13225 14399
Voorbereidingsfase
Reiskosten 2000 1200
Materiaalkosten 15000 13981
Uitwerken draaiboeken projectleider 40 45 75 3000 3375
Projectmanagement 15 22 75 1125 1650
subtotaal voorbereidingfase: 22125 31209
Realisatiefase
Reiskosten personeel 2000 2100
Kosten vervoer materiaal 3000 2850
Uitvoering eigen personeel timmermannen 160 200 45 7200 9000
loodgieters 160 165 50 8000 8250
vormgevers 80 75 65 5200 4875
Uitzendkrachten 25000 24560
Gas, water, licht 3000 3800
Projectmanagement 80 80 75 6000 6000
Onvoorzien 231
subtotaal realisatiefase: 59400 57316
Nazorgfase
Reiskosten personeel 2000 1642
Afvoer materialen 3000 3500
Opruimen materialen projectteam 40 45 60 2400 2700
Eindrapportage projectleider 40 40 75 3000 3000
Accountantsverklaring 1000 981
Projectmanagement 40 62 75 3000 4650
Onvoorzien 861
subtotaal nazorg: 15900 17334
Resumé
subtotaal initiatiefase: 6950 7405
subtotaal definitiefase: 10850 15167
subtotaal ontwerpfase: 13225 14399
subtotaal voorbereidingfase: 22125 31209
subtotaal realisatiefase: 59400 57316
subtotaal nazorg: 15900 17334
onvoorzien 10% 13495 14321
Totaal: 141945 157151
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