9 Fase 5: Opleveren kennis/competenties - HU
advertisement
Auteurs Debby Goedknegt Rien van Stigt Tom van Weert Inlichtingen T (030) 230 8151 E [email protected] Datum 25 juli 2017 Hogeschool Utrecht Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding Ontwerpprojecten Handleiding ontwerpprojecten Inhoudsopgave 1 Inleiding 5 1.1 Kenniswerk ................................................................................................................ 5 1.2 Werkwijze .................................................................................................................. 5 1.3 Mobiliseren van kennis .............................................................................................. 7 1.4 Valideren ................................................................................................................... 7 1.5 Reviewen ................................................................................................................... 8 1.6 Beoordelen ................................................................................................................ 13 1.7 Werkomgeving: rol van ICT ....................................................................................... 14 2 Op te lossen praktijkvragen 15 2.1 Onderzoeksgebieden ................................................................................................ 15 2.2 Competentiegebieden ............................................................................................... 15 2.3 Op te lossen vragen uit de praktijk ............................................................................ 16 2.3.1 Opdrachtgever .................................................................................................... 16 2.3.2 Projectsponsor .................................................................................................... 17 2.4 Solliciteren op projecten ............................................................................................ 18 3 Projectmethode 19 3.1 Inleiding ..................................................................................................................... 19 4 Fase 0: Vraag ontwikkelen 24 5 Fase 1: Voorbereiden 26 5.1 Solliciteren ................................................................................................................. 27 5.2 Sollicitatieprocedure .................................................................................................. 28 5.3 Start-Up voorbereiden ............................................................................................... 29 5.4 Start-Up bijeenkomst ................................................................................................. 30 5.4.1 Organisatie van de het projectteam .................................................................... 31 5.4.2 Verdelen van taken ............................................................................................. 31 5.4.3 Verhoudingen in het team ................................................................................... 32 5.4.4 Beheersbaar houden van het werkproces .......................................................... 32 5.4.5 Documentatie van het werkproces ...................................................................... 33 6 Fase 2: Project ontwikkelen 34 6.1 De projectstappen in de fase project ontwikkelen...................................................... 36 6.2 Uitgangspositie bepalen ............................................................................................ 39 6.2.1 Valideren praktijkvraag ....................................................................................... 39 6.2.2 Kennis mobiliseren ............................................................................................. 42 6.3 Diagnose stellen ........................................................................................................ 45 6.3.1 Analyseren huidige praktijksituatie...................................................................... 45 6.3.2 Gewenste praktijksituatie in kaart brengen ......................................................... 46 6.4 Aanpak uitwerken ...................................................................................................... 49 6.4.1 Specificeren probleemaanpak ............................................................................ 50 6.4.2 Probleemaanpak intern valideren voor de kennisvraag ...................................... 52 6.5 Project organiseren ................................................................................................... 54 6.5.1 Specificeren werkwijze projectteam .................................................................... 54 6.5.2 Specificeren competentieontwikkeling ................................................................ 58 6.6 Kwaliteitsborging organiseren.................................................................................... 63 2/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 6.6.1 Risicomanagement ............................................................................................. 63 6.6.2 Kwaliteitscriteria specificeren .............................................................................. 63 6.7 Plan van Aanpak ....................................................................................................... 72 6.7.1 Inhoudsopgave van het Plan van Aanpak .......................................................... 72 6.7.2 Achtergrond literatuur ......................................................................................... 73 6.8 Valideren Plan van Aanpak ....................................................................................... 75 6.9 Start-Up Review ........................................................................................................ 76 6.10 Flankerend workshops .............................................................................................. 77 7 Fase 3: Ontwerpen en ontwikkelen 78 7.1 Het functioneren van het projectteam ........................................................................ 78 7.2 Oplossing ontwerpen ................................................................................................. 80 7.3 Flankerende workshops ............................................................................................ 81 7.4 Valideren conceptueel ontwerp ................................................................................. 81 7.5 Oplossing ontwikkelen ............................................................................................... 81 7.6 Oplossing implementeren .......................................................................................... 81 7.7 Valideren geïmplementeerde oplossing .................................................................... 81 7.8 Mid-Term Review ...................................................................................................... 81 7.9 Oplossing verbeteren ................................................................................................ 82 8 Fase 4: Opleveren oplossing 83 9 Fase 5: Opleveren kennis/competenties 85 9.1 Lessons Learned Review .......................................................................................... 86 9.2 Opleveren kennis en competentie ............................................................................. 86 9.2.1 Voortgangs zelfevaluatie..................................................................................... 86 9.2.2 Team zelfevaluatie.............................................................................................. 86 9.2.3 Individuele zelfevaluatie competentie ontwikkeling ............................................. 86 9.2.4 Resultaten van de afsluiting van het project ....................................................... 87 9.2.5 Tips ..................................................................................................................... 87 10 Beoordeling 88 10.1 Voorlopige beoordelingen .......................................................................................... 88 10.2 Definitieve beoordeling .............................................................................................. 88 11 Nazorg 89 12 Projecten in onderwijsinformatiesysteem 90 13 Belangrijke Begrippen 91 13.1 Algemene begrippen ................................................................................................. 91 13.2 Projectgebonden begrippen ...................................................................................... 92 14 Verantwoording 94 15 Verwijzingen 95 3/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Deze handleiding is herbruikbaar door derden onder een Creative Commons licentie Naamsvermelding-NietCommercieel-Gelijk delen licentie is van toepassing op dit werk. Ga naar http://creativecommons.org/licenses/by-nc-sa/2.5/nl/ om deze licentie te bekijken. 4/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 1 Inleiding 1.1 Kenniswerk In de praktijk werken hbo-afgestudeerden vaak aan ingewikkelde problemen, waarvoor ze een innovatieve oplossing zoeken. Het gaat dan vaak om complexe problemen, die niet vanuit één discipline zijn op te lossen: er wordt gewerkt in multidisciplinaire teams, waarin de teamleden verschillende rollen spelen, bijvoorbeeld projectleider of domeinexpert. Projectonderwijs probeert hierop in te spelen. Bij het projectonderwijs waar we het hier over hebben is er een vraag uit de praktijk. Door middel van een sollicitatieprocedure worden teams van studenten samengesteld die de vraag projectmatig aanpakken en een innovatieve oplossing aandragen. Een onderzoeker naar duurzame vormen van bewoning in Pretoria heeft bijvoorbeeld het idee om een database op te zetten van woningtypen in de informele nederzettingen die de stad rijk is. Zijn probleem is opgelost als de database volgens zijn wensen werkt, is gevuld met de onderzoeksresultaten en door hemzelf en zijn medewerkers kan worden gebruikt bij het onderzoek. Projectonderwijs is bedoeld om er iets van te leren; het projectteam verwerft werkenderweg verschillende competenties. Elke vraag uit de praktijk zal weer om andere combinaties van competenties vragen en het hangt ook af van de rol die iemand in een projectteam speelt welke competenties hij of zij ontwikkelt. Het is daarom van belang om deel te nemen aan een projectteam waar juist die competenties worden gevraagd die je wilt ontwikkelen. Anders dan je waarschijnlijk gewend bent van eerdere onderwijsprojecten kom je hier voor praktijkvragen te staan waarbij je niet alleen de kennis die je hebt opgedaan in een praktijksituatie zult toepassen, maar juist ook nieuwe kennis zult moeten ontwikkelen. Dat kan bijvoorbeeld procedurele kennis zijn: er is een methode, maar die is in de gegeven situatie nog niet op die manier toegepast en we willen weten of dat een verbetering oplevert van de praktijk. Een projectontwikkelaar krijgt nogal wat kritiek van bewonersgroepen op een stedenbouwkundig plan; er zou te weinig aandacht zijn besteed aan aspecten van duurzame ontwikkeling en ook het betrekken van huidige en toekomstige bewoners van het project zou te laat en te weinig zijn gebeurd. De projectontwikkelaar vraagt zich af of er in zo'n geval een alternatief is, dat toch voldoet aan de financiële en stedenbouwkundige randvoorwaarden. Deze handleiding beschrijft opzet en organisatie van ontwerpprojecten die in kader van het project Verbinden van Onderwijs en Onderzoek van de Digitale Universiteit worden uitgevoerd. In het geval dat deze handleiding aanwijzingen bevat die strijdig zijn met geldende gedragsreglement, de Onderwijs & Examenregeling (OER) of de studiegids, gaat de aanwijzingen in deze laatst genoemde regelingen vóór. 1.2 Werkwijze Een project waarin we naast een concrete oplossing voor de praktijk ook competenties en nieuwe kennis ontwikkelen, kent een aantal fasen: Projectontwikkeling: Het projectteam analyseert de vraag van de opdrachtgever, stelt een diagnose en bepaalt wat het project aan resultaten zal opleveren (zowel voor de opdrachtgever als voor de eigen competentieontwikkeling en voor de kennisontwikkeling. De organisatie van het project wordt opgezet: planning in de tijd, oplevering van (tussen)resultaten en kwaliteitssysteem. 5/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Ontwerp van de oplossing: Eerst is er een "oplossing op grote lijnen", een conceptueel ontwerp. Ontwikkelen van de oplossing: Het conceptueel ontwerp wordt omgezet in een oplossing die "werkt". Implementeren van de oplossing: De werkende oplossing wordt uitgevoerd in de context waarin deze ook gebruikt moet worden, meestal bij de opdrachtgever "in huis". Verbeteren van de oplossing: Uitgaande van ervaringen in de praktijk wordt de ontworpen oplossing verder verbeterd. Opleveren van de oplossing: Als alles "werkt" wordt de oplossing overgedragen aan de opdrachtgever. Opleveren van kennis en competentie: Naast de oplossing voor de opdrachtgever heeft het project ook nieuwe kennis opgeleverd en hebben de individuele projectteamleden competenties ontwikkeld. Die worden gecheckt en gedocumenteerd. Praktijk vraag Praktijk oplossing Competentieagenda Competentieontwikkeling Ontwikkelde competentie Oplossing Ontwikkelen Oplossing ontwerpen Oplossing Implementeren Oplossing Projectontwikkelen Conceptueel ontwerp Probleemstelling Diagnose Projectorganisatie Vraag Vraagontwikkelen Oplossing opleveren Kennis en competentie opleveren Oplossing verbeteren Contextkennis Kennisagenda Methoden Oplossingen Ontwikkelde kennis Kennisontwikkeling Figuur 1.1 Projectfasen in ontwerpprojecten 6/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 1.3 Mobiliseren van kennis Hergebruik van kennis is noodzaak om een goede, werkzame oplossing te kunnen realiseren. Daarbij moet worden nagegaan of er lokaal voldoende kennis beschikbaar is om dit specifieke probleem op te lossen of dat er ook nog kennis van elders nodig is. Consultatie van experts en literatuurstudie zal hierover uitsluitsel moeten geven. Gevonden bruikbare kennis moet worden geïntegreerd met reeds beschikbare kennis en vertaald worden naar de specifieke probleemsituatie (Figuur 1.2). Praktijk vraag Praktijk oplossing Competentieagenda Competentieontwikkeling Ontwikkelde competentie Oplossing Ontwikkelen Oplossing Implementeren Oplossing Oplossing ontwerpen Conceptueel ontwerp Projectontwikkelen Probleemstelling Probleemaanpak Projectorganisatie Vraag Vraagontwikkelen Oplossing opleveren Kennis en competentie opleveren Oplossing verbeteren Kennisagenda Oplossingen ContextMethoden kennis Projectorganisatiekennis Kennisontwikkeling Ontwikkelde kennis Kennis mobiliseren Figuur 1.2 Kennis mobiliseren in een ontwerpgericht project Contextkennis is nodig om de praktijkomgeving waar het probleem speelt te kunnen analyseren. Oplossingskennis gebruik je om mogelijke oplossingen te kunnen identificeren. Methoden kennis maakt het mogelijk om een aanpak te bepalen waarlangs het probleem kan worden opgelost. En ten slotte is er nog projectorganisatiekennis die het je mogelijk maakt om het project effectief te organiseren. 1.4 Valideren In het verleden was het niet ongebruikelijk dat experts een oplossing voor een probleem bedachten die “over de schutting werd gegooid”. Deze aanpak is weinig succesvol gebleken. Tegenwoordig worden de “gebruikers” van de te ontwikkelen oplossing nauw bij probleemanalyse en daarna bij ontwerp, ontwikkeling en implementatie van de oplossing betrokken, zodat er goede garantie bestaat dat de oplossing ook echt werkt.‘Valideren’ is het proces waarmee wordt nagegaan dat daadwerkelijk aan de behoefte van de omgeving tegemoet wordt gekomen (Figuur 1.3). In het ontwerp en ontwikkelproces neemt de ontwerper/ontwikkelaar het initiatief voor het valideren, organiseert het proces en voert het uit. Het proces van valideren wordt bij het gereed komen van een mijlpaalresultaat gestart. 7/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Valideren of geldig in context Praktijk vraag Praktijk oplossing Competentieagenda Competentieontwikkeling Ontwikkelde competentie Oplossing Ontwikkelen Oplossing Implementeren Oplossing Oplossing ontwerpen Conceptueel ontwerp Projectontwikkelen Probleemstelling Diagnose Projectorganisatie Vraag Vraagontwikkelen Oplossing opleveren Kennis en competentie opleveren Oplossing verbeteren Contextkennis Kennisagenda Methoden Oplossingen Ontwikkelde kennis Kennisontwikkeling Figuur 1.3 Valideren van geldigheid in de praktijk 1.5 Reviewen Maar ook al is een resultaat of oplossing valide, deugt het resultaat dan ook? En hoe moet dat worden vastgesteld? Vroeger ging het vaak om standaardproblemen waarvoor een professional werd ingeschakeld om het probleem op te lossen volgens een gefixeerde en alom bekende kwaliteitsstandaard. In die situatie wisten alle betrokkenen waar zij aan toe waren. Tegenwoordig gaat het echter vaak om innovatieve problemen waarvoor geen gefixeerde kwaliteitsstandaarden beschikbaar zijn en het niet meteen duidelijk is of een oplossingsproces effectief is en of de oplossing kwaliteit heeft. Om toch de kwaliteit van probleemoplossing en resultaat te kunnen garanderen en transparant te maken wordt “reviewing” gebruikt: geregeld nagaan dat ontwerp/ontwikkelproces en (tussen)resultaten aan geformuleerde kwaliteitscriteria voldoen (Figuur 1.4). Zo niet, dan worden verbeteracties ondernomen, ook ten aanzien van de rolvervulling van de ontwerpers/ontwikkelaars. Deze aanpak blijkt succesvol in situaties waar professionals innovatieve problemen aanpakken. In het ontwerp en ontwikkelproces neemt een ontwerper/kennisontwikkelaar (of een groep ontwerpers/kennisontwikkelaars) het initiatief voor reviewing. Het proces van reviewen wordt onmiddellijk na validatie van een mijlpaalresultaat gestart. 8/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Praktijk vraag Praktijk oplossing Competentieagenda Competentieontwikkeling Ontwikkelde competentie Oplossing Ontwikkelen Oplossing Implementeren Oplossing Oplossing ontwerpen Conceptueel ontwerp Projectontwikkelen Probleemstelling Diagnose Projectorganisatie Vraag Vraagontwikkelen Oplossing opleveren Kennis en competentie opleveren Oplossing verbeteren Contextkennis Kennisagenda Methoden Oplossingen Ontwikkelde kennis Kennisontwikkeling Review = Kritisch reflecteren vanuit kwaliteitscriteria Start Up review Midterm review Lessons Learned review Figuur 1.4. Reviewen op kwaliteit Kwaliteitscriteria In een review wordt zowel kritisch gekeken naar hoe het proces verlopen is, als naar de geboekte resultaten. Omdat te kunnen doen moet je weten waarnaar je moet kijken. Er zijn dus kwaliteitscriteria nodig voor: de werkwijze het functioneren van de teamleden het praktijkresultaat het kennisresultaat het competentieresultaat. Op grond van de beschikbare kennis hanteren wij de volgende kwaliteitskenmerken. Kwaliteitskenmerken voor de werkwijze Controleerbaar o de activiteiten in de werkwijze vormen een compleet geheel, o de activiteiten zijn voldoende gedetailleerd om te kunnen zien wat ze voor effect zullen hebben, o de werkwijze is transparant, dat wil zeggen informatief en begrijpelijk. 9/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Vakkundig o de beschikbare kennis is goed gemobiliseerd (kenniseffectief), o de werkwijze is goed georganiseerd en kwaliteitgericht (organisatorisch effectief), o de werkwijze is efficiënt naar tijd, (geld) en te investeren energie, o de werkwijze is toelaatbaar (voldoet aan de ARBO-eisen, is ethisch verantwoord, etc.). Logisch o de werkwijze is logisch consistent (houdt zich aan de regels van de logica), o de werkwijze volgt de gekozen methode en wat is afgesproken, o de werkwijze houdt zich aan de geschreven, of ongeschreven, beroepscode, Valide in de context o de werkwijze is functioneel in de contextsituatie o de werkwijze is haalbaar in de contextsituatie Kwaliteitskenmerken voor het functioneren van de teamleden Deze criteria hebben alles te maken met de (te ontwikkelen) competenties van de persoon. De competenties leggen vast hoe verwacht wordt dat teamleden functioneren en op welk niveau. Er zijn competenties die verbonden zijn met de taken die horen bij specifieke functies uit de professionele praktijk (praktijkcompetenties). Aankomend Vastgoedontwikkelaar (m/v) U bent als vastgoedontwikkelaar in staat om conform de binnen onze organisatie gangbare methoden een projectteam te managen en het planvormingsproces te ontwerpen en te begeleiden. Uw relatie tot het projectteam is die van meewerkend voorman. Daarnaast bent u in staat om conform de binnen onze organisatie gebruikelijke methode het proces van kennisontwikkeling te managen. Taken: Managen van een projectteam conform projectmethode Begeleiden van een complex planvormingsproces conform planvormingmethode Begeleiden van kennisontwikkelingsproces conform onderzoekmethode Haalbaarheidsonderzoek uitvoeren zoals binnen onze organisatie gebruikelijk Opstellen programma van eisen conform het door ons gehanteerde format Verder zijn er de meer algemene competenties die elke beroepsbeoefenaar moet hebben (professionele of academische competenties). Deze zijn verbonden met bepaalde rollen: Lerende professional Organisator Ontwerper Onderzoeker, en Adviseur De lerende professional is verbonden met een kritisch lerende aanpak van Plannen-HandelenWaarnemen-Reflecteren. De professionele competenties in de andere rollen staan gespecificeerd in Tabel 0.1. 10/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Organisator Ontwerper Onderzoeker Adviseur Organisatiecompetenties Intellectuele competenties Informatie competenties Interactie competenties Vraag en project ontwikkelen Situatie analyseren Kennis mobiliseren Interactiebehoefte ontwikkelen Planvorming Draagvlak creëren Conceptueel modelleren Kennis ontwikkelen Interacties vormgeven Uitvoering Modellen toepassen Kennis toepassen Dialoog voeren Interactief samenwerken Kwaliteitsborging Kritisch reflecteren op toepassing Kennis beoordelen Interacties beoordelen Tabel 0.1 Algemene competenties van de lerende professional Persoonlijk ontwikkelingsPlan (POP) Praktijk- en professionele competenties kunnen op verschillende niveaus worden waargemaakt; reproductiegericht, taakgericht, probleemgericht en situatiegericht (zie Tabel 0.2) Praktijkrol Kenniswerkersrol Reproductie gericht Taak gericht Probleem gericht Situatie gericht Probleem (wat) Doel (wat) Afgebakend gegeven Afgebakend gegeven Afgebakend gegeven Af te bakenen Methode (hoe) Patroon (hoe) Bekend Bekend Te kiezen Te kiezen Domeinkennis Proceskennis Gegeven Gegeven Te mobiliseren Te mobiliseren Uitvoering (wie, wanneer, waar) Handelen Reproductief In te vullen In te vullen In te vullen Valide oplossing Valide resultaaat Afgebakend Af te bakenen Af te bakenen Af te bakenen Tabel 0.2 Competentieniveaus 11/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten In het Persoonlijk OntwikkelingsPlan wordt vastgelegd welke praktijkcompetenties en welke professionele competenties je in het project specifiek gaat ontwikkelen en tot welk niveau. Uiteraard is daarbij je ingangsniveau van belang. De kwaliteitscriteria die gelden voor je persoonlijk functioneren, zijn dan de (te ontwikkelen) competenties. Persoonlijke OntwikkelingsPlannen van de teamleden worden afgestemd in het Team OntwikkelingsPlan (TOP), zie 6.5.2. Kwaliteitscriteria voor resultaten Criteria voor praktijkresultaten, kennisresultaten en competentieresultaten: valide o functioneel o begrijpelijk betrouwbaar adequaat is, dat wil zeggen precies controleerbaar verankerd relevant consistent is in de score op de criteria. Hieronder staan deze kenmerken uitgewerkt in criteria voor een Plan van Aanpak dat het resultaat is van de fase project ontwikkelen (fase 2). Voorbeeld Uitwerking kwaliteitscriteria Plan van Aanpak Valide Doelgericht en functioneel Richt de inhoud van het Plan van Aanpak op gebruik er van. Laat daarom de stappen in de hoofdlijn van de inhoud aansluiten bij het beoogde gebruik. Schrijf de inhoud in termen van het gebruik. Laat verder zien dat de voorgestelde oplossing controleerbaar geldig is in de huidige context. Laat dit zien vanuit inhoudelijke argumenten en vanuit raadpleging van stakeholders in en mogelijk gebruikers van de oplossing. Laat zien dat de voorgestelde aanpak wordt gedragen door stakeholders en gebruikers. Begrijpelijk Schrijft niet vanuit wat jíj weet en jíj wilt vertellen, maar vanuit wat de lezer moet weten om een antwoord te krijgen op begrijpelijke hoofdvragen, die je expliciet hebt vermeld. Maak zinnen en tekst die in één keer lezen begrijpelijk zijn voor de lezer. Pas je toon aan bij het taalgebruik in de organisatie en zorg dat je niet van de inhoud afleidt door te informeel, te geladen of niet neutraal genoeg taalgebruik, teveel eigen en persoonlijke opinies van jou als schrijver. Haalbaar Laat zien dat de beschreven oplossing haalbaar is in de praktijkcontext en dat gebruikers er mee uit de voeten kunnen. 12/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Betrouwbaar Laat zien dat de oplossing op een controleerbare en binnen de professionele praktijk geaccepteerde wijze tot stand zal komen. Maak duidelijk dat er hierdoor weinig risico is van een onjuiste of ondermaatse uitkomst van de oplossing. Laat zien dat de organisatie van het werk op binnen de professionele praktijk geaccepteerde wijze plaatsvindt en dat de gestelde doelen haalbaar zijn. Adequaat Precies Zorg dat alle nodige stappen, keuzes en vooronderstellingen zijn weergegeven. En dat alle gegevens en overwegingen die de keuzes,conclusies of adviezen onderbouwen, zijn vermeld. Zorg dat illustraties/schema’s/grafieken functioneel zijn en de duidelijkheid of de aantrekkelijkheid van de inhoud vergroten. Gebruik daarom illustraties voor bieden van overzicht, maak ze gemakkelijk afleesbaar, licht ze goed toe en beperk ze tot essenties. Verankerd Zorg dat de inhoud is verankerd in praktijkcontext en met name de gebruikscontext van de oplossing. Gebruik geen niet passende theoretische indelingen of procesbeschrijvingen. Maak een correct en op de gebruiker afgestemd gebruik van vaktermen en gebruik deze volgens de gangbare definities. Licht vaktermen toe in het geval de tekst ook voor een breder publiek dan vakgenoten bedoeld is. Relevant Laat zien dat de beschreven oplossing nuttig is voor de gebruikers die deze gaan toepassen. Ga na dat zonder déze inhoud toepassing niet goed mogelijk zou zijn. Zorg dat alle informatie die relevant is voor toepassing, aanwezig is, maar niet meer dan dat. Neem geen overbodige onderdelen op. Controleerbaar Laat zien hoe je aan de gegevens en overwegingen bent gekomen die de keuzes,conclusies of adviezen onderbouwen. Maak duidelijk wie betrokken waren en wat je met hun input hebt gedaan. Consistent en logisch Zorg dat de stappen elkaar aanvullen en dat ze op elkaar voortbouwen naar een totaal. Stappen, keuzes en vooronderstellingen moeten logisch consistent zijn en logisch op elkaar aansluiten. Ga verder na dat het totaal Ga na dat aan het totaal van de kwaliteitscriteria consistent voldaan is, dat er balans is. 1.6 Beoordelen Na de Midterm Review is het voor de organisatie waarbinnen het project wordt uitgevoerd, tijd de voorlopige balans van het project op te maken. De projectsponsor, als manager van de afdeling waarbinnen het project wordt uitgevoerd, is hierin de centrale figuur. Op basis van de resultaten van de Midterm Review geeft de projectsponsor aan de hand van de vastgelegde beoordelingscriteria een gemotiveerde beoordeling van: Team o resultaten tot nu toe de kwaliteit van de oplossing, de kwaliteit van de ontwikkelde kennis. o uitvoering van het proces tot nu toe de professionele rolvervulling van het team. Individuele teamleden o de professionele rolvervulling van individuele teamleden. o de individuele persoonlijke ontwikkeling. De voorlopige beoordeling worden gevalideerd met het projectteam. Degene die uiteindelijk de validiteit van de beoordeling vaststelt, is de projectsponsor. Indien geen overeenstemming over de voorlopige 13/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten beoordeling bereikt kan worden, stelt de projectsponsor de beoordeling vast, maar neemt de bezwaren van het projectteam of het betreffende teamlid bij de beoordeling op. Na de Lessons Learned Review wordt de eindbeoordeling opgemaakt. Deze wordt afgeleid van de voorlopige beoordeling door na te gaan welke verbeteringen (of verslechteringen) sinds deze voorlopige beoordeling zijn bereikt. De eindbeoordeling worden gevalideerd met het projectteam. Degene die uiteindelijk de validiteit van de beoordeling vaststelt, is de projectsponsor. Indien geen overeenstemming over de voorlopige beoordeling bereikt kan worden, stelt de projectsponsor de beoordeling vast. Het projectteam of het betreffende teamlid kan bezwaren tegen de eindbeoordeling kenbaar maken bij examencommissie of de commissie van beroep. Het eindcijfer wordt afgeleid uit de definitieve beoordeling. 1.7 Werkomgeving: rol van ICT Een (webgebaseerde) werkomgeving levert een aantal belangrijke ondersteunende functies die geïntegreerd en onafhankelijk van tijd en plaats te gebruiken zijn: procesorganisatie communicatie ontwikkeling kennismanagement Bij de centrale functie communicatie gaat het om hulpmiddelen en gegevens ter ondersteuning van het teamproces, waarin gecommuniceerd en gewerkt wordt met teamleden, begeleiders en opdrachtgevers. De functie procesorganisatie levert hulpmiddelen en gegevens die werkwijze en planning ondersteunen. In de functie ontwikkeling hebben teamleden de beschikking over diverse ICT-tools (office suite) om hun persoonlijke productiviteit te verhogen. Verder wordt er in voorkomende situaties gebruik gemaakt van vakof beroepsspecifieke ICT-tools die in de beroepspraktijk gebruikt worden. Ook worden er tussenresultaten bewaard. Bij de functie kennismanagement gaat het om opsporen en toegankelijk krijgen van digitale kennis en expertkennis die via intranet of internet te vinden zijn, maar ook om het beschikbaar stellen van kennis aan team en buitenwereld. 14/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 2 Op te lossen praktijkvragen 2.1 Onderzoeksgebieden In ontwerpprojecten is kennisontwikkeling (onderzoek) onlosmakelijk verbonden met de oplossing van innovatieve vragen in de praktijk. De te ontwikkelen kennis valt binnen onderzoeksgebieden waar de opleiding zich op specialiseert. In de minor PeoplePlanetProfit werk je in multidisciplinaire teams aan praktijkvragen waarmee een onderzoeksvraag verbonden is op de volgende twee onderzoeksgebieden: 1. Zuid Afrika Het onderzoeken van alle aspecten die te maken hebben met de leefbaarheid in townships en met name die van Mamelodi, een township gelegen ter noordoosten van Tswane (voorheen Pretoria). Het onderzoeksgebied wordt bepaald door de vraag: “Wat zijn de milieukundige, culturele, sociaal-economische en politieke factoren die de bestaande buurten/wijken (hier: Mamelodi) vormgeven en veranderen, hoe reageren de stedelijke, bouwkundige en constructieve ontwerptechnische configuraties en hoe duurzaam zijn deze buurten/wijken werkelijk?” 2. Nederland Het onderzoeken van (grootschalige) ruimtelijke ontwikkelingen in de oostflank van de Randstad; het gebied tussen Amsterdam, Almere, Amersfoort en Utrecht. Het onderzoeksgebied wordt bepaald door de vraag: “Sterk groeiende economische bedrijvigheid legt een groot beslag op het gebruik van de ruimte. Almere bijvoorbeeld, heeft zich in 25 jaar ontwikkeld tot een stad met 160.00 inwoners. Deze groei zal doorzetten naar 350.00 inwoners in 2025. Hiermee is Almere een van de snelst groeiende new-towns van Europa. Welke visies zijn op verschillende schaalniveaus mogelijk om een dergelijke groei in goede banen te leiden?” 2.2 Competentiegebieden In ontwerpprojecten is ook competentieontwikkeling onlosmakelijk verbonden met de oplossing van vragen uit de praktijk. Uiteraard moeten de door jou te ontwikkelen competenties vallen binnen de competentieprofielen van de opleiding. Ook zul je bij de aanvang van het ontwerpproject moeten beschikken over een toereikend competentieniveau (je voorkennis moet op peil zijn). Je bent anders een blok aan het been van je teamgenoten en een plaag voor de opdrachtgever. In de minor PeoplePlanetProfit werk je in multidisciplinaire teams aan praktijkvragen in de volgende twee competentieprofielen: Aankomend Vastgoedontwikkelaar (m/v) U bent als vastgoedontwikkelaar in staat om conform de binnen onze organisatie gangbare methoden een projectteam te managen en het planvormingsproces te ontwerpen en te begeleiden. Uw relatie tot het projectteam is die van meewerkend voorman. Daarnaast bent u in staat om conform de binnen onze organisatie gebruikelijke methode het proces van kennisontwikkeling te managen. Taken: Managen van een projectteam conform projectmethode Begeleiden van een complex planvormingsproces conform planvormingmethode Begeleiden van kennisontwikkelingsproces conform onderzoekmethode 15/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Haalbaarheidsonderzoek uitvoeren zoals binnen onze organisatie gebruikelijk Opstellen programma van eisen conform het door ons gehanteerde format Domeinexpert (m/v) U bent als domeinexpert (met een planologische, juridische, bouwkundige of communicatie achtergrond) in staat om het project van de nodige input te voorzien om gezamenlijk tot een antwoord op de door de opdrachtgever gestelde Praktijkvraag en door het kenniscentrum, het lectoraat, gestelde Kennisvraag te komen. Taken: Het maken van verschillende stedenbouwkundige scenario’s waarin alle gewenste functies een eigen plek krijgen. Het maken van een haalbaarheidsstudie op financieel, juridisch en bouwtechnisch gebied van de verschillende scenario’s Zorgdragen voor een heldere communicatie tussen alle stakeholders Uitgebreide functiebeschrijvingen vindt u op onze website: http://www.bb.fnt.hvu.nl > courses > ‘People Planet Profit’ De verschillende projectfuncties die je binnen de minor kunt vervullen, bieden te mogelijkheid om je competentieontwikkeling individueel in te vullen. Wil je deelnemen aan de minor, dan zul je bij instap het volgende competentieniveau moeten hebben: <competentieniveau invullen> Bepaalde projectfuncties kunnen daarbij extra voorkennis eisen met zich meebrengen. 2.3 Op te lossen vragen uit de praktijk Ontwerpprojecten richten zich op vragen van een opdrachtgever uit de praktijk. Selectiecriteria voor deze vragen zijn onder andere: De vraag is relevant voor de praktijk waar de opleiding zich op richt, De met de praktijkvraag verbonden onderzoeksvraag valt binnen de onderzoeksgebieden waar de opleiding zich op richt. De met de praktijkvraag verbonden competentieontwikkeling valt binnen de competentieprofielen van de opleiding. Oplossen van de praktijkvraag is mogelijk met de voor dit ontwerpproject geldende voorkennis en met de beschikbare capaciteit. Er moet verder een docent zijn die de vraag van een opdrachtgever uit de praktijk ‘adopteert’, die als projectsponsor kan optreden. 2.3.1 Opdrachtgever De opdrachtgever van het ontwerpproject is meestal ook de probleemeigenaar (stakeholder) die er belang bij heeft dat het zich voordoende praktijkprobleem wordt opgelost. De opdrachtgever is degene die uiteindelijk bepaalt wat het probleem is en welke oplossing voldoet. Er zijn echter vaak ook nog gebruikers van de door het projectteam te ontwikkelen oplossing. Wil de door de opdrachtgever geaccepteerde oplossing voldoen, dan zullen de gebruikers er in de praktijk goed mee uit de voeten moeten kunnen. Gebruikers vormen dus een groep om als projectteam gedegen rekening mee te houden. 16/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Opdrachtgevers hebben belang bij een goede beantwoording van de gestelde praktijkvraag omdat zij iets met het resultaat willen in hun eigen (werk)situatie. Het is echter wel van belang dat opdrachtgevers inzien dat het niet om aangenomen werk gaat, maar om een leerproject door studenten. Van belang is hierbij dat de opleiding niet door het vragen van een (te hoge) geldelijke vergoeding impliciet verwachtingen wekt die later niet zijn waar te maken. Een tegemoetkoming door de opdrachtgever van door studenten te maken kosten (bijvoorbeeld materiaal-., reis- en communicatiekosten) zijn voor de hand liggend. Vergoeding van door de studenten te besteden tijd niet; deze wordt immers al vergoed via studiepunten. Ook met vragen van vergoeding van door docenten te besteden tijd moet terughoudend worden omgegaan. Begeleiding van de studenten behoort immers tot de normale taken van een docent. Alleen in geval de docent in een inhoudelijke adviesrol essentieel zou bijdragen aan een resultaat dat voor de opdrachtgever in de normale bedrijfsvoering interessant is, kan een tarief voor consultancy worden overwogen. Verder moet bedacht worden dat een opdrachtgever niet perse de professionele kennis in huis heeft om de gevraagde oplossing te overzien. Het is een eigen verantwoordelijkheid van het projectteam om te bewaken dat de oplossing professioneel vakkundig wordt gemaakt en geïmplementeerd. De kwaliteitsreviews zijn hierin onontbeerlijk hulpmiddel. Naast de opdrachtgever uit de praktijk is er ook een probleemeigenaar van de kennisvraag. Dit kan een onderzoeker uit een kenniscentrum zijn, maar ook de projectsponsor (zie hieronder). 2.3.2 Projectsponsor De projectsponsor uit de opleiding is te vergelijken met een afdelingsmanager in een bedrijf of organisatie waar projecten voor opdrachtgevers uit de praktijk worden uitgevoerd. De projectsponsor zal vanuit het bedrijf of de organisatie voorwaarden verbinden aan wélke projecten worden uitgevoerd (vallen die binnen het werkterrein van bedrijf of organisatie). Ook aan de manier waarop het project zal worden uitgevoerd en de samenstelling van het projectteam, zullen voorwaarden verbonden zijn. Dit zijn voorwaarden vanuit de gebruikelijke werkwijze binnen bedrijf of organisatie. Tenslotte is de afdelingsmanager als projectsponsor ook degene die - aan de hand van te voren bepaalde criteria - bepaalt of een project tevredenstellend is afgerond of niet. Volgens Scholtes, Joiner & Streibel (2002; p. 1-8 en p. 3-2) helpt de projectsponsor het team te handelen in lijn met de strategie van de organisatie, komt de sponsor bij gelegenheid voor het team tussenbeide en vertegenwoordigt de sponsor het team naar de organisatie. Speciale steun aan het team is vereist op drie punten: 1. De doelstelling van het team helpen verhelderen en vastleggen, 2. Helpen verhelderen hoe met elkaar en met de organisatie wordt omgegaan en gecommuniceerd, 3. De methode van werken helpen verhelderen en vastleggen. Belangrijke activiteiten van de projectsponsor zijn: Nauw met de teammanager (projectmanager) samenwerken. Ervoor zorgen dat de doelstelling van het team en de organisatie op elkaar zijn (en blijven) afgestemd. Er voor helpen zorgen dat de juiste mensen in het team zitten. Er op toezien dat de teamleden duidelijk weten wat hun rol en verantwoordelijkheid is en zich daarbij betrokken voelen; dat zij weten wat de grenzen van hun bevoegdheden zijn. Het team helpen bij het bouwen van communicatiekanalen naar andere groepen en individuen binnen de organisatie. Het team kritisch volgen bij het ontwikkelen van werkmethoden en plannen. 17/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten In de activiteiten van de projectsponsor zijn drie fasen te onderscheiden: A) Vraagontwikkeling (voorafgaand aan het project) B) Gedurende het project Koers mee helpen uitzetten voor team, Voortgang helpen bewaken, Belangen van team in organisatie behartigen, Voorlopige beoordeling geven van project en resultaten. C) Na het project Project en resultaten beoordelen, Lessons learned implementeren voor toekomstige verbeteringen, Opgeleverde implementatie in het oog houden. 2.4 Solliciteren op projecten De projectsponsoren publiceren voor de projecten die zij ‘geadopteerd’ hebben, personeelsadvertenties. Deze advertenties: a. geven zicht op wat de praktijkvraag en de kennisvraag zijn, b. maken duidelijk welke functies met welke taken in het project te vervullen zijn, en c. aan welke voorkennis- en ervaringseisen sollicitanten moeten voldoen. Sollicitanten worden via een transparante sollicitatieprocedure beoordeeld en aan projecten toegewezen. Afwijzingen worden met redenen omkleed. Vanuit de praktijkvraag en de kennisontwikkelingsvraag zijn er eisen aan de teamsamenstelling, bijvoorbeeld omdat het probleem alleen is aan te pakken met een bepaald niveau van competentie of vanuit een mix van disciplines. Ook zal voor het oplossen van de vragen een bepaald aantal teamleden nodig zijn: het moeten er genoeg zijn om al het werk te kunnen doen, en het moeten er niet zoveel zijn dat er duimen wordt gedraaid. Er wordt dus niet per definitie van een vaste omvang van de teams uitgegaan; de omvang wordt aan de vraag aangepast. Afhankelijk van de praktijkvraag zullen er in het team verschillende functies te vervullen zijn door de teamleden. Binnen de eisen die voortvloeien uit de vraag kunnen studenten zelf de teams samenstellen. Daarbij geldt dat hoe eerder zij weten in welk team ze gaan opereren, hoe beter het is. De activiteiten in de Start-Up fase van het project hebben alleen zin als die door teams in definitieve samenstelling worden gedaan. Het is daarom verstandig om de teamsamenstelling zo vroeg mogelijk bekend te maken en ook bezettingsproblemen zo vroeg mogelijk te onderkennen en op te lossen. 18/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 3 Projectmethode 3.1 Inleiding Bij het projectonderwijs waar dit handboek op van toepassing is, is er een vraag uit de praktijk. Om voor deze praktijkvraag een oplossing te ontwerpen zul je niet alleen reeds opgedane kennis in een praktijksituatie moeten toepassen, maar je zult juist ook nieuwe kennis moeten ontwikkelen. Dat kan bijvoorbeeld procedurele kennis zijn: er is een methode, maar die is in de gegeven situatie nog niet op die manier toegepast en we willen weten of dat een verbetering oplevert van de praktijk. Een dergelijk project waarin we naast een concrete oplossing voor de praktijk ook competenties en nieuwe kennis ontwikkelen kent een aantal fasen (Figuur 3.1). In Tabel 3.1 staan deze fasen nader uitgewerkt. Praktijk vraag Praktijk oplossing Competentieagenda Competentieontwikkeling Ontwikkelde competentie Oplossing Ontwikkelen Oplossing ontwerpen Oplossing Implementeren Oplossing Projectontwikkelen Conceptueel ontwerp Voorbereiden Probleemstelling Diagnose Projectorganisatie Vraag Vraagontwikkelen Oplossing opleveren Kennis en competentie opleveren Oplossing verbeteren Contextkennis Kennisagenda Methoden Oplossingen Ontwikkelde kennis Kennisontwikkeling Figuur 3.1 Projectfasen in de projectmethode 19/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Nadere uitwerking projectfasen ontwerpprojecten Fase 0 Vraag ontwikkelen Fase 1 Voorbereiden Fase 2 Project ontwikkelen Deze fase valt buiten het eigenlijke project. Ontwerpprojecten richten zich op vragen van een opdrachtgever uit de praktijk. Deze zijn in eerder stadium door docenten verzameld. Een docent die een vraag van een opdrachtgever ‘adopteert’ zullen wij de projectsponsor noemen. Solliciteren Kennisnemen van de mogelijke projecten en solliciteren op beschikbare functies in ontwerpprojecten (personeelsadvertenties). Start-Up voorbereiden Wanneer je in een specifieke functie bent aangenomen, bereid je de project Start-Up voor. Waar heb je vragen over? Start-Up bijeenkomst In de Start-Up bijeenkomst zorg je ervoor dat al je vragen over opzet en uitvoering van het ontwerpproject door de projectsponsor worden beantwoord. Verder maak je kennis met de andere leden van het projectteam en verdeel met hen je de taken voor Fase 2. Uitgangspositie bepalen Valideren vraag Het projectteam houdt een interview met de opdrachtgever voor het praktijkprobleem en met de opdrachtgever voor het kennisprobleem om de interpretatie van het projectteam van praktijkvraag en kennisvraag te valideren. Verkeerd begrip van de vragen leidt tot veel onnodig werk en frustratie. Kennis mobiliseren Het projectteam gaat op zoek naar kennis over de praktijkcontext, over mogelijke oplossingen van het probleem, over methoden om werkende oplossingen te krijgen en over projectorganisatie. Praktijkdiagnose stellen Voortgangsbijeenkomsten Als projecteam plan je geregelde voortgangsbijeenkomsten in om de gang van zaken te bespreken en problemen op te lossen. Analyseren huidige praktijksituatie Vanuit de gemobiliseerde contextkennis worden de sterke en zwakke punten van de huidige situatie in kaart gebracht Gewenste praktijksituatie in kaart brengen Vanuit de gemobiliseerde oplossingskennis wordt de gewenste praktijksituatie in kaart gebracht. 20/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Aanpak uitwerken Specificeren probleemaanpak Vanuit gemobiliseerde kennis over methoden de aanpak van het probleem specificeren Aanpak intern valideren voor kennisvraag Met projectteam nagaan dat met dit probleem en deze aanpak de gevraagde kennis kan worden ontwikkeld Project organiseren Specificeren werkwijze projectteam Werkwijze en bijdrage van teamleden specificeren, met voortgangsbewaking en kwaliteitsborging Specificeren competentieontwikkeling De competentieontwikkeling van de teamleden in kaart brengen Kwaliteitsborging organiseren Risico- en succesfactoren specificeren Vanuit de gemobiliseerde kennis de risico- en succesfactoren voor deze situatie in kaart brengen Kwaliteitscriteria specificeren Zowel voor werkwijze, professionele rolvervulling, en de resultaten (praktijk, kennis, competentieontwikkeling) kwaliteitscriteria in kaart brengen Plan van Aanpak Plan van Aanpak samenstellen uit de resultaten van voorgaande stappen. Valideren Plan van Aanpak Met je projectteam ga je na of de opdrachtgever de probleemanalyse onderschrijft en accoord is met oplossingsrichting en projectaanpak. Als er een aparte opdrachtgever is voor het onderdeel kennisontwikkeling (bijvoorbeeld een onderzoeker van een kenniscentrum) wordt ook met deze het Plan van Aanpak gevalideerd Ook ga je na of de projectsponsor accoord is met de geplande competentie- en kennisontwikkeling in de vorm van een Persoonlijk OntwikkelingsPlan. Voortgangsbijeenkomst Het is van belang om ná de validatie en vóór de review als projectteam na te gaan wat de consequenties van de wensen van de opdrachtgever en projectsponsor zijn. Start-Up Review Het gevalideerde Plan van Aanpak wordt samen met professionele experts nog eens kritisch bekeken op kwaliteit. Kan het professioneel gezien door de beugel of zijn er nog verbeteringen mogelijk? 21/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Fase 3 Ontwerpen en implementeren Oplossing ontwerpen Eerst maak je met je projectteam een model van de nagestreefde oplossing; dat heet een conceptueel ontwerp. De gewenste situatie is hiervoor de basis. De ontworpen modeloplossing moet er toe leiden dat de gewenste situatie straks realiteit wordt. Gemobiliseerde kennis wordt gebruikt en mogelijk nieuwe kennis ontwikkeld en toegepast. Flankerende workshop Mogelijk bestaat er behoefte om problemen die het projectteam ontmoet bij het ontwerpen van een oplossing of het ontwikkelen van de kennis in een workshop te tackelen. Valideren conceptueel ontwerp Het conceptueel ontwerp legt de contouren van de uiteindelijke oplossing vast. Het is dus van belang dat je nagaat of de opdrachtgever het conceptueel ontwerp ‘ziet zitten’, voordat je met je projectteam aan de uitwerking begint. Oplossing ontwikkelen Het conceptueel ontwerp wordt uitgewerkt in een oplossing die in het echt kan ‘werken’, gebruikt kan worden. Gemobiliseerde kennis wordt gebruikt en mogelijk nieuwe kennis ontwikkeld en toegepast. Oplossing implementeren De werkende oplossing wordt uitgeprobeerd in de praktijk waarin deze ook gebruikt moet worden, meestal bij de opdrachtgever ‘in huis’. Gemobiliseerde kennis wordt gebruikt en mogelijk nieuwe kennis ontwikkeld en toegepast. Flankerende workshop Mogelijk bestaat er behoefte om problemen die het projectteam ontmoet bij het ontwikkelen en implementeren van een oplossing of het ontwikkelen van de kennis in een workshop te tackelen. Valideren geïmplementeerde oplossing Met je projectteam ga je na of opdrachtgever en gebruikers tevreden zijn met de geïmplementeerde oplossing. Als er een aparte opdrachtgever is voor het onderdeel kennisontwikkeling (bijvoorbeeld een onderzoeker van een kenniscentrum), dan wordt de tot nu toe ontwikkelde kennis ook met deze opdrachtgever gevalideerd. Voortgangsbijeenkomsten Voortgangsbijeenkomsten Voortgangsbijeenkomsten 22/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Fase 4 Opleveren van de oplossing Fase 5 Opleveren van ontwikkelde kennis en competenties Mid-Term Review De kwaliteit van de geïmplementeerde oplossing, de ontwikkelde kennis en de ontwikkelde competenties wordt samen met experts nagegaan. Verbeteracties worden geïnventariseerd. Oplossing verbeteren Verbeteracties worden uitgevoerd en de oplossing verder verbeterd. Ook ontwikkelde kennis en competentieniveau worden waar nodig verbeterd. Opleveren van de verbeterde oplossing Als alles naar tevredenheid ‘werkt’, wordt de oplossing overgedragen aan de opdrachtgever. Als er een aparte opdrachtgever is voor het onderdeel kennisontwikkeling (bijvoorbeeld een onderzoeker van een kenniscentrum), dan wordt de ontwikkelde kennis aan deze opdrachtgever overgedragen. Lessons Learned Review Na oplevering van het eindresultaat aan de opdrachtgever wordt de balans opgemaakt over het totaalproject. Dit gebeurt door aan de hand van de kwaliteitscriteria nog een keer kritisch te kijken naar hoe een en ander verlopen is en wat de kwaliteit van resultaten, ontwikkelde kennis en ontwikkelde competenties is. ‘Lessons learned’ vormen het resultaat van deze review. Oplevering van kennis en competentie De nieuw ontwikkelde kennis, inclusief ‘lessons learned’, wordt opgeleverd en aan de bestaande kennisbasis toegevoegd. De door individuele projectteamleden ontwikkelde competenties worden gecheckt en vastgelegd (bijvoorbeeld in competentiekaarten). Voortgangsbijeenkomsten Tabel 3.1 Uitgewerkte projectfasen 23/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 4 Fase 0: Vraag ontwikkelen Praktijk vraag Praktijk oplossing Competentieagenda Competentieontwikkeling Ontwikkelde competentie Oplossing Ontwikkelen Oplossing ontwerpen Oplossing Implementeren Oplossing Projectontwikkelen Conceptueel ontwerp Voorbereiden Probleemstelling Diagnose Projectorganisatie Vraag Vraagontwikkelen Oplossing opleveren Kennis en competentie opleveren Oplossing verbeteren Contextkennis Kennisagenda Methoden Oplossingen Ontwikkelde kennis Kennisontwikkeling Ontwerpprojecten richten zich op vragen van een opdrachtgever uit de praktijk. Deze zijn in eerder stadium door docenten verzameld. Een docent die een vraag van een opdrachtgever ‘adopteert’ zullen wij de projectsponsor noemen. Niet elke vraag uit de praktijk komt in aanmerking om binnen een opleiding opgelost te worden: welke vragen dan wel? Dat wordt bepaald door: De competenties die het project vraagt van de deelnemers (en die moeten passen in de opleidings’agenda’ met beroepsgerichte en algemene competenties). De kennis die in het project wordt ontwikkeld (die moet passen binnen een ‘kennisagenda’). De omvang en complexiteit van het project (het moet immers ‘te doen’ zijn voor de betrokken studenten binnen de beschikbare tijd). Vanuit de praktijkvragen wordt bepaald welke functionele bezetting projectteams moeten hebben om de vraag te kunnen oplossen. Voor de functies worden advertentieteksten gemaakt door de projectsponsor. In de advertentie komen de volgende zaken aan bod: Praktijkvraag Kennisvraag Competentievraag In een aankondiging van een functie moeten in ieder geval de volgende gegevens vermeld worden: o functienaam, o voornaamste taken en verantwoordelijkheden, o plaats in de organisatie, 24/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten o functie-eisen, o bijzondere arbeidsvoorwaarden, o naam en email adres van contactpersoon voor verkrijgen nadere informatie, o sluitingsdatum sollicitatie. Ofwel in de aankondiging, ofwel in de bevestiging van ontvangst van een sollicitatie moet verder worden aangegeven hoe de sollicitatieprocedure zal verlopen en op welke termijn inhoudelijk gereageerd zal worden op de sollicitatie. Op grond van de advertenties kunnen studenten solliciteren naar functies zoals projectmedewerker, manager of vakspecialist in een project van hun keuze. Via een afgesproken sollicitatieprocedure benoemt de projectsponsor personen op de functies van een project. 25/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 5 Fase 1: Voorbereiden Praktijk vraag Praktijk oplossing Competentieagenda Competentieontwikkeling Ontwikkelde competentie Oplossing Ontwikkelen Oplossing ontwerpen Oplossing Implementeren Oplossing Projectontwikkelen Conceptueel ontwerp Voorbereiden Probleemstelling Diagnose Projectorganisatie Vraag Vraagontwikkelen Oplossing opleveren Kennis en competentie opleveren Oplossing verbeteren Contextkennis Kennisagenda Methoden Oplossingen Ontwikkelde kennis Kennisontwikkeling De projectsponsor plaatst personeels advertenties voor de binnengehaalde opdrachten. Studenten kunnen solliciteren naar functies zoals projectmedewerker, -manager of vakspecialist in een project van hun keuze. Via een afgesproken sollicitatieprocedure benoemt de projectsponsor personen op de functies van een project. In je nieuwe functie bereid je je voor op de start van het project. Wie zijn je collega’s? Hoe wordt de opdracht aangepakt? Wat wordt er verwacht aan het eind van het project? Is die opdracht wel te doen? Alle vragen komen aan bod in de project Start-Up bijeenkomst waar je ze samen met je projectteam beantwoordt. 26/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 5.1 Solliciteren Bij de schriftelijke sollicitatie gaat het om een sollicitatiebrief en een curriculum vitae (cv). De sollicitatiebrief wordt ingedeeld als elke andere zakelijke brief. De brief verwijst naar de specifieke advertentie waarop de sollicitatie betrekking heeft. De hoofdtekst bevat: aanleiding: op grond waarvan en waarnaar solliciteer je, relevantie: laat zien dat je de eisen uit de advertentie goed hebt begrepen en dat je sollicitatie relevant is, motivatie: waarom wil je juist déze aangeboden functie en waarom denk je dat je daarvoor geschikt bent. geschiktheid: toon aan dat je de geschikte kandidaat bent; aanpassingsvermogen, communicatievermogen, doorzettingsvermogen, leidinggevend vermogen, organisatietalent, ondernemingszin, spreekvaardigheid, technisch inzicht benadrukken je capaciteiten. Het curriculum vitae (cv) geeft een overzichtelijke presentatie van je persoonlijke gegevens en daarnaast in ieder geval de volgende rubrieken: Opleiding, Cursussen (Vakken), Talenkennis, Ervaring (stages, vakantiewerk, hobby's). Een curriculum vitae moet leesbaar, to the point, begrijpelijk, overzichtelijk en motiverend zijn. Taalaanwijzing: schrijf Nederlands, schrijf persoonlijk, let op de logica in de woordkeus, gebruik geen afkortingen, maak geen spelfouten. Checklist voor een compleet C.V. Bron: Sollicitatiegids 2002-2003, INISOL; http://www.inisol.com/sollicitatie/bestanden/sollicitatiegids.pdf, benaderd: 21-01-06) Heb je alle persoonlijke gegevens correct weergegeven? Heb je duidelijk vermeld welke meerwaarde je voor het project betekent? Haal je voldoende de persoonlijke eigenschappen aan die relevant zijn voor de functie in kwestie? Springt je meest recente opleidingservaring die het best bij de vacature past, voldoende in het oog? Ben je volledig eerlijk geweest en heb je geen verwachtingen geschept die je later niet kan inlossen? Vermeld je je meeste relevante competenties aan het begin van de lijst? Heb je de chronologische volgorde van je opleidingsvoorkennis in omgekeerde volgorde vermeld? Verspil je geen kostbare ruimte met opsommingen van opleidingsvoorkennis die geen relevantie heeft in dit c.v.? Reageer niet negatief op een afwijzing. Analyseer de motivatie voor afwijzing. Als je deze niet begrijpt, vraag dan om een mondelinge toelichting. Als je je niet met de afwijzing kunt verenigen, dien dan een gemotiveerd bezwaarschrift in. 27/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 5.2 Sollicitatieprocedure Uitgangspunten Bij selectie geldt slechts één criterium: geschiktheid van de kandidaat voor de functie, Functies zijn zowel toegankelijke voor vrouwelijke als mannelijke sollicitanten, De selectieprocedure moet in overeenstemming zijn met de rechten van de sollicitant: o recht op gelijke kansen bij gelijke geschiktheid, o recht op informatie, o recht op vertrouwelijke behandeling van persoonlijke gegevens, o recht op doelmatige procedure, o recht van klacht. De selectieprocedure moet ook recht doen aan het belang van de organisatie: de van uit de organisatie gezien meest geschikte kandidaat aanstellen. Selectie Selectie geschiedt op grond van de in de aankondiging gestelde functie-eisen en geen andere. De sollicitant ontvangt zo spoedig mogelijk gemotiveerd bericht van het selectieresultaat. 28/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 5.3 Start-Up voorbereiden Studenten die de sollicitatieprocedure goed doorgekomen zijn, kunnen beginnen aan hun project, hopelijk het project van hun keuze. Maar dat vergt voorbereiding, want: Is het duidelijk hoe de werkwijze zal zijn? Snap je wat je teamleden in hun functie gaan bijdragen aan het project? En waar hun verantwoordelijkheid begint en eindigt? Begrijp je waarom de projectmethode nodig is en snap je hoe je die kunt toepassen? Begrijp je wat er in de eerste fase (Projectontwikkeling) verwacht wordt. Zie je het nut daarvan in? Heb je enig idee hoe je het moet aanpakken als je de praktijkvraag gaat analyseren? En wat er komt kijken bij de kennisontwikkeling? En hoe moet je in een Plan van Aanpak het werk opdelen in concrete activiteiten en deze plannen in de tijd? En weet je hoe je een fatsoenlijk Persoonlijk OntwikkelingsPlan (POP) opstelt, dat past in de competentieagenda van de opleiding? Vragen genoeg die om een antwoord vragen. In de voorbereiding op de Start-Up probeer je antwoorden te vinden op deze vragen en de andere vragen die je hebt. De Start-Up bijeenkomst maakt het je mogelijk om je verwachtingen gelijk te trekken met de verwachtingen van de andere betrokkenen: de andere leden van projectteam en de projectsponsor. De Projectsponsor zorgt dat in de digitale projectruimte (http://www.xxx.yyy) voor het projectteam beschikbaar zijn: o deze projecthandleiding o de omschrijving van de praktijkvraag o de omschrijving van de kennisvraag o de omschrijving van competentievraag Aan de hand van de beschikbare documentatie vorm je je als individueel teamlid een beeld van wat er in het project allemaal speelt: o Je gaat na wat je functie in het projectteam concreet inhoudt. o Je maakt een eerste analyse van de praktijkvraag, de kennisvraag en de competentievraag met als resultaat mogelijke deelvragen en een mogelijke aanpak. o Je vormt je een beeld van de werkwijze in het project en plant projectdeadlines en vastgelegde projectbijeenkomsten in je agenda in. o Je gaat na wat specifiek de bedoeling is van de fase projectontwikkeling en wat jouw rol in die fase zal zijn; je markeert onduidelijkheden en knelpunten o Je gaat na wat de eisen zijn die gesteld worden aan het Plan van Aanpak; je markeert onduidelijkheden en knelpunten 29/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 5.4 Start-Up bijeenkomst Via de sollicitatieprocedure zijn kandidaten aangenomen en team(s) samengesteld om praktijkopdrachten uit te voeren. In de Start-Up bijeenkomst’ stemmen de verschillende teamleden hun verwachtingen op elkaar af. Hun gezamenlijke verwachtingen stemmen zij af met de projectsponsor. De bedoeling is om de verschillende krachten en belangen van direct betrokkenen ‘in lijn’ te brengen (‘alignment’). Scholtes, Joiner & Streibe (2002) gebruiken de volgende dimensies van ‘alignment’ ( p. 1 -11): Dimensies Organisatie (Opleiding) Team Individuele leden ‘Het-kant’ ‘Wij-kant’ ‘Ik-kant’ Doelstelling (Waarom, Wat) Missie Handvest en doelen Taken en verantwoordelijkheden Partnership (Met wie en waarom) Waarden en overtuigingen Normen en communicatiekanalen Sociale vaardigheden Proces (Hoe) Managementsysteem en beoordelingen Methoden en procedures Probleemoplossing en Planning Tabel 5.1 Dimensies van alignment (Scholtes, Joiner & Streibel 2002; p. 1-11) Het projectteam stemt met elkaar op de volgende punten af: teamsamenstelling wie zitten er in het team, wanneer zijn ze beschikbaar en hoe wordt onderling contact onderhouden? welke kwaliteiten zijn in het team vertegenwoordigd? Lijken die voldoende om het project tot een goed einde te brengen? welke taken en verantwoordelijkheden horen bij de verschillende functies de gestelde vragen wat houden de gestelde vragen (praktijkvraag, kennisvraag en competentievraag) in? waarom zijn deze vragen relevant voor de praktijk, het kennisgebied en het professioneel handelen? de werkwijze wat is de te volgen werkwijze in grote lijnen? is deze werkwijze in dit geval functioneel? welke eisen worden aan de kwaliteit van werken gesteld? het resultaat (oplossing) welke eisen worden globaal aan het resultaat (praktijkresultaat, kennisresultaat en competentieresultaat) gesteld? de haalbaarheid is beantwoording van de gestelde vragen in principe haalbaar voor het team? wekt de werkwijze vertrouwen? geeft de teamsamenstelling vertrouwen? aanpak van projectontwikkeling welke eisen worden specifiek aan het Plan van Aanpak gesteld? hoe worden de werkzaamheden van de fase projectontwikkeling gepland in de tijd? hoe worden deze werkzaamheden over de leden van het Projectteam verdeeld? waar en wanneer zijn voortgangsbijeenkomsten gepland? Wie komen daar? 30/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten wanneer zijn validaties en Start-Up Review gepland? communicatie met opdrachtgever(s) en projectsponsor wanneer en hoe wordt gecommuniceerd? En door wie? hoe worden sessies voorbereid? En wie zijn aanwezig? samenvatting conclusies, afspraken en knelpunten worden samengevat presentatie aan projectsponsor conclusies en knelpunten worden aan de projectsponsor gepresenteerd. de projectsponsor helpt onduidelijkheden te verhelderen en knelpunten weg te nemen. Na de Start-Up bijeenkomst zijn teamsamenstelling, de vraag (praktijkvraag, kennisvraag, competentievraag), de werkwijze, de haalbaarheid en de aanpak van fase projectontwikkeling voor alle teamleden duidelijk. De communicatie met opdrachtgever(s) en projectsponsor is geregeld. Conclusies, op te lossen knelpunten en afspraken zijn opgenomen in een samenvattend verslag. dat binnen een week na de Start-Up bijeenkomst door de projectsponsor wordt gevalideerd. Het gaat er in de Start-Up bijeenkomst dus allereerst om de zaken helder te krijgen en de organisatie op orde. De Start-Up bijeenkomst vindt daarom bij voorkeur face-to-face plaats. Eigenlijk vindt in de Start-Up bijeenkomst validatie plaats door het projectteam van: vraagomschrijving, projectfasering en werkwijze, inhoudelijke aanpak en samenstelling projectteam. Meer informatie over de Start-Up bijeenkomst is te vinden in Bos & Harting (1998; p. 22-360/22-371). Checklist voor een goed uitgevoerde Start-Up bijeenkomst Het team: kent de werkomgeving en vindt deze ‘veilig”, vindt de communicatie helder geregeld, is het eens met hoe er beoordeeld zal worden en hoe doelen gesteld worden, ziet voldoende ondersteuning in het beschikbare flankerend onderwijs, ziet voldoende persoonlijke ontwikkelingsmogelijkheden, is het eens met de beoogde managementstijl en effectiviteitsdoelstellingen, voelt zich bij machte om het project succesvol uit te voeren, voelt zich betrokken bij het project, onderschrijft de aan te leggen kwaliteitscriteria en de organisatie van het verbeterproces. 5.4.1 Organisatie van de het projectteam Het projectteam moet zich organiseren tot een hechte eenheid, waarin iedereen zijn plaats weet. Belangrijk daarbij is het zeker stellen van de communicatie: Regelen van technisch-overleg van de groepsleden zelf, zonder projectmanager. Afspreken van een vaste wekelijkse voortgangsbijeenkomst. Uitwisselen en verzamelen van alle belangrijke namen, adressen en telefoonnummers, en e-mailadressen, ook van opdrachtgever en projectsponsor. Vasteggen van vrije dagen, vakanties, tentamenverplichtingen, enzovoorts. Afspreken en reserveren van vaste vergaderplaatsen, 5.4.2 Verdelen van taken De teamleden verdelen verantwoordelijkheden onder elkaar. Dat kan aan de hand van ieders sterke en zwakke punten wat betreft voorkennis, of voorkeuren. Verantwoordelijkheden kunnen specifieke kennis of vaardigheden betreffen die nodig zijn voor de opdracht (voorzover dat in het begin valt te overzien), maar ook proces- en productdocumentatie. Een goede inventarisatie en toedeling van verantwoordelijkheden 31/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten voorkomt dat sommige teamleden tijdens bepaalde activiteiten niets te doen hebben; bovendien kan het leiden tot een beter product. Voorbeelden van verantwoordelijkheden zijn: Maken van besluitenlijsten van vergaderingen, Bijhouden van de uitvoering van besluiten, Bewaken van de kwaliteit van de gebruikte methoden en technieken, Onderhouden van de klantcontacten, inclusief het afnemen van interviews, Bewaken van de tijdsplanning. Dit is natuurlijk een taak van de projectmanager, maar het kan geen kwaad als iemand in het team er nog eens extra op let. Standaardiseren van lay-out van documentatie en resultaten. Versiebeheer en bijhouden van backups van belangrijk materiaal. Bijhouden van een projectlogboek. Administratie van gemaakte kosten. Het projectteam is vrij om zo'n verdeling zelf in te vullen. Het belangrijkste is dat de zaken op tijd geregeld worden, en dat er iemand aangesproken kan worden als een bepaalde taak niet uitgevoerd wordt. Een duidelijke verdeling van taken en verantwoordelijkheden schept veel duidelijkheid binnen het team. Daarbij moet iedereen beseffen dat het hebben van een individuele verantwoordelijkheid, niet betekent dat er niet ook een collectieve verantwoordelijkheid is voor de goede uitvoering van taken door andere teamleden. Iedereen is bijvoorbeeld verantwoordelijk voor het signaleren van problemen. Tijdig onderkende problemen zijn meestal nog wel te ondervangen. Dit betekent dat het team taken onderling verdeelt, maar ze niet uit het oog verliest. 5.4.3 Verhoudingen in het team Sommige teamleden kennen elkaar en kunnen goed met elkaar overweg, andere niet. Dat is normaal in projectwerk. Mochten zich persoonlijke spanningen voordoen, dan is de beste manier om er met elkaar over praten, eventueel onder begeleiding. Mocht er in het team ontevredenheid ontstaan over iemands inzet, dan behoort dat op een voortgangsbijeenkomst besproken te worden. Als in eerder stadium de taken naar behoren zijn verdeeld en op papier gezet, kan worden nagegaan of iemand verantwoordelijkheden niet nakomt; mocht dit zo zijn dat wordt gezamenlijk naar een oplossing gezocht. Door besluiten schriftelijk vast te leggen, kan dit proces later worden gereconstrueerd (en is het controleerbaar). Blijft iemand in voortdurend in gebreke, dan is dat zichtbaar en kan er actie worden ondernomen die kan leiden tot ontslag uit het project. 5.4.4 Beheersbaar houden van het werkproces Teamleden zullen de voor het project toegemeten tijd zondermeer nodig hebben. Het Plan van Aanpak zal duidelijkheid moeten geven welke activiteiten worden uitgevoerd, hoeveel tijd daarvoor beschikbaar is en wat de doorlooptijd is. Met behulp hiervan wordt het project beheerst en bewaakt. Daarbij zal een planning zelden exact kloppen. Elke uit te voeren activiteit moet qua omvang geschat worden. Je kunt een planning daardoor dan ook niet zien als een accurate beschrijving van de taken en hun tijdsduur, maar als een houvast voor het uitvoeren van het project. Het zal vaak blijken dat een bepaalde taak door iedereen over het hoofd is gezien of aanzienlijk meer of minder tijd vergt. Door middel van tijdbriefjes wordt de aan activiteiten bestede tijd bijgehouden. Een tijdbriefje vermeldt naam van het teamlid, weeknummer, activiteit, deze week aan deze activiteit bestede uren, aantal uren dat nog in het budget beschikbaar is voor deze activiteit. Tijdbriefjes worden ingeleverd bij de projectmanager die ze controleert en nagaat of nog binnen budget gewerkt wordt en of de voorziene resultaten op tijd zullen worden of zijn opgeleverd. Een activiteit dient gepland te zijn. Teamleden kunnen niet op eigen houtje dingen gaan doen die niet gepland zijn. Acht iemand het noodzakelijk een niet ingeplande activiteit uit te voeren, dan zal daarover met het projectteam moeten worden overlegd. 32/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 5.4.5 Documentatie van het werkproces Een logboek documenteert het werkproces. Het heeft de volgende indeling: Een inhoudsopgave. Een lijst met de namen, adressen, telefoonnummers, en email-adressen. Vermelding van plaats, datum, en aanvangstijd van de vaste vergaderingen. Plan van Aanpak als basisreferentie voor de teamleden. Besluitenlijsten van intern technisch overleg. Besluitenlijsten van het voortgangsbijeenkomsten. Belangrijke tussentijdse verslagen, zoals interviews met klant of gebruikers. Validatieverslagen. Reviewverslagen. Stand van zaken verbeteracties. Tijddeclaraties. Door middel van dit logboek (ook wel projectdossier genoemd) wordt het gehele projectverloop transparant. Alle ontwikkelingen, activiteiten en beslissingen die zich tijdens het project hebben voorgedaan zijn er in opgeslagen. Voordelen hiervan zijn: In een later stadium kan het nuttig zijn om te weten waar zaken fout zijn gelopen of waar juist goede beslissingen zijn genomen. Het kan als ondersteuning voor nieuwe projecten dienen. Overwegingen die een rol hebben gespeeld bij het nemen van beslissingen kunnen meegenomen worden voor een ander project. Het dient als communicatiemiddel binnen het projectteam. Logboeken worden in de digitale projectruimte van het projectteam toegankelijk gehouden. 33/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 6 Fase 2: Project ontwikkelen Praktijk vraag Praktijk oplossing Competentieagenda Competentieontwikkeling Ontwikkelde competentie Oplossing Ontwikkelen Oplossing ontwerpen Oplossing Implementeren Oplossing Projectontwikkelen Conceptueel ontwerp Voorbereiden Probleemstelling Diagnose Projectorganisatie Vraag Vraagontwikkelen Oplossing opleveren Kennis en competentie opleveren Oplossing verbeteren Contextkennis Kennisagenda Methoden Oplossingen Ontwikkelde kennis Kennisontwikkeling Op het bord van het projectteam ligt een praktijkvraag met daaraan gekoppeld een kennisvraag en een competentievraag. In de fase project ontwikkelen maakt het projectteam een nadere analyse van de praktijkvraag. Daarna wordt een diagnose gesteld en een oplossingsaanpak bepaald. Er wordt nagegaan dat de aanpak ook zal leiden tot beantwoorden van de gestelde kennisvraag en de gestelde competentievraag. Tenslotte geeft het projectteam organisatorisch vorm aan het project. Doel is om in deze fase de aanpak van alle belangrijke onderdelen van het project uit te werken vóór er met de uitvoering wordt begonnen. Bezinnen voor beginnen spaart tijd, geld en ergernis, en leidt tot betere resultaten. Waarom project ontwikkeling? Waarom is projectontwikkeling (fase 2) nodig? Het probleem is dat de in de vragen aan de orde gestelde problemen meestal geen simpele, voor de hand liggende, oplossing zullen hebben. Er moet dan eerst worden uitgezocht in welke richting de oplossingen kunnen worden gezocht en welke aanpak tot oplossingen kan leiden. Bijkomend probleem is dat bij de aanpak van de problemen veel mensen betrokken zijn (opdrachtgever(s), gebruikers, projectteamleden) en er veel activiteiten moeten worden uitgevoerd. Niet alleen de oplossingsdoelen moeten in de fase project ontwikkelen helder worden bepaald, ook de (organisatorische) aanpak moet worden uitgewerkt. De tijd die in deze fase wordt besteed aan nadenken over de aanpak, wordt tijdens de rit in het project dubbel en dwars terugverdiend, omdat geen nutteloze activiteiten zullen worden uitgevoerd. 34/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Actoren Bij de projectontwikkeling in fase 2 zijn de volgende actoren betrokken: Opdrachtgever: degene die belang heeft bij de oplossing van de gestelde praktijkvraag. Gebruiker: degene die de oplossing in de praktijk toepast en gebruikt. Kennisopdrachtgever: degene die belang heeft bij de oplossing van de kennisvraag. Kennisgebruiker: degene die de ontwikkelde kennis in de praktijk toepast en gebruikt. Projectsponsor: degene die het project in gang zet om praktijkvraag en kennisvraag te laten beantwoorden en die de randvoorwaarden van het project stelt. Dit is ook degene die uiteindelijk vaststelt of in het project aan de eisen voldaan heeft. Die eisen betreffen: de praktijkoplossing, de ontwikkelde kennis en de competentieontwikkeling. Projectteam: degenen die het project binnen de gestelde randvoorwaarden uitvoeren. 35/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 6.1 De projectstappen in de fase project ontwikkelen In de fase project ontwikkelen voert het projectteam de volgende projectstappen uit. Uitgangspositie bepalen (resultaat: uitgangspositie) (zie 6.2) Valideren van de vraag Bij de opdrachtgevers nagaan wat de praktijkvraag en de kennisvraag precies inhouden Kennis mobiliseren Kennis mobiliseren = kennis vinden én in zodanige vorm presenteren dat deze in het project bruikbaar is o Contextkennis over dit soort praktijksituaties, waar dit type vragen/problemen leven o Oplossingskennis over werkende oplossingen o Methoden kennis over hoe werkende oplossingen kunnen worden gerealiseerd o Projectorganisatie kennis over hoe ontwerpprojecten tot een goed einde kunnen worden gebracht Praktijkdiagnose stellen (resultaat: probleemstelling) (zie 6.3) Analyseren huidige praktijksituatie Vanuit gemobiliseerde contextkennis de huidige praktijksituatie verklaren en daarbij: Sterke punten (+) en zwakke punten (-) van de huidige praktijksituatie in kaart brengen Gewenste praktijksituatie in kaart brengen Vanuit de gemobiliseerde oplossingskennis de gewenste praktijksituatie op hoofdpunten specificeren en daarbij: Sterke punten (+) en zwakke punten (-) van de gewenste praktijksituatie in kaart brengen Vergelijken van de gewenste met de huidige situatie (welke sterke punten blijven behouden, welke zwakke punten worden weggewerkt, komen er nieuwe sterke of zwakke punten bij? Vanuit gemobiliseerde kennis verklaren waarom de gewenste situatie beter voldoet Valideren van analyse, probleemstelling (huidig gewenst) en verklaring (zie 6.7) Aanpak uitwerken (resultaat: probleemaanpak) (zie 6.4) Specificeren probleemaanpak Vanuit de gemobiliseerde methoden kennis de aanpak specificeren waarmee vanuit de huidige situatie de gewenste praktijksituatie kan worden bereikt Tevens vanuit gemobiliseerde kennis verklaren waarom de voorgestelde aanpak het gewenste resultaat (de gewenste praktijksituatie) zal opleveren Valideren dat de probleemaanpak door de praktijk gewenst wordt en daar haalbaar is (zie 6.7) Probleemaanpak intern valideren voor de kennisvraag De nieuw te ontwikkelen kennis specificeren ten opzichte van de reeds gemobiliseerde kennis; of is de gevraagde kennis eigenlijk al beschikbaar? 36/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Vanuit de probleemstelling en de probleemaanpak verklaren hoe deze nieuwe kennis ontwikkeld zal worden Valideren dat de nieuw te ontwikkelen kennis binnen de kennisvraag valt (zie 6.7) Valideren met opdrachtgevers (praktijk & kennis) Valideren met opdrachtgevers en projectsponsor Valideren praktijkvraag (6.2.1) Valideren kennisvraag Valideren Plan van Aanpak (6.8) Competentievraag Start-Up Bijeenkomst Duidelijkheid Praktijkvraag Start-Up Review (6.9) (6.2) UitgangsPositie bepalen Uitgangspositie Te ontwikkelen competenties (6.3) Praktijkdiagnose stellen Kennisvraag Probleemstelling Plan van Aanpak (6.4) Probleemaanpak Aanpak uitwerken (6.5) Project ornganiseren Contextkennis (6.7) Projectorganisatie Oplossingskennis Methoden kennis Te ontwikkelen praktijkoplossing Werkwijze Te ontwikkelen kennis (6.6) Kwaliteitsborging Kwaliteitsorganibeheersing seren Projectorganisatie kennis Kritische reflecteren tegen kwaliteitscriteria HU Lectoraat ICT en hoger onderwijs Figuur 6.1 Projectstappen in de fase project ontwikkelen (fase 2) Project organiseren (resultaat: projectorganisatie) (zie 6.5) Specificeren werkwijze projectteam Vanuit de gemobiliseerde projectorganisatie kennis de werkwijze in het project en ieders bijdrage daarin specificeren, evenals de wijze van voortgangsbewaking en kwaliteitsborging Vanuit de gespecificeerde probleemaanpak en gemobiliseerde kennis over projectorganisatie verklaren waarom deze werkwijze effectief en efficiënt is Intern valideren met het projectteam dat deze werkwijze wenselijk en werkbaar is Specificeren competentieontwikkeling De door de teamleden te ontwikkelen competenties specificeren ten opzichte van de reeds beschikbare competenties; of zijn alle competenties eigenlijk al op het goede niveau beschikbaar? Vanuit de probleemstelling, probleemaanpak en projectorganisatie verklaren hoe deze competenties ontwikkeld zullen worden Intern valideren met het projectteam dat deze competentieontwikkeling wenselijk en haalbaar is Valideren dat de competentieontwikkeling binnen de competentievraag valt (zie 6.7) 37/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Kwaliteitsborging organiseren (resultaat: kwaliteitsbeheersing) (zie 6.6) Risico en succesfactoren specificeren Vanuit de gemobiliseerde kennis de risicofactoren en succesfactoren specificeren, evenals de wijze waarop deze in de voortgangsbijeenkomsten zullen worden gemonitord Verklaren waarom juist deze factoren in deze situatie relevant zijn Intern valideren met het projectteam dat deze werkwijze wenselijk en werkbaar is Kwaliteitscriteria specificeren Vanuit de gemobiliseerde kennis kwaliteitscriteria specificeren voor: o de werkwijze o professionele rolvervulling o het praktijkresultaat o het kennisresultaat o het competentieresultaat Verklaren waarom juist deze criteria in deze situatie van toepassing zijn Intern valideren met het projectteam dat toepassing van deze criteria van belang is Plan van Aanpak (zie 6.7) Plan van Aanpak samenstellen van uit de resultaten uit de stappen hiervoor: I. Uitgangspositie II. Probleemstelling III. Probleemaanpak in fasen IV. Activiteitenplan vanuit: probleemaanpak en projectorganisatie V. Tijdbeheersing van uit: projectorganisatie VI. Kwaliteitsbeheersing VII. Projectorganisatie vanuit: projectorganisatie VIII. Informatiebeheersing vanuit: projectorganisatie Verder nader uitwerken hoe over het project zal worden gecommuniceerd met betrokkenen en hoe de lessons learned zullen worden getrokken IX. Communicatie X. Lessons learned Valideren Plan van Aanpak (zie 6.8) Start-Up Review (zie 6.9) 38/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 6.2 Uitgangspositie bepalen 6.2.1 Valideren praktijkvraag Via de projectsponsor heeft het projectteam een praktijkvraag en een kennisvraag voorgelegd gekregen. Het is van belang om bij de opdrachtgever(s) na te gaan of deze vragen daadwerkelijk de problemen van de opdrachtgever vangen. Valideren is dus het vaststellen of iets geldig is in een bepaalde omgeving of context. Soms lijkt valideren eenvoudig: is de euro in dit land geldig betaalmiddel of niet (is dit een euroland of niet?). Maar dan blijkt dat er landen zijn waar de euro gewoon als betaalmiddel wordt geaccepteerd, zonder dat het land tot de eurozone behoort. Het is dus oppassen geblazen met het vaststellen van geldigheid. Valideren is mensenwerk, want het zal zelden voorkomen dat de omgeving waarvoor gevalideerd wordt puur technisch is (bijvoorbeeld als een ontworpen onderdeel ingepast moet worden in een technisch apparaat). Meestal zullen mensen, met hun werkprocessen en cultuur, het belangrijkste deel van de omgeving uitmaken. Wel speelt natuurlijk de (technische) infrastructuur waarbinnen zij werken ook een rol. Tijdens de validatie moeten de volgende vragen moeten in ieder geval beantwoord worden: Praktijkprobleem Wat is het probleem (de vraag) precies en waarom is het van belang? Wie merkt het meest van het probleem (de vraag)? Hoe erg is het als dit probleem (deze vraag) niet wordt aangepakt? Weet de opdrachtgever of dit probleem ook elders voorkomt? Wordt het daar ook aangepakt? Ontstaan van probleem of vraag Sinds wanneer is dit probleem aan de orde? Hoe is dit probleem ontstaan of duidelijk geworden? Is er sindsdien iets gebeurd of veranderd? Wat is de aanleiding dat het nu op tafel komt? Is het probleem al eens eerder aan de orde is geweest? Wat is er al aan gedaan? Welke oorzaken zijn al bedacht? Welke oplossingen zijn al geprobeerd? Wat is de context van het probleem (omgevingsanalyse)? Wat zijn de ontwikkelingen in de omgeving (bijvoorbeeld marktontwikkelingen) Wat is de wijze van werken, leiding geven en de werkcultuur? Hoe ziet de bestaande infrastructuur eruit? Zitten daar knelpunten? Hoe is met de werknemers? Zijn die toegerust voor hun taak? Zitten daar knelpunten? Klanten zijn in het algemeen ongeduldig en willen eigenlijk alleen resultaten zien. Het doorlopen van een ontwikkeltraject zien zij soms als een nodeloze vertraging, want de probleemstelling en de context van de opdracht is in hun ogen overduidelijk. De door hen op papier gezette opdrachtformulering blijkt echter bijna altijd onvolledig (of zelfs onjuist) te zijn. Het projectteam moet door middel van interviews alle relevante informatie zien te ontfutselen van de klant. Soms zal de klant een voorgestelde verandering moeten bekrachtigen. Enkele richtlijnen voor interviewen van opdrachtgevers: Afspraken met opdrachtgevers worden altijd via de projectmanager gemaakt. De bereikbaarheid van de klant moet in de gaten gehouden worden. Onaangekondigde vakanties en dergelijke kunnen rampzalig zijn voor de tijdsplanning van het project. Gestreefd moet worden naar meer dan één contactpersoon, om stagnaties te voorkomen in geval van ziekte. Na de noodzakelijke interviews in het begin van het project dreigt de klant naar de achtergrond te verdwijnen. Toch is het raadzaam contacten te plannen op vaste tijden. Klanten hebben de 39/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten neiging om hun eisen later bij te stellen, omdat ze de consequenties van een aan hun gepresenteerd plan toch niet helemaal overzien. De klant is koning en er dient krediet bij een klant te worden opgebouwd. Interviewen van opdrachtgevers en gebruikers Bron: Patrick van Bommel, Wil Lamain, Harrie van Seters, John Symes, Tom van Weert (1996) GiP, Handleiding Geïntegreerd Practicum. Nijmegen: Radbout Universiteit. Tijdens een interview over de gestelde vraag kunnen nogal wat knelpunten optreden die het rendement verlagen. Typische voorbeelden hiervan zijn: Er worden onverwachte antwoorden gegeven. De interviewers blijken onvoldoende kennis van zaken te hebben. De verkeerde persoon blijkt te worden geïnterviewd. De antwoorden zijn te vaag. Het interview duurt langer dan verwacht. Vragen worden niet begrepen. Dergelijke problemen kunnen verminderd worden door een goede voorbereiding van zowel interviewers als geïnterviewde, en door een goede organisatie van het interview zelf. Formulering van het doel Allereerst zal exact duidelijk moeten worden wat het doel van het interview is. Dit lijkt op het intrappen van een open deur; toch blijkt het doel vaak niet grondig genoeg uitgewerkt te zijn. Door het doel precies te formuleren wordt de interviewer gedwongen er goed over na te denken. Een concrete doelstelling leidt tot het formuleren van concrete vragen. Bedenk dat vage vragen leiden tot vage antwoorden. Een op schrift gesteld doel kan de geïnterviewde veel informatie geven, zodat zijn antwoorden gerichter kunnen zijn. Welke informatie moet boven water komen?.Wie kan deze informatie verstrekken? Wat zal er met de informatie gebeuren, waar is zij voor nodig? Hoe gedetailleerd dient deze te zijn? Een voorbeeld van een doelstelling kan zijn: “Ik wil alle informatie- en productstromen binnen de verkoop-afdeling in kaart brengen. Hiervan wil ik weten wie de informatie verstuurt, wie haar ontvangt, wat er met die informatie gedaan wordt en hoeveel tijd dit kost.” Met name de laatste zin draagt er toe bij dat het interessegebied concreet wordt. Vaststellen van het interviewteam Iemand die geïnterviewd wordt praat in het algemeen niet graag tegen meerdere mensen. Bovendien kan een groot aantal aanwezigen tot een wanordelijk gesprek leiden. Het aantal aanwezigen zal daarom tot een minimum beperkt moeten blijven, en er dient een duidelijke rolverdeling afgesproken worden. In ieder geval moeten er een interviewer en een notulist zijn. De interviewer heeft de leiding in het gesprek en stelt de vragen. De interviewer formuleert eventuele vervolgvragen en vat antwoorden tussentijds samen. Tevens houdt de interviewer contact met de andere aanwezigen om hen de mogelijkheid te bieden een vraag te stellen. Eigenlijk is de interviewer een soort voorzitter die de leiding nooit uit handen geeft. De notulist registreert de antwoorden. De notulist is tevens verantwoordelijk voor het verslag van het interview. Eventuele andere leden van het interviewteam behoren tot degenen die de vragen hebben opgesteld. Zij geven ruggesteun aan de interviewer met hun kennis over het probleemgebied, en zij denken mee over eventuele vervolgvragen; zij schikken zich echter in een ondersteunende rol. Formulering van de vragen 40/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Het is belangrijk voordurend het doel van het interview in het achterhoofd te houden. Elke vraag die geformuleerd wordt dient aan dit doel getoetst te worden. Verder zal de verzameling van vragen het totale doel dienen te dekken. Het is bijzonder vervelend en knullig achteraf nogmaals contact met de klant te moeten opnemen, voor aanvullende informatie. Open en gesloten vragen Onder gesloten vragen worden vragen verstaan waarop met ja of nee geantwoord kan worden. Gesloten vragen zijn efficiënt en concreet. Een nadeel is echter dat ze de geïnterviewde niet alle informatie kan geven die mogelijk van belang is. Ze kunnen als vervelend en te dwingend worden ervaren worden. Open vragen zijn vragen, die meer verhalende antwoorden als gevolg kunnen hebben. Ze stimuleren de geïnterviewde. In een explorerende fase kan dat zeer goed van pas komen. Het nadeel is dat ze tot minder relevante uitwijdingen kunnen leiden. Open vragen kunnen veel tijd in beslag nemen. Het is dan ook belangrijk in een zo vroeg mogelijk stadium het domein van de vraag aan te geven of in te perken. Suggestieve en directe vragen Suggestieve vragen zijn vragen waar de interviewer een mening of idee inlegt. Ze sturen de geïnterviewde in een bepaalde richting: “Blijven bij uw collega de formulieren vervolgens erg lang liggen?” Het gevaar bestaat dan dat de geïnterviewde enkel reageert op de ideeën van de interviewer en niet vertelt hoe hij er zelf over denkt. Wanneer concrete, zakelijke informatie gewenst is kunnen suggestieve vragen het interview negatief beïnvloeden. Directe vragen zijn vragen die naar concrete informatie vragen: “Vindt u formulieren afhandelen vervelend werk?” Directe vragen zijn zeer effectief en geven snel informatie. Ze kunnen soms confronterend zijn en niet door iedereen als prettig ervaren worden. Effectieve vragen Aspecten die kunnen bijdragen tot een verbetering van de vraag: Definieer bepaalde termen als inleiding tot de vraag. Schat daarom zorgvuldig in wat de geïnterviewde wel zal weten en wat niet. “Onder user-interface wordt de communicatie tussen de gebruiker en het computersysteem verstaan.” Plaats de vraag in een context. “Een klant dient een aanvraagformulier in. Hoelang is een zo’n formulier onderweg tussen de afdelingen?” Verstrek feiten. “Er is gebleken dat de vraag naar product A in zomermaanden vrijwel nihil is.” Voorkom ego-bedreiging. Iemand die ondervraagd wordt over zijn minder goed lopende taken kan zich bedreigd voelen. Dan is het zinvol de vraag wat subtieler te stellen. “Er is gebleken dat de verwerking van formulieren op deze afdeling doorgaans een week duurt. Hoelang bent u met een formulier bezig?” Voorkom wenselijke antwoorden. Een te suggestieve vraag kan een voor de interviewer wenselijk antwoord afdwingen, terwijl het niet het juiste is. Stel de vraag neutraal. Vorm van de vraag Aandachtspunten voor de vorm van de vraag: Maak zo min mogelijk gebruik van samengestelde zinnen. Deze zijn moeilijker te begrijpen. Pas de woordkeus aan het referentiekader van de geïnterviewde aan. Een vraag moet eenduidig zijn en mag niet meerdere vragen in zich dragen. Antwoorden en vervolgvragen Door te voren te bedenken welke mogelijke antwoorden gegeven zouden kunnen worden, ben je in staat aanvullende vragen te formuleren. Tijdens het gesprek is dit lastiger, omdat de geïnterviewde zich volledig moet concentreren op de antwoorden. Veel ruimte voor eigen gedachten is er niet. 41/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Het interview zelf Bij het afspreken van het interview dienen de doelstellingen van het interview aan de geïnterviewde bekend gemaakt te worden. Hij kan dan meteen aangeven of hij wel de juiste persoon is om de gewenste informatie te verstrekken. Uiterlijk een dag van tevoren kunnen de vragen dan toegestuurd worden. Verder worden plaats, tijd en datum afgesproken, en wordt vermeld wie erbij aanwezig zullen zijn. Op het interview zelf begin de interviewer met een kalme en niet te gehaaste introductie. Dit moet een verhaal zijn, en niet een opsomming van losse punten. De introductie zet de toon van het interview. Hij moet gebruik maken van de reeds aangebrachte structuur van het interview. Hiermee wordt bijvoorbeeld bedoeld: Sla geen vragen over. Handhaaf de volgorde van vragen. Handhaaf letterlijk de woordkeus die op papier staat. Ooit zijn de vragen zo bedacht en doordacht, en er kan haast geen reden zijn om daar van af te wijken. Bij open vragen is het belangrijk door terugkoppeling te controleren of de geïnterviewde goed begrepen wordt. De geïnterviewde hoort zo zijn verhaal nog eens met andere woorden, en het ondersteunt de notulist. Nadat terugkoppeling dient het antwoord getoetst te worden aan het oorspronkelijke doel van de vraag. Het kan nieuwe aspecten aan het licht gebracht hebben, die nadere toelichting behoeven. Daarnaast kan een deel van de vraag nog steeds onbeantwoord zijn. Hier speelt een goede voorbereiding een belangrijke rol. Niet voor de hand liggende antwoorden kunnen reeds bekeken zijn en vervolgvragen reeds bedacht. Onduidelijkheden dienen meteen opgehelderd te worden. In later stadium of thuis komen de interviewers daar niet meer achter! De laatste vraag van een interview informeert naar eventuele hiaten in het interview. De geïnterviewde kan nog iets toe te voegen hebben, of vinden dat bepaalde zaken niet aan de orde zijn gekomen. Als er nog een terugkoppeling plaats zal vinden kan vermeld worden wanneer deze plaats vindt. Uitwerking en terugkoppeling Na afloop werkt de notulist het interview zo vlug mogelijk uit, eventueel samen met het interviewteam. Het verslag kan het beste geformuleerd worden in de vorm waarin het verder gebruikt gaat worden, zodat problemen in interpretatie zoveel mogelijk gereduceerd worden. Het wordt voorgelegd aan de geïnterviewde ter validatie. Het is zaak goede afspraken te maken over het tijdstip waarop hij dit krijgt, en wanneer de reactie erop terugkomt. Deze terugkoppeling moet eenmalig en kort zijn, en niet een interview op zich. Laat de geïnterviewde reageren op de resultaten en sluit het daarmee af. Met de eerste versie van het verslag kan het projectteam natuurlijk meteen aan de slag. 6.2.2 Kennis mobiliseren Hergebruik van kennis is noodzaak om een goede oplossing te kunnen realiseren. Het projectteam gaat na welke kennis (bronnen) en welke expertise (experts) er reeds beschikbaar zijn en mobiliseert de volgende kennis: over het probleem in de praktijksituatie (contextkennis) mogelijke oplossingen (oplossingskennis) manieren om tot een geïmplementeerde oplossing te komen (methoden kennis) over de manier om ontwerpprojecten tot een goed einde te brengen (projectorganisatie kennis) In een praktijksituatie gaat het daarbij meestal zowel om een ‘zaak’ als om mensen en organisaties die bij de ‘zaak’ betrokken zijn of er belang bij hebben, de ‘omgeving’. Neem als voorbeeld een situatie waarin gevraagd wordt om een inrichtingsplan voor een bepaald stedelijk gebied te maken. Het inrichtingsplan is de ‘zaak’; hierbij komen allerlei professionele en technische zaken 42/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten bij kijken op het gebied van bestemmingsplannen, milieu, duurzaamheid, stedenbouw, enz. Maar zo’n inrichtingsplan raakt de belangen van bewoners van het gebied en de beslissers hebben ook zo hun eigen belangen en organisatorische inbedding. Een voorbeeldig inrichtingsplan zal niet ver komen als de bewoners er overheen vallen, het niet past bij de belangen van de beslissers of in een organisatorisch onhandige vorm is gegoten. De omgeving De ‘zaak’ Maatschappelijke omgeving Doelen Strategie Structuur Cultuur Technologie Mensen Figuur 6.2 Praktijksituatie: de ‘zaak’ en de ‘omgeving’ Je moet dus zowel op zoek naar kennis over de ‘zaak’, als kennis over de ‘omgeving’ van mensen en organisaties waar de zaak speelt. Kennis over de ‘omgeving’ ligt op de volgende terreinen: Maatschappelijke omgeving van de praktijksituatie Doelen die men in de praktijksituatie wil bereiken (vanuit missie en doelstellingen) Strategie (= aanpak) die in de praktijksituatie wordt gevolgd om de doelstellingen te realiseren Structuur van de praktijksituatie Cultuur Technologie Mensen Als je problemen hebt met het vinden van relevante kennis, kan je de projectsponsor vragen naar suggesties of om een doorverwijzing naar experts. Te beantwoorden kennisvragen Te beantwoorden kennisvragen zijn in ieder geval: Wat is bekend over de probleemsituatie? Het ‘zaak’probleem en de ‘omgeving’ lijkt dit probleem op wat elders al eens eerder is gesignaleerd? wat waren de kenmerken van dat probleem? wat was de context waarin dat probleem speelde? welke oorzaken zijn er gevonden? Wat is bekend over mogelijke oplossingen? Oplossing van de ‘zaak’ en de effectiviteit van deze oplossing in de ‘omgeving’ zijn er oplossingen geprobeerd? En in welke context? o welke succesfactoren speelden daarbij een rol? o welke risico’s werden gevonden? Wat is bekend over de mogelijke aanpak? Aanpak van de ‘zaak’ en aanpak om de ‘zaakoplossing’ effectief te krijgen in de ‘omgeving’ op welke manieren kwamen de oplossingen tot stand? o welke succesfactoren speelden daarbij een rol? o welke risico’s werden gevonden? 43/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Hoe worden dit soort projecten georganiseerd? Hoe is de fasering van dit soort projecten? Hoe kom je tot een activiteitenplanning in de tijd? Hoe bewaak je de voortgang? Hoe borg je de kwaliteit? Hoe borg je de persoonlijke ontwikkeling van teamleden? Aan welke eisen moet een Plan van Aanpak voor dit soort projecten voldoen? 44/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 6.3 Diagnose stellen 6.3.1 Analyseren huidige praktijksituatie Vanuit de gemobiliseerde contextkennis (6.2.2) wordt de huidige praktijksituatie, zowel de ‘zaak’ als de ‘omgeving’, verklaard: Wat is de huidige praktijksituatie? Welke zijn de specifieke sterke (+) en zwakke (-) punten in deze situatie en waarom? Hoe past de praktijkvraag hierin? De positieve punten van de huidige situatie worden dus in beeld gebracht, evenals de negatieve, verbeterpunten. Gemobiliseerde contextkennis Zaak Gevalideerde praktijkvraag Analyse Omgeving Maatschappelijke omgeving Doelen Strategie Structuur Cultuur Technologie Mensen Huidige situatie Positieve punten (+++) Negatieve punten (- - -) Figuur 6.3 Analyse van de praktijksituatie (‘zaak’ en ‘omgeving’) De positieve en negatieve punten van de ‘zaak’ worden bepaald door kennis over de ‘zaak’ die is gemobiliseerd. Positieve punten en negatieve punten van de ‘omgeving’ van de huidige praktijksituatie zullen liggen op de volgende terreinen: Maatschappelijke omgeving van de praktijksituatie o Voorbeeld: De huidige situatie speelt goed in op marktontwikkelingen (+) o Voorbeeld: De huidige situatie voldoet niet aan regelgeving en dat geeft problemen (-), Doelen die men in de praktijksituatie wil bereiken (vanuit missie en doelstellingen) o Voorbeeld: De huidige situatie realiseert doelen die niet binnen missie en doelstellingen vallen; bijstelling is op dit punt nodig (-) Strategie (= aanpak) die in de praktijksituatie wordt gevolgd om de doelstellingen te realiseren o Voorbeeld: De aanpak in de huidige situatie is conform de organisatiestrategie (+) o Voorbeeld: Met de aanpak in de huidige situatie worden gewenste doelen niet bereikt (-) Structuur van de praktijksituatie o Voorbeeld: De huidige “productie”structuur voldoet goed om de gewenste doelen te halen (+) o Voorbeeld: De manier waarop de aansturing in de “productie”structuur verankerd is, is niet effectief (-) Cultuur o Voorbeeld: De cultuur van werken is collegiaal en kwaliteitsgericht (+) o Voorbeeld: De cultuur is resistent tegen noodzakelijke veranderingen (-) Technologie 45/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten o o Mensen o o o Voorbeeld: de werkruimten zijn niet geschikt om de doelen te bereiken (-) Voorbeeld: ICT-ondersteuning is niet effectief en de digitale verbindingen zijn te traag (-) Voorbeeld: het werk wordt als niet uitdagend ervaren (-) Voorbeeld: het opleidingsniveau is adequaat om de gewenste doelen te bereiken (+) Voorbeeld: De medewerkers begrijpen niet wat er van hun verwacht wordt (-) Het is van belang al deze terreinen te bekijken. De ervaring leert dat geïnventariseerde positieve en negatieve punten een sterke relatie hebben met succes- en risicofactoren in de toekomstige implementatie van de oplossing. Als de cultuur bijvoorbeeld resistent is tegen veranderingen, dan zul je daar bij de implementatie van de oplossing gedegen rekening mee moeten houden. 6.3.2 Gewenste praktijksituatie in kaart brengen Vanuit de gemobiliseerde oplossingskennis (6.2.2) specificeert het projectteam de gewenste situatie. Ook hier worden de positieve punten in beeld gebracht, evenals de negatieve punten. Het gaat weer zowel om de ‘zaak’, als de ‘omgeving’ waarin weer alle terreinen bekeken worden: Maatschappelijke omgeving van de praktijksituatie Doelen die men in de praktijksituatie wil bereiken (vanuit missie en doelstellingen) Strategie (= aanpak) die in de praktijksituatie wordt gevolgd om de doelstellingen te realiseren Structuur van de praktijksituatie Cultuur Technologie Mensen Zaak Gemobiliseerde oplossingskennis Specificeren Vergelijken Positieve punten (+++) Negatieve punten (- ) Gewenste situatie Huidige situatie Positieve punten (+++) Negatieve punten (- - -) Omgeving Maatschappelijke omgeving Doelen Strategie Structuur Cultuur Technologie Mensen Verklaren Figuur 6.4 Gewenste praktijksituatie in kaart brengen Te beantwoorden vragen zijn: Wat moet er veranderen in de huidige situatie om het probleem op te lossen (de vraag te beantwoorden) en wat is in die verandering de essentie? Waarom zou die verandering moeten werken? Spoort die verandering met wat men belangrijk vindt (missie, visie en centrale waarden)? Spoort die verandering met ontwikkelingen in de omgeving (bijvoorbeeld marktontwikkelingen) Past die verandering in de wijze van werken, leiding geven en de werkcultuur? Past die verandering binnen de bestaande infrastructuur? 46/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Heeft de verandering voldoende rendement? Is de verandering in deze context haalbaar? Wat is er zichtbaar of tastbaar als ons project klaar is (het resultaat)? Welke effecten zien wij dan voor ons? Is het resultaat het juiste middel om de verandering te realiseren? Komt de oplossing dichterbij met ons resultaat? Vergelijken van de gewenste met de huidige situatie Door de huidige situatie te vergelijken met de gewenste situatie wordt nagegaan: welke positieve punten uit de huidige situatie worden behouden in de gewenste situatie, welke negatieve punten uit de huidige situatie zijn verdwenen in de gewenste situatie, welke nieuwe positieve of negatieve punten er zijn in de gewenste situatie. Op basis van de vergelijking kan het projectteam verder nagaan in hoeverre de te ontwerpen gewenste situatie past bij de te realiseren doelen, de strategie en de besliscultuur. En verder hoe de gewenste situatie kan worden ingepast in de huidige structuur, in het krachtenveld van belangen en opvattingen van betrokkenen, in de cultuur en in de huidige (technologische) infrastructuur. Ook gaat het Projectteam na in hoeverre de te ontwerpen situatie inspeelt op in de maatschappelijke omgeving gesignaleerde ontwikkelingen. Op grond van de bevindingen maakt het projectteam een keuze ten aanzien van welke elementen uit de huidige situatie behouden blijven en van welke het wenselijk en haalbaar is dat deze worden aangepakt. Verklaren van de gewenste situatie Vanuit wat aan kennis gemobiliseerd is over mogelijke oplossingen (oplossingkennis) (6.2.2.) verklaart (beargumenteert) het projectteam waarom de gewenste situatie wenselijk is ten opzichte van de huidige situatie (beter voldoet dan de huidige situatie) en werkbaar is. Dit betekent dat het projectteam laat zien dat de gewenste situatie valide is o functioneel is o begrijpelijk is o haalbaar is betrouwbaar is adequaat is, dat wil zeggen precies is controleerbaar is verankerd is in de kennis over de praktijk relevant is, dat wil zeggen de moeite waard is consistent is in de score op de criteria Probleemstelling De probleemstelling wordt gevormd door: De beschrijving van ‘zaak’ en ‘omgeving’ in de huidige situatie (met zijn plus- en minpunten), De beschrijving van de ‘zaak’ en ‘omgeving’ in de gewenste situatie (met zijn plus- en minpunten). 47/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Valideren van de probleemstelling De analyse van de huidige situatie, de door het projectteam geformuleerde probleemstelling en de verklaring moeten met de praktijkopdrachtgever gevalideerd worden. Als het om een ingewikkelde situatie gaat, waarin niet duidelijk is welke positie de praktijkopdrachtgever zal kiezen, is het aan te bevelen om deze validatie zo spoedig mogelijk te doen. Wanneer de gewenste situatie door de praktijkopdrachtgever als voor de hand liggend zal worden ervaren, kan met validatie gewacht worden tot de validatie van het gehele Plan van Aanpak (6.7). 48/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 6.4 Aanpak uitwerken Nu het ‘wat’ van het project met de probleemstelling duidelijk is, bepaalt het projectteam het ‘hoe’: welke aanpak zal er toe leiden dat het beoogde resultaat wordt bereikt. Richting gevend voor de aanpak is de projectfasering zoals deze in Figuur 1.1 is weergegeven. Met andere woorden: onderstaande stappen moeten nader worden gepland. Praktijk vraag Praktijk oplossing Competentieagenda Competentieontwikkeling Ontwikkelde competentie Oplossing Ontwikkelen Oplossing ontwerpen Oplossing Implementeren Oplossing Projectontwikkelen Conceptueel ontwerp Voorbereiden Probleemstelling Diagnose Projectorganisatie Vraag Vraagontwikkelen Oplossing opleveren Kennis en competentie opleveren Oplossing verbeteren Contextkennis Kennisagenda Methoden Oplossingen Ontwikkelde kennis Kennisontwikkeling Fase 3 Ontwerpen en implementeren Oplossing ontwerpen Eerst maak je met je projectteam een model van de nagestreefde oplossing; dat heet een conceptueel ontwerp. De gewenste situatie is hiervoor de basis. De ontworpen modeloplossing moet er toe leiden dat de gewenste situatie straks realiteit wordt. Gemobiliseerde kennis wordt gebruikt en mogelijk nieuwe kennis ontwikkeld en toegepast. Valideren conceptueel ontwerp Het conceptueel ontwerp legt de contouren van de uiteindelijke oplossing vast. Het is dus van belang dat je nagaat of de opdrachtgever het conceptueel ontwerp ‘ziet zitten’, voordat je met je projectteam aan de uitwerking begint. Oplossing ontwikkelen Het conceptueel ontwerp wordt uitgewerkt in een oplossing die in het echt kan ‘werken’, gebruikt kan worden. Gemobiliseerde kennis wordt gebruikt en mogelijk nieuwe kennis ontwikkeld en toegepast. Oplossing implementeren De werkende oplossing wordt uitgeprobeerd in de praktijk waarin deze ook gebruikt moet worden, meestal bij de opdrachtgever ‘in huis’. Gemobiliseerde kennis wordt gebruikt en mogelijk nieuwe kennis ontwikkeld en toegepast. Valideren geïmplementeerde oplossing Met je projectteam ga je na of opdrachtgever en gebruikers tevreden zijn met de geïmplementeerde oplossing. 49/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Als er een aparte opdrachtgever is voor het onderdeel kennisontwikkeling (bijvoorbeeld een onderzoeker van een kenniscentrum), dan wordt de tot nu toe ontwikkelde kennis ook met deze opdrachtgever gevalideerd. Mid-Term Review De kwaliteit van de geïmplementeerde oplossing, de ontwikkelde kennis en de ontwikkelde competenties wordt samen met experts nagegaan. Verbeteracties worden geïnventariseerd. Oplossing verbeteren Verbeteracties worden uitgevoerd en de oplossing verder verbeterd. Ook ontwikkelde kennis en competentieniveau worden waar nodig verbeterd. Fase 4 Opleveren van de oplossing Als alles naar tevredenheid ‘werkt’, wordt de oplossing overgedragen aan de opdrachtgever. Als er een aparte opdrachtgever is voor het onderdeel kennisontwikkeling (bijvoorbeeld een onderzoeker van een kenniscentrum), dan wordt de ontwikkelde kennis aan deze opdrachtgever overgedragen. 6.4.1 Specificeren probleemaanpak Vanuit de gemobiliseerde methoden kennis worden bovenstaande stappen voor zowel de ‘zaak’ als de ‘omgeving’ uitgewerkt: Welke resultaten zijn nodig om voor de ‘zaak’ een conceptueel ontwerp te maken, dit uit te ontwikkelen en te implementeren? Welke resultaten zijn nodig om de implementatie van de ‘zaak’ in de ‘omgeving’ van mensen, organisaties en belangen tot een succes te maken? Voor de stappen validatie en review zijn beschrijvingen beschikbaar in het Handboek Ontwerpprojecten dat bij deze handleiding hoort. Te beantwoorden vragen zijn: Wat wordt de aanpak om het resultaat te realiseren? Welke methoden en technieken worden voor dit soort problemen in de praktijk gebruikt? Wat levert in dit soort gevallen normaliter een goed resultaat op? Wat wordt de aanpak om het resultaat geïmplementeerd te krijgen? Waar liggen de prioriteiten? Hoe gaan wij na dat de aanpak werkt? Voor wat betreft de ‘zaak’ zullen voor de aanpak methoden en technieken beschikbaar zijn die professionals in de praktijk hanteren. Nagegaan moet worden in de aanpak van de ‘zaak’ ook voldoende aandacht wordt geschonken aan de ‘omgeving’. In onderstaand voorbeeld worden aanpak van de ‘zaak’ en van de ‘omgeving’ gecombineerd. Voorbeeld Aanpak stedelijke vernieuwing Conceptueel ontwerp “Startnotitie” Taakstelling/opgave Afbakening aandachtsgebied Inventarisatie van wensen en belangen Uitgangspunten (fysische) duurzaamheidaspecten Scenario’s Bouwkundige uitwerking van de scenario’s Onderhandelingsresultaat Markt-/klantonderzoek 50/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Risicoanalyse Ontwikkelen 1. Bepalen van de gemeenschappelijke drager en/of strategische doelstelling. 2. Verrichten van een omgevingsanalyse om partijen en belangen in kaart te brengen. 3. Ontwikkelen van veranderprogramma’s (kaders, programmatisch, ruimtelijk, financieel). 4. Bepalen van het organisatiemodel en de partijen die deelnemen aan de betreffende vernieuwing. 5. Bepalen van de rol van het ontwerp, gelijktijdig tekenen en rekenen en transparantie over het rekenmodel. Implementeren 6. Verkennen van draagvlak bij belanghebbenden en opstellen communicatiestrategie. 7. Toetsing aan regelgeving en duurzaamheideisen. 8. Samenwerking vastleggen in contracten. 9. Zorgdragen voor korte termijn maatregelen leefbaarheid en beheer. 10. In relaties met mensen vertrouwen opbouwen Nadere uitwerking van stappen in de aanpak Bij de uitwerking van de stappen in de aanpak kun je als hulpmiddel gebruik maken van de ‘Work Breakdown Structure (WBS)’ (zie bijvoorbeeld Bos & Harting (1998) p. 67 -75): Eerst worden de resultaten van elke stap bepaald, Daarna worden voor elke stap deelresultaten bepaald en wordt nagegaan welke activiteiten nodig zijn om deze deelresultaten te verkrijgen, Tenslotte worden de deelresultaten en activiteiten waar nodig geclusterd tot logisch samenhangende werkpakketten Door tussentijdse resultaten te benoemen kan het project in logische delen uiteengerafeld worden, zodat uiteindelijk kleinere overzichtelijke taken en activiteiten overblijven. Figuur 6.5 Voorbeeld van een Work Breakdown Structure (Bron: Bos en Harting (1998). Verklaren waarom de voorgestelde aanpak werkt Vanuit de gemobiliseerde methoden kennis laten zien dat de aanpak van de ‘zaak’ en de ‘omgeving’ het gewenste resultaat (de gewenste praktijksituatie) zal opleveren. 51/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Als projectteam laat je in de verklaring zien dat de aanpak (faseren, stappen en activiteiten) Controleerbaar is o de activiteiten in de werkwijze vormen een compleet geheel, o de activiteiten zijn voldoende gedetailleerd om te kunnen zien wat ze voor effect zullen hebben, o de werkwijze is transparant, dat wil zeggen informatief en begrijpelijk. Vakkundig is o de beschikbare kennis goed is gemobiliseerd (kenniseffectief), o de werkwijze goed is georganiseerd en kwaliteitgericht (organisatorisch effectief), o de werkwijze efficiënt is naar tijd, (geld) en te investeren energie, o de werkwijze toelaatbaar is (voldoet aan de ARBO-eisen, is ethisch verantwoord, etc.). Logisch is o de werkwijze is logisch consistent (houdt zich aan de regels van de logica), o de werkwijze volgt de gekozen methode en wat is afgesproken, o de werkwijze houdt zich aan de geschreven, of ongeschreven, beroepscode, Valide is in de praktijkcontext o de werkwijze is functioneel in de praktijksituatie o de werkwijze is haalbaar in de praktijksituatie Probleemaanpak valideren met de praktijk De aanpak moet met de praktijkopdrachtgever (en mogelijk ook met andere betrokkenen, zoals gebruikers van de oplossing) gevalideerd worden: wordt deze aanpak als gewenst en haalbaar beoordeeld. Als het om een ingewikkelde situatie gaat, waarin niet duidelijk is welke positie de praktijkopdrachtgever zal kiezen, is het aan te bevelen om deze validatie zo spoedig mogelijk te doen. Wanneer de voorgestelde aanpak door de praktijkopdrachtgever als voor de hand liggend zal worden ervaren, kan met validatie gewacht worden tot de validatie van het gehele Plan van Aanpak (6.7). 6.4.2 Probleemaanpak intern valideren voor de kennisvraag Nu bekend is wat de probleemstelling is en wat de aanpak zal zijn kan worden nagegaan of de kennisvraag daadwerkelijk zal kunnen worden beantwoord. Nieuw te ontwikkelen kennis specificeren Je specificeert met je projectteam de nieuw te ontwikkelen kennis ten opzichte van de reeds gemobiliseerde kennis en gaat na of de gevraagde kennis eigenlijk al beschikbaar is. Verklaren waarom deze nieuwe kennis ontwikkeld kan worden in het project Vanuit de probleemstelling en de probleemaanpak verklaren waarom deze kennis nuttig is en hoe deze nieuwe kennis ontwikkeld zal worden. Dit betekent dat je als projectteam laat zien dat de te ontwikkelen kennis valide is o functioneel is o begrijpelijk is o haalbaar is betrouwbaar is adequaat is, dat wil zeggen 52/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten precies is controleerbaar is verankerd is in de kennis over de praktijk relevant is, dat wil zeggen de moeite waard is consistent is in de score op de criteria Als projectteam laat je in de verklaring zien dat de aanpak (faseren, stappen en activiteiten) Controleerbaar is o de activiteiten in de werkwijze vormen een compleet geheel, o de activiteiten zijn voldoende gedetailleerd om te kunnen zien wat ze voor effect zullen hebben, o de werkwijze is transparant, dat wil zeggen informatief en begrijpelijk. Vakkundig is o de beschikbare kennis goed is gemobiliseerd (kenniseffectief), o de werkwijze goed is georganiseerd en kwaliteitgericht (organisatorisch effectief), o de werkwijze efficiënt is naar tijd, (geld) en te investeren energie, o de werkwijze toelaatbaar is (voldoet aan de ARBO-eisen, is ethisch verantwoord, etc.). Logisch is o de werkwijze is logisch consistent (houdt zich aan de regels van de logica), o de werkwijze volgt de gekozen methode en wat is afgesproken, o de werkwijze houdt zich aan de geschreven, of ongeschreven, beroepscode, Valide is in de praktijkcontext o de werkwijze is functioneel in de praktijksituatie o de werkwijze is haalbaar in de praktijksituatie Valideren dat de nieuw te ontwikkelen kennis binnen de kennisvraag valt De concrete invulling van de kennisvraag moet met de kennisopdrachtgever (en mogelijk ook met andere betrokkenen, zoals gebruikers van de kennis) gevalideerd worden. Als het om een ingewikkelde situatie gaat, waarin niet duidelijk is welke positie de kennisopdrachtgever zal kiezen, is het aan te bevelen om deze validatie zo spoedig mogelijk te doen. Wanneer de concrete invulling van de kennisvraag door de praktijkopdrachtgever als voor de hand liggend zal worden ervaren, kan met validatie gewacht worden tot de validatie van het gehele Plan van Aanpak (6.8). 53/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 6.5 Project organiseren 6.5.1 Specificeren werkwijze projectteam Werkwijze specificeren vanuit de gemobiliseerde projectorganisatie kennis. Ook wordt ieders bijdrage gespecificeerd, evenals de wijze van voortgangsbewaking en kwaliteitsborging. Activiteiten plannen De taken en activiteiten die in de Work Breakdown Structure (zie 6.4.1) zijn opgenomen moeten in de tijd gepland worden. Het is niet altijd gemakkelijk in te schatten hoelang een taak of activiteit zal duren. Deze initiële planning is de eerste stap naar houvast en structuur en is dan ook levensbelang voor het slagen van het project. Eén van de wetten van projectmanagement luidt: “De voltooiing van een onzorgvuldig gepland project neemt drie keer zoveel tijd in beslag dan verwacht. De voltooiing van een zorgvuldig gepland project slechts twee keer zoveel.” Onder een goede planning wordt niet verstaan een planning die qua schatting exact klopt, maar een planning die door iedereen die bij het project betrokken is als een haalbare planning wordt gezien. Elk projectlid dient de planning als zijn persoonlijk doel te zien. Door gezamenlijk als projectteam een planning op te stellen en samen een schatting van de verschillende activiteiten te maken, zal de betrokkenheid groter zijn. In de planning maken wij onderscheid tussen de tijdsomvang van een activiteit (hoeveel werkdagen moeten teamleden aan de activiteit besteden om deze af te ronden) en de doorlooptijd van de activiteit (hoeveel werkdagen duurt het voor de activiteit is afgerond). Een activiteit met een tijdsomvang van 32 uur, kan een doorlooptijd hebben van 4 weken, omdat tussentijds gewacht moet worden op resultaten van anderen. Zo kan het zijn dat vanwege de wachttijd 2 teamleden elke week niet meer dan 4 uren aan de activiteit kunnen besteden (zij hebben dan elk nog 36 uren per week te besteden over). Het planningsprocedé ziet er als volgt uit: Bron: Patrick van Bommel, Wil Lamain, Harrie van Seters, John Symes, Tom van Weert (1996) GiP, Handleiding Geïntegreerd Practicum. Nijmegen: Radbout Universiteit. “The key to successful estimating is understanding the problem.” Leg - zoals hierboven aangegeven - mijlpalen en mijlpaalresultaten vast, die een bepaalde fase of grote activiteit afsluiten. Deze momenten en resultaten zijn belangrijk voor de beheersing van het project. Zij leveren een waarborg voor de afronding van het betreffende deel van het project en maken controle op de voortgang van het project eenvoudiger. Maak - uitgaande van de fasering van het project in Figuur 1.1 - een Work Breakdown Structure (WBS). Zorg dat elke fase zodanig gedetailleerd is dat duidelijk afgebakende projecttaken ontstaan. Maak met het projectteam een tijdschatting van de verschillende taken en construeer een verbeterde WBS. Zorg dat deze duidelijke afgebakende taken heeft, die niet te veel tijd kosten. Veel is een begrip relatief aan de totale duur van het project. Verdeel de verantwoordelijkheden over de zo ontstane activiteiten en taken binnen het projectteam. Uiteraard dient de verdeling te geschieden op basis van kwaliteiten, motivatie en belangen van de projectteamleden zelf. Bepaal voor elke taak afzonderlijk hoeveel mensen er aan moeten werken. Stel vast welke taken onafhankelijk van elkaar uitgevoerd kunnen worden en welke na elkaar. Sommige activiteiten kunnen voor een groot deel onafhankelijk van elkaar uitgevoerd worden, maar hebben bijvoorbeeld toch enige afhankelijkheid. Een andere opsplitsing van activiteiten kan 54/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten mogelijk de afhankelijkheid wegnemen zodat ze toch parallel aan elkaar kunnen worden afgewerkt. Bepaal de doorlooptijd van de activiteiten door het kritisch pad te bepalen. Leg de gemaakte planning en afspraken vast in het Plan van Aanpak. Zorg ervoor dat iedereen exact weet wat wanneer en door wie gedaan moet worden. . Kritisch pad Een taak is een activiteit die een bepaalde hoeveelheid tijd kost. Taak Een mijlpaal is een moment, kost geen tijd en sluit een reeks taken af, meestal met een mijlpaalresultaat. Mijlpaal Taak A Taak A Taak B 5 Taak B Taak B Taak D Taak A Taak C Twee taken die verbonden worden door een lijn zijn afhankelijke taken. Taak B kan pas uitgevoerd worden nadat Taak A is afgerond. Taak B kan pas worden uitgevoerd nadat taak A is afgerond en nadat de aangegeven tijd (5 dagen) is verstreken; dit heet de lag time. Lag time ontstaat bijvoorbeeld doordat gewacht moet worden op een reactie van een opdrachtgever. Activiteiten netwerk. De taken B en C zijn taken die parallel kunnen worden uitgevoerd. Dit betekent dat zij gelijktijdig kunnen starten. A,B,D en A,C,D zijn paden in het netwerk van aaneengesloten taken. De tijdsduur van een pad is de som van de tijdsduur van de taken op dit pad. Het kritieke pad (critical path) in het netwerk van activiteiten is die combinatie van aaneengesloten taken die de grootst mogelijke som oplevert in het netwerk. Het kritieke pad bepaalt dus de uiteindelijke duur van het project. 55/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 1/5/92 4 Taak C 1/1/92 4 Taak A 1/10/92 4 Taak D 1/5/92 1/1/92 0 1/14/92 0 5 Einde Taak E Start 1/10/92 1/1/92 3 5 Taak F Taak B Figuur 6.6 Kritisch pad. Bron: GiP, Handleiding Geïntegreerd Practicum. Nijmegen: Radbout Universiteit. In Figuur 6.6 is (Start, A, E, F, Einde) het kritieke pad (vet gedrukt), omdat dit het langst durende pad van Start tot Einde is. Taak C zal niet snel op het kritieke pad terechtkomen, daar deze zes dagen korter vergt dan het boven weergegeven kritieke pad. Uitloop op zo’n taak heeft geen directe gevolgen voor het kritieke pad, en wordt daarom slack time genoemd. Wanneer Taak B twee dagen langer zou duren dan nu, dan loopt het kritieke pad niet via Taak A, maar via Taak B. Te beantwoorden vragen zijn: Fasering: Wat is de looptijd van het project? Welke fases kent het project? In het algemeen: o Conceptueel ontwerp: een idee van de oplossing. o Prototype: het idee gerealiseerd. o Implementatie: het idee gerealiseerd en werkzaam in de context. o Opleveren: natuurlijk de oplossing, maar ook kennis en competentie. Wanneer gaat het project in een andere fase over (opleverdata, reviewbijeenkomsten)? Activiteitenplan: Welke activiteiten worden in iedere fase ondernomen? Hoeveel tijd is daarmee gemoeid? Hoe zijn verschillende activiteiten van elkaar afhankelijk? Wie doet wat? Welke hulpmiddelen zijn er nodig (en zijn die beschikbaar)? Kwaliteitsbeheersing: Zijn de geplande activiteiten SMARTI geformuleerd: o Specifiek: passend in de context van het praktijkprobleem. o Meetbaar o Aanvaardbaar: passend bij de geldende normen van de opdrachtgever, de gebruikers en de beroepsgroep. o Realistisch o Tijdgebonden: haalbaar in de gegeven tijd en passend bij geplande momenten voor validatie en review. 56/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten o Innovatief: gebruikmakend van nieuwe kennis. Zijn de generieke criteria voor (tussen)resultaten operationeel gemaakt? Is duidelijk gemaakt hoe gecontroleerd wordt of aan deze criteria wordt voldaan? Afspraken projectteam: Hoe zijn de rollen binnen het project verdeeld over de teamleden? Wie draagt welke verantwoordelijkheid? Welke werkafspraken zijn gemaakt (plaats, tijd, bereikbaarheid enz.) Informatiebeheersing: Wanneer worden betrokkenen op de hoogte gebracht van de voortgang van het project? Hoe worden projectdocumenten, afspraken en (tussen)resultaten bewaard en toegankelijk gemaakt? Verklaren waarom de specificeerde werkwijze effectief en efficiënt is Als projectteam laat je in de verklaring zien dat de aanpak (faseren, stappen en activiteiten) Controleerbaar is o de activiteiten in de werkwijze vormen een compleet geheel, o de activiteiten zijn voldoende gedetailleerd om te kunnen zien wat ze voor effect zullen hebben, o de werkwijze is transparant, dat wil zeggen informatief en begrijpelijk. Vakkundig is o de beschikbare kennis goed is gemobiliseerd (kenniseffectief), o de werkwijze goed is georganiseerd en kwaliteitgericht (organisatorisch effectief), o de werkwijze efficiënt is naar tijd, (geld) en te investeren energie, o de werkwijze toelaatbaar is (voldoet aan de ARBO-eisen, is ethisch verantwoord, etc.). Logisch is o de werkwijze is logisch consistent (houdt zich aan de regels van de logica), o de werkwijze volgt de gekozen methode en wat is afgesproken, o de werkwijze houdt zich aan de geschreven, of ongeschreven, beroepscode, Valide is in de praktijkcontext o de werkwijze is functioneel in de praktijksituatie o de werkwijze is haalbaar in de praktijksituatie Het is goed om speciaal aandacht te besteden aan de effectiviteit en efficiëntie van het werken in teamverband. Projectteams zijn niet altijd effectief. Johnson and Johnson (1994) onderscheiden de volgende niveaus van effectiviteit (zie Figuur 6.7): Pseudo-groep: er is geen stimulans voor samenwerking, groepsleden helpen elkaar niet, samenwerking stoort eerder het proces en veroorzaakt misverstanden. Het groepsresultaat is minder dan de som van de potentiële resultaten van de groepsleden. Traditionele groep: groepsleden willen in principe samenwerken, maar zien niet veel voordeel in deze samenwerking. Het werk wordt gestructureerd op zo’n wijze dat de meeste activiteiten individueel kunnen worden gedaan. De leden van de groep voelen zich alleen verantwoordelijk voor hun deel van het groepswerk, maar zullen informatie delen over de aanpak van de taak. Het groepsresultaat is iets meer of iets minder dan de som van de potentiële resultaten van de groepsleden. Coöperatieve groep (team): groepsleden werken samen om een gemeenschappelijk doel te bereiken en het eigen en collectieve resultaat te maximaliseren. Sociale competenties worden ontwikkeld en toegepast. De effectiviteit van de groep en de groepsleden wordt geanalyseerd en remediërende activiteiten worden ondernomen. Het groepsresultaat is meer dan de som van de potentiële resultaten van de groepsleden. Optimaal team: dit is een coöperatieve groep waarin de leden een grote betrokkenheid hebben bij de opdracht en hun eigen persoonlijke ontwikkeling, maar ook bij de activiteiten van andere leden 57/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten van de groep en hun persoonlijke ontwikkeling. Meestal hebben de leden ook veel waardering voor het werken in de groep. Figuur 6.7 Het functioneren van een groep (Johnson & Johnson 1994) Werkwijze intern valideren met het projectteam Binnen het projectteam nagaan dat de leden de werkwijze accepteren en werkbaar vinden. 6.5.2 Specificeren competentieontwikkeling TeamOntwikkelingsPlan (TOP) opstellen De door de teamleden te ontwikkelen competenties specificeren ten opzichte van de reeds beschikbare competenties; of zijn alle competenties eigenlijk al op het goede niveau beschikbaar? De huidige competentiesituatie Het projectteam inventariseert welke expertise (competenties) reeds in het Projectteam beschikbaar zijn, en op welk niveau. Het gaat daarbij om: Praktijkcompetenties die samenhangen met de specifiek te vervullen functies Professionele competenties die samenhangen met de professionele rollen: Lerende professional Organisator Ontwerper Onderzoeker, en Adviseur 58/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Praktijk- en professionele competenties kunnen op verschillende niveaus worden waargemaakt: reproductiegericht, taakgericht, probleemgericht en situatiegericht (zie Tabel 0.2 hieronder) Praktijkrol Kenniswerkersrol Reproductie gericht Taak gericht Probleem gericht Situatie gericht Probleem (wat) Doel (wat) Afgebakend gegeven Afgebakend gegeven Afgebakend gegeven Af te bakenen Methode (hoe) Patroon (hoe) Bekend Bekend Te kiezen Te kiezen Domeinkennis Proceskennis Gegeven Gegeven Te mobiliseren Te mobiliseren Uitvoering (wie, wanneer, waar) Handelen Reproductief In te vullen In te vullen In te vullen Valide oplossing Valide resultaaat Afgebakend Af te bakenen Af te bakenen Af te bakenen Te ontwikkelen competenties Het projectteam gaat na welke expertise (competenties) er ontwikkeld kunnen zijn na afloop van het project en op welk niveau. Door vergelijking met de huidige competentiesituatie wordt bepaald welke competenties tijdens het project kunnen worden ontwikkeld. Knelpunten worden gesignaleerd, zodat deze met de Projectsponsor kunnen worden besproken. Bijvoorbeeld Praktijkcompetenties verbonden met een functie Aankomend Vastgoedontwikkelaar (m/v) U bent als vastgoedontwikkelaar in staat om conform de binnen onze organisatie gangbare methoden een projectteam te managen en het planvormingsproces te ontwerpen en te begeleiden. Uw relatie tot het projectteam is die van meewerkend voorman. Daarnaast bent u in staat om conform de binnen onze organisatie gebruikelijke methode het proces van kennisontwikkeling te managen. Taken: Managen van een projectteam conform projectmethode Begeleiden van een complex planvormingsproces conform planvormingmethode Begeleiden van kennisontwikkelingsproces conform onderzoekmethode Haalbaarheidsonderzoek uitvoeren zoals binnen onze organisatie gebruikelijk Opstellen programma van eisen conform het door ons gehanteerde format Domeinexpert (m/v) U bent als domeinexpert (met een planologische, juridische, bouwkundige of communicatie achtergrond) in staat om het project van de nodige input te voorzien om gezamenlijk tot een antwoord op de door de opdrachtgever gestelde Praktijkvraag en door het kenniscentrum, het lectoraat, gestelde Kennisvraag te komen. 59/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Taken: Het maken van verschillende stedenbouwkundige scenario’s waarin alle gewenste functies een eigen plek krijgen. Het maken van een haalbaarheidsstudie op financieel, juridisch en bouwtechnisch gebied van de verschillende scenario’s Zorgdragen voor een heldere communicatie tussen alle stakeholders Uitgebreide functiebeschrijvingen vindt u op onze website: http://www.bb.fnt.hvu.nl > courses > ‘People Planet Profit’ Bijvoorbeeld Professionele competenties verbonden met professionele rollen Aankomend Organisator Binnen uw taken van aankomend vastgoedontwikkelaar vervult u een hoofdrol als aankomend Organisator. Hier liggen extra uitdagingen die tot uiting komen in het niveau van uw rolvervulling. Hoofdrol Organisator Taken U weet middelen en bevoegdheden af te bakenen, een team samen te stellen en het werk te organiseren; u wordt beoordeeld op aanpak, uitvoering en resultaat (rolvervulling probleemgericht) U weet binnen het projectteam draagvlak te creëren voor dit project, voor de door u beoogde kwaliteit van werken en voor uw managementbijdrage; u wordt beoordeeld op uw aanpak, de uitvoering en het resultaat (rolvervulling probleemgericht) U weet uw activiteiten en de projectactiviteiten te organiseren en een Plan van Aanpak te ontwikkelen; u wordt beoordeeld op aanpak, uitvoering en resultaat (rolvervulling taakgericht) U weet de kwaliteit van het project, de bijdrage van teamleden aan het project en hun competentieontwikkeling te borgen; u wordt beoordeeld op aanpak, uitvoering en resultaat (rolvervulling taakgericht) Aankomend Onderzoeker Binnen uw taken van aankomend vastgoedontwikkelaar vervult u de rol van aankomend Onderzoeker. Rol Aankomend Onderzoeker Taken De kennis mobiliseren die ondersteunend is aan de taken van vastgoedontwikkelaar; u wordt beoordeeld op de volledigheid van de mobilisatie, de presentatie, de bruikbaarheid en de deugdelijkheid van de gevonden kennis (rolvervulling taakgericht) 60/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Daarnaast weet u op de gebruikelijke wijze en op basis van beschikbare rolpatronen de kennis te mobiliseren die ondersteunend is bij de beantwoording van de gestelde kennisvraag; u wordt beoordeeld op de uitvoering, de presentatie, bruikbaarheid, deugdelijkheid en diepgang van de gemobiliseerde kennis (rolvervulling taakgericht) U ontwikkelt op gebruikelijke wijze en op basis van beschikbare rolpatronen kennis rond ‘lessons learned’ van het project, zowel ten aanzien van de taken van vastgoedontwikkelaar als ten aanzien van de werkwijze en resultaten in het uitgevoerde project ; u wordt beoordeeld op de uitvoering, de presentatie, de bruikbaarheid, de deugdelijkheid en de diepgang van ‘lessons learned’ (rolvervulling groen) Daarnaast weet u op de gebruikelijke wijze en op basis van beschikbare rolpatronen gevraagde nieuwe kennis te ontwikkelen; u wordt beoordeeld op de uitvoering, de presentatie, bruikbaarheid, deugdelijkheid en diepgang van de ontwikkeld kennis (rolvervulling taakgericht) U weet gemobiliseerde kennis toe te passen in uw werk; u wordt beoordeeld op de wijze van toepassen en de kwaliteitsverhoging als resultaat van de toepassing (rolvervulling oranje) U weet ontwikkelde kennis toe te passen in de gegeven praktijksituatie; u wordt beoordeeld op de wijze van toepassen en het resultaat van de toepassing (rolvervulling probleemgericht) U beoordeelt de toepassing van de gemobiliseerde en ontwikkelde kennis volgens de bij ons gebruikelijke standaard; u wordt beoordeeld op toepassing van de standaard en de kwaliteit van de beoordeling (rolvervulling taakgericht) Te ontwikkelen competenties toewijzen Na de inventarisatie van welke competenties binnen het project kunnen worden ontwikkeld worden deze toegewezen aan de teamleden. Voor een belangrijk deel is deze toewijzing een formaliteit omdat de competenties samenhangen met de functie die het projectlid in het project vervult. De overige competenties worden rekening houdend met de reeds beschikbare expertise en de ambities, toegewezen aan projectteamleden. Verklaren waarom het TOP effectief is Vanuit de probleemstelling, probleemaanpak en projectorganisatie verklaren hoe deze competenties ontwikkeld zullen worden. Dit betekent dat het projectteam laat zien dat de toewijzing valide is o functioneel is o begrijpelijk is o haalbaar is betrouwbaar is adequaat is, dat wil zeggen precies is controleerbaar is verankerd is in de kennis over de praktijk relevant is, dat wil zeggen de moeite waard is consistent is in de score op de criteria Intern valideren met het projectteam De leden van het projectteam valideren met elkaar dat deze competentieontwikkeling wenselijk en haalbaar is. 61/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Valideren dat de te ontwikkelen competenties binnen de competentievraag valt De concrete invulling van de competentievraag moet met de projectsponsor gevalideerd worden. Als het om een ingewikkelde situatie gaat, waarin niet duidelijk is welke positie de projectsponsor zal kiezen, is het aan te bevelen om deze validatie zo spoedig mogelijk te doen. Wanneer de concrete invulling van de competentievraag door de projectsponsor als voor de hand liggend zal worden ervaren, kan met validatie gewacht worden tot de validatie van het gehele Plan van Aanpak (6.8). 62/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 6.6 Kwaliteitsborging organiseren 6.6.1 Risicomanagement Vanuit de gemobiliseerde kennis de risicofactoren specificeren, evenals de wijze waarop deze gemanaged zullen worden. Bos & Harting (1998; p.p. 306-318) onderscheiden drie stappen: Gevoeligheidsanalyse Inventariseren op welke gebieden het project het meest kwetsbaar is. Situatie en omstandigheden rond het project zijn steeds verschillend. In het ene project kan de praktijksituatie instabiel zijn door veranderingen in personele bezetting of herijking van prioriteiten. Externe omstandigheden (een verhuizing, een stroomstoring) kunnen risico’s met zich meebrengen. Ook de samenstelling van het projectteam kan risico’s met zich meebrengen. Het projectteam inventariseert de risico’s en ordent deze naar prioriteit. Algemene risicoanalyse Per gesignaleerd risico worden specifieke ‘onplezierige gebeurtenissen’ geïnventariseerd. Vervolgens wordt een beredeneerde schatting gemaakt van de kans dat de gebeurtenis optreedt, het effect dat de gebeurtenis heeft en de responstijd (de hoeveelheid tijd die het duurt voordat op een gebeurtenis gereageerd kan worden). De gebeurtenissen worden gerangschikt in volgorde van de risicowaarde (kans x effect x responstijd). Risicobeheersing Stoppen met het project als de kans op bepaalde gebeurtenissen bijna 1 is (dan zijn de risico’s onbeheersbaar). Preventie: maatregelen nemen die de kans op een onplezierige gebeurtenis beperken. Verlengen responstijd, bijvoorbeeld door je voelhoorns uit te steken in de praktijksituatie. Aanpassen: bijvoorbeeld marges inbouwen in planning en urenbudget. Beperken effecten: bijvoorbeeld, zorgen dat de interne informatievoorziening binnen het projectteam zo goed is dat een nieuw teamlid snel kan worden ingewerkt. Zorgen dat er vlak voor een deadline twee printers beschikbaar zijn om resultaten uit te printen. Risico’s ombuigen: bepaalde risico’s uitsluiten in het Plan van Aanpak. Het heeft zin om tijdens voortgangsbijeenkomsten de lijst van risicovolle gebeurtenissen na te lopen en te kijken of de risicoanalyse noch geldig en de risicobeheersing voldoende is. Sommige risico’s nemen bijvoorbeeld toe in zwaarte als deadlines naderen, omdat de responstijd buiten de deadline terecht komt; het risico is dan niet meer op te vangen. Verklaren waarom deze risicobeheersing in deze situatie gekozen is. Intern valideren met het projectteam dat deze risicobeheersing wenselijk en werkbaar is 6.6.2 Kwaliteitscriteria specificeren Projectwerk in de praktijk is duidelijk gereguleerd en geregeld om tot goede resultaten te komen. De procedures in de projectmethode hebben geen bureaucratische achtergrond, maar zijn specifiek gericht op bevordering van een kwalitatief goed teamproces en een goed resultaat. Authentieke projectmethoden hebben dit kenmerk: je kunt duidelijk zien dat de procedures en afspraken ten dienste staan van het resultaat. Bij de uitvoering van een project wordt de kwaliteit bepaald door drie elementen: 1. Kwaliteit van werkwijze en voortgang 2. Kwaliteit professionele rolvervulling 3. Kwaliteit resultaat het praktijkresultaat het kennisresultaat het competentieresultaat 63/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Voor de kwaliteit van elk van deze elementen moeten kwaliteitscriteria worden opgesteld die operationeel inhoud geven aan het begrip kwaliteit. Operationeel betekent dat ze zo zijn geformuleerd dat je weet waar verbeteringen mogelijk zijn als je als aan een kwaliteitscriterium niet wordt voldaan. Bovendien moeten de criteria ‘SMAI’ *) zijn: Simpel en specifiek Meetbaar, waar te nemen, constateerbaar Acceptabel en activerend, geformuleerd in de vorm van activiteiten Inspirerend tot verbetering *) vergelijk: SMART = Specific, Measurable, Acceptable, Realistic, Time bound Kwaliteitscriteria worden afgeleid uit kwaliteitskenmerken die uit de beschikbare literatuur zijn verzameld. Kwaliteitskenmerken voor een werkwijze Controleerbaar o de activiteiten in de werkwijze vormen een compleet geheel, o de activiteiten zijn voldoende gedetailleerd om te kunnen zien wat ze voor effect zullen hebben, o de werkwijze is transparant, dat wil zeggen informatief en begrijpelijk. Vakkundig o de beschikbare kennis goed is gemobiliseerd (kenniseffectief), o de werkwijze goed is georganiseerd en kwaliteitgericht (organisatorisch effectief), o de werkwijze efficiënt is naar tijd, (geld) en te investeren energie, o de werkwijze toelaatbaar is (voldoet aan de ARBO-eisen, is ethisch verantwoord, etc.). Logisch o de werkwijze is logisch consistent (houdt zich aan de regels van de logica), o de werkwijze volgt de gekozen methode en wat is afgesproken, o de werkwijze houdt zich aan de geschreven, of ongeschreven, beroepscode, Valide is in de context o de werkwijze is functioneel in de contextsituatie o de werkwijze is haalbaar in de contextsituatie Voorbeeld Uitwerking kwaliteitskenmerken voor de werkwijze Criteria voor kwaliteit van de werkwijze Organisatie Generieke criteria Consistent en precies Voer de taken volgends de standaard werkwijze uit. Maak de taakuitvoering transparant (laat zien wat je doet). Effectief Werk resultaatgericht, niet activiteitgericht. Uitwerking voor PeoplePlanetProfit Faculteit Natuur en Techniek Hogeschool Utrecht Leg de taakuitvoering vast in je Plan van Aanpak. 64/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Kwaliteit Tijd en geld Informatie Communicatie Laat zien dat je daadwerkelijk de gespecificeerde resultaten oplevert. Samenwerkend Werk resultaatgericht, niet activiteitgericht samen met anderen. Haal gezamenlijke belangen naar voren. Baken de taken zodanig af dat de samenwerking effectief is. Risicobeheersend Breng vooraf de risico’s in kaart, volledig en overtuigend. Formuleer vooraf hoe het risico effectief kan worden beheerst. Regel vooraf incident-management. Laat zien hoe je de risico’s hebt beheerst. Pro-actief Ga steeds na of de taakuitvoering (nog) haalbaar is. Zo gauw onhaalbaarheid waarschijnlijk is, trek je aan de bel. Kwaliteitsborgend Regel vooraf management van verbeteracties. Verifieer kwaliteit conform de gegeven standaarden. Identificeer verbeteracties. Laat zien dat verbeteracties adequaat zijn afgehandeld. Neem waar nodig initiatief voor verbetering van de standaarden. Efficiënt Lever de gevraagde resultaten op binnen de overeengekomen urenbegroting en aangegeven doorlooptijd. Informatieborgend Lever de informatie aan die nodig is om je taakuitvoering te volgen. Lever de resultaten adequaat en veilig op. Communicatief Als je denkt dat mogelijk onjuiste schatting van de benodigde tijd een belangrijk risico is kun je bijvoorbeeld het op te leveren resultaat opdelen in een kern die zeker klaar moet zijn en details die, zo nodig, minder ver uitgewerkt kunnen blijven. Als je advies nodig hebt van een vakdocent of externe expert, blijf dan niet zelf tobben maar regel het. Gebruik deze lijst met metacriteria, aangevuld met specifieke criteria voor uitvoering, inhoud en vorm van een haalbaarheidsonderzoek als kwaliteitscriteria. Plan validatie- en reviewbijeenkomsten en zorg dat hetgeen je daarbij nodig hebt (niet alleen een resultaat om te reviewen, maar ook de vragen daarover die je relevant acht en de criteria waartegen wordt gereviewd) op tijd beschikbaar is. Maak korte verslagen van jullie voortgangsbesprekingen en stel die beschikbaar aan de begeleidende docent volgens afspraak. Laat geen gevoelige informatie slingeren. Maak gebruik van de elektronische opslag van gedeelde documenten in BbCS Voer het communicatieplan (dat je o.b.v. 65/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Wees goed bereikbaar; reageer snel en adequaat. Neem initiatief om resultaten en bevindingen te delen. Gebruik van communicatie tools Gebruik de beschikbare communicatietools adequaat. Validiteit Validerend Ga na dat de activiteiten in de gegeven context effectief zijn en tot geldige resultaten zullen leiden. de krachtenveldanalyse hebt gemaakt en in je PvA hebt opgenomen), uit. Zorg dat jullie gegevens (e-mail, telefoonnummer) in Bb beschikbaar zijn en actueel. Zorg dat documenten waaraan je werkt en informatie over (de voortgang van) het project steeds voor alle projectmedewerkers beschikbaar zijn; zet digitale documenten in Bb. Stel informatie over de voortgang beschikbaar aan je begeleiders via Bb. Houd m.b.t. de inhoud van scenario’s contact met de stakeholders. Vraag zo nodig m.b.t. de methoden en concepten die je gebruikt advies aan vakdocenten en externe experts. Kwaliteitskenmerken voor resultaten valide o functioneel is o begrijpelijk is o haalbaar is betrouwbaar adequaat, dat wil zeggen precies controleerbaar verankerd in de kennis over de praktijk relevant, dat wil zeggen de moeite waard consistent in de score op de criteria Voorbeeld Uitwerking kwaliteitskenmerken schriftelijke rapportages Criteria voor de kwaliteit een resultaat A. Kwaliteitseisen aan de vorm Eisen vanuit het Generieke criteria professionele domein Aan de vorm van de resultaten worden eisen gesteld vanuit het professionele domein Uitwerking voor PeoplePlanetProfit Faculteit Natuur en Techniek Hogeschool Utrecht standaard voor een haalbaaheidsonderzoek Zie inhoudsopgave Grontmij OEEI Twijnstra & Gudde 66/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten criteria voor schriftelijke rapportages Doel en status van Geef duidelijk aan in welk kader en de tekst zijn welk stadium van besluitvorming de duidelijk tekst fungeert. Wat wil je met het stuk bereiken, welke reactie wil je van de lezer: is het stuk ter kennisname of ter discussie, bevat het stuk voorstellen of afspraken? Hier wil je bereiken dat wordt besloten tot realisering van één van de voorgestelde scenario’s (of een combinatie van elementen uit meerdere van die scenario’s). Het is dus een advies, gericht op implementatie. Zie ook: Nederhoed, P., Helder Rapporteren, Bohn Stafleu Van Loghum, Houten, 2004 Er is een samenvatting die de hoofdvragen met antwoorden bevat en die los van de tekst begrepen kan worden Onderdelen en opbouw komen overeen met de gebruikelijke structuur van dit soort teksten in de organisatie De structuur is expliciet gemaakt in tussenkoppen, verbindingszinnen, typografie, etc. Spelling en grammatica zijn correct Lay-out is verzorgd Zorg dat de samenvatting een snelle oriëntatie op de hoofdlijn geeft. Sluit aan bij de praktijk van rapporteren die in deze organisatie gebruikelijk is. Volg waar mogelijk voorbeelden van bestaande teksten in deze organisatie, wat betreft informatieselectie en opbouw. Gebruik de tips en vuistregels die je bij Communicatietechniek hebt gehad. Zorg dat de lezer gemakkelijk de hoofdlijn kan volgen en snel specifieke onderdelen kan vinden. Leg heldere verbanden tussen de onderdelen. Markeer hoofdzaken (o.a. conclusies, kerngegevens) op duidelijke wijze en vat ze bondig, maar volledig samen Zie ook de beoordelingscriteria voor de aangeklede inhoudsopgave PPP in Blackboard Gebruik de spellingscorrector van een tekstverwerkingsprogramma en verwijder alle daarmee op te sporen fouten. Ga na dat zinsconstructies correct zijn m.b.v. de grammaticacontrole. Gebruik een consequente paginaindeling, typografie en documentopbouw die helder is en (zo mogelijk) conform de huisstijl. IGO verwijst steeds naar Nederhoed, P, Helder Rapporteren, Bohn Stafleu Van Loghum, Houten, 2004 www.bb.fnt.hvu.nl > people planet profit > course information > beoordelingscriteria De meeste PPP-projectgroepen ontwerpen een eigen huisstijl. 67/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Voorbeeld Uitwerking professionele kwaliteitskenmerken voor inhoud Startnotitie B. Kwaliteitseisen aan de inhoud van een startnotitie Eisen vanuit het Generieke criteria professionele domein Taakstelling/opgave Afbakening aandachtsgebied Inventarisatie van wensen en belangen Uitgangspunten (fysische) duurzaamheidaspecten Scenario’s opstellen Bouwkundige uitwerking van de scenario’s Onderhandelingsresultaat Markt-/klantonderzoek Uitwerking voor PeoplePlanetProfit Faculteit Natuur en Techniek Hogeschool Utrecht De startnotitie beschrijft een eenduidig doel waaraan de betrokken partijen gaan werken en een drietal scenario’s om dat te bereiken door extra commerciële functies in te brengen. De startnotitie geeft aan welke partijen bij de beleidsvorming betrokken worden en welke aspecten (functioneel, technisch, juridisch, financieel) zijn “meegenomen” in het onderzoek. De startnotitie geeft aan wat de (fysieke) grenzen zijn van het plangebied. Er is een duidelijke inventarisatie van belangen van betrokkenen met het oog op ruimtelijke, maatschappelijke, financiële en politieke haalbaarheid en draagvlak. Zie voor krachtenveldanalyse Twijnstra & Gudde Er is duidelijk aangegeven welke opties voor duurzame ontwikkeling in dit stadium open staan en hoe die bij realisering van de scenario’s kunnen worden uitgewerkt. Er zijn alternatieven en varianten van modellen (maatschappelijk, ruimtelijk, financieel, technisch) bepaald op basis van globale gegevens. De verschillende scenario’s worden op technische haalbaarheid getoetst. Hiertoe dienen de alternatieven bouwkundig te worden uitgewerkt volgens de principes van de Stichting Bouwresearch (SBR). Daarnaast dienen de duurzaamheidsaspecten zoals die in het Nationaal Pakket Duurzaam bouwen (NPDB) te vinden zijn. Gemeente, bewonersvereniging en projectontwikkelaars onderschrijven de startnotitie. Er is onderzocht welke marktpartijen in aanmerking komen voor de extra 68/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Risicoanalyse commerciële functies (bijvoorbeeld medegebruik van de multifunctionele ruimte). De maatschappelijke, economische, financiële en technische risico’s van de scenario’s zijn in beeld gebracht. Voorbeeld Uitwerking kwaliteitscriteria voor een advies Criteria voor een advies De inhoud van de op te leveren resultaten is hier prescriptief, dat wil zeggen dat de inhoud wordt gebruikt om vervolgactiviteiten te (kunnen) ontplooien. Wanneer zulk soort resultaten in een document worden gepresenteerd zijn er de volgende kwaliteitscriteria mee verbonden: Hoofdlijn Doelgericht en Generieke criteria Uitwerking voor PeoplePlanetProfit functioneel Faculteit Natuur en Techniek Hogeschool Utrecht Richt de inhoud op gebruik van de Neem de Gemeente mee in je ontwikkelde oplossing. Laat daarom de gedachtegang: een keuze voor scenario stappen in de hoofdlijn van de inhoud X heeft die-en-die effecten en om die te aansluiten bij het beoogde gebruik. realiseren moet er dat-en-dat gebeuren Schrijf de inhoud in termen van gebruik. Relevant Zorg dat het de beschreven oplossing Blijf dicht bij de hoofdvraag: één of meer nuttig is voor de gebruikers die het haalbare scenario’s opstellen waarin de gaan toepassen. Ga na dat zonder wensen van Gemeente, ontwikkelaars déze inhoud toepassing niet goed en gebruikers (bewoners) allemaal mogelijk zou zijn. Zorg dat alle zoveel mogelijk kunnen worden informatie die relevant is voor gerealiseerd. toepassing, aanwezig is, maar niet meer dan dat. Neem geen overbodige onderdelen op. Consistent en Geef de hoofdlijn van de inhoud Bijvoorbeeld: logisch duidelijk weer in stappen, keuzes en - bestaande situatie vooronderstellingen bij de keuzes. Zorg - wensen betrokkenen dat de stappen elkaar aanvullen en dat - stand van zaken planvorming ze op elkaar voortbouwen naar een - criteria voor vergelijking van totaal. Ga na dat de stappen, keuzes en scenario’s vooronderstellingen logisch consistent - beschrijving van scenario’s zijn en logisch op elkaar aansluiten. - onderzoeksmethode (welke aspecten zijn onderzocht en hoe) - resultaten op hoofdlijnen (functioneel, technisch, juridisch, financieel; gedetailleerde resultaten in bijlage) - vergelijking haalbaarheid scenario’s - conclusies en aanbevelingen voor 69/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten implementatie Precies Inhoud Verankerd Informatief Controleerbaar Valide Zorg dat in de hoofdlijn alle nodige stappen, keuzes en vooronderstellingen zijn weergegeven. En dat alle gegevens en overwegingen die de keuzes,conclusies of adviezen onderbouwen, zijn vermeld. Zorg dat de inhoud is verankerd in het betreffende kennisgebied en aansluit bij de gebruikscontext van de oplossing. Gebruik geen niet-passende theoretische indelingen of procesbeschrijvingen. Maak een correct en op de gebruiker afgestemd gebruik van vaktermen en gebruik deze volgens de gangbare definities. Licht vaktermen toe in het geval de tekst ook voor een breder publiek dan vakgenoten bedoeld is. Schrijf niet vanuit wat jíj weet en jíj wilt vertellen, maar vanuit wat de lezer moet weten om een antwoord te krijgen op begrijpelijke hoofdvragen, die je expliciet hebt vermeld. Maak zinnen en tekst die in één keer lezen begrijpelijk zijn voor de lezer. Pas je toon aan bij het taalgebruik in de organisatie en zorg dat je niet van de inhoud afleidt door te informeel, te geladen of niet neutraal genoeg taalgebruik, of teveel eigen en persoonlijke opinies van jou als schrijver. Zorg dat illustraties, schema’s en grafieken functioneel zijn en de duidelijkheid of de aantrekkelijkheid van de inhoud vergroten. Gebruik daarom illustraties voor het bieden van overzicht, maak ze gemakkelijk afleesbaar, licht ze goed toe en beperk ze tot essenties. Laat zien dat de beschreven oplossing controleerbaar geldig is in de huidige context. Laat dit zien vanuit inhoudelijke argumenten en vanuit raadpleging van stakeholders in en mogelijk gebruikers van de oplossing Gebruik een erkende methode voor financiële berekeningen. X Wigmans, G., De Grondexploitatie, Publikatieburo Bouwkunde, Delft, 2002 Afstudeerscriptie Bianca Huijsers (mediatheek) Maak gebruik van de vuistregels voor haalbaarheidsonderzoek Zie materiaal Grontmij, OEEI, Twijnstra & Gudde Gebruik recente kengetallen, onderzoeksgegevens en voorbeelden Zorg dat de lezer zich een beeld kan vormen van de ruimtelijke situatie: kaart, ligging in de stad, overzichtsfoto van het gebied e.d. Denk bij kaarten aan de gebruikelijke professionele kwaliteitseiseisen: legenda, schaal, noordpijl, kleurconventies e.d. Zorg dat je niet al bij de omschrijving van de scenario’s en voorkeur uitspreekt door taalgebruik. Zie ook: Nederhoed, P, Helder Rapporteren, Bohn Stafleu Van Loghum, Houten, 2004 Laat bijvoorbeeld zien dat er daadwerkelijk belangstelling bestaat bij bedrijven die je in aanmerking vindt komen voor vestiging in het gebied en geef aan wat voor meerwaarde dat voor hen heeft. Laat zien dat de oplossing voldoet aan de door jou vooraf opgestelde 70/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten beoordelingscrietria. Betrouwbaar Laat zien dat de oplossing op een controleerbare en binnen de professionele praktijk geaccepteerde wijze tot stand is gekomen. Maak duidelijk dat er hierdoor weinig risico is van een onjuiste of ondermaatse uitkomst van de oplossing. Vermeld en beargumenteer al je aannamen, zo nodig in bijlagen. Neem de financiële berekeningen die je hebt gedaan op in bijlagen. Waar je niet zeker bent van een aanname in een berekening kun je een gevoeligheidsanalyse uitvoeren waarmee je de invloed van de onzekerheid in die aanname op de uitkomst van de berekening vaststelt. Vermeld alle bronnen waarop je je baseert. Verklaren waarom juist deze criteria in deze situatie van toepassing zijn Intern valideren met het projectteam dat toepassing van deze criteria van belang geacht wordt en begrepen wordt. 71/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 6.7 Plan van Aanpak In ontwerpprojecten is van tevoren meestal slechts globaal bekend wat het probleem is en welk resultaat er moet worden opgeleverd. Ook is vaak niet zonder meer duidelijk hoe dat resultaat gerealiseerd gaat worden. Daarom is er een uitgebreid vooronderzoek nodig in de fase project ontwikkelen. De resultaten van het vooronderzoek worden opgenomen in een Plan van Aanpak dat duidelijk maakt wat het aan te pakken probleem is (en niet is), wat het te realiseren resultaat is en hoe het projectteam denkt het resultaat te bereiken en welke tussenresultaten het daarbij zal opleveren. Verder bevat het Plan van Aanpak een activiteitenplanning, een urenbegroting en maakt het duidelijk hoe de kwaliteit geborgd zal worden. Soms moet een Plan van Aanpak daarna nog verder in details worden uitgewerkt. Het resultaat van deze uitwerking is een Projectplan. Het projectplan gaat meer in detail in op de te volgen werkwijze, de kwaliteitsborging en de projectorganisatie. Is het project niet al te omvangrijk, dan is een detailuitwerking niet nodig en kan volstaan worden met een Plan van Aanpak. In het Plan van Aanpak worden dus de resultaten (Uitgangspositie, Probleemstelling, Probleemaanpak, Projectorganisatie en Kwaliteitsborging) van de voorgaande stappen samengebracht. Het Plan van Aanpak helpt het projectteam om greep te krijgen op: Het managen van de verwachtingen van de betrokkenen (opdrachtgever(s), gebruikers, projectteam, projectsponsor) o Duidelijkheid over wat er komen gaat o Duidelijk over welke bijdragen betrokken leveren o Vertrouwen in het proces en de afloop De complexiteit van de probleemsituatie met ingewikkelde vragen, veel belangen, veel activiteiten en veel betrokkenen o Duidelijkheid over te beantwoorden vragen o Duidelijkheid over de resultaten en de consequenties van het project o Duidelijkheid over te besteden tijd De kwaliteit van proces en resultaten 6.7.1 Inhoudsopgave van het Plan van Aanpak I. Uitgangspositie (Resultaat van 6.2) Aanleiding voor het project De gestelde praktijkvraag Hoe de praktijkvraag tot stand is gekomen De kennisbasis II. Probleemstelling Praktijkprobleemstelling (resultaat van 6.3) Een ‘Rich Picture’ van de huidige praktijksituatie waarin de ‘zaak’ en de ‘omgeving’ worden belicht Positieve en negatieve punten van de huidige praktijksituatie De gewenste praktijksituatie met behouden positieve punten en opgeheven negatieve punten De verklaring van de gewenste praktijksituatie Kennisprobleemstelling (resultaat van 6.4) De huidige kennissituatie (gemobiliseerde kennis) De gewenste kennissituatie Te ontwikkelen kennis De verklaring waarom deze kennis in dit project ontwikkeld kan worden 72/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Het competentieprobleem (resultaat van 6.5) De huidige competentiesituatie met de daarin beschikbare expertise De gewenste competentiesituatie Te ontwikkelen competenties De verklaring waarom deze competenties in het project ontwikkeld kunnen worden III. Probleemaanpak in fasen (resultaat van 6.4) Aanpak praktijkprobleem Aanpak kennisprobleem Aanpak competentieontwikkeling Fasering Fasen, stappen, tussenresultaten, kwaliteitsborging in de tijd De randvoorwaarden IV. Activiteitenplan (resultaat van 6.5) Uitsplitsing van stappen in activiteiten Voortgangsbijeenkomsten, validatie- en reviewsessies, opleveringssessies Planning van activiteiten en bijeenkomsten in de tijd V. Tijdbeheersing (resultaat van 6.5) Urenbegroting en urenregistratie VI. Kwaliteitsbeheersing (resultaat van 6.6) Risicobeheersing Specificatie van kwaliteitscriteria Verbeterprocedure, change management VII. Projectorganisatie (resultaat van 6.5) Projectorganisatie Interne projectorganisatie Rollen, taken en verantwoordelijkheden in projectteam Verdeling over leden projectteam Overlegmomenten en communicatie Externe projectorganisatie Stakeholders en projectsponsor Gebruikers van op te leveren resultaten VIII. Informatiebeheersing (resultaat van 6.5) Projectsecretaris Projectlogboek Projectdossier Formele communicatie binnen het project IX. Communicatie Communicatie met stakeholders, projectsponsor en gebruikers X. Lessons learned 6.7.2 Achtergrond literatuur Bos & Harting (1998; p. 3-25/3-40) gebruiken een vergelijkbare indeling van het Plan van Aanpak en geven goede raad voor de invulling van de verschillende elementen. I. II. III. IV. V. Context Projectdefinitie (p. 4-41/4-65) Fasering en activiteitenplan (p. 5-66/5-80) Tijdbeheersing (p. 6-81/6-90 & 7-91/7-111)) Geldbeheersing (p. 8-112/8-128) 73/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten VI. VII. VIII. IX. X. Kwaliteitsbeheersing (p. 9-129/9-145 Projectorganisatie (p. 10-146/10-158) Informatiebeheersing (p. 11-159/11-173) Communicatie (p. 12-174/12-194) Evaluatie 74/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 6.8 Valideren Plan van Aanpak Het Plan van Aanpak moet natuurlijk uitzicht geven op een goed resultaat. Daarom wordt het eerst gevalideerd door de opdrachtgever. Dat wil zeggen dat hij beziet of hij het eens is met de probleemstelling en of de voorgestelde aanpak in zijn ogen een goed resultaat kan opleveren. Het team voert alle handelingen om tot de validatie te komen zelfstandig uit: Zorgen dat het Plan van Aanpak tijdig gereed is Het Plan van Aanpak ter beschikking stellen van de opdrachtgever De validatiebijeenkomst plannen en organiseren Het resultaat vastleggen voor review in de volgende stap. Waarom valideren? Stel, een bedrijf of organisatie heeft een probleem dat moet worden opgelost. Dan zal een oplossing moeten worden ontworpen die effectief is in de specifieke context van dat bedrijf of die organisatie. Dat wil zeggen dat mensen in dat bedrijf of die organisatie met de oplossing uit de voeten moeten kunnen. Vroeger was het gebruikelijk dat experts een oplossing voor het probleem bedachten die ‘over de schutting werd gegooid’. Deze aanpak is weinig succesvol gebleken. Tegenwoordig worden de ‘gebruikers’ van de te ontwikkelen oplossing nauw bij probleemanalyse en daarna bij ontwerp, ontwikkeling en implementatie van de oplossing betrokken, zodat er goede garantie bestaat dat de oplossing ook echt werkt. ‘Valideren’ is het proces waarmee wordt nagegaan dat daadwerkelijk aan de behoefte van de omgeving tegemoet wordt gekomen. Zie voor uitvoering van validatie het desbetreffende hoofdstuk in het Handboek Ontwerpprojecten. 75/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 6.9 Start-Up Review Als de plannen zijn goedgekeurd is het tijd om kritisch stil te staan bij de planvorming. Hier noemen we dat review. In een review wordt iets tegen het licht gehouden om te zien of het aan van te voren geformuleerde kwaliteitscriteria voldoet. Een review is toekomst georiënteerd, want de belangrijkste vraag is: hoe kunnen wij zorgen dat dit ‘iets’ nog beter wordt. In het projectonderwijs waarover we het hier hebben levert een review inzichten op over verloop en resultaten van het oplossingsproces. Eerst wordt vastgesteld wat de feiten zijn (wat is er feitelijk gebeurd, wat zijn de feitelijke resultaten). Daarna worden de feiten getoetst aan kwaliteitscriteria. Ten slotte wordt nagegaan hoe verbeteringen kunnen worden bereikt. Dat betekent dat de volgende vragen moeten worden beantwoord: Voldoet het Plan van Aanpak aan de daaraan te stellen eisen, zoals: o Zijn de praktijkvraag, de kennisvraag en de competentieontwikkeling duidelijk? o Zijn de probleemstelling en de werkwijze duidelijk (precies) beschreven en is er een beeld van de geplande oplossing dat SMARTI is geformuleerd? o Is de probleemstelling relevant? o Is de werkwijze functioneel en verankerd in de bestaande vakkennis? o Is het Plan van Aanpak logisch en consistent? o Is het Plan van Aanpak controleerbaar, bijvoorbeeld doordat alle aannamen zijn beschreven en verantwoord? o Is het plan haalbaar met de beschikbare capaciteit en hulpmiddelen en binnen de beschikbare tijd? Wat ging in deze fase van het project meteen goed en wat zouden we in een volgend geval anders en beter doen? Hoe nemen we de verbetersuggesties op in de plannen? Zie voor uitvoering van reviews het desbetreffende hoofdstuk in het Handboek op de website. 76/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 6.10 Flankerend workshops <Nader in te vullen> 77/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 7 Fase 3: Ontwerpen en ontwikkelen De oplossing wordt ontworpen, ontwikkeld en geïmplementeerd in een cyclisch proces dat uit een aantal stappen bestaat (zie figuur 7.1). Het Plan van Aanpak ‘drijft’ de gang van zaken in deze fase, want in het Plan van Aanpak staan de activiteiten geïnventariseerd die worden ondernomen, inclusief de planning. Met ontwerpen, ontwikkelen en implementeren zijn competentieontwikkeling en kennisontwikkeling verbonden zoals gespecificeerd in het Plan van Aanpak. Praktijk vraag Praktijk oplossing Competentieagenda Competentieontwikkeling Ontwikkelde competentie Oplossing Ontwikkelen Oplossing ontwerpen Oplossing Implementeren Oplossing Projectontwikkelen Conceptueel ontwerp Voorbereiden Probleemstelling Diagnose Projectorganisatie Vraag Vraagontwikkelen Oplossing opleveren Kennis en competentie opleveren Oplossing verbeteren Contextkennis Kennisagenda Methoden Oplossingen Ontwikkelde kennis Kennisontwikkeling Figuur 7.1. Ontwerpen, ontwikkelen en implementeren van oplossingen. 7.1 Het functioneren van het projectteam Tijdens het project kunnen zich problemen voordoen bij het uitvoeren van activiteiten en het samenwerken in het team. Scholtes, Joiner & Streibel (2002; p. 4-1/4-56) geven technieken en tips die teams helpen in hun functioneren: Afdeling A: Technieken voor teams I. Richtlijnen voor een goede vergadering (4-2/4-10) II. Richtlijnen voor een effectieve discussie (4-11/4-10) III. Richtlijnen voor effectieve besluitvorming (4-20/4-25) IV. Richtlijnen voor effectieve verslaglegging (4-26/4-28) V. Richtlijnen voor planning (4-20/4-32) Afdeling B: De goede uitvoering I. De eerste teamvergadering (4-33/4-45) 78/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten II. III. IV. Reguliere teamvergaderingen (4-46/4-47) Voortgangsbesprekingen (4-48/4-49) De afsluiting van een project (4-49/4-55) Ook in Projectmanagement (Roel Grit 2005) is praktisch advies te vinden: I. Vergaderen (hoofdstuk 6) Voorbereiden De agenda Tijdens de vergadering Na de vergadering II. Interview afnemen (hoofdstuk 7) Typen interviews De drie fasen van een interview III. Een brief schrijven (hoofdstuk 8) Voorbereiden Schrijven IV. Een rapport schrijven (hoofdstuk 9) Voorbereiden Uitvoering Indeling van het rapport Hoofdtekst van het rapport V. Een presentatie houden (hoofdstuk 10) Organisatie en inhoud Gebruik overhead projector of beamer Opbouw Tijdens de presentatie VI. Een management samenvatting maken (hoofdstuk 11) Met de samenvatting van het projectresultaat, verantwoording van de gebruikte middelen, conclusies en aanbevelingen van het onderzoek, door het management te nemen beslissingen en een planning voor het vervolg. Appendices 1. Risicoanalyse Ook besteden Scholtes, Joiner & Streibel (2002; p. 6-1/6-32) aandacht aan het aspect van samenwerken: I. Verborgen gedachten achter teamdynamiek (6-1/6-3) II. Groeifasen van een team (6-4/6-7) III. Hoogte- en dieptepunten (6-8/6-9) IV. Recept voor een succesvol team( (6-10/6-22) V. Constructieve feedback (6-23/6-31) Ook aan het omgaan met onvermijdelijke, leerzame conflicten besteden Scholtes, Joiner & Streibel aandacht (2002; p. 7-1/7-24): I. De waarde van een conflict (7-1/7-2) II. Begrijp uw reacties (7-2/7-6) III. Managen van groepsproblemen (7-7/7-12) IV. Tien veel voorkomende problemen (7-13/7-23) Evenals Bos & Harting (1998; p. 21-343/21-359): Weerstanden, conflicten en tegenslagen, het voorkomen van machteloosheid en slachtoffergedrag: 1. Weerstanden (21-345/21-351) 79/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 2. 3. Conflicten (21-351/21-354) Tegenslagen (21-354/21-359) 7.2 Oplossing ontwerpen De eerste stap in het ontwikkelen van de oplossing is het vormen van een idee (of concept) van hoe de uiteindelijke oplossing eruit zal gaan zien. Daarbij zal het projectteam gebruik maken van al bekende en nog onbekende concepten. Juist in dit stadium staan studenten er dan ook niet alleen voor: (vak)docenten zijn beschikbaar om de weg te wijzen in relevante bronnen (lesmateriaal, voorbeelden, databases etc.) en te helpen om daaruit de kennis te destilleren die nodig is voor het conceptuele ontwerp. De tweede stap is het concreet maken van het conceptuele ontwerp. Vaak is de oplossing daarmee al ‘klaar’, maar het kan evengoed voorkomen dat er een aparte implementatiestap nodig is. In het schema is het eventueel samenvallen van de beide stappen weergegeven met de rechthoek die beide cirkels verbindt. Tijdens regelmatig werkoverleg bespreken de teamleden de voortgang en de persoonlijke rolvervulling van de teamleden. Hoe weet je nu of het resultaat ‘goed’ is? En of het projectteam ‘goed’ heeft gewerkt? Daar zijn diverse maatstaven voor: Het projectteam maakt een professioneel product, dat dus ook moet voldoen aan professionele criteria. Algemene criteria kun je ontlenen aan de kwaliteitskenmerken uit het Plan van Aanpak. Meer in detail moet het resultaat natuurlijk voldoen aan de wensen van de opdrachtgever; als het goed is zijn die vastgelegd in het Plan van Aanpak en door de opdrachtgever gevalideerd. Iets dergelijks geldt voor de professionele rolvervulling door het team als geheel en de individuele teamleden: Voor algemene vaardigheden als presenteren, vergaderen, notuleren of communiceren bestaan algemene criteria. De individuele POP’s maken het mogelijk om te kijken of de competenties die een projectteamlid beoogde te ontwikkelen ook inderdaad zijn verworven. Deze maatstaven (criteria) spelen gedurende de gehele uitvoeringsfase een rol: zowel de kwaliteit van de ontworpen oplossing als de ontwikkeling van competenties kunnen tijdens werkbesprekingen aan deze criteria worden afgemeten. Maar uiteindelijk moeten alle resultaten van het projectwerk voldoen aan de eisen van de opdrachtgever en de opleiding (in persoon van de projectsponsor). Er wordt dus ergens in deze uitvoeringsfase een oment gekozen om de resultaten te valideren met de opdrachtgever. Het resultaat hiervan is, samen met de manier van werken, onderwerp van review met de docent. De momenten van validatie en review moeten niet te veel naar de einddatum (deadline) van het project liggen, omdat er dan weinig tijd overblijft om de lering die uit het review wordt getrokken om te zetten in daadwerkelijke verbetering van het resultaat, de werkwijze of de manier van rolvervulling. Ergens halverwege is een goed moment. Er is dan nog voldoende gelegenheid om het resultaat, de ontworpen oplossing te verbeteren. In het schema is dat weergegeven door de stappen ontwerpen, ontwikkelen, implementeren in een cirkel te plaatsen. Op dit moment is het zaak na te gaan hoe het met het project staat. Dit gebeurt door middel van checks op de oplossing (zover als die dan klaar is) én de competentieontwikkeling van de teamleden. Dit zijn reviews waarin datgene wat tot dusverre bereikt is tegen het licht gehouden wordt om te zien of alles aan van te voren geformuleerde eisen of criteria voldoet. Zo’n review is toekomstgeoriënteerd, want de belangrijkste vragen zijn: zitten wij op de goede weg en hoe kunnen wij zorgen dat het nog beter gaat? 80/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 7.3 Flankerende workshops <nader invullen> 7.4 Valideren conceptueel ontwerp Ook de oplossing wordt, in het concept- en/of het prototypestadium gevalideerd door de opdrachtgever. Ook nu geldt dat het team alle handelingen om tot de validatie te komen zelfstandig uitvoert: Zorgen dat het conceptueel model resp. het prototype tijdig gereed is Dit ter beschikking stellen van de opdrachtgever De validatiebijeenkomst plannen en organiseren Het resultaat vastleggen voor review in de volgende stap. Zie voor uitvoering van validatie het desbetreffende hoofdstuk in het Handboek op de website. 7.5 Oplossing ontwikkelen 7.6 Oplossing implementeren 7.7 Valideren geïmplementeerde oplossing Zie het handboek Ontwerpprojecten voor de organisatie van validatiesessies. 7.8 Mid-Term Review In de mid-term review komen de volgende checks aan de orde. Bij deze checks wordt de projectsponsor betrokken. De conclusies moeten door de projectsponsor worden geaccordeerd. 1. Check op de ontworpen oplossing: Vragen die het projectteam in de review moet beantwoorden, zijn: Voldoet de oplossing aan de in het Plan van Aanpak geformuleerde eisen, inclusief de kwaliteitseisen? Zo nee, hoe wordt het resultaat dan aangepast? Is het tussenresultaat door de opdrachtgever gevalideerd? 2. Check op de ontwikkelde kennis: Hierbij gaat het erom of met de ontwikkelde kennis een antwoord is gegeven op de bij aanvang van het project gearticuleerde kennisvragen. 3. Check op competentieontwikkeling: Vragen die het projectteam moet beantwoorden, zijn: Heeft iedereen in het team haar of zijn rol op niveau waar gemaakt? Zo nee, waarom niet? Wat kan er verbeterd worden op teamniveau en individueel niveau? Ligt de persoonlijke ontwikkeling van elk teamlid op schema met het POP? Moeten er aanpassingen komen of verbeteracties gestart? 4. Check op de werkwijze: Vragen die het projectteam in de review moet beantwoorden, zijn: Is er goed gewerkt (controleerbaar, vakkundig, logisch en valide)? 81/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Waar zijn verbeteringen mogelijk? Hoe zullen die vorm krijgen? Zie voor uitvoering van reviews het desbetreffende hoofdstuk in het Handboek op de website. 7.9 Oplossing verbeteren De verbeteracties die uit een Review voortvloeien worden SMARTI geformuleerd S Specifiek Geeft precies aan wat wordt verbeterd M Meetbaar Wat het waar te nemen resultaat zal zijn A Activerend Geformuleerd in activiteiten, actieplan R Realistisch Haalbaar gezien omstandigheden T in Tijd gezet Voorzien van een tijdsplanning I Zelf weer Inspirerend tot verbetering 82/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 8 Fase 4: Opleveren oplossing Praktijk vraag Praktijk oplossing Competentieagenda Competentieontwikkeling Ontwikkelde competentie Oplossing Ontwikkelen Oplossing ontwerpen Oplossing Implementeren Oplossing Projectontwikkelen Conceptueel ontwerp Voorbereiden Probleemstelling Diagnose Projectorganisatie Vraag Vraagontwikkelen Oplossing opleveren Kennis en competentie opleveren Oplossing verbeteren Contextkennis Kennisagenda Methoden Oplossingen Ontwikkelde kennis Kennisontwikkeling Aan het einde van het project zijn er drie soorten resultaten op te leveren: 1. de gerealiseerde praktijkoplossing voor de opdrachtgever 2. de ontwikkelde competentie(s) voor de projectteamleden 3. de ontwikkelde kennis voor het instituut. Bij het opleveren van elk van deze resultaten letten we op verschillende dingen. De oplevering van het resultaat verloopt vergelijkbaar met de oplevering van de tussenresultaten, met één belangrijk verschil: de acceptatie review van de ontworpen oplossing door de opdrachtgever (en het is verstandig om de check op competentie-ontwikkeling nu maar even niet te houden; iedereen weet nu zo langzamerhand wel hoe het zit en er is een enorme druk om het resultaat op de deadline op te leveren). In de acceptatie review wordt het resultaat door de opdrachtgever formeel geaccepteerd. Deze zal de oplossing getest en/of beoordeeld hebben om na te gaan of die bruikbaar is en voldoet aan de gemaakte afspraken (conform gevalideerd Plan van Aanpak). Daarmee is een acceptatie review eigenlijk geen review, maar een beoordeling: de balans wordt opgemaakt en dit leidt tot een oordeel. Als het oordeel positief is wordt het resultaat door de opdrachtgever geaccepteerd (feest!), maar het kan ook zijn dat de opdrachtgever nog aanpassingen wenst alvorens te accepteren. Indien deze redelijk zijn en te doen, zullen deze gewoonlijk door het projectteam worden aangebracht, waarna het resultaat alsnog geaccepteerd wordt (uitgesteld feest). Indien de opdrachtgever tot een negatief oordeel komt ontstaat een nieuwe situatie. De projectsponsor zal met de opdrachtgever in de slag moeten om naar oplossingen voor deze patstelling te zoeken. Zie voor uitvoering van validatie het desbetreffende hoofdstuk in het Handboek Ontwerpprojecten. 83/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Op gegeven moment komt het eind van het project in beeld. De oplevering van het Eindresultaat verloopt vergelijkbaar met de oplevering van Tussenresultaten, met één belangrijk verschil: de Acceptatie review van het Eindresultaat door de Opdrachtgever. Verder is het verstandig om de Competentie Ontwikkelings review nu maar even niet te houden; iedereen weet nu zo langzamerhand wel hoe het zit en er is een enorme druk om het eindresultaat op de deadline op te leveren. Acceptatie review In de Acceptatie review wordt het Eindresultaat door de Opdrachtgever formeel geaccepteerd. Deze zal het Eindresultaat getest en/of beoordeeld hebben om na te gaan of het bruikbaar is als probleemoplossing en of het voldoet aan de gemaakte afspraken (conform gevalideerd Plan van Aanpak). Daarmee is een Acceptatie review eigenlijk geen review, maar een Beoordeling: de balans wordt opgemaakt en dit leidt tot een oordeel. Als het oordeel positief is wordt het Eindresultaat door de opdrachtgever geaccepteerd (feest!), maar het kan ook zijn dat de Opdrachtgever nog aanpassingen wenst alvorens te accepteren. Indien deze redelijk zijn en te doen zijn, zullen deze gewoonlijk door het Projectteam worden aangebracht, waarna het Eindresultaat alsnog geaccepteerd wordt (uitgesteld feest). Indien de Opdrachtgever tot een negatief oordeel komt ontstaat een nieuwe situatie. De projectsponsor zal met de Opdrachtgever in de slag moeten om naar oplossingen voor deze patstelling te komen. 84/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 9 Fase 5: Opleveren kennis/competenties Praktijk vraag Praktijk oplossing Competentieagenda Competentieontwikkeling Ontwikkelde competentie Oplossing Ontwikkelen Oplossing ontwerpen Oplossing Implementeren Oplossing Projectontwikkelen Conceptueel ontwerp Voorbereiden Probleemstelling Diagnose Projectorganisatie Vraag Vraagontwikkelen Oplossing opleveren Kennis en competentie opleveren Oplossing verbeteren Contextkennis Kennisagenda Methoden Oplossingen Ontwikkelde kennis Kennisontwikkeling Het projectteam beschrijft welke lessen er zijn geleerd bij de uitvoering van het project. Vaak zal het gaan om kennis die van belang is voor de betrokkenen zelf of voor toekomstige studenten die zo’n klus gaan aanpakken. Maar het zal ook voorkomen dat het geleerde voor professionals buiten het instituut ook van belang is, bijvoorbeeld omdat het gaat om een werkwijze die voor het eerst in de voorliggende situatie werd toegepast. In dat geval is een presentatie op een vakconferentie of een artikel in een vakblad een goede manier om die kennis te delen. Deze ‘kennisproducten’ zijn, als het goed is, al voorzien in het Plan van Aanpak en er zijn tijdens de projectontwikkeling dus ook al criteria voor de kwaliteit ervan ontwikkeld, evenals afspraken over wie waar welke presentatie verzorgt. Elk teamlid maakt de balans op van de eigen persoonlijke ontwikkeling op basis van eerder gehouden ontwikkelingschecks en de beoordeling van de rolverdeling in en van het team. Tevens wordt de professionele rolvervulling in en van het team over het gehele project beoordeeld. Input voor deze beoordeling zijn de resultaten van werkbesprekingen en de eerder gehouden ontwikkelingscheck. Het gaat hier niet om een review, maar een zelf- beoordeling, in dit geval door het projectteam. Evenzo maakt elk teamlid de balans op van de eigen persoonlijke ontwikkeling (op basis van de eerder gehouden ontwikkelingscheck en de beoordeling van de rolvervulling in en van het team). Ook dit is een zelfbeoordeling, in dit geval door een individueel teamlid. 85/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 9.1 Lessons Learned Review In de ‘Lessons Learned Review’ komen de volgende checks aan de orde. Bij deze checks wordt de projectsponsor betrokken. De conclusies moeten door de projectsponsor worden geaccordeerd. 1. Check op de ontworpen oplossing: Vragen die het projectteam in de review moet beantwoorden, zijn: Voldoet de oplossing aan de in het Plan van Aanpak geformuleerde eisen, inclusief de kwaliteitseisen? Zo nee, hoe komt dat? Is het eindresultaat door de opdrachtgever gevalideerd? 2. Check op de ontwikkelde kennis: Hierbij gaat het erom of met de ontwikkelde kennis een antwoord is gegeven op de bij aanvang van het project gearticuleerde kennisvragen. 3. Check op competentieontwikkeling: Vragen die het projectteam moet beantwoorden, zijn: Wat kunnen de projectleden nu en wat wordt er mee gedaan? Heeft iedereen in het team haar of zijn rol op niveau waar gemaakt? Zo nee, waarom niet? Is de persoonlijke ontwikkeling van elk teamlid in overeenstemming met de beoogde ontwikkeling, vastgelegd in het POP? Zie voor uitvoering van reviews het desbetreffende hoofdstuk in het Handboek Ontwerpprojecten 9.2 Opleveren kennis en competentie Laten wij aannemen dat het Eindresultaat van het project is geaccepteerd door de Opdrachtgever. Nu komt het moment om de balans van het project op te maken en het project af te sluiten. Belangrijke vragen zijn: hoe hebben wij het nu uiteindelijk in dit project gedaan en wat hebben wij er van geleerd? De balans wordt opgemaakt in een drietal documenten. 9.2.1 Voortgangs zelfevaluatie Hierin wordt door het Projectteam teruggekeken op de gang van zaken in het project als geheel. De kwaliteit van de voortgang wordt geanalyseerd en van een kwalificatie voorzien. Ook de kwaliteit van de opgeleverde resultaten wordt geanalyseerd en van een kwalificatie voorzien. Input voor deze analyses zijn de resultaten van eerdere reviews en de Acceptatie review. Het opmaken van de balans betekent een zelfbeoordeling door het Projectteam. 9.2.2 Team zelfevaluatie Hierin wordt door het projectteam de professionele rolvervulling in en van het team over het gehele project beoordeeld. Input voor deze beoordeling zijn de resultaten van Professional Role reviews en de eerder gehouden Ontwikkelings review. Het opmaken van de balans betekent een zelf-beoordeling door het Projectteam. 9.2.3 Individuele zelfevaluatie competentie ontwikkeling Op basis van de met betrekking tot Voortgang en Team opgemaakte balans kan een beoordeling door elk teamlid van de eigen persoonlijke ontwikkeling plaatsvinden. Het opmaken van de balans betekent een 86/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten zelf-beoordeling door een individueel lid van het team. Deze zelfbeoordeling moet door het Projectteam als geheel worden gevalideerd. a. b. c. d. e. 9.2.4 Resultaten van de afsluiting van het project Opgeleverd resultaat Verslag van de Acceptatie review Voortgangs zelfevaluatie Team zelfevaluatie Individuele zelfevaluatie competentieontwikkeling 9.2.5 Tips Bos & Harting (1998; p. 23-372/23-378) geven tips ten aanzien van: 1. Leren van de ervaringen 2. Projectevaluatie 87/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 10 Beoordeling Nu is het moment aangebroken om als projectorganisatie de balans van de projecten op te maken. De projectsponsor, als manager van de afdeling waarbinnen de projecten zijn uitgevoerd, is hierin de centrale figuur. De beoordeling gebeurd in drie stappen: 1. De projectsponsor voert analyses uit op de resultaten die bij opleveren van de resultaten zijn ontstaan: de beoordeling van de professionele rolvervulling in en van het team over het project de balans op van de eigen persoonlijke ontwikkeling (individueel). 2. De projectsponsor stelt op grond van de gevalideerde beoordelingscriteria voorlopige beoordelingen vast voor het team en voor de teamleden individueel. 3. Ten slotte wordt de voorlopige Teambeoordeling gevalideerd met het projectteam en de voorlopige individuele beoordelingen met de betreffende leden van het projectteam. Degene die uiteindelijk de validiteit van de beoordeling vaststelt is de projectsponsor. Indien geen overeenstemming over de beoordeling bereikt kan worden, stelt de projectsponsor de beoordeling vast, maar neemt de bezwaren van het projectteam of het betreffende teamlid bij de beoordeling op. Meer informatie over de beoordeling en beoordelingscriteria zijn te vinden op de website. 10.1 Voorlopige beoordelingen Nu is het moment aangebroken om als projectorganisatie de balans van de projecten op te maken. De projectsponsor, als manager van de afdeling waarbinnen de projecten zijn uitgevoerd, is hierin de centrale figuur. De projectsponsor voert analyses uit op de resultaten van Afsluiting project: a. Opgeleverd resultaat b. Verslag van de Acceptatie review c. Voortgangs zelfevaluatie d. Team zelfevaluatie e. Individuele zelfevaluatie competentieontwikkeling De projectsponsor stelt op grond van de gevalideerde Beoordelingscriteria voorlopige beoordelingen vast: 1. Voorlopige Teambeoordeling, 2. Voorlopige Individuele Beoordeling. 10.2 Definitieve beoordeling Daarna valideert de projectsponsor de Voorlopige Teambeoordeling en de Voorlopige Individuele Beoordeling met het Projectteam. Indien geen overeenstemming over de validiteit kan worden, stelt de projectsponsor de definitieve beoordeling vast, maar neemt de bezwaren van het Projectteam of het betreffende teamlid bij de beoordeling op. 88/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 11 Nazorg Verwerken lessons learned Verwerken resultaten voor hergebruik Bijstellen materiaal 89/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 12 Projecten in onderwijsinformatiesysteem Projecten worden natuurlijk niet zomaar gegeven. Studenten zullen er cijfer(s), en studiepunten, voor willen krijgen als zij het project voldoende hebben afgerond, docenten zullen uren willen krijgen voor de begeleiding van de studenten. Daarvoor moeten projecten zijn ingevoerd in het onderwijsinformatiesysteem van de instelling. De minor PPP is op onderstaande wijze in Osiris geplaatst. Studenten worden voor elk afzonderlijk onderdeel beoordeeld. Let wel: de afzonderlijke deelcijfers moeten minimaal een 5,5 zijn voor toekenning van studiepunten. Fase 1: Introductie T-MBN-PPPINTR-04 T-MBN-PPPOZV-04 Introductiecursussen Onderzoeksvaardigheden 3 x cijfer (totaal / 3) 2 x cijfer (totaal / 2) 3 ects 3 ects Plan van Aanpak / Ondernemingsplan 2 x cijfer (totaal / 2) 3 ects Fase 3: Onderzoek T-MBN-PPPOND1-04 Inhoudsopgave 1 x cijfer 3 ects T-MBN-PPPOND2-04 Tussenpresentatie 3 ects T-MBN-PPPOND3-04 Presentatie concept 2 x cijfer (proces + inhoud) (totaal / 2) 1 x cijfer 1 x cijfer 2x cijfer (proces + inhoud) (totaal / 2) 6 ects 3 ects Fase 2: Plan van Aanpak T-MBN-PPPPVA-04 Fase 4: Rapport en presentatie T-MBN-PPPEIND-04 Rapport T-MBN-PPPPRES-04 Presentatie 6 ects 90/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 13 Belangrijke Begrippen 13.1 Algemene begrippen Hieronder volgen definities van een aantal belangrijke begrippen. Deze begrippen spelen in alle fasen van het project een hoofdrol. Het is daarom belangrijk dat iedereen die bij dit project betrokken is, dezelfde definities hanteert. Assessment Volgens ‘van Dale Hedendaags Nederlands’ kan de volgende definitie worden gegeven: beoordeling van een sollicitant of werknemer op geschiktheid voor een functie. Bachelor1 Een 4-jarige Hbo-opleiding of de eerste drie jaar van een universitaire opleiding. Competenties Volgens ‘van Dale Hedendaags Nederlands’ kunnen de volgende definities worden gegeven: - deskundigheid, geschiktheid bekwaamheid - bevoegdheid tot handelen of oordelen - (taalkundig) impliciete kennis die men heeft van de eigen taal taalcompetentie Dat de student kennis heeft van een bepaald vakgebied of onderwerp en dat hij/zij weet hoe moet worden gehandeld om binnen dat gebied tot een goed eindresultaat te komen. 2 Een competentie is een samenhang van kennis, attitude en vaardigheden.3 Kennisvraag Een door een kennisinstituut gestelde kennisvraag. Meta-criteria Algemeen geldende criteria voor deze manier van werken. Criteria over criteria (dus criteria die nog nader in de betreffende context uitgewerkt moeten worden). Praktijkvraag Een door een opdrachtgever gestelde vraag. Project Een tijdelijk, resultaatgericht samenwerkingsverband tussen mensen, waarin gebruik gemaakt wordt van schaarse middelen. Projectsponsor Degene die het project heeft ‘binnengehaald’, meestal een docent van de opleiding of een medewerker van een kenniscentrum. Projectmatig werken4 1 Bron: BaMa site van de HU Bron: Stageprotocol Bouwkunde 2003-2004 pagina 17 3 Bron: auditrapport ROP 2004 4 Bron: Wijnen, G. W. Renes en P. Storm (2001). Projectmatig werken. Utrecht: Het Spectrum. 2 91/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Het biedt in het algemeen het voordeel van een meer resultaatgerichte of effectieve aanpak en wordt toegepast indien: het gewenste resultaat niet volstrekt nieuw is, maar wel veel nieuwe elementen of aspecten omvat; mensen uit verschillende disciplines of vakgebieden dat resultaat samen moeten bereiken; men eenmalig een maximale prestatie moet leveren; men over beperkte middelen beschikt om dat resultaat te bereiken. Review Voldoet dat wat bedacht is aan de professionele kwaliteitseisen? Is altijd toekomst en verbeteringsgericht: waar staan we en wat kan er beter? Daarom hebben de kwaliteitscriteria bij voorkeur een operationele vorm, zodat een constatering dat niet wordt voldaan aan een criterium, meteen leidt tot gerichte verbetering. Volgens ‘van Dale Hedendaags Nederlands’ kunnen de volgende definities worden gegeven: recensie, beoordeling, kritiek; terugblik, overzicht, bezinning, heroverweging; opnieuw bekijken, recenseren, bekritiseren, beoordelen. Self-assessment Het door de student zelf beoordelen van zijn / haar (behaalde) competenties en persoonskenmerken. Valideren Het proces waarmee wordt nagegaan dat daadwerkelijk aan de behoefte van de omgeving (opdrachtgever, kennisinstituut) tegemoet wordt gekomen. Nagaan of wat bedacht is functioneert in de context. Volgens ‘van Dale Hedendaags Nederlands’ kunnen de volgende definities worden gegeven: Geldend maken, geldig verklaren 13.2 Projectgebonden begrippen Duurzaamheid5 "Onder duurzame ontwikkeling wordt een ontwikkeling verstaan die voorziet in de behoefte van de huidige generatie zonder daarmee voor de toekomstige generaties de mogelijkheid in gevaar te brengen om ook in hun behoeften te voorzien." Waarom duurzaam ontwikkelen? Duurzaam bouwen biedt vele goede kansen aan diverse actoren om de bouw verder te brengen dan wel te helpen in een duurzame ontwikkeling. En dat gaat veel verder dan alleen het toepassen van milieuvriendelijke materialen. Flexibiliteit en hergebruik kunnen belangrijke aspecten vormen in het bouwen voor de toekomst. Toch gaat het vooral ook om een stap voorwaarts te brengen in het conceptueel denken over gebruiksfuncties en hun mogelijkheden. Duurzaam bouwen is het zodanig ordenen, inrichten en beheren van een woning, gebouw, buurt, wijk, dorp, stad en regio dat de gebruikswaarde (functie), belevingswaarde (vorm) en de toekomstwaarde (tijd) worden verhoogd. Anders gezegd: het creëren van vormen en functies die duurzaam wonen, werken en recreëren bevorderd. 5 Bron: www.dubo-centrum.nl 92/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten Minor6 Een samenhangend geheel van keuzecursussen dat als zodanig is opgenomen in de HU Onderwijscatalogus dan wel door een andere onderwijsinstelling als zodanig wordt aangeboden. Een studiepakket van keuzecursussen met een omvang van 30 ects binnen de profileringruimte van de bacheloropleiding. People Planet Profit Een project gebaseerd op duurzaamheid in drie gebieden: sociale duurzaamheid (people), milieukundige of ecologische duurzaamheid (planet) en economische duurzaamheid of efficiëntie (profit). In deze context behelst ecologie natuur, omgeving en landschap en is dus meer dan wat in de biologie onder ecologie wordt verstaan, namelijk een relatie tussen planten en dieren. Short-course Letterlijk: korte cursus Een via Blackboard aangeleverde korte cursus ten behoeve van de minor PPP. Aanvullende short-courses kunnen door studenten aangevraagd worden. Een aantal short-courses worden aan het begin van de minor voor alle deelnemende studenten verplicht gesteld. Sustainable city – duurzame stad7 A city where achievements in social, economic and physical development are made to last. Een stad waar bereikte doelstellingen in sociale, economische en fysieke ontwikkelingen blijvend zijn. 6 7 Bron: BaMa site van de HU Bron: www.unhabitat.org/programmes/sustainablecities in: NFR Research Niche Area Framework 93/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 14 Verantwoording in deze handleiding is kennis samengebracht uit meerdere projecten: SURF project Taakgericht Teamleren (Hogeschool Utrecht, Universiteit Utrecht) DU project Virtueel Project/Virtueel Bedrijf (Hogeschool Utrecht, Open Universiteit, Fontys Hogescholen) DU project Virtueel Bedrijf (Open Universiteit, Hogeschool Utrecht, Fontys Hogescholen) SURF project Multi-professioneel leren met ICT (Hogeschool Utrecht, Universiteit Utrecht) HU project Verbinden van Onderwijs en Onderzoek (lectoraat ICT en hoger onderwijs) De volgende personen hebben bijgerdragen: Tom van Weert (lector ICT en hoger onderwijs, Hogeschool Utrecht) Daan Andriessen (lector Intellectual Capital, Hogeschool Inholland) Ilya Zitter, promotieonderzoek Multi-professioneel leren met behulp van ICT (lectoraat ICT en hoger onderwijs, IVLOS Universiteit Utrecht) Debby Goedknegt en Rien van Stigt (lectoraat ICT en hoger onderwijs, HU faculteit Natuur en Techniek) Heinze Oost (IVLOS Universiteit Utrecht) 94/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen Handleiding ontwerpprojecten 15 Verwijzingen Bommel, Patrick, Wil Lamain, Harrie van Seters, John Symes & Tom van Weert (1996) GiP, Handleiding Geïntegreerd Practicum. Nijmegen: Radboud Universiteit. Bos, J. & E. Harting (Eds.) (1998) Projectmatig creëren. Scriptum Books, Schiedam. Grit, Roel (2005) Projectmanagement. Groningen: Wolters Noordhoff Handboek Ontwerpprojecten (2006) In ontwikkeling Johnson, D.W. & R.T. Johnson (1994) Learning together. In: S. Sharan (Ed.), Handbook of Co-operative Learning methods. Greenwood Press, Westport, pp. 51-65. Scholtes, P. R., B. L. Joiner & B. J. Streibel (2002) Het Team-Handbook. Uitgeverij Nieuwezijds, Amsterdam. 95/95 Hogeschool Utrecht, Lectoraat ICT en hoger onderwijs Creative Commons Naamsvermelding-NietCommercieel-Gelijk delen
