Project Initiation Document Project VVE-Beheer. Project Initiation Document. Project: VVE-Beheer

Transcriptie

1 Project VVE-Beheer Project Initiation Document Project: VVE-Beheer

2 Management samenvatting Het voorliggende Project Initiatie Document behelst het plan van aanpak voor de ontwikkeling van een VVE-Beheer applicatie. Deze applicatie zal het beheren van verenigingen van eigenaren eenvoudiger te maken. Voorafgaande aan het begin van deze fase hebben wij een gesprek gehad met de materiedeskundigen van Stedelijk Wonen om de gewenste applicatie vast te leggen, en deze teruggekoppeld door middel van een functioneel ontwerp. Na acceptatie van dit rapport stellen wij nu dit document op dat ons zal helpen bij het voortzetten van de ontwerpfase. De applicatie die ontwikkeld gaat worden voor de woningcorporaties zal als standaard gaan dienen en met OSS-tools gemaakt worden. Op dit moment wordt er gewerkt met verschillende systemen die op maat zijn gemaakt. Aanpassingen zijn nu lastiger te maken omdat, iedere corporatie / VVE met een andere applicatie(s) werkt. Gedurende het traject zullen er meerdere studenten teams aan de ontwikkelfase werken. Uitgaande van de complexiteit en grootschaligheid van dit project. Het is daarom niet zeker wanneer het project in zijn geheel opgeleverd zal zijn. Het aantal studenten kan per semester verschillen en kan leidden tot uitstel van (deel-) producten. De verwachte opleverdata en de geplande uren zijn als volgt: Fase Geplande Einddata Geplande Uren Fase 1 PID Fase 1 Functioneel ontwerp Fase 1 Technisch ontwerp Fase 2 Basis creëren Fase 2 Relaties Fase 2 Eigenaars Fase 2 Debiteurbewaking Fase 2 Beheerteam Fase 2 Advieslijst Fase 2 Urenadministratie Fase 2 Testen Algemeen Beheer TOTAAL: 2176 uur Bestandsnaam: PID Auteur:Lars Schumacher 2

3 Inhoudsopgave Management samenvatting... 2 Inhoudsopgave Inleiding en achtergrond project Achtergrond project Projectdefinitie Doelstellingen Aanpak en fasering Resultaten Omvang Randvoorwaarden & beperkingen Relaties met andere projecten Initiële Business Case Redenen Aannames Kosten Baten Organisatiestructuur Initiële Projectplanning Randvoorwaarden Externe afhankelijkheden Productdecompositie, beschrijvingen en stroomdiagram Planning aannames Projectplanning Benodigde Hulpbronnen Kosten Beheersingsmechanismen Toleranties Voortgangsrapportage Tijd- en kostenrapportages Kwaliteitsrapportages Uitzonderingsprocedure ( Management by Exception ) Projectrisico s Bijlage 1: Kwaliteitsplan...i Bijlage 2: Projectarchief... iii Bijlage 3: Grafische weergaven projectplanning... iv Bestandsnaam: PID Auteur:Lars Schumacher 3

4 1 Inleiding en achtergrond project In dit document worden alle zaken beschreven die van belang zijn bij de opzet en ontwikkeling van het VVE-Beheer voor W.O.S.I. Dit document is van belang voor het management van W.O.S.I. Voornamelijk worden er gesprekken gevoerd met Stedelijk Wonen uit Enschede en dient als opdrachtgever. In dit document worden de producten beschreven die opgeleverd zullen worden, welke fasen het project zal doorlopen en hoe de planning eruit ziet. Naast de producten en de planning van het project wordt ook de organisatiestructuur uitgelicht, beschrijven wij welke beheersmechanismen er in plaats zijn, wat de eventuele projectrisico s zijn en wat de businesscase voor dit project is. In de businesscase zullen de redenen naar voren komen voor het bestaan van dit project, welke aannames er worden gedaan aangaande de effecten van het nieuwe systeem en welke kosten en baten erbij komen kijken. De volgende materiedeskundigen zullen gedurende dit project ons van dienst zijn om informatie te verstrekken m.b.t. VVE-Beheer: Materiedeskundigen Na(a)m(en) Telefoon Peter Winterman [email protected] Simon Wassenaar [email protected] Bouwe Regeling [email protected] Bestandsnaam: PID Auteur:Lars Schumacher 4

5 1.1 Achtergrond project Dit project wordt uitgevoerd door WOSI in opdracht van Stedelijk Wonen. Stedelijk Wonen wil een VVE Beheer applicatie om het beheren van verenigingen van eigenaren eenvoudiger en efficiënter te maken. Dit project is een "module" van het project WOSI. Dit houdt in dat er meerdere projecten ( modules) geprogrammeerd zullen worden, echter is dit project het grootste van alle projecten lopende projecten. Gedurende het traject zullen er meerdere studenten teams aan de ontwikkelfase werken. Uitgaande van de complexiteit en grootschaligheid van dit project. Voorafgaande aan het begin van deze fase hebben wij een gesprek gehad met de materiedeskundigen van Stedelijk Wonen om de gewenste applicatie vast te leggen, en deze teruggekoppeld door middel van een functioneel ontwerp. Na acceptatie van dit rapport stellen wij nu dit document op dat ons zal helpen bij het voortzetten van de ontwerpfase. Bestandsnaam: PID Auteur:Lars Schumacher 5

6 2 Projectdefinitie In dit hoofdstuk worden er een aantal zaken behandeld die te maken hebben met het definiëren van dit project. In dit hoofdstuk wordt uitgelegd wat de doelstelling, aanpak en fasering, resultaten, omvang, randvoorwaarden en relaties met andere projecten zijn. 2.1 Doelstellingen Het doel van het project is om een applicatie te ontwikkelen dat het beheer van verenigingen van eigenaren eenvoudiger maakt en als standaard wordt gebruikt door woningbouwcorporaties en/of VvE-beheerders. 2.2 Aanpak en fasering Het project wordt aangepakt volgens de Prince2 methodiek en bestaat uit de volgende fasen: Inventarisatie en Projectdefinitie(Fase 1): In deze fase wordt het project gedefinieerd en wordt er duidelijk gemaakt wat er precies gedaan moet worden. Dit wordt gedaan door gesprekken te houden met de opdrachtgever. In deze fase zal het PID worden gemaakt; Ontwerp fase(fase 1): In deze fase worden alle ontwerpen voor het eindproduct gemaakt. Dit is het functioneel ontwerp en technisch ontwerp; Uitvoer fase(fase 2): In deze fase worden de producten gemaakt dat samen het eindproduct vormt. Dit is de database en de VVE-Beheer applicatie; Test fase(fase 3): In deze fase wordt het eindproduct uitvoerig getest. Oplevering product: Het product wordt opgeleverd. 2.3 Resultaten Het project levert de volgende hoofdproducten op: Database; VVE Beheer applicatie; Functioneel Ontwerp; Technisch Ontwerp; Gebruikershandleiding. Bestandsnaam: PID Auteur:Lars Schumacher 6

7 2.4 Omvang Om een duidelijke omvang van het project te bepalen, is het volgende opgesteld: Wat doen we wel: Het ontwerpen en configureren van de Database; Het bouwen van de VVE-Beheer applicatie; Uitvoerig testen; Implementeren. Wat doen we niet: Cursus geven m.b.t. de applicatie; Onderhoud op lange termijn. 2.5 Randvoorwaarden & beperkingen Dit zijn de voorwaarden om het project volgens de planning te laten verlopen: De teamleden moeten niet langdurig ziek zijn; De teams dienen informatie tot hun beschikking te hebben over een VVE; Afspraken moeten op tijd gemaakt worden; Afspraken moeten worden nagekomen; Ieder semester dient er een team werkzaam te zijn aan dit project; Mogelijkheid tot het opvangen van werk mocht een teamlid wegvallen. 2.6 Relaties met andere projecten Omdat dit project uitgevoerd wordt door studenten, is er een relatie met de Hogeschool van Amsterdam. De toestroom van studenten naar WOSI moet worden gewaarborgd. Bestandsnaam: PID Auteur:Lars Schumacher 7

8 3 Initiële Business Case De applicatie die ontwikkeld gaat worden voor de woningcorporaties zal als standaard gaan dienen en met OSS-tools gemaakt worden. Op dit moment wordt er gewerkt met verschillende systemen die op maat zijn gemaakt. Aanpassingen zijn nu lastiger te maken omdat, iedere corporatie / VVE met een andere applicatie(s) werkt. 3.1 Redenen De reden van het bestaan van dit project is: Een open source applicatie ontwikkelen voor de woningbouwcorporaties; Hopelijk een standaard te ontwerpen voor het beheren van een VVE; Makkelijke uitbreidbaarheid, flexibiliteit, duurzaamheid. 3.2 Aannames Ten behoeve van de Business Case zijn de volgende algemene aannames gedaan: Voldoende studenten aanwezig per semester om aan dit project te werken; Informatie van de opdrachtgever dient op tijd vergaard te worden, zodat er geen vertraging voor de ontwikkeling ontstaat; Minimaal 2 werkdagen per week per team de gelegenheid bieden om aan dit project te werken. 3.3 Kosten De kosten van het project zullen niet in euro s genoteerd worden maar in het aantal uren dat ervoor nodig is om het project tot een goed einde te brengen. Technische ondersteuning: Aantal personen: 2 Aantaal uren per week p.p.: 16 Aantal weken: 22 Totale uren: 704 Projectleiding: Aantal personen: 1 Aantaal uren per week p.p.: 40 Aantal weken: 22 Totale uren: 880 Team leden: Aantal personen: 11 Aantaal uren per week p.p.: 16 Aantal weken: 22 Totale uren: 3872 Personeelskosten bij de informatieverstrekker. Bestandsnaam: PID Auteur:Lars Schumacher 8

9 3.4 Baten De te verwachten baten van het project zijn: Uitwisselbaarheid Om te zorgen dat elke woningcorporatie hetzelfde bedoelt bij een bepaald woord of entiteit moeten er afspraken gemaakt worden. Dit is belangrijk, want wanneer er databases samengevoegd gaan worden, scheelt het aanzienlijk in tijd en kosten als data niet meer geconverteerd hoeft te worden of overgetypt. Bijkomend voordeel is dat wanneer data uitgewisseld moet worden met andere instanties, bijvoorbeeld de Belastingdienst, er relatief snel afspraken gemaakt worden over de open standaard. Op deze manier kunnen de alle corporaties op dezelfde manier de gegevens aanleveren. Duurzaamheid Omdat een open standaard in overleg aangepast kan worden, heeft dit als voordeel dat deze niet voor beperkingen zorgt. Wanneer een woningcorporatie nieuwe ideeën heeft of aanpassingen wilt doorvoeren is dit mogelijk mits dit niet andere deelnemers belemmerd. Op deze manier zijn niet steeds nieuwe standaarden nodig maar wordt de huidige standaard breder. Door het gebruik van deze standaarden in nieuw te ontwikkelen modules of externe applicaties blijven deze onderling langer bruikbaar naast elkaar. Deze verlengt de levensduur van een module of applicatie. Bestandsnaam: PID Auteur:Lars Schumacher 9

10 4 Organisatiestructuur Voor de duur van het project wordt een tijdelijke organisatie opgezet: Hierna worden de verantwoordelijkheden van de diverse betrokken groepen algemeen toegelicht. Project Manager Naam Jo Lahaye Rol Opdrachtgever/Budgethouder De Project Manager is verantwoordelijk voor de optimale inpassing van het project in het programma en aansluiting bij de bedrijfsdoelstellingen. De Project Manager is eindverantwoordelijk voor het overall eindresultaat van het project en voor het ter beschikking stellen van mensen en middelen. Projectleader & Technical Project Support Na(a)m(en) Rol Lars Schumacher Projectleader Ties van Ham Technical Project Support Jasper Krijgsman Technical Project Support De Projectleader krijgt van de Project Manager de verantwoordelijkheid en bevoegdheid voor de dagelijkse gang van zaken in het project. Bestandsnaam: PID Auteur:Lars Schumacher 10

11 De Projectleader kan beslissingen nemen binnen de grenzen zoals aangegeven door de Project Manager (tolerantie). De belangrijkste verantwoordelijkheid van de Projectleader is het zekerstellen dat het project de gewenste producten oplevert, binnen tijd, binnen budget en volgens de afgesproken kwaliteit. De Projectleader rapporteert aan de Project Manager. Technical Project Support ondersteunt de Projectleader technisch en administratief ( denk hierbij aan het bewaren van documenten / source code op de daarvoor aangewezen plaatsen). De volgende teams zullen in de periode van 1 februari 2010 t/m 28 juni 2010 werkzaam zijn aan dit project. Team 1 Na(a)m(en) Rol Lara Freeke Teamleader Bryan Oemar Developer Ivo Wapstra Developer Giovanni van Ingen Developer Nazeem Ramsaroep Developer Menno Tas Developer / Kwaliteitscontroleur Team 2 Na(a)m(en) Rumeysa Ozdmir Mark Droog Roy van Putten Arjan Pronk Thijs ten Veldhuis Rol Teamleader Developer Developer Developer Developer / Kwaliteitscontroleur De teams zijn verantwoordelijk voor het opleveren van producten volgens de specificaties zoals aangegeven door de Projectleader. De Teamleader kan beslissingen nemen binnen de grenzen zoals aangegeven door de Projectleader. De Teamleaders rapporteren regelmatig aan de Projectleader; de Developers rapporteren aan de Teamleaders. De Projectleader en de Teams kunnen ieder Semester veranderen. Dit document dient dan gewijzigd te worden wanneer dat gebeurd. Bestandsnaam: PID Auteur:Lars Schumacher 11

12 5 Initiële Projectplanning De projectplanning geeft aan welke acties wanneer door wie worden ondernomen en wat de bijbehorende kosten zijn. De planning kan gedurende de loop van het project aangepast worden op basis van ervaringen in het project en / of nieuwe gegevens. In de bijlage vindt u de gedetailleerde planning. 5.1 Randvoorwaarden Aan de volgende randvoorwaarden dient te zijn voldaan om onderstaande planning te kunnen halen: Benodigde hulpbronnen beschikbaar conform aanvraag; Tijdige besluitvorming; Studenten met kennis van programmeren; Technische ondersteuning door Senior programmeurs. 5.2 Externe afhankelijkheden Het beschikbaar zijn van de contactpersonen die namens Stedelijk Wonen uit Enschede met ons in contact zijn; Ieder semester beschikbare studenten (van de "Hogeschool van Amsterdam"). 5.3 Productdecompositie, beschrijvingen en stroomdiagram Voor het project is de volgende productdecompositie op projectniveau gedefinieerd. Een beschrijving van de op te leveren Business producten is opgenomen in de bijlage Productbeschrijvingen. Producten zonder identificatie worden in de gedetailleerde faseplanningen indien nodig nader gespecificeerd: Business producten (op projectniveau): B100 Ondersteunende producten B101 Functioneel ontwerp B102 Technisch ontwerp B103 PID B104 Gebruikershandleiding B200 Specialistische producten B201 Algemeen Beheer B2010 B2011 B2012 B2013 B2014 B2015 B202 Technisch Beheer B2020 B2021 B2022 B2023 Relaties Eigenaars Beheerteam Debiteurbewaking Advieslijst Urenadministratie Reparatieverzoeken Contracten Soort Reparaties Leveranciers Bestandsnaam: PID Auteur:Lars Schumacher 12

13 B203 B204 B2024 Administratief Beheer B2030 B2031 B2032 B2033 B2034 Financieel Beheer B2040 B2041 B2042 B2043 B2044 B2045 B2046 B2047 Reparatievoorwaarden Eigenaren Vergaderingen Verenigingen Post Prikbord Debiteuren Boekjaren Telebankieren Facturen Begrotingen Prolongatie Dagboeken Voorschotten Het bijbehorende Product Stroomschema, waarin de afhankelijkheden tussen de belangrijkste Business producten zijn weergegeven, ziet er als volgt uit: 5.4 Planning aannames Voor het behalen van de onderstaande projectplanning zijn de volgende aannames relevant: De specialistische producten, die het resultaat weergeven van een interview met "Stedelijk Wonen", zijn niet slechts indicatief maar weerspiegelen de concrete behoefte en de betreffende organisatieonderdelen zijn in staat en bereid om -indien nodig bij te dragen aan de uitwerking van realiseerbare specificaties; Eventuele nieuwe vragen naar specialistische producten zullen alleen worden meegenomen in het project mits de beschikbare middelen dit mogelijk maken en onder het voorbehoud van instemming door het Management; De uitgewerkte planning voor de 1 e reeks business producten is indicatief. Uitvoering van deze producten zal resulteren in concrete ervaringscijfers die vervolgens de richtlijn kunnen vormen voor de volgende reeks producten. Bestandsnaam: PID Auteur:Lars Schumacher 13

14 5.5 Projectplanning In de bijlagen zijn grafische weergaven opgenomen van de planning op projectniveau, waarbij de verschillende fasen van het project met hun doorlooptijd en afhankelijkheden zijn weergegeven. In de gedetailleerde faseplanningen kunnen als gevolg van opgedane ervaringen en nieuwe gegevens aanpassingen plaatsvinden. Samengevat: Fase Geplande Startdata Geplande Einddata Geplande Uren Doorlooptijd cumulatief Fase 1 PID Fase 1 Functioneel ontwerp Fase 1 Technisch ontwerp Fase 2 Basis creëren Fase 2 Relaties Fase 2 Eigenaars Fase 2 Debiteurbewaking Fase 2 Beheerteam Fase 2 Advieslijst Fase 2 Urenadministratie Fase 2 Testen Algemeen Beheer TOTAAL: 2176 uur 178 dagen 5.6 Benodigde Hulpbronnen Fase Wat Wie Globale vereiste beschikbaarheid Tarief In /uur /p.p. 1,2,3 Project Manager Jo Lahaye 0.40 fte 80 1,2,3 Projectleader Verschilt per semester 1.00 fte 60 1,2,3 Teamleader Verschilt per semester 1.00 fte 40 1,2,3 Technical Project support Ties van Ham Jasper Krijgsman 0.40 fte 0.40 fte ,2 Materiedeskundigheid Peter Winterman Simon Wassenaar Bouwe Regeling 0.10 fte 0.10 fte 0.10 fte ,2,3 Developer Verschilt per semester 1.00 fte Kosten De eenmalige kosten hebben geen invloed op dit deelproject, maar deze heeft wel invloed op het overkoepelende project WOSI. Bestandsnaam: PID Auteur:Lars Schumacher 14

15 6 Beheersingsmechanismen Hierna wordt aangegeven welke mechanismen worden toegepast om te waarborgen dat het project beheersbaar blijft. 6.1 Toleranties Tijdens de uitvoering van het project controleert de Projectleader regelmatig de voortgang. Indien de afwijking van de plannen naar verwachting groter is dan de afgesproken tolerantie, wordt daarover apart gerapporteerd aan de Project Manager. De tolerantie op projectniveau is als volgt gedefinieerd: - doorlooptijd plus of min 10%; - kosten plus of min 10%. Per fase kunnen afwijkende toleranties worden opgenomen in de faseplanningen, afhankelijk van de omvang en impact van risico s. 6.2 Voortgangsrapportage Er zijn drie soorten voortgangsrapportages van de Projectleader aan de Project Manager: Highlight Report (reguliere voortgangsrapportage, kwalitatief en kwantitatief); Exception Report (rapportage indien de tolerantiegrenzen van het project of de fase in tijd en/of geld dreigen te worden overschreden); End Stage Report (terugblik op afgelopen fase (evaluatie) en vooruitblik op eerstkomende fase (faseplanning). Daarnaast is er een voortgangsrapportage van de Teamleaders aan de Projectleader: Checkpoint Report (reguliere voortgangsrapportage, kwalitatief en kwantitatief). 6.3 Tijd- en kostenrapportages Om de Projectleader te voorzien van stuurinformatie en in staat te stellen voortgangsrapportages op te stellen is het noodzakelijk dat developers regelmatig de bestede tijd, de nog te besteden tijd en de verwachte opleverdatum van de diverse producten rapporteren, eventueel via de Teamleader. Daarnaast dienen degenen die verantwoordelijk zijn voor extern in te kopen (deel-) producten, voorziene afwijkingen van geplande kosten en definitieve kosten direct te melden aan de Projectleader. Bestandsnaam: PID Auteur:Lars Schumacher 15

16 6.4 Kwaliteitsrapportages De verantwoordelijken voor kwaliteitscontrole rapporteren regelmatig aan de Projectleader over de voortgang en resultaten van kwaliteitscontroles, conform de daarvoor geldende procedures. Om de effectiviteit van de kwaliteitscontroles vast te stellen, worden hierover statistieken verzameld, die in elk End Stage Report vermeldt worden. 6.5 Uitzonderingsprocedure ( Management by Exception ) De uitzonderingsprocedure treedt in werking als van een fase of van het project verwacht wordt dat het niet binnen de afgesproken tolerantiegrenzen ten aanzien van tijd en geld blijft. Zodra de Projectleader dit op basis van aangeleverde informatie verwacht, meldt de Projectleader dit in een Exception Report aan de Project Manager. In onderling overleg wordt de aanleiding en oorzaak besproken. Daarna wordt besloten tot één van de volgende situaties: - De Project Manager treft maatregelen ter voorkoming/opheffing van de aanleiding; - De Project Manager besluit geen actie te ondernemen, omdat het denkt dat de overschrijding van de tolerantie niet plaats zal vinden; - de toleranties voor de fase worden verruimd; - er worden concessies gedaan ten aanzien van tijd, geld, kwaliteit of omvang van het op te leveren resultaat (bereik). De eerste drie situaties worden vermeld in het eerstvolgende Highlight Report. De laatste situatie kan op verzoek van de Project Manager leiden tot het opstellen van een Exception Plan met alternatieven voor de aanpak van het vervolg van het project en aangepaste planningen. Bestandsnaam: PID Auteur:Lars Schumacher 16

17 7 Projectrisico s De volgende tabel geeft een overzicht van de tot nu toe onderkende bedreigingen ten aanzien van het project met voorgestelde tegenmaatregelen, de kans van optreden en de mate van negatief effect op het project (aangegeven op een schaal van 1tot 5). De laatste kolom geeft het risico aan (kans*effect). Op deze wijze kan gefundeerd worden afgewogen welke bedreigingen de meeste aandacht of hulpbronnen verdienen. Bedreiging Tegenmaatregel Kans Effect Risico Een van de teamleden kan tijdelijk niet meer deelnemen aan het project. Deadlines worden niet gehaald. De gebruikers kunnen niet goed overweg met het programma WOSI wordt stopgezet De harde schijf waar alle gegevens opstaan gaat kapot. Kwaliteit van applicatie en ontwerpen is onder de maat. De rest van het team zal het werk van de afwezige moeten verdelen en afmaken. Een controleur aanstellen in het team die de voortgang bewaakt en de teamleden aanspreekt mochten ze achterlopen op schema. Een duidelijke handleiding schrijven en evt. een workshop geven Is niets tegen te doen Regelmatig back-up maken van de gegevens. Teamleden het gedane werk laten controleren en voortijdig een overleg met Technical Project Support & Projectleader en de Project Manager Bestandsnaam: PID Auteur:Lars Schumacher 17

18 Bijlage 1: Kwaliteitsplan De kwaliteit van de op te leveren producten wordt in grote lijnen gewaarborgd door functiescheiding, het aansluiten op (bedrijf)standaarden, meetbare kwaliteitscriteria en diverse procedures voor kwaliteitscontrole, configuratie- en wijzigingsbeheer. Verantwoordelijkheden Uitgangspunt: Kwaliteitcontroles vinden plaats door onafhankelijke derden (functiescheiding). Verantwoordelijkheid voor kwaliteit is op diverse niveaus belegd, zoals hieronder beschreven. Verantwoordelijkheden m.b.t. kwaliteit op projectniveau Rol Belangrijkste Verantwoordelijkheden Kwaliteitscontrole Controleren of aan afspraken is voldaan en conform de standaarden wordt gewerkt (zowel t.a.v. de kwaliteit van het projectmanagement als van de in het project opgeleverde/nog op te leveren producten). Projectleader Bewaken dat kwaliteitscontroles plaatsvinden conform de afspraken en indien nodig escaleren van gemelde omissies in kwaliteit Toekomstige gebruikers Vroegtijdig aangeven aan welke kwaliteitscriteria de (deel)producten dienen te voldoen Goedkeuren van productbeschrijvingen, inclusief kwaliteitscriteria Tussentijds uitvoeren van acceptatietests op (deel)producten Projectmedewerkers beschrijven van kwaliteitscriteria per (deel)product bij ontwikkeling producten houden aan die criteria Kwaliteitscontroleurs meten/verifiëren of (deel)producten voldoen aan de (Teamleader, beschreven kwaliteitscriteria (objectief) Developers & melden van niet beschreven, maar wellicht wel Eindgebruikers) relevante criteria aan Projectleader Bestandsnaam: PID Auteur:Lars Schumacher i

19 Aansluiting bij (bedrijf)standaarden & Kwaliteit producten Het project sluit aan bij de volgende (bedrijf)standaarden: Prince 2 projectmanagement methodiek. Voor alle op te leveren (deel)producten wordt een productbeschrijving gemaakt (zie bijlagen). Een belangrijk onderdeel van elke projectbeschrijving wordt gevormd door: - meetbare kwaliteitscriteria; - kwaliteitsmethode om die criteria te meten/verifiëren; - kwaliteitsverantwoordelijke(n) voor de uitvoering van de kwaliteitsmeting. De belangrijkste kwaliteitscriteria waaraan de belangrijkste producten dienen te voldoen zijn: uitvoering van een acceptatietest met (eind)gebruikers en/of belanghebbenden; acceptatie door de (eind)gebruikers en/of belanghebbenden conform de op basis van het functioneel ontwerp gespecificeerde criteria. Kwaliteitscontrole Er zijn kwaliteitscontroleprocedures voor: - de kwaliteit van het projectmanagement; - de kwaliteit van de (deel)producten. Bij de controleprocedures voor de kwaliteit van de (deel-)producten wordt een onderscheid gemaakt tussen een algemene procedure voor alle typen producten en een methode voor kwaliteitscontrole die specifiek voor documenten toepasbaar is (Quality Review). Bestandsnaam: PID Auteur:Lars Schumacher ii

20 Bijlage 2: Projectarchief Het projectarchief is opgedeeld in 2 niveaus. Het elektronisch archief en het analoge archief (papier). Een uitleg zal gegeven worden m.b.t. de naamgeving en versiebeheer. Naam Rol Beschrijving Elektronisch archief (basis) Projectleader Elektronisch archief Voor het project dient een Elektronisch archief te worden aangelegd in de volgende directory: In het Elektronisch archief worden alle gegevens opgeslagen. De hoofd-directorie zal subdirectories bevatten voor informatie betreft deelproducten. Vb.: Project VvE (Hoofdmap) --> Fase1 deelproduct PID (Submap) Analoge archief (basis) Projectleader/ Teamleader Analoge archief De projectleader heeft een projectdossier en bewaart deze in een map op zijn kamer(c2.05). Deze map is toegankelijk voor alle projectmedewerkers en kan de volgende stukken bevatten: PID Functioneel ontwerp Technisch ontwerp Naamgeving Management producten (basis) Versiebeheer (basis) Projectleader Projectleader Naamgeving Management producten Het documentnaam volluit schrijven gevolgd door de projectnaam, maand, versienummer, en jaartal. Vb.: PID PIDVVEmaart(1.0)2010.doc Versiebeheer De Projectleader is verantwoordelijk voor een juist versiebeheer en zorgt ervoor dat de nieuwste versie van een document zich zowel in het digitaal als in het papieren dossier bevindt. Versie 1.0 is altijd een definitieve versie Het projectarchief wordt beheerd door de Projectleader, eventueel gedelegeerd aan Technical Project Support. In een inhoudsopgave worden alle stukken in het archief vermeld met een korte beschrijving. Dit wordt bijgehouden door een ieder die stukken toevoegt. Er wordt regelmatig een back-up van het archief gemaakt. Bestandsnaam: PID Auteur:Lars Schumacher iii

21 Bijlage 3: Grafische weergaven projectplanning Fase t/m Fase t/m Bestandsnaam: PID Auteur:Lars Schumacher iv