Projectopdracht TOOL- BOX

Transcriptie

1 Projectopdracht De sjabloon van de projectopdracht is de eerste sjabloon dat je invult voor je project. De nadruk in deze fase ligt op de afbakening van je opdracht: wat ga je wel en wat ga je niet doen? En waarom? Dit is ook het moment waarop je zou moeten nagaan of er voor het project een geldige business case is. Is die er niet, dan is het wellicht raadzaam om een business case op te stellen aan de hand van de sjabloon business case. Maak dan geen projectopdracht voor het gehele project, maar voor het opstellen van de business case! Tijdens de fase van het opstellen van de projectopdracht heb je (als het goed is) verschillende gesprekken met je opdrachtgever. Realiseer je dat ook zijn ideeën over het project nog aan het kristalliseren zijn, net als jouw ideeën. Gebruik de projectopdracht als discussiestuk bij de gesprekken. Formuleer scherp om de discussie over de juiste onderwerpen uit te lokken! Bedenk dat het beter is om nu de discussie te krijgen over wat jij wel en niet gaat doen, dan bij oplevering van de resultaten. Laat de versie waarover de opdrachtgever en jij het allebei eens zijn (dat wil zeggen de definitieve versie) ondertekenen door beide partijen. Dit lijkt erg formeel, maar het is wel een mijlpaal die je op die manier zeer bewust passeert: er is groen licht om verder te gaan met dit project. Gebruik de sjabloon met de toelichting of de lege sjabloon voor het opstellen van een nieuwe projectopdracht. In de toelichting staan allerlei checklisten met als doel je te helpen bij het invullen van de sjabloon.

2 Projectopdracht (Naam project) Versie: X.X Status: Datum: Naam opdrachtgever Akkoord opdrachtgever: Datum: Naam opsteller Projectcode Startdatum Einddatum De projectopdracht wordt door de opdrachtgever en beoogde projectmanager opgesteld tijdens de initiatieffase. De afspraken tussen de opdrachtgever en projectmanager voor het op te starten project worden erin vastgelegd. In deze toelichting staan allerlei checklisten met als doel je te helpen bij het invullen van de sjabloon. Je hoeft niet alle vragen te beantwoorden. Het is de kunst om de juiste vragen bij jouw project te beantwoorden. Stem de hoeveelheid tekst af op de omvang van het project. Schrijf kort en bondig. Begin de zinnen bijvoorbeeld met een werkwoord. Begin met versie C0.1. De C staat voor concept. Na afstemmen met diverse partijen, ontstaat na verloop van tijd versie F1.0 (final), de eerste goedgekeurde versie. Na een grote wijziging kan een versie F2.0 ontstaan. De projectcode wordt verstrekt door de afdeling planning en control. Versie Datum Auteur Korte beschrijving wijzigingen C0.1 Voorstel projectnaam Kies een korte sprekende naam.

3 Achtergrond Beschrijf de aanleiding voor het project: waarom moet er een project worden opgestart? waarom dit project juist NU? wat is de aanleiding, historie? welke problemen, oorzaken of ambitie geven aanleiding tot het ontwikkelen van het gevraagde resultaat? waarom is de opdracht gegeven door deze opdrachtgever? waarom heeft de opdrachtgever het resultaat nodig? in welke context wordt het project gestart. Welke afdelingen en bedrijfsprocessen? wordt het project uitgevoerd in een groter verband met andere projecten? Doel van het project Beschrijf het doel van het project: wat wil de opdrachtgever met dit project bereiken? Dit is de tevredenheids - knop van de opdrachtgever. Waarop wordt de opdrachtgever afgerekend? hoe gaat hij de harde resultaten inzetten die het project gaat opleveren? wat is de koppeling tussen het te ontwikkelen resultaat en de bedrijfsprocessen? schrijf het doel in terminologie van de opdrachtgever! beschrijf het doel zo concreet mogelijk, zowel kwantitatief als kwalitatief hoe dragen de doelen bij aan de bedrijfsdoelstellingen? op het doel beoordeelt de opdrachtgever of de opdracht succesvol is verlopen, bijvoorbeeld: als resultaat van de implementatie van een nieuw systeem... wordt op x% van de perrons de juiste treininformatie getoond in verband met de nieuwe wet..., die 1 januari 2005 ingaat, moet het systeem uiterlijk 1 september 2004 ter acceptatie worden opgeleverd. beschrijf de doelen SMART: Specifiek (concreet resultaat), Meetbaar (kwantiteit, kwaliteit, tijd, geld), Acceptabel (voor jezelf en anderen), Realistisch (haalbaar en uitvoerbaar) en Tijdgebonden (in tijdsperiode geformuleerd). het behalen van het doel is de verantwoordelijkheid van de opdrachtgever, het behalen van de resultaten die van de projectmanager. De resultaten dragen bij aan het doel, en dienen dus in dat perspectief gesteld te worden. Eindresultaat: Wat is er klaar als het klaar is? Beschrijf de (beoogde) resultaten van het project: maak een lijst van de op te leveren producten met per product een zo helder mogelijke beschrijving. Een product is iets tastbaars, iets dat je uit je handen kunt laten vallen. Een beslisdocument is ook een resultaat. N.B. Een projectopdracht hoeft niet automatisch tot een project te leiden, de uitkomst kan ook de opdracht tot het maken van een business case zijn.

4 in een goede resultaatspecificatie ontbreken ER-woorden (zoals beter, mooier, efficiënter, sneller, groter, klantvriendelijker). Een resultaat wordt beschreven in de vorm van een zelfstandig naamwoord, het is immers een product, een ding, iets dat aantoonbaar aanwezig is na afloop van het project, iets dat je uit je handen kunt laten vallen. beschrijf de resultaten SMART: Specifiek (concreet resultaat), Meetbaar (kwantiteit, kwaliteit, tijd, geld), Acceptabel (voor jezelf en anderen), Realistisch (haalbaar en uitvoerbaar) en Tijdgebonden (in tijdsperiode geformuleerd). beschrijf bijvoorbeeld bij advies als het resultaat, ook de vorm waarin het advies opgeleverd wordt (een rapport, een presentatie, enz.). Minimale eisen aan het resultaat Welke kwaliteitsverwachting heeft de opdrachtgever of de gebruiker van het op te leveren resultaat: wat is wezenlijk van belang aan de op te leveren producten van dit project? welk kwaliteitsniveau moet het product hebben? Kortom moet het van goud of van hout? Maak daarbij een afweging tussen kosten, tijd en kwaliteit. De kwaliteitsverwachtingen worden in de volgende fase verder gespecificeerd, maar neem hier vast de belangrijke en algemene eisen op. Denk daarbij ook aan kwaliteitsverwachtingen op het gebied van functionaliteit, uiterlijke verschijningsvorm, vereiste kennis- of vaardigheidsniveau om het op te leveren product te kunnen gebruiken, performance, capaciteit, nauwkeurigheid, beschikbaarheid, betrouwbaarheid, ontwikkelingskosten, beheersbaarheid (onderhoudbaarheid), veiligheid, privacy en gebruikersvriendelijkheid. zijn er wettelijke of bedrijfsvoorschriften waaraan moet worden voldaan? moet het product voldoen aan een bepaalde kwaliteitsstandaard? is er een uiterste opleverdatum en wat is dan die einddatum? Als het product klaar is? Als het geïmplementeerd is? Als de evaluatie gereed is? Hoe hard is de datum die de opdrachtgever heeft genoemd? Is dat een datum die hij in zijn hoofd heeft, of zijn er andere redenen waarom het project op die datum klaar moet zijn? Let op: De einddatum is die datum waarop alle resultaten in het hoofdstuk wat is er klaar als het klaar is? EN alle projectmanagementdocumenten (ook projectevaluatie) gereed zijn! stel ook de acceptatiecriteria op: hoe constateer je dat aan de kwaliteitseisen is voldaan. maak afspraken over de kwaliteitsborging: wie borgt de kwaliteit in het project, de op te leveren producten, en het correcte gebruik van de standaarden? Het gaat dus om het toetsen van het toetsen (wordt er getoetst conform het kwaliteitsplan?).

5 Afbakening: Wat is het resultaat niet? Dit is een belangrijke paragraaf, omdat je hiermee de verwachtingen van je opdrachtgever (en de andere betrokkenen bij het project) een beetje kunt managen. Op het moment dat jij meldt dat je een huis gaat bouwen, denkt de opdrachtgever gelijk aan een flinke luxe woning met een prachtig ingerichte tuin en garage. Dat is nu eenmaal de menselijke natuur om daar iets moois bij te bedenken. Jij als projectmanager hebt meestal wel duidelijk in jouw hoofd wat je wel en niet gaat opleveren. Je moet toetsen of dat beeld overeenkomt met het beeld dat jouw opdrachtgever heeft. Gesprekken zijn hierbij het belangrijkste hulpmiddel (verwachtingsmanagement). Maar ook door in dit hoofdstukje expliciet te definiëren wat je NIET gaat doen, kun je het enthousiasme bij jouw opdrachtgever enigszins temperen tot realistische waarden. Denk hierbij aan: voor welke afdeling doe je het, maak je alleen het ontwerp, of maak je ook het product, en zorg je voor de benodigde opleidingen, enzovoort. Projectorganisatie Geef hier de eerste invulling aan de projectorganisatie: wie is de opdrachtgever? (voor wie is het uiteindelijke resultaat) wie zijn de belangrijkste stakeholders? (en vormen straks de stuurgroep) Gebruik eventueel de bouwsteen stakeholderanalyse uit de ToolboxPlus. wie is de beoogd projectmanager? (wie gaat het project doen) welke gebruikersgroepen moeten worden betrokken? (wie gaan straks het resultaat gebruiken) welke beheersorganisatie moet worden betrokken? (wie gaan straks het resultaat beheren) zijn er essentiële medewerkers noodzakelijk voor het slagen van het project? (bijvoorbeeld kennis die je moet hebben) Indien het een ICT-project betreft: hoe past het project in de architectuur? Maak zo mogelijk al afspraken over de taakverdeling. Neem zo mogelijk al een organigram op. Voorstel voor de fasering die gevolgd wordt, en tussenresultaten Beschrijf hier in grote lijnen de weg die gevolgd gaat worden om de genoemde resultaten op te leveren. In onderstaande voorbeeldfasering is de standaard PMW-fasering opgenomen. Het is niet noodzakelijk om je aan deze fasering te houden. Het kan best zijn dat jouw project heel andere fases nodig heeft.

6 Fasering (Tussen)resultaten Start Eind Fase 1: INITIATIEF de projectopdracht en eventueel: globale business case eerste aanzet tot risicoanalyse plan voor de definitiefase Fase 2: DEFINITIE projectplan, eventueel incl. activiteitenplan, mijlpalenplan, capaciteitsplan en financieel plan detailplan voor de ontwerpfase en eventueel: definitieve business case workshop project start-up stakeholderanalyse risicoanalyse kick-off programma van eisen gedetailleerde productomschrijvingen auditplan Fase 3: ONTWERP gedetailleerd ontwerp (bestek) detailplan voor de voorbereidingsfase en eventueel: test- en implementatieplan acceptatieprocedure Fase 4: VOORBEREIDING beschikbare resources (mensen en middelen) ingerichte projectomgeving detailplan voor de realisatiefase Fase 5: REALISATIE gerealiseerde, goedgekeurde en overgedragen resultaten opgeleide gebruikers ingerichte beheersorganisatie detailplan voor de nazorgfase

7 Fasering (Tussen)resultaten Start Eind Fase 6: NAZORG resultaat zonder kinderziektes decharge en overgedragen projectarchief goed ingewerkte gebruikers en beheersorganisatie Business case Het doel van de business case is het beargumenteren van het nut en de noodzaak van het voorgestelde idee ten opzichte van de bedrijfsdoelstellingen. De business case wordt uitgewerkt nog voor het project van start gaat, kortom in principe nog voor er überhaupt sprake is van een project en dus voor deze projectopdracht geschreven wordt. Voor middelgrote en grote projecten raden we de bouwsteen business case uit de ToolboxPlus aan. Daarin worden verschillende oplossingsvarianten, zowel kwalitatief als kwantitatief, uitgewerkt en een advies gegeven ten aanzien van de oplossingsrichting. Indien er een aparte business case geschreven is, verwijs dan in deze paragraaf naar dat document. Voor kleinere projecten kan het eenvoudiger zijn om de uitwerking van de business case in de projectopdracht te integreren. De business case moet antwoord geven op de volgende vragen: Aan welke bedrijfsdoelstellingen draagt het idee bij (nut)? Welke nadelige effecten heeft het niet uitvoeren van het idee op de bedrijfsdoelstellingen (verantwoord)? Welke consequenties zijn te identificeren als het idee niet wordt uitgevoerd (noodzaak)? Is het idee uitvoerbaar binnen de gestelde kaders en context (kans van slagen)? Zijn de gedefinieerde resultaten kwantificeerbaar en na de implementatie meetbaar (toetsbaar)? Schenk daarbij aandacht aan de volgende aspecten: 1. Rechtvaardiging van de oplossingsrichting: Te verwachten kosten: onderzoekskosten ontwikkelings- en implementatiekosten exploitatiekosten Te verwachten baten: meetbare, in geld uit te drukken baten: - extra opbrengsten - besparingen meetbare, niet in geld uit te drukken baten moeilijk meetbare baten

8 2. Haalbaarheid van de oplossingsrichting: het effect van de verandering op de organisatie inclusief het proces, de informatievoorziening en de besturing de weg van de verandering de risico s van het veranderingstraject (zie verderop in deze projectopdracht) Budgetindicatie voor dit project Geef in deze rubriek aan: welk budget wordt aangevraagd voor dit project? wanneer hierboven de business case voor het project is uitgewerkt, volgt het budget uit de te verwachten kosten. Geef dan wel aan hoe het budget aangevraagd gaat worden. wanneer de business case separaat uitgewerkt is, neem dan het budget hier over. wie moet dit goedkeuren? Projectcontext: afhankelijkheden Beschrijf de afhankelijkheden en koppelingen van het project met andere projecten, bedrijfsonderdelen en anderen: zijn er fysieke verbindingen nodig? zijn processen van elkaar afhankelijk? hebben veranderingen door dit project gevolgen voor andere partijen? hoe liggen de verschillende tijdspaden? wat zijn de onderlinge afspraken en verwachtingen? Opmerkingen Overige belangrijke aspecten, aannamen, deadlines, enzovoort.