AL DOENDE

Het beheersen van de projectscope

De projectscope, ook de scope of works van het project genoemd, heeft betrekking op de omvang van het project. Het is een beschrijving van alle op te leveren producten van het project en van de werkzaamheden (taken), die moeten worden verricht om die producten op te leveren. Het gaat hierbij om de inhoudelijke producten van een project. De op te leveren managementproducten, zoals de business case of de voortgangsrapportage horen bij het beheersaspect informatie.

Plan van aanpak: opdrachtformulering en beheersplan De planning- & controlcyclus, ofwel de plan-do-check-act (PDCA)-cyclus, is een standaardbouwsteen die een organisatie gebruikt voor het beheersen van projecten. De cyclus bestaat uit het maken van het plan van aanpak voor de projectfase, het uitvoeren van dat plan, het periodiek vergelijken van de stand van zaken van het project met het plan en het bedenken en uitvoeren van acties als de uitvoering niet conform plan verloopt. Als het resultaat van de betreffende fase klaar is, stopt de PDCA-cyclus. Alle werkzaamheden zijn immers afgerond. Vervolgens wordt de projectfase geëvalueerd, waarna deze wordt afgesloten. De volgende projectfase start opnieuw met een plan van aanpak. Op basis van het plan van aanpak (met een actuele business case) beslist het management of het project wordt voortgezet. Dit gebeurt ook bij de incidentele terugkoppelmomenten (do) en bij de reguliere terugkoppelmomenten (check). Hierbij gaat het in eerste instantie om het beslissen over corrigerende maatregelen, maar ook het (tijdelijk) stoppen van het project behoort tot de mogelijkheden, bijvoorbeeld in een crisissituatie. Het plan van aanpak is opgebouwd uit twee onderdelen (zie figuur 1): A. De opdrachtformulering en B. Het beheersplan met de tien beheersaspecten van de actuele projectfase De opdrachtformulering beschrijft tien punten. Dit zijn: de achtergrond van het project (1), het doel van de organisatie waar het project een bijdrage aan levert (2), de specifieke benefits van het project (3), het projectresultaat (4, wat is er af als het hele project is afgerond), de fasering met een globale tijdlijn (5), het resultaat van de actuele projectfase (6), de afbakening (7, wat wordt niet opgeleverd), de interfaces met andere projecten (8), de uitgangspunten van het management (9, door het management vastgestelde voorwaarden en restricties) en de businesscase (10, de zakelijke overweging om een project wel of niet te doen). De afbakening, dus datgene wat niet tot het project(fase)resultaat behoort, wordt ook out of scope genoemd. Het beheersplan gaat over de beheersing van de betreffende projectfase en beschrijft de tien beheersaspecten. De link met de opdrachtformulering is het resultaat van de actueel uit te voeren projectfase. Het projectfaseresultaat wordt verder uitgewerkt in de scope van de betreffende fase. Het projectresultaat wordt uitgedrukt in producten (wat is er concreet af?) en in werkzaamheden die hiervoor worden uitgevoerd. Het gaat om het opleveren van de scope (1) met bijbehorende managementproducten (2) volgens afgesproken kwaliteit (3) binnen een afgesproken tijd (4) in een projectteam (organisatie, 6) met medewerker/resources die worden geleverd vanuit een afdeling (capaciteit, 5) met bepaalde kennis, kunde en vaardigheden en onderlinge interactie (sociale dynamiek, 7) rekening houdend met de omgeving (stakeholders, 8) en de risico’s (9) en dit alles binnen een vastgesteld budget (10) voor de betreffende fase.

Figuur 1: Plan van Aanpak -> opdrachtformulering en beheersplan

Een project begint met een idee en eindigt met het opleveren en gebruiken van het projectresultaat. Hierbij doorloopt een project verschillende fasen. Iedere projectfase doorloopt de stappen van de PDCA-cyclus. Projectfase en projectscope Een project wordt vanaf het idee tot en met de oplevering verdeeld in projectfasen. Iedere fase heeft zijn eigen faseresultaat en heeft dus een eigen scope of works. De projectmanager stelt het plan van aanpak op van de fase. De opdrachtformulering wordt voor iedere nieuwe projectfase aangepast aan de actuele omstandigheden (met name de businesscase) en samen met het beheersplan voor die fase aan het management voorgelegd. Het management geeft daarna de go/no-go voor het uitvoeren de nieuwe fase.

Figuur 2: projectfasering en scope of works

Een bijzondere fase is de definitiefase. Het resultaat hiervan is o.a. het Programma van Eisen (PvE). Hierin staat beschreven wat op het einde van het project wordt opgeleverd met bijbehorende prioriteiten. Dit is voor een zeer groot gedeelte de scope van de realisatiefase. Vervolgens wordt de ontwerpfase doorlopen, het detailontwerp opgesteld, de inkoop gedaan, waarna het projectresultaat wordt vervaardigd. In het PvE worden eisen en wensen geformuleerd, waarbij aan de eisen voldaan moet worden. Het gaat dan om eisen en wensen met bijbehorende acceptatiecriteria op het gebied van: functionaliteit, techniek, operatie, materiaal, onderhoud, ontwerp/design, uiterlijke verschijningsvorm, wetgeving, veiligheid tijdens gebruik en onderhoud van het projectresultaat. Het management beslist uiteindelijk over welke requirements wel (in scope) en welke niet worden meegenomen en dus out of scope zijn. Geen enkel project wordt exact volgens de oorspronkelijke requirements opgeleverd. Tijdens de realisatiefase wordt het projectresultaat stap voor stap zichtbaar en gebeurt het regelmatig dat de opdrachtgever zich realiseert dat er toch iets is vergeten, het iets anders moet of dat er extra eisen/wensen zijn. Hiervoor moet een scope change worden opgesteld en beoordeeld. Het is niet verwonderlijk dat in de realisatie de meeste scope changes voorkomen, maar ook in andere fasen is dit mogelijk: iedere fase heeft immers een eigen scope. Een wijziging in de scope heeft ook gevolgen voor andere beheersaspecten, zoals kwaliteit, tijd en budget. Voordat een scope change wordt uitgevoerd worden dan ook eerst de gevolgen voor de andere beheersaspecten in kaart gebracht. Scope creep is een gevreesd verschijnsel binnen de projectenwereld. De meeste projecten krijgen ermee te maken. Bij scope creep neemt de omvang van de uit te voeren hoeveelheid werk ongemerkt en/of ongecontroleerd steeds verder toe zonder dat er een scope change wordt ingediend. Het goed beheersen van de wijzigingen is dan ook erg belangrijk. Het beheersen van de scope Projecten gaan over verandering. Na het project maken mensen gebruik van iets dat er eerder niet was. Het is dus belangrijk de verandering zo goed mogelijk te beheersen om het project succesvol te maken. Meer concreet gaat het dan om het:

  • afbakenen van het projectresultaat;
  • opstellen van een kwalitatief goed PvE met de juiste requirements;
  • voorkomen van scope creep;
  • beheersen van de wijzigingen (change control) van de scope.

Het afbakenen van het projectresultaat gebeurt bij het opstellen van de opdrachtformulering. De projectmanager moet hierbij goed luisteren wat de opdrachtgever wil en wat mogelijk latente verwachtingen en resultaten zijn. Deze worden dan expliciet gemaakt en vervolgens wel of niet opgenomen in het project.

De kwaliteit van het PvE wordt bewaakt door bij het opstellen de juiste mensen te betrekken. Dit zijn bijvoorbeeld de gebruikers van het projectresultaat en ook diegenen die het moeten gaan onderhouden. Een techniek om de kwaliteit te bewaken is uit uitvoeren van een quality review op het PvE. Hiervoor kan de Fagan-inspectiemethode worden gebruikt (zie het artikel: “Kwaliteitsbeheersing voor projecten”). Scope creep wordt voorkomen door wijzigingen tijdig te signaleren, deze te melden en de change procedure te doorlopen.

Het op te leveren projectfaseresultaat wordt vastgelegd in de scope (of works) van die fase. De scope bestaat uit twee onderdelen, namelijk de:

  1. Product Breakdown Structuur (PBS) – het uitsplitsen van het resultaat van de projectfase in concrete producten die op het einde van de betreffende fase klaar zijn;
  2. Work Breakdown Structuur (WBS) – werkzaamheden, uitgesplitst in concrete taken, die moeten worden uitgevoerd, zodat de producten uit de PBS worden opgeleverd.

De PBS en de WBS vormen de basisstructuur voor de beheersing van de projectfase. De PBS is een hiërarchische structuur, waar de belangrijkste output van de projectfase op het hoogste niveau wordt geplaatst. Het volgende niveau toont de componenten waaruit het hogere niveau is opgebouwd. Dit proces gaat door tot op het niveau van individuele producten. Elk product heeft gedefinieerde acceptatiecriteria en afspraken voor kwaliteitscontroles. De WBS wordt direct gekoppeld aan de PBS. De taken uit de WBS (de werksoort) is het niveau waarop ook uren worden geregistreerd. Per taak wordt vastgelegd wanneer deze plaatsvindt, hoe lang deze duurt (beheersaspect tijd: de planning) en hoeveel uren een medewerker eraan besteedt (beheersaspect capaciteit). De PBS wordt beschreven met zelfstandige naamwoorden (het is iets concreets), de WBS in werkwoorden (je moet immers iets doen). In figuur 3 geeft een eenvoudig voorbeeld weer van de PBS en WBS voor de definitiefase. Het faseresultaat is een PvE, een long-list van leveranciers en een Request for Information.

Figuur 3: Voorbeeld definitiefase

Gedurende het project kan de hoeveelheid werk veranderen (meer/minder/ander werk). Mocht dit het geval zijn, dan wordt een wijziging van de scope, een scope change, opgesteld. Een scope change ontstaat door:

  • ander inzicht – de opdrachtgever wil iets anders, een andere uitvoering (ander materiaal, andere kleur, iets op een andere plaats);
  • een fout – er is iets vergeten dat noodzakelijk is;
  • de opdrachtgever die iets extra’s wil – niet per se noodzakelijk, maar het levert wel een beter resultaat of andere voordelen op.

Hiervoor wordt vaak een post onvoorzien opgenomen. Deze posten onvoorzien zijn een standaardonderdeel van het projectbudget. Uit ervaring weet de organisatie dat er wijzigingen optreden en ze houdt hiermee van tevoren rekening. De melder van een scope change is meestal een projectmedewerker of aannemer die aangeeft dat hij meer/minder of andere zaken moet opleveren dan oorspronkelijk is vastgelegd. De scope changes worden bijgehouden op een lijst, de change log. De opdrachtgever en de projectmanager tekenen de scope change af ter accordering. Vaak hebben wijzigingen gevolgen voor de aspecten tijd, capaciteit en geld. Wijzigingen die betrekking hebben op extra capaciteit aan uren gaan ook langs de betreffende afdelingsmanager. Wijzigingen die nog niet zijn goedgekeurd, hebben de status pending. Deze wijzigingen zijn wel al gemeld en ook de consequenties zijn doorberekend en bekend. Op het moment dat ze zijn geaccordeerd, worden ze uitgevoerd en verwerkt in de systemen. Scope changes worden ingedeeld in twee categorieën:

  • Interne change – De wijziging moet binnen het huidige budget worden uitgevoerd.
  • Externe change – Het project ontvangt extra budget voor de wijziging.

Een scope change heeft te maken met wijzigingen in de PBS of een opdrachtgever die wil dat er andere werkzaamheden worden uitgevoerd. Als er meer uren nodig zijn voor dezelfde scope (c.q. dezelfde werkzaamheden) dan komt dat tot uitdrukking in de prognose van de nog te maken uren (capaciteit) of te maken kosten (geld). Hiervoor wordt geen scope change ingediend. In de praktijk gebeurt dit wel. Stel, een hoeveelheid werk wordt uitbesteed bij een externe leverancier. Als die leverancier meer uren nodig heeft dan probeert hij die via een scope change vergoed te krijgen. Hij dient dat een scope change in die er eigenlijk geen is. Hij heeft immers geen extra product opgeleverd, alleen meer uren gemaakt. De projectmanager en de projectcontroller moeten hier goed op letten. Alle scope changes worden vastgelegd en gearchiveerd, zodat aan het einde van het project duidelijk is welke veranderingen hebben plaatsgevonden en wat de gevolgen daarvan waren. De scope change kan ook via een documentflow worden doorlopen. De projectcontroller speelt een cruciale rol bij het beheersen van een project en stelt voor het beheersaspect scope periodiek minimaal de volgende vragen:

  • Staat het onderwerp scope in het plan van aanpak en de managementrapportages?
  • Is de afgesproken hoeveelheid werk gewijzigd?
  • Zijn alle scope changes verwerkt in de systemen?
  • Is de PBS of de WBS gewijzigd?
  • Is er meer werk/minder werk/ander werk en heeft dit gevolgen voor de opbrengsten of kosten
  • Welke gevolgen heeft dit voor de andere beheersaspecten?
  • Wordt er gelet op scope creep?
  • Is de afbakening van het project duidelijk?
  • Is er een quality review van het PvE gehouden?
Tabel 1: in te bouwen controls (interne beheersmaatregelen) in de PDCA-cyclus

In tabel 1 staat in het kort per stap uit de PDCA-cyclus samengevat welke controls er moeten worden ingericht om het beheersaspect sope cin de grip te houden. Conclusie Een project is een hoeveelheid werk bestaande uit één of meer verschillende taken, die worden uitgevoerd door één of meer verschillende soorten resources binnen randvoorwaarden, die worden vastgelegd in tien beheersaspecten, zodanig georganiseerd dat een van tevoren omschreven (en mogelijk tussentijds aangepast) resultaat wordt opgeleverd. Projecten gaan over iets opleveren in de toekomst en daarom zijn de scope en requirements nooit helemaal helder. Wijzigingen zijn dan ook gangbaar en het managen en beheersen ervan cruciaal voor het succes van een project.

Over de auteur:

Ir. Guido Fröhlichs RC (CAP-able) is zelfstandig organisatieadviseur, Licensed NLP-coach en auteur van het boek “ Projecten en projectportfolio in control: mens, methoden en proces”, guido@cap-able.nl en www.cap-able.nl.

Volgende artikel: Nieuws & Events