Definitieproces

Algemeen

Dit proces managet de definitiefase van de project- of programmalevenscyclus. De doelen zijn:

  • een gedetailleerd beeld van het project of programma ontwikkelen;
  • vaststellen of het werk gerechtvaardigd is;
  • beleidsrichtlijn beschrijven die omschrijven hoe het werk zal worden gemanaged;
  • toestemming van de opdrachtgever voor de opleveringsfase verkrijgen.

Het proces wordt op gang gebracht door een goedgekeurd voorstel en definitieplan, dat in wezen hetzelfde is, ongeacht of besloten is de werkzaamheden als project of programma te besturen. Het product bestaat uit een reeks documenten die alle aspecten van het werk beschrijven, waarbij de inhoud en de details variëren al naar gelang de context.

 

Klik op de onderdelen van het diagram voor meer details

 

 

In het kader van het definitieproces zullen het management en de oplevering van de werkzaamheden worden gepland. Vervolgens wordt een samenvatting van de plannen aan de sponsor voorgelegd om toestemming te krijgen voor de opleveringsfase. Hoewel de formele autorisatieaanvraag aan het eind van het proces wordt getoond, dienen de manager en sponsor regelmatig met elkaar te communiceren.

Wanneer het formele verzoek om toelating uiteindelijk wordt ingediend, moet de sponsor een goed beeld hebben van wat er wordt voorgesteld. Dit is met name van belang wanneer in overleg met de sponsor enige voorbereidende werkzaamheden nodig kunnen zijn.

De planning van de wijze waarop het werk zal worden gemanaged, omvat de ontwikkeling van beleid en procedures voor alle relevante functies die zullen worden gebruikt. Wat een 'relevante functie' is, is afhankelijk van de context van het werk.

Om te kunnen plannen hoe het werk zal worden uitgevoerd, moet het team van deskundigen competent zijn in alle relevante functies. De resulterende opleveringsdocumenten bepalen het project of programma en hoe het zal worden uitgevoerd. Zodra zij zijn goedgekeurd, zullen zij als uitgangspunt dienen voor het toezicht op en de controle van de vorderingen.

Thamhain en Wilemon identificeerden dat deze fase van de levenscyclus de fase is waarin conflicten zich meestal op het hoogste niveau bevinden. Als dit gecombineerd wordt met het feit dat het team nog steeds bij elkaar komt en waarschijnlijk in Tuckman's 'storming' fase zit, dan is het duidelijk dat de project- of programmamanager zeer gevoelig moet zijn voor conflicten en moet beschikken over goed leiderschap, conflictmanagement en beïnvloedende vaardigheden.

Een goed uitgevoerd definitieproces legt de basis voor een succesvol opleveringsproces.

 

Aanstellen definitieteam

Bij kleinere projecten kan het identificatieteam over voldoende deskundigheid en capaciteit beschikken om de volledige definitie voort te zetten en uit te voeren. Bij grotere projecten en programma's zal het identificatieteam waarschijnlijk moeten worden aangevuld om voldoende middelen met de nodige capaciteiten ter beschikking te stellen. Bij een bouwproject moeten mogelijk extra specialisten worden aangetrokken, zoals bouwkundig ingenieurs of mechanische en elektrische (M&E) ingenieurs; bij een IT- of bedrijfsveranderprogramma kunnen extra bedrijfsanalisten of systeemarchitecten worden aangetrokken.

Dergelijke technische rollen zijn gericht op het bepalen van de scope van het werk en zullen minder betrokken zijn bij de opleveringsfase van het project of programma. Het opstellen van de managementplannen, scopedocumenten op hoog niveau en initiële opleveringsdocumenten wordt meestal gedaan door rollen die doorlopen om het team te vormen dat de opleverfase managet.

 

Terug naar het diagram

 

Bepaal scope

De in de scopemanagementfunctie beschreven procedures zullen worden gebruikt om de behoeften van belanghebbenden in kaart te brengen, oplossingen te ontwikkelen en waar nodig baten te definiëren. Sommige projecten hebben alleen betrekking op de producten, andere op de baten. De programma's zullen ook betrekking hebben op de baten en vaak op belangrijke bedrijfswijzigingen die nodig zijn om deze te bereiken.

Documenten die betrekking hebben op het project of programma kunnen omvatten:

Het bereik en de gedetailleerdheid van de scopedocumenten zal ook worden beïnvloed door de gekozen levenscyclus. Gewoonlijk worden in een seriële levenscyclus de doelstellingen (producten of voordelen) in dit stadium gedetailleerder gedefinieerd dan in een parallelle levenscyclus. Parallelle benaderingen (zoals Agile) zullen de scope gedurende de hele levenscyclus voortdurend ontwikkelen, zodat de initiële definitie op hoog niveau en flexibel zal zijn.

 

Terug naar het diagram

 

Pre-autorisatiewerkzaamheden

Het is vaak onpraktisch om alle planningswerkzaamheden af te ronden voordat er een beroep wordt gedaan op of begonnen wordt met de uitvoering. Het kan nodig zijn gespecialiseerde materialen of apparatuur aan te schaffen waarvoor lange doorlooptijden gelden; het kan nodig zijn om vroegtijdig te beginnen met het aantrekken van leveranciers via een openbare aanbesteding; het aanvragen van wettelijke of reglementaire goedkeuringen kan tijdrovend zijn.

Gelijktijdig met de planning moet het managementteam alle noodzakelijke voorbereidende werkzaamheden vaststellen die moeten worden uitgevoerd voordat het volledig is gedefinieerd of goedgekeurd. Het voordeel van het plaatsen van voorlopige orders voor materialen of het starten van een aanbestedingsprocedure moet worden afgewogen tegen het risico dat de volgende fase of tranche niet wordt toegestaan.

De uitvoering van de pre-autorisatiewerkzaamheden moet in overleg met de opdrachtgever worden gepland. De voltooiing van deze werkzaamheden moet in de plannen tot uiting komen, maar het feit dat de pre-autorisatiewerkzaamheden zijn voltooid, mag geen invloed hebben op de beoordeling van de levensvatbaarheid van de business case op het moment dat de aanvraag om toestemming wordt ingediend.

 

Terug naar het diagram

 

Voorbereiden besturingsdocumenten

De besturingsdocumentatie omvat intern opgestelde managementplannen en alle relevante externe beleidsdocumenten. Managementplannen kunnen voor vele functies worden geschreven en elke functionele procedure begint met een stap die 'plan' wordt genoemd. Sommige, zoals een stakeholdermanagementplan of een risicomanagementplan, zijn universeel, aangezien de noodzaak om stakeholders en risico's te managen voor alle projecten en programma's geldt. Andere, zoals een batenmanagementplan of een plan voor het managen van aankopen, zijn alleen relevant als het werk ook de levering van baten omvat of als externe leveranciers worden gebruikt.

Bij Praxis is het onafhankelijk opstellen van managementplannen door projecten en programma's een eigenschap van niveau-2 bekwaamheid.

Het opstellen van centraal gecontroleerde managementplannen die zijn aangepast aan de context van elk project en programma is een eigenschap van niveau-3 bekwaamheid.

Op basis van de scope van de werkzaamheden zal het definitieteam beslissen welke functies een managementplan nodig hebben. In meer volwassen organisaties zullen er standaard managementplannen zijn die kunnen worden aangepast aan de specifieke context van de werkzaamheden. In minder volwassen organisaties worden managementplannen voor elk nieuw project of programma vaak opnieuw opgesteld.

Managementplannen mogen niet los van elkaar worden opgesteld. Elk van deze plannen zal worden beïnvloed door de opleveringsdocumenten en andere managementplannen. Als bijvoorbeeld op de kaart van de stakeholders mogelijke tegenstand tegen de werkzaamheden wordt geconstateerd, moet het risicomanagementplan ervoor zorgen dat dit soort risico's adequaat wordt gemanaged.

 

Terug naar het diagram

 

Plan oplevering

De inhoud en omvang van deze activiteit zijn uniek voor elk project of programma. In verschillende planningsdocumenten komen verschillende aspecten aan de orde. Typische voorbeelden zijn onder andere:

Hoewel deze instrumenten en technieken afzonderlijk worden vermeld, is er wel sprake van interactie. Het zal niet mogelijk zijn om elk afzonderlijk voor te bereiden. Het proces zal zich iteratief voltrekken met bijvoorbeeld de eerste versie van de stakeholderkaart met informatie voor het eerste ontwerp van het risicoregister, die op zijn beurt van invloed kan zijn op de initiële investeringsbegroting.

Meestal is het niet nodig of zelfs wenselijk om het hele project of programma in detail te plannen. In een project zal de eerste fase in detail worden gepland, maar de rest van de werkzaamheden zal op een hoger niveau worden gepland. In een programma zullen de plannen voor de eerste tranche gedetailleerder zijn dan de rest van de werkzaamheden. Dit wordt rolling wave planning genoemd. De opleveringsdocumentatie bestaat derhalve uit twee delen: de algemene opleveringsplannen en de gedetailleerde opleveringsplannen voor de eerste fase of tranche.

Zodra het project of programma is goedgekeurd, worden deze documenten " gebaselined ". Tijdens de opleveringsfase zal de voortgang worden gemonitord en vergeleken met de basisdocumenten.

 

Terug naar het diagram

 

Consolideer definitiedocumentatie

Aan het einde van het definitieproces wordt bij de project- of programmasponsor een verzoek om toestemming ingediend. De beslissing om al dan niet door te gaan naar de opleveringsfase zal worden genomen na een evaluatie van de relevante documentatie. Als daarvoor toestemming wordt gegeven, is de volgende stap de beschikbaarstelling van middelen in de eerste fase of tranche van de opleveringsfase. Indien de autorisatie wordt geweigerd, zal een minimale versie van het afsluitingsproces worden uitgevoerd om de informatie van het definitieteam te demobiliseren en te archiveren.

Hoewel de aard van wat ter goedkeuring wordt voorgelegd zal variëren naar gelang van de context, is het gebruikelijk om drie documenten te verstrekken:

  • Project- of programmamanagementplan

  • In dit document worden alle managementplannen voor het project of programma samengevat of samengebracht. Het kan gaan om één enkel op zichzelf staand document met een sectie voor elke relevante functie of een verzameling afzonderlijke managementplannen.

  • In een volwassen organisatie die standaard managementplannen heeft die in haar hele portfolio van projecten en programma's worden gebruikt, zal het alleen nodig zijn dat in het algemene managementplan naar deze plannen wordt verwezen en de aanpassingen worden belicht die in het kader van de lopende werkzaamheden zijn aangebracht. Een sponsor die bekend is met deze organisatiestandaarden hoeft alleen maar naar de aanpassingen te kijken om er zeker van te zijn dat het werk de nodige besturing heeft.

  • Business case

  • In de business case wordt de rechtvaardiging van de werkzaamheden toegelicht. Het geeft een samenvatting van de scope en weegt deze af tegen de kosten en risico's die nodig zijn om deze te bereiken. Daarbij wordt verwezen naar meer gedetailleerde leverings- en contentdocumenten zoals de specificatie, budgetten, het risicoregister, enzovoort.

  • Project- of programma-opleveringsplan

  • Het opleveringsplan geeft aan hoe de doelstellingen zullen worden bereikt. Het bevat een samenvatting van de afleveringsdocumenten en een algemeen tijdschema, de benodigde resources, de cashflow en de organisatiestructuren. Dit plan kan betrekking hebben op alle uit te voeren werkzaamheden of kan verwijzen naar meer gedetailleerde plannen voor fasen, tranches of functionele gebieden, zoals communicatie, risico of kwaliteit.

 

Terug naar het diagram

 

Mobiliseer

Na ontvangst van de autorisatie kan het project of programma worden gemobiliseerd. Hierdoor worden alle apparatuur, faciliteiten en andere resources ingezet die nodig zijn om de doelstellingen te bereiken.

 

Terug naar het diagram

 

Projecten en programma’s

Bij kleine projecten mogen de definitieactiviteiten worden gemanaged en uitgevoerd door de projectmanager, maar de combinatie van een afzonderlijke sponsor en manager is de minimumvereiste. Het kan ook mogelijk zijn de identificatie- en de definitiefase in één proces te combineren.

Dit proces levert veel documentatie op. Teveel is even schadelijk voor het potentiële succes van het werk als te weinig. De documentatiesectie van Praxis moet niet worden gezien als de verzameling documenten die moet worden geproduceerd. Het is eerder het scala aan documenten dat kan worden gebruikt. Het bepalen van de specifieke set die het beste past bij de schaal en complexiteit van elk project of programma is een belangrijk onderdeel van dit proces.

Een belangrijk onderdeel hiervan is het bepalen wat relevante documentatie is met het oog op het aanvragen van autorisatie. Bij kleine projecten kan de documentatie in een presentatie aan de sponsor tot hoofdpunten worden gedestilleerd. Bij grote projecten of programma's kunnen de besturings- en opleveringsdocumenten worden samengevat en aan de opdrachtgever ter overweging worden voorgelegd, waarbij de gedetailleerde documenten indien nodig ter inzage beschikbaar zijn.

In sommige contexten kan het definitieproces worden uitgevoerd door een klantorganisatie. De ontwerpdocumentatie kan worden verstrekt aan een aannemer die de levering plant. Het definitieproces wordt vervolgens opgesplitst tussen de klantzijde van het project en de aannemerszijde van het project.

Bij grotere programma's kan het definitieproces een op zichzelf staand klein project zijn. Het kan als project worden uitgevoerd met de programmadefinitiedocumentatie en het opleveringsplan als producten van het project. Alle aspecten van het procesmodel zijn schaalbaar en kleinere versies kunnen in grotere versies worden genest.

 

Met dank aan het BPUG-team voor de vertaling naar het Nederlands

SHARE THIS PAGE
No history has been recorded.

Definitieproces

Terug naar boven