Plan van Aanpak

Plan van Aanpak

Het begrip 'plan van aanpak' of 'projectplan' kom je vaak in de praktijk voor. Bij navraag blijkt echter dat bij diverse organisaties een verschillende invulling van het begrip wordt gegeven. Vaak is echter binnen een organisatie zeer nauw omschreven wat er in een plan van aanpak staat. Dit stuk is brengt een aantal van de ideeën in kaart.
In alle gevallen is een plan van aanpak een stuk dat in een vroeg stadium van het project wordt gemaakt. Grofweg ergens in de loop van de definitiefase. Er zijn ook organisaties die zowel aan het begin als aan het eind van de definitiefase een stuk opleveren dat “plan van aanpak” genoemd zou kunnen worden. Alternatieve begrippen die vaak inhoudelijk lijken op het plan van aanpak –afhankelijk van de organisatie- zijn:

• startdocument
• offerte
• projectvoorstel
• verzoek om budgetopening
• projectdefinitie

Oorsprong van het plan van aanpak

De kern van projectmanagement is “het beheersen van het onzekere”. Daartoe wordt er –onder andere- gefaseerd. Een strikte fasering gaat uit van een mijlpaalbeslissing en een daarop volgende budgetopening per fase. Voor een beslisser is dat een onprettige gang van zaken. Hij geeft geld uit zonder dat hij weet op dat uiteindelijk winst zal opleveren; winst is er namelijk pas als het gehele project succesvol wordt afgesloten (haast een cirkelredenering).
Opdrachtgevers willen het liefst aan het begin van het project een overzicht over het hele gebeuren: tijd, geld en kwaliteit. Om daaraan tegemoet te komen vragen ze “wat ga je doen en wat kost dat”. Het antwoord daarop is een “plan van aanpak”.

Functie van het plan van aanpak

Het plan van aanpak heeft vier, in elkaar overlopende functies:

• helder maken van probleem en resultaat
• onderhandeling met opdrachtgevers en teamleden
• afbakening van de projectinhoud
• beschrijven van de vragen, risico’s en onzekerheden

Door op te schrijven wat hij gaat doen –uiteraard in overleg met opdrachtgever en teamleden- dwingt de projectleider zichzelf om duidelijk te zijn over de inhoud van het project. Waar gaat het om, wat is er af als het af is. Het is duidelijk dat deze analyse gebrekkig zal zijn. Hij is meer richtinggevend dan normatief.
Met het resultaat van zijn denken kan de projectleider naar de opdrachtgever stappen: “is dit wat u bedoelt?”. Als de opdrachtgever –na enige discussieronden en bijstellingen- akkoord gaat is dat een dekking voor de projectleider, hij heeft een fiat. Anderzijds gaat hij ermee naar zijn team. Het wordt de teamleden duidelijker wat ze gaan doen en ze kunnen, vanuit hun expertise, kritisch reageren op de eerste denkbeelden.
Tenslotte zegt het plan iets over wat er wel en wat er niet tot het project hoort. Het is een groot verschil of we een houten voetgangersbruggetje gaan maken of een vierbaans betonnen brug met een beweegbaar deel. Op een ander vlak is er een verschil tussen het opslaan van mijn persoonlijke adressen in een spreadsheet en het bouwen van een relationele database voor de relaties van Shell. We zeggen niet “dit project zal € 148.944,95 gaan kosten”, maar we maken wel een onderscheid tussen een “tonnen-project” en een “miljoenenproject”.

Inhoud van het plan van aanpak

We kunnen de inhoud op twee manieren beschrijven. Als we kijken naar de inhoudsopgave, het soort onderwerpen dat aan de orde komt kunnen we alle gebruikelijke onderwerpen aantreffen (tijd, geld, kwaliteit, organisatie, informatie, risico’s, deelprojecten, fasering). Als we kijken naar de zwaartepunten dan zien we vooral zaken die in de definitiefase belangrijk zijn: doel en resultaat, eisen, bestaande situatie, valkuilen, risicobeperking.
Mogelijke onderwerpen zijn:

• Commercieel: waar komt de projectopdracht vandaan, welke aanneemsom is er mee gemoeid, welk budget heeft de projectleider ter beschikking, is er sprake van boetebedingen of bonussen.
• Organisatie: wie is de interne opdrachtgever, de projectleider, welke externe contacten moeten worden onderhouden, welke interne contacten (bv. inkoop, kwaliteit, projectondersteuning)
• Personeel: wie zijn de teamleden, hoe lopen de contracten daarmee (wat is de rol van de lijnmanager), welke onderaannemers zijn betrokken, is er inhuur van personeel
• Administratie: welke rapportagesystemen worden gebruikt, wie maakt, cq ontvangt de gegevens
• Financiën: kosten en opbrengsten, evt. systemen die daarbij een rool spelen (bv. boekhouding, bankrekeningen)
• Informatie: waar is de informatie terug te vinden, hoe is de informatie rond het project geordend, hoe wordt omgegeaan met vrijgave, geheimhouding
• Techniek: welke technische beginselen worden toegepast, welke ontwerpmethodiek, welke bestaande technieken en ontwerpen.
• Juridisch: alles rond contracten, bonus/malus regelingen, aansprakelijkheden (ook van externen naar het project toe).

We kunnen ons voorstellen dat de opdrachtgever zegt “over deze dingen wil ik het hebben, geen daarvan mag verwaarloosd worden”. Dat wil nog niet zeggen dat ze allemaal duidelijk zijn. Sterker nog, als het Plan van Aanpak volledig kan worden beschreven is kennelijk het project al uitgevoerd. Veel onderwerpen zullen dus voorlopig beschreven worden, wellicht alleen als “moet nader bestudeerd worden”. Ook dat is relevant. Het geeft aan waar de voornaamste onzekerheden zitten. Veel onzekerheden kunnen voorzien worden van een deadline of milestone: dan en dan weten we de oplossing. Nog een stap terug is: dan en dan vertellen we hoe we het gaan aanpakken en hoeveel tijd en kosten het dan nog met zich meebrengt.

Een algemeen plan van aanpak

Als we dicht bij de bedoelingen van het plan van aanpak blijven, dan kunnen we het volgende model voorstellen dat een min of meer algemene geldigheid heeft (er zijn verschillen tussen grote en kleine projecten, tussen interne en externe projecten, tussen research en toepassing). Zo’n model heeft de volgende indeling. Voor elk onderwerp geldt dat beschreven wordt wat er op het moment bekend is en eventueel wat er nog bestudeerd moet worden en wanneer dat af is.

Voorblad en Titel Geeft aan wie de auteur is van het stuk en op welke datum de huidige versie voltooid is.
Summary Een samenvatting van het stuk in maximaal 1 A4.
Versie en wijzigingen Geeft de achtereenvolgende versies van het stuk, welke wijzigingen er per versie zijn aangebracht en waarom.
Identificatie Hier staat om welk project het gaat. Het project moet een naam hebben, evt. een projectnummer, er moet een opdrachtgever zijn (kan een groep zijn, bv. marketing of directie) en een gedelegeerd opdrachtgever (de “mond” van de opdrachtgever als die uit een groep bestaat).
Verder wordt hier genoemd wie er in het projectteam zit (projectleider en –voor zover bekend- teamleden).
Achtergrond Hier wordt beschreven wat de huidige situatie is.
Voor zover bekend wordt aangegeven welke aanpak gevolgd zal worden in het project.
Verder wordt hier beschreven voor wie het projectresultaat gemaakt wordt (de gebruikers en de probleemhebbers).
Voor zover van toepassing wordt verwezen naar documenten waarin de achtergrond beschreven wordt.
Doel en resultaat Hierin staat de doelstelling (het brede probleem waar het project uit voort komt, met de probleemstelling) en het projectresultaat en het projectgevolg (het resultaat geeft de concrete producten, het projectgevolg geeft aan wat dat resultaat moet “doen”, welk probleem wordt opgelost of welke veranderingen het tot stand brengt). Ook wordt de scope vermeld, wat het project doet en niet doet (beperkingen) en aan welke eisen het resultaat moet voldoen.
Als er sprake is van prioriteiten wordt bijvoorbeeld gebruik gemaakt van het MoSCoW-principe om dat aan te geven.
Business Case De business Case is wellicht nog niet geheel uitgewerkt, maar als er geen Business Case is, is het nog te vroeg voor een Plan van Aanpak.
Risicoanalyse Aangegeven worden de valkuilen, de onbekende factoren en de risicofactoren. Tevens wordt aangegeven hoe met de risico’s zal worden omgegaan (risicostrategie). Voor zover van toepassing wordt hier aangegeven welke bijdrage wordt verwacht van diverse betrokkenen. Ook wordt een beeld gegeven van de wijze waarop de risico’s in de loop van het project worden geactualiseerd.
Projectorganisatie Hier wordt een primaire projectplanning gegeven met –voor zover bekend- milestones. De gehanteerde fasering wordt aangegeven en de beheersmethoden.
Er wordt aangegeven met wie het project een relatie heeft (dat kunnen zowel teamleden/onderaannnemers als externe partijen zijn). Te denken valt aan een soort projectkaart.
De bevoegdheden en verantwoordelijkheden van de diverse partijen worden beschreven (een responsibilitychart).
Als de organisatie een standaardmethode van projectmatig werken of een handboek daarvoor heeft, wordt aangegeven waar van de standaard wordt afgeweken en waarom.
Resources en kosten Voor zover nu bekend wordt aangegeven wie er aan het project deelnemen (interne en externe resources), welke kosten het project met zich meebrengt, welke opbrengsten men verwacht en welke kosten en opbrengsten men tijdens de exploitatie verwacht (er is hier natuurlijk een verschil tussen projectresultaten die intern gebruikt worden en projectresultaten die verkocht worden).
Informatiebeheersing Waar staat de informatie rond dit project, welke standaarden worden gebruikt (bv. Word, Excel, MSProject, JPG),welke systematiek van versienummers, vrijgave en geheimhouding worden gebruikt, wie is waarvoor verantwoordelijk, wie is waartoe gemachtigd. Tegenwoordig is papieren informatie zeldzaam, maar bv. bij externe contracten kan dat wel een rol spelen, ook al worden de documenten gescand.
Contractuele zaken Het projectcontract vindt hier een plaats, maar ook alle andere overeenkomsten met betrekking tot het project (bv. onderaannemers, resourcegebruik van andere –interne- afdelingen, betrokkenheid gebruikers, etc.).
Er wordt ook aangegeven hoe contractuele zaken worden geregeld (wie is de juridisch adviseur, hoe worden “interne contracten” gemaakt).
In het bijzonder wordt aangegeven, wat verwacht wordt van de opdrachtgever (inbreng expertise, gegevens, medewerking aan dataverzameling, goedkeuringen, etc.) en wanneer.
Impact op de organisatie Geeft aan, welke afdelingen veranderen op grond van het projectresultaat en hoe groot de impact is. In het bijzonder bij interne projecten kunnen verantwoordelijkheden schuiven, kunnen activiteiten uitbreiden, inkrimpen als van plaats veranderen. Het geheel kan ook personele consequenties hebben.
Relatie met andere projecten Zijn er andere projecten die versnellen of vertragen door dit project, worden resources en bronnen gezamenlijk gebruikt, wordt er gezamenlijk onderzoek gedaan.
Diversen Geeft de projectleider de gelegenheid om punten aan te stippen die buiten de systematiek vallen (uiteindelijk is elk project anders).
Goedkeuring Geeft aan wie het plan hebben bekrachtigd (of nog moeten bekrachtigen).
Bijlagen Alle stukken die relevant zijn voor de beoordeling van het plan, c.q. een verwijzing naar de plek waar die documenten en andere objecten zich bevinden.
Bijlagen zijn van belang, omdat ze het Plan zelf vrijwaren van allerlei details, die bovendien voortdurend aan verandering onderhevig zijn