Scope beheersing bekeken vanuit een Project Management Office (PMO) Bijeenkomst 16 september 2010 18:30 uur ontvangst 19:00 21:30 bijeenkomst Trekker: Eric Menger (Intendance PMO, www.intendance-pm-support.nl) Locatie: Yacht, Eindhoven Aantal deelnemers: 29 Inleiding Eric Menger introduceert een probleem: de CEO wil graag een rapportage hebben over alle projecten inzake tijd, geld en scope *. Nu kunnen we tijd en geld gemakkelijk meten en in een dashbord weergeven, maar het meten we scope (wijziging), blijkt minder makkelijk te zijn? Literatuur is er op nagezocht, maar niets gevonden. Men praat over het vaststellen van de scope, in abstracte termen over het managen van de scope, maar niet over hoe je dat nu meet als PMO. De bedoeling van vanavond is, uit te zoeken of we met z n allen een stuk verder kunnen komen. Of we iets kunnen bedenken hoe we de scope kunnen meten. [Op de avond worden 5 subgroepen gevormd, die een uur over het onderwerp discussiëren ] Samenvatting van de groepsdiscussies (een sterretje achter een term betekent dat hij aan het eind gedefinieerd wordt). Subgroep1. Definitie van een PMO * : een office dat over projecten heen rapporteert aan het lijnmanagement. Onderscheid tussen projecten: je hebt meer creatieve projecten en meer constructieve projecten. Die moet je t.a.v. scopebeheersing andere behandelen. Creatief: 1. Scope vaststellen door decompositie, SMART 2. Scope beheersen door Agile * methoden (interatieve benadering) en regelmatige tevredenheidsmetingen. Constructief: Scope is helder, moet goed gevolgd worden Meetmethode is bv. functiepuntanalyse *. Grootste gevaar is scopecreep * : scopewijzigingen die je nauwelijks merkt. Vraag: wat is de dimensie van scope, als het niet euro s of uren is. Subgroep 2. Je moet uitgaan van deliverables * : om de prioriteit te bepalen gebruik je MoSCoW *. Stef Blom/Eric Menger 1/5
Het resultaat is een vastgestelde scope: (kwaliteits)niveau en functionaliteit. Je kan alleen meten wat vaststaat. Je meet per fase * : wat moet ik hier leveren en voldoe ik daar aan? Dit alles om een beeld te krijgen van wat ik aan het eind kan leveren (eindmeting). Ik moet kunnen meten of mijn eindresultaat conform de oorspronkelijke specificatie is. Dat zegt iets over mijn meetmethoden. Mbt changes: ik moet weten welke gevolgen die hebben (ook, maar niet alleen in tijd en geld). Daaruit moet ik afleiden of ik: de scope moet veranderen mijn uitvoering weer terug moet brengen naar de scope (compliance) Subgroep 3. De scope ligt vast in de PID en de scopedefinitie. Hoe helder die definitie is, hangt (mede) af van het type project. Dat is overigens een aangevochten stelling: een ontastbaar projectresultaat moet wel degelijk helder (SMART) omschreven worden, al kost dat wellicht meer inspanning. Ik zoek naar indicatoren en een meetmethode (formule). Indicatoren vind ik in mij issuelog *. Daarnaast moeten we zoeken naar andere indicatoren. Een formule vind ik, als ik scopechanges ga wegen: impact = (functie van) = [tijd] [geld] [kwaliteit] scopechange = impact * aantal Ik kom op die manier tot een scoringskaart, die lijkt op de manier waarop riskmanagement dat doet. Wat ik daarmee kan meten is de stabiliteit van mijn project. Die stabiliteit moet in ieder geval toenemen in de loop van de tijd: ik moet de scopechange uitzetten in de tijd. Daarnaast zijn scopewijzigingen belangrijker (meer impact) als het project vordert. Subgroep 4. Scope ligt vast door de projectdefinitie. Scopewijzigingen zijn belangrijk wegens het risico op uitloop in tijd en geld, hoe meer scopewijzigingen, hoe groter het risico. Scope is exact meetbaar aan het eind van het project, maar hoe doe je dat in een vroeger stadium? Scope = functies en specificaties. Daarvan zijn functies lastig en specificaties makkelijk te meten. Projectmanagement is het managen van risico s! Scope(wijziging?) is de bandbreedte van het risico. Wat ik wil weten is: * hoe ver ben ik * wat is mijn huidige (schatting van) NPV * * wat is de probability van succes Subgroep 5. Stef Blom/Eric Menger 2/5
Er zijn typen projecten: ontwikkelprojecten/zachte projecten en uitvoeringsprojecten/harde projecten. Ontwikkelprojecten * functie staat vast * methode is ongewis * hak het in mootjes * toets voortdurend aan de verwachtingen Uitvoeringsprojecten * vink het bereiken van functies/specificaties af * houd een change-log bij * zorg voor regelmatig overleg met OG over de change-log: toets aan opdracht en doel opdrachtgever In ieder geval moet je zorgen voor een heldere definitie in het programma van eisen (PVE). Daarnaast is het belangrijk om te werken in hapklare brokken, dat vermindert onduidelijkheid en scopecreep. Inbreng Stef Blom en Eric Menger Tijdens de voorbereidingen op deze avond hadden we zelf de volgende ideeën: Meet regelmatig de tevredenheid/verwachtingen van de klant meet het aantal scopechanges bepaal de impact van elke change * welke factoren beïnvloeden dat * tijd en geld * hoe later in het project, hoe zwaarder de impact bepaal daarmee de scopestabiliteit van het project we vonden (dank aan Joop Pouls) één artikel op internet: http://harsh-thefirstattempt.blogspot.com/2007/03/quantifying-scope-creep-using-scope.html Samenvatting De eerste ervaring was, dat er in het begin onduidelijkheid bestond rond termen en bedoelingen: iedereen blijkt zijn eigen referentiekader te hebben. Ook is duidelijk dat mensen reageren vanuit hun eigen projectervaringen (dus bepaalde type projecten). Onduidelijkheden * project of portfolio * wat is een PMO * wat is een project * wat is projectsucces * wat is de scope en moest dat geen kwaliteit zijn. Voorlopige conclusies Niet elke change is een probleem (in de ontwikkelfase verander je voortdurend) De tevredenheid van de opdrachtgever staat voorop en kan je als PMO meten Het hangt ook sterk af van het type project Je kan alleen meten als je eerst je scope SMART hebt vastgesteld. Het PMO kan de M van SMART volgen. Wellicht is het meten van risico een belangrijker aspect dan het meten van scope Stef Blom/Eric Menger 3/5
Weten we eigenlijk wel wat scope is (heeft het een dimensie. Dat was een interessant moment van bewustwording) We hebben het kort gehad over scope-freeze en scope creep EXTRA Definities Tijdens de avond kwam naar voren, dat niet iedereen dezelfde definitie van begrippen hanteerde. Daarom hier wat definities zoals ze zijn vastgelegd in PMBoK en ICB. Deze definities vind u ook op de PMWiki. Scope 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. Scope is dus essentiëel een dimensieloos begrip! PMO PMO is een afdeling die de organisatie ondersteund met de uitvoering van de projecten, portfolio s en/of programma s. Het PMO verzorgt rapportages voor de projectmanagers, maar ook voor het management. Een professioneel PMO kan zich ook bezig houden met opleiding van de projectmanagers, documentatie, auditing, toolselecties, processen, etc. Een PMO is dus een afdeling, geen staf. Verder is een PMO geen assistent voor een specifieke projectmanager. Een PMO kan wel een project- of programma assistent leveren voor dat ene project of programma. Een PMO werkt over projecten heen en heeft twee gezichten: (specialistische) ondersteuning van de projectleider en rapporteur naar het (top)management. Overigens zijn er PMO s in veel verschillende soorten en maten. Agile Het Engelse woord Agile betekent behendig. Agile is een raamwerk voor softwareontwikkeling en kent diverse uitwerkingen. Agile softwareontwikkeling baseert zich op korte iteratieslagen, met telkens een concrete oplevering. Binnen Agile-projecten is veel communicatie tussen stakeholders. Functiepuntanalyse Functiepuntanayse is afkomstig uit de softwareontwikkeling en is een manier om de omvang of complexiteit van een softwareproduct vooraf te meten. Scopecreep Stef Blom/Eric Menger 4/5
Scopecreep is het in kleine stapjes, ongemerkt veranderen (meestal vergroten) van de scope. Omdat het gaat om kleine wijzigingen verwaarloost men de invloed daarvan op tijd, geld en kwaliteit. Deliverable Tastbaar of ontastbaar resultaat van het project, dat bedoeld is om af te leveren aan de klant. Resultaten die intern zijn voor het product rekenen we dus niet tot de deliverables. MoSCoW Acroniem om aan te geven dat met prioriteiten wordt gewerkt: Must (noodzakelijk onderdeel) Shoudl (belangrijk onderdeel) Could (gewenst onderdeel) Would ( nice to have, wordt waarschijnlijk niet gerealiseerd) Fase Deel van het project (in de tijd), waarin een tussenproduct wordt gerealiseerd. Na afloop van een fase (faseovergang) wordt de beslissing genomen of het project doorgaat en zo ja hoe. Het begrip fase wordt vooral in de Nederlandstalige literatuur gebruikt (afkomstig uit Wijnen, Renes en Storm). In sommige vakgebieden wordt fase meer gebruikt als deelproject, bv. een bouwfase. NPV Net Present Value of netto contante waarde is een rekenmethode uit de boekhouding, waarbij alle waarden (inkomsten en uitgaven) teruggerekend worden naar één tijdstip (meestal het begin van het project). Op die manier wordt er rekening mee gehouden, dat kapitaal bij een andere aanwending ook rendement oplevert. Volgende bijeenkomst Zoals gebruikelijk sluiten we af met een inventarisatie van mogelijke toekomstige onderwerpen. De onderwerpen die nu in de planning zitten zijn: PMWiki: filosofie, betekenis en praktische uitwerking (workshop waarbij deelnemers daadwerkelijk stukken op de PMWiki plaatsen) gepland in okt/nov Sprookjes en organisatie: hoe richten we onze organisaties in, als we rekening willen houden met de psychologie van de mens (nov/dec) 2011 Flow en Covey gepland in jan/febr Risicomanagement Pakketvergelijking voor beheersingstools Toekomst van werkwijzen in projecten (netwerrkorganisaties, gebruik van nieuwe media, het nieuwe werken, etc) Alle verdere suggesties voor onderwerpen zijn welkom, evenals trekkers voor bovengenoemde en gastheren voor bijeenkomsten (melden bij sblom@wxs.nl) Verder wil Stef het trekken van deze programmagroep na 6 jaar graag overdragen. Geïnteresseerden kunnen zich bij hem melden. Eric Menger eric.menger@intendance-pm-support.nl Stef Blom sblom@wxs.nl Stef Blom/Eric Menger 5/5