Scopemanagement

Algemeen

Scopemanagement identificeert, definieert en beheerst doelen in de vorm van effecten, producten, resultaten, en baten. Haar doelen zijn om:

  • de wensen en behoeften van stakeholders te identificeren;
  • de producten, resultaten en baten te specificeren die aan de vastgestelde requirements voldoen;
  • de scope gedurende de hele levenscyclus te handhaven.

Scope is het geheel van producten, resultaten, en baten dat moet worden geleverd. De complexiteit van de scope is de belangrijkste onderscheidende factor tussen werk dat als project, programma of portfolio wordt gemanaged.

Een belangrijk element in het identificatieproces is de vraag of het behalen van de doelen veranderingen in de normale gang van zaken vereist.

Het managen van veranderingen op een laag niveau zou wel eens haalbaar kunnen zijn met behulp van specifieke  projectbeheersstructuren. Uitgebreidere en complexere veranderingen zijn een indicator dat programmabesturing-structuren (of in sommige gevallen portfoliobesturings-structuren) geschikter zijn.

De wijze waarop de scope wordt gemanaged, hangt af van drie dingen: de aard van de doelen (producten, resultaten of baten), de definieerbaarheid van de doelen en de complexiteit van het werk.

De scope van een project omvat doorgaans alleen producten, maar kan, wanneer de complexiteit gering is, worden uitgebreid tot baten. De scope van een opleiding omvat steevast de realisatie van baten en het daaruit voortvloeiende verandermanagement. De scope van een standaardportfolio wordt bepaald door de projecten en programma's die er deel van uitmaken, terwijl de scope van een gestructureerde portfolio wordt bepaald door de strategische doelen die de portfolio beoogd te bereiken.

Scopemanagement bestaat uit vijf terreinen die in harmonie de scope identificeert, definieert en beheerst:

  • Requirementsmanagement registreert en analyseert de visie van stakeholders op de doelen van het werk. Requirements zijn 'oplossingsvrij', d.w.z. ze beschrijven de wensen en behoeften van de stakeholders, maar bepalen niet welke producten nodig zijn om deze wensen en behoeften te vervullen.

  • Oplossingsontwikkeling onderzoekt de requirements en hoe daaraan voldaan kan worden tegen het beste rendement op investering.

  • Batenmanagement drukt requirements uit in termen van baten en beheerd deze tot en met de uiteindelijke oplevering. Batenmanagement is gewoonlijk afhankelijk van het verandermanagement om de producten om te zetten in resultaten en de baten van de resultaten af te leiden.

  • Wijzigingsbeheer is een procedure die mogelijke veranderingen in de scope vastlegt en beoordeelt. Het zorgt ervoor dat alleen wenselijke, haalbare en levensvatbare veranderingen worden doorgevoerd.

  • Configuratiemanagement bewaakt en documenteert de ontwikkeling van producten. Het registreert goedgekeurde wijzigingen en de archivering van achterhaalde versies. De informatie in een configuratiemanagementsysteem helpt bij de beoordeling van wijzigingsaanvragen.

De onderlinge verbanden tussen deze gebieden lopen sterk uiteen. Een eenvoudige scopemanagementprocedure zou de volgende vorm kunnen aannemen (de 'implementatieoplossing' omvat zowel wijzigingsbeheer als configuratiemanagement):

 

 

Dit beschrijft een lineaire aanpak die geschikt is wanneer een klein aantal producten een klein aantal baten ondersteunt, d.w.z. een stuk werk van lage complexiteit dat waarschijnlijk als project zal worden gemanaged.

In een uitgebreider werkstuk waar meerdere producten en baten complexe relaties hebben, integreert scope management de procedures van zijn deelfuncties.

 

 

Requirementsmanagement zal altijd aanleiding geven tot oplossingsontwikkeling, die de tastbare producten ontwerpt. Als er requirements zijn gedefinieerd in termen van baten, dan zal de functie voor batenmanagement in werking worden gesteld. De baten hangen af van de implementatie van de producten, dus oplossingsontwikkeling en batenmanagement moeten in eerste instantie parallel uitgevoerd worden.

Zodra de producten in een specificatie en de baten in batenprofielen zijn vastgelegd, heeft het werk een referentiepunt voor wat moet worden opgeleverd. Dit gebeurt gewoonlijk aan het einde van de definitiefase van de levenscyclus, hoewel de details aan het begin van de fasen of termijnen nog kunnen worden ingevuld.

De definitie van de werkzaamheden die nodig zijn om de specificatie en de baten te leveren, maakt deel uit van het planningsmanagement. Deze werkdefinitie zal gebruikt worden om modellen van het werk te maken die tijdsplanning, resourceplanning, budgettering en kostenbebeheer mogelijk maken.

Zodra de opleveringswerkzaamheden van projecten en programma's beginnen, moeten alle wijzigingen op de baseline scope aan formeel wijzigingsbeheer worden onderworpen en samen met de resultaten van het kwaliteitsbeheer in het configuratiemanagement worden geregistreerd.

Het ontwikkelingproces van producten omvat de uitvoering van werkzaamheden die volledig afhankelijk is van de technische inhoud, of het nu gaat om de bouw, softwareontwikkeling, farmaceutische ontwikkeling of een andere sector. De details hiervan vallen buiten de taak van het P3-management, behalve waar het een raakvlak heeft met het scopemanagement.

Het managen van de baten gaat verder dan het opstellen van de batenprofielen en omvat ook het gebruik van verandermanagement om baten te realiseren. Deze functie kan op sectoronafhankelijke wijze worden beschreven en wordt daarom beschouwd als onderdeel van het P3-management.

De mate waarin gedetailleerde requirements en oplossingen aan het begin van het project, programma of portfolio kunnen worden voorspeld, is van invloed op de wijze waarop de scope wordt gemanaged.

De evolutie van de P3-terminologie heeft geleid tot mogelijke verwarring in de termen "wijzigingsbeheer" en "verandermanagement".

Wijzigingsbeheer heeft specifiek betrekking op de beheersing van mogelijke veranderingen in de scope.

Verandermanagement heeft betrekking op het werk dat gepaard gaat met veranderende werkmethodes in de bedrijfsvoering.

Wanneer het doel goed wordt begrepen en een tastbaar product heeft (bv. bij bouw- en ontwerpprojecten en -programma's), is het gebruikelijk de scope in de definitiefase zo nauwkeurig mogelijk vast te stellen. Wijzigingsbeheer beoordeelt vervolgens alle mogelijke veranderingen in scope, reduceert kostenescalatie en handhaaft de levensvatbaarheid van de business case.

Het is ook nuttig te definiëren wat buiten de scope valt om misverstanden te voorkomen. Duidelijk definiëren wat binnen en buiten de scope valt vermindert de risico's en managet de verwachtingen van alle belangrijke stakeholders.

Wanneer het doel minder tastbaar is of onderworpen is aan ingrijpende wijzigingen, bijvoorbeeld een verandering in de bedrijfsvoering of bepaalde IT-systemen, is een flexibele benadering van de scope nodig. Er kan worden gekozen voor een parallelle levenscyclus en een agile aanpak waarbij de scope gedurende de hele leveringsfase iteratief wordt verfijnd. Dit vereist een voorzichtige aanpak om escalatie van kosten te voorkomen.

Een belangrijke factor bij het managen van de scope van het werk is het maximaliseren van de prijs-kwaliteitverhouding. De discipline van value management brengt een belangrijke reeks procedures en technieken samen die in de zes domeinen actief zijn. Het zorgt ervoor dat de investering in een project, programma of portfolio verbetert voor het potentiële rendement dat het kan opleveren.

 

Projecten, programma's en portfolio's

Zodra een product is gespecificeerd, bepaalt de werkdefinitie de individuele activiteiten die nodig zijn om het product en de onderdelen daarvan te maken. Deze informatie kan worden gepresenteerd als een product breakdown structure (PBS) en/of een work breakdown structure (WBS).

Het ontwikkelen van een breakdown structuur is een iteratieve oefening. Dit zal in eerste instantie gebeuren tijdens het definitieproces, parallel aan de gedetailleerde planning voor andere aspecten van het project (d.w.z. tijd en kosten). Deze drie elementen van de triple constraint (drievoudige beperking) moeten tegen elkaar worden afgewogen, wat verschillende aanpassingen van de details van de PBS en het WBS kan vereisen.

Bij traditionele projecten met een redelijk uitgebreide specificatie van het product wordt de goedgekeurde breakdownstructuur aan het eind van het definitieproces als uitgangspunt genomen. De producten in een PBS worden configuratie-items in een configuratiemanagementsysteem, en elke voorgestelde wijziging van de scope zal door een formele wijzigingsbeheerprocedure gaan.

De terminologie van de scope is de laatste jaren enigszins vervaagd. Praxis hanteert de volgende aanpak om enige duidelijkheid te scheppen:

  • Een doel kan een product, resultaat of een bate zijn.

  • De meeste producten worden formeel overgedragen van de ene partij aan de andere, in welk geval ze kunnen worden geduid naar te leveren prestaties.

  • Een complexer product kan uit meerdere producten bestaan, waarvan sommige op zichzelf kunnen worden opgeleverd.

  • Sommige producten worden ook opgenomen in een configuratiemanagement-systeem en gedefinieerd als configuratie-items.

  • Producten, productgroepen en werkzaamheden om deze te produceren worden gezamenlijk werkpakketten genoemd.

Sommige projecten hanteren een agile benadering waarbij de basis scope in eerste instantie functionele requirements zal omvatten in plaats van volledig gespecificeerde producten. De producten die deze functies vervullen worden ontwikkeld in iteraties die timeboxen worden genoemd.

De programmarequirements worden doorgaans beschreven in termen van resultaten en baten, waarbij de bijbehorende producten door de projecten worden geleverd. De scope van een programma wordt daarom gespecificeerd aan de hand van een blauwdruk, batenprofielen en een lijst van deelprojecten.

De relatie tussen producten, resultaten en baten is zelden één-op-één en er zal sprake zijn van meervoudige afhankelijkheden tussen de producten, resultaten en baten. Deze onderlinge afhankelijkheden moeten worden gedefinieerd en gedocumenteerd. Voor een effectieve oplossingsontwikkeling, batenmanagement, wijzigingsbeheer en configuratiemanagement voor het programma als geheel is inzicht in deze onderlinge afhankelijkheden een voorwaarde.

De scope van een programma is doorgaans vloeiender dan die van een project. Het is onwaarschijnlijk dat voor alle projecten binnen het programma in het begin oplossingen kunnen worden geïdentificeerd en dat het ondernemingsklimaat verandert. Een programmamanagementteam zal de evoluerende scope gedurende de hele levenscyclus moeten managen.

Een standaardportfolio is een opeenstapeling van projecten en programma's met los van elkaar staande doelen. Het primaire doel van een standaardportfolio is het creëren van een infrastructuur die consistente standaarden implementeert en optimaal gebruik maakt van de middelen van de organisatie. De scope is flexibel en is slechts de som van de projecten en programma's die het omvat.

Een gestructureerde portfolio wordt gedefinieerd door de strategische doelen van de organisatie en moet daaraan voldoen. De scope ervan is de som van de projecten, programma's en veranderactiviteiten die nodig zijn om deze strategische doelen te verwezenlijken.

Scope management van een gestructureerde portfolio begint bij het identificeren van relevante projecten en programma's. Het is waarschijnlijk dat bestaande projecten en programma's in eerste instantie zullen worden opgenomen, gedurende de looptijd van een portfolio zullen veel ideeën voor projecten en programma's naar voren komen en strijden om opgenomen te worden in de portfolio. De scope wordt regelmatig herbeoordeeld en bijgestuurd door de prioriterings- en balanceringsactiviteiten in het portfoliomanagementproces. Er moeten geschiktheidscriteria worden vastgesteld, die kunnen worden uitgedrukt in termen zoals het vereiste rendement van de investering of aanvaardbare risiconiveaus.

Het portfoliobestuursproces dient regels te bevatten voor het ter review voorleggen van nieuwe voorstellen, waarbij de portfoliomanager de project- en programmasponsors helpt hun potentiële toevoeging aan de portfolio vorm te geven. Hoewel oplossingsontwikkeling en batenmanagement grotendeels zijn gedelegeerd aan projecten en programma's, zal het coördinatieproces van de portfolio’s ervoor zorgen dat de waarde wordt gemaximaliseerd.

 

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

SHARE THIS PAGE

Please consider allowing cookies to be able to share this page on social media sites.

Change cookie settings
No history has been recorded.
Terug naar boven