NCB 1.10 scope & op te leveren resultaten

Beoordeling requirements bij start realisatiefase

Lange titel/ondertitel: 
Incompleet eisen- en behoeftenpakket vaak oorzaak projectfalen
Tijdschrift: 
Projectie

In haar Chaos report van 2009 stelde The Standish Group vast dat 44 procent van de IT-projecten wordt stopgezet als gevolg van slechte ‘requirements’. Dit zijn projecten waarin de uitvoeringsfase (in Prince2-termen de PID) gebaseerd blijkt te zijn op een incompleet of onduidelijk pakket van eisen- en behoeften. De oorzaak van dit probleem doet zich voor in de faseovergang van het (voor)onderzoek naar de realisatie van het project. Op dit raakvlak wordt het werk van bijvoorbeeld de business analist overgedragen aan een projectmanager realisatiefase.

Samenwerken aan eenduidige verwachtingen

Lange titel/ondertitel: 
Opdrachtgever en projectmanager op één lijn
Tijdschrift: 
Projectie

Vele veranderingen worden projectmatig aangepakt. Als je de opdrachtgever en projectmanager achteraf vraagt of het project het resultaat heeft opgeleverd dat was afgesproken, hoor je vaak verschillende verhalen. De projectmanager stelt vast dat het resultaat is behaald binnen de goedgekeurde tijdslijnen en budget, terwijl de opdrachtgever van mening is dat zijn besparingen uiteindelijk niet gerealiseerd zijn of het project wel erg is uitgelopen en duur geworden is.

Scopecreep

Definitie: 

Scopecreep is het fenomeen waarbij de scope langzaam en bijna ongemerkt wordt uitgebreid zonder dat een nieuwe scope expliciet is vastgesteld. Hierdoor worden geld en tijd besteed aan activiteiten en producten die niet zijn begroot cq gepland en de overrun is een feit. Scopecreep is een serieus risico voor ieder project.

Oorzaken van scopecreep

In het algemeen zijn twee bronnen van scopecreep te onderscheiden:

NCB 1.10 Scope & op te leveren resultaten

Definitie: 

De projectscope definieert de grenzen van een project. De op te leveren resultaten van een succesvol project, programma of portfolio zijn materiële of immateriële zaken die door het project, programma of portfolio voor de klant worden geproduceerd. Configuratie wordt gedefinieerd als de functionele en fysieke structuur van projectresultaten zoals beschreven in de projectdocumentatie.

De competentie 1.10 Scope & op te leveren resultaten omvat:

Scope

Definitie: 

Scope betekent bereik of omvang. Als we het hebben over de scope van een project, dan bedoelen we dus iets als 'alles wat geleverd moet worden'.
Scope wordt op verschillende manieren gedefiniëerd:

  1. Projectscope: Het werk dat verricht moet worden om een product, dienst of resultaat met gespecificeerde eigenschappen en functies te realiseren.
  2. Productscope: De eigenschappen en functies die een product, dienst of resultaat definiëren.

Beide definities komen uit de PMBoK.

Scope is dus een 'gewoon' Engels woord en in oorsprong geen specifieke term uit projectmanagement. De betekenis die het dichtst bij het gebruik in projectmanagent komt is the area covered by an activity (Collins Dictionary and Thesaurus).

Zoals ook bij WBS genoemd, is het woord werk hier een zelfstandig naamwoord en geen werkwoord. Daarmee komen beide definities vrijwel overeen: datgene wat afgeleverd moet worden.

 

Zie ook het verslag van Zuid Oost Nederland:

SMART

De afkorting "SMART" is synoniem voor de Nederlandse term "concreet". Het is een afkorting van een vijftal Engelse woorden, die de term "concreet" nader specificeren:

MoSCoW

Definitie: 

Wijze van prioriteiten stellen in het programma van eisen. Het is een afkorting, waarvan de letters staan voor: kwaliteit

  • Must have this - deze eis moet in het eindresultaat terugkomen;
  • Should have this if at all possible - deze eis is zeer gewenst, maar een vergelijkbare eigenschap is ook goed genoeg;
  • Could have this if it does not affect anything else - deze eis mag alleen aan bod komen als er tijd genoeg is;
  • Would like to have but won't have this time around - deze eis zal nu niet aan bod komen maar kan in de toekomst interessant zijn.

Een project wordt als gefaald gezien wanneer niet alle Must-have eisen in het eindproduct verwerkt zitten.

In principe zal je als project de Must Have en Should Have requirements zeker opleveren, de Could Haves mogelijk, de Should Have zijn te interpreteren als Nice to Haves, die normaal gesproken niet worden opgeleverd (leveren immers niet voldoende op).
 

Business Case

Definitie: 

Kwalitatieve en kwantitatieve kosten/baten analyse van een voorgenomen project, als basis voor de go/no go beslissing.

Kenmerkend voor het begrip Business Case is, dat gesproken wordt van 'het bestaan van een Business Case', als de kosten/baten analyse laat zien dat er een goede aanleiding is om het project goed te keuren (er bestaat dus geen 'slechte Business Case'). Eventueel wordt er gesproken van een 'sterke Business Case', als de baten zeer groot zijn in vergelijking met de kosten.

Het schrijven van de Business Case

Bij het schrijven van de Business Case worden de volgende 5 vragen beantwoordt:

1.      Wat zijn de projectkosten (incl. manuren en evt. immateriële kosten (bv. naamsverlies))
De kosten om het projectresultaat op te leveren.

2.      Wat zijn de gebruikskosten (incl. manuren)
De kosten om het projectresultaat te gebruiken.

Baten

Definitie: 

Baten worden gedefinieerd als: stoffelijke voordelen, winst ((Van Dale)).
Enkelvoud is baat; op deze site wordt doorgaans het Engelse woord benefit gebruikt

Gebruik bij projecten

Bij projectmatig werken is het begrip baten van groot belang. Ten grondslag van elk project hoort een kosten-baten analyse (Business Case) te liggen ofwel zullen de verwachte baten na afloop van het project wel opwegen tegen de geschatte kosten? Zo niet, dan heeft het geen zin het project op te starten. het is dus van groot belang de verwachte baten aan het begin van het project zo goed mogelijk te inventariseren en gedurende het project te monitoren en eventueel aan te passen.

Inhoud syndiceren