Project Business Case

(o.b.v. PRINCE2, bron: Vis van Heemst, Hedeman, Fredriksz 2017)

 

Het doel van het thema Business case is om mechanismen aan te reiken om te kunnen beoordelen of het project wenselijk, levensvatbaar en haalbaar is en blijft ter ondersteu-ning van de besluit om het project te starten of voort te zetten.

Inleiding

Het is voor de opdrachtgever essentieel te weten hoe de kosten van het project zich verhouden tot de verwachte baten en risico’s. Wegen de kosten en de risico’s niet op tegen de te verwachten baten, dan is er geen valide business case en is er ook geen reden het project te starten of voort te zetten.

Door handvatten te bieden voor het eenduidig ontwikkelen, onderhouden, beoordelen en verifiëren van de business case en de batenmanagementaanpak, draagt het thema Business case direct bij aan het principe van de voortdurende zakelijke rechtvaardiging en ondersteunt het thema Business case het principe van managen ‘by exception’.

Business case

De business case is de zakelijke rechtvaardiging van het project waarin wordt vastge-steld of een project gewenst, levensvatbaar en realiseerbaar is en daarmee of het inte-ressant is om in het project te investeren.

·  Gewenst: is het nodig voor het realiseren van de bedrijfsdoelstellingen? ·  Levensvatbaar: wegen de verwachte baten op tegen de kosten en de risico’s? ·  Realiseerbaar: kan het product worden gerealiseerd?

In de business case staat waarom de organisatie het project wil uitvoeren en wat de verwachte kosten, risico’s en baten zijn voor de organisatie. Het is daarbij van belang dat dit op een eenduidige manier geschiedt zodat verschillende projecten met elkaar kunnen worden vergeleken en kan worden beoordeeld welke projecten wel en welke projecten geen doorgang moeten vinden.

De opdrachtgever is eigenaar van de business case en moet ook de business case goedkeuren. De opdrachtgever kan de projectmanager vragen de business case voor het project op te stellen. De seniorgebruiker is verantwoordelijk voor het specificeren van de baten en moet er later ook voor zorgen dat met de projectresultaten de noodzakelijke veranderingen worden doorgevoerd en de voorziene  baten worden gerealiseerd. De opdrachtgever kan de projectborging vragen de projectmanager te ondersteunen met het opstellen en bewaken van de business case.

Batenmanagementaanpak

De batenmanagementaanpak beschrijft de acties die moeten worden uitgevoerd om met de projectresultaten de gewenste veranderingen in de lijn door te voeren en beschrijft de acties die nodig zijn om vast te stellen dat de voorziene baten ook daadwerkelijk zijn c.q. worden gerealiseerd.

De opdrachtgever is eigenaar van de batenmanagementaanpak en moet ook de baten-managementaanpak goedkeuren. De opdrachtgever kan de projectmanager vragen de batenmanagementaanpak op te stellen en te onderhouden. De seniorgebruiker is inhoudelijk verantwoordelijk voor de batenmanagementaanpak en dient aan te geven welke acties nodig zijn om met de projectresultaten de gewenste veranderingen door te voeren en hoe, wanneer en door wie de baten kunnen worden gemeten.

Output, uitkomst en baten

In het kader van het thema Business case hanteert PRINCE2 de volgende definities:

• Projectresultaat (output) – het projectproduct dat door het project wordt opgeleverd.
• Uitkomst (outcome) – de verandering als resultaat van het gebruik van de output.
• Bate (benefit) – een meetbare verandering als gevolg van de uitkomst, die als positief wordt ervaren door één of meer belanghebbenden.
• Negatieve bate (dis-benefit)– een meetbare verandering als gevolg van de uitkomst, die als negatief wordt ervaren door één of meer belanghebbenden.

 

Voorbeeld: ·   Projectresultaat: het nieuwe digitale patiëntendossier. ·   Uitkomst: effectiever werken ·   Bate: kortere wachtlijsten en kostenreductie. ·   Negatief bate: afscheid moeten nemen van 10 administratieve medewerkers.

Figuur 1 Doorvoeren van veranderingen (Bron Axelos Ltd.)

De output van projecten stelt de organisatie in staat veranderingen door te voeren, die baten opleveren waarmee de organisatie haar strategische doelen kan realiseren. Het doorvoeren van veranderingen kunnen echter op zichzelf ook neveneffecten met zich meebrengen, die op hun beurt weer positieve, maar ook negatieve baten kunnen opleveren (zie figuur 1).

PRINCE2 voorwaarden voor de business case

Het eerste principe van PRINCE2 is dat ieder project een zakelijke rechtvaardiging ofwel een positieve business case moet hebben. Het thema Business case ondersteunt dit principe door mechanismen aan te reiken om te kunnen beoordelen of het project ook inderdaad wenselijk, levensvatbaar en haalbaar is (en blijft). Daarvoor moet in ieder project tenminste:

• Een business case en een batenmanagementaanpak worden opgesteld aan het begin van het project die gedurende het project worden onderhouden;
• De impact van alle issues en risico’s op de business case worden getoetst.
• De rollen en verantwoordelijkheden voor het opstellen, actualiseren en goedkeuren van de business case en de batenmanagementaanpak worden vastgelegd.

 

PRINCE2-aanpak business case

De business case moet worden ontwikkeld aan het begin van het project en moet worden onderhouden gedurende de gehele levenscyclus van het project. Tijdens het opstarten van het project worden de hoofdlijnen van de business case geverifieerd. Tijdens het proces initiëren van een project wordt de business case uitgewerkt. Gedurende het gehele project zullen alle issues en risico’s moeten worden beoordeeld mede aan de hand van de business case en moet de business case zo nodig daarop worden aangepast. Tijdens managen van een faseovergang en bij afsluiten van een project moet de business case worden geactualiseerd. Tijdens het proces sturen van een project zal de opdracht-gever de business case moeten beoordelen en goedkeuren, daarbij ondersteunt door de andere leden van de stuurgroep (zie figuur 2).

 

Figuur 2 Het ontwikkelpad van de business case (bron: Vis van Heemst, Hedeman, Fredriksz, 2017)

Parallel aan het ontwikkelen en onderhouden van de business case zal ook een batenma-nagementaanpak moeten worden ontwikkeld, onderhouden en beoordeeld. De realisatie van deze baten valt echter buiten de verantwoordelijkheid van het project. Een eventuele batenreview tijdens het project kan echter wel weer tot het project behoren, een en ander afhankelijk van de afspraken met de opdrachtgever.

Ontwikkelen business case (develop)

De initiële business case wordt vaak al ontwikkeld in het kader van een haalbaarheids-studie. In een dergelijke studie worden verschillende alternatieven uitgewerkt en met elkaar vergeleken. Dit zijn in principe verschillende business cases op hoofdlijnen. De resultaten van een dergelijke haalbaarheidsstudie worden voorgelegd aan het bedrijfs- of programmamanagement. Op basis daarvan wordt het projectmandaat verstrekt en kan het proces opstarten van een project worden gestart.

Tijdens het proces opstarten van een project wordt de business case op hoofdlijnen geactualiseerd/opgesteld en opgenomen in het projectvoorstel als basis voor het autoriseren van de initiatiefase. Tijdens de Initiatiefase wordt de business case uitgewerkt en opgenomen in de projectinitiatiedocumentatie als basis voor de besluitvorming de uitvoering van het project te autoriseren.

De business case omschrijft:

• Redenen om het project uit te voeren en hoe het bijdraagt aan de organisatiedoelen.
• Opties die zijn overwogen plus de argumentatie waarom daarvoor niet is gekozen.
• De financiële en niet-financiële baten ten opzichte van de nuloptie.
• De te verwachten negatieve baten zoals hogere onderhouds- en exploitatiekosten.
• Benodigde investeringskosten en financieringsafspraken.
• Duur projectuitvoering en de economische levensduur van de investering.
• Belangrijkste risico’s en het geaggregeerd risiconiveau voor het project als geheel.
• Investeringsanalyse plus advies over mogelijk te nemen acties.

Als het project onderdeel is van een programma kan de business case voor het project ook worden aangeleverd door het programma.

Onderhouden business case (maintain)

Binnen het project is de projectmanager verantwoordelijk voor het onderhouden van de business case, al hoeft hij de werkzaamheden niet zelf uit te voeren. Bij het beoordelen van een issue of risico zal de projectmanager moeten nagaan wat de impact van het betreffende issue of risico is op de business case en zo nodig de business case moeten actualiseren. Verder moet de projectmanager de business case actualiseren op het eind van iedere managementfase en als een afwijkingsplan moet worden opgesteld.

De projectborging helpt zo nodig bij het ontwikkelen van de business case en ziet er op toe dat de business case wordt onderhouden en zo nodig wordt geactualiseerd.

Beoordelen business case (verify)

De business case wordt binnen het project beoordeeld door de stuurgroep onder leiding van de opdrachtgever. De stuurgroep beoordeelt de business case op hoofdlijnen om de initiatie van het project te kunnen autoriseren. Aan het eind van de initiatiefase wordt de  uitgewerkte business case beoordeeld om de uitvoering van het project te kunnen autoriseren.

Het management van de afdeling was enthousiast over de nieuwe telefooncentrale. De nieuwe centrale mocht dan wel € 50.000,- kosten, maar de projectmanager had uitgerekend, dat met de nieuwe centrale iedere medewerker tenminste vijf minuten per dag zou besparen en dat is gelijk aan twee manjaar voor de gehele organisatie. Het eind van het verhaal is echter, dat na de installatie van de centrale dit natuurlijk niet betekende dat er twee man ander werk konden gaan uitvoeren. Er was slechts een theoretische winst behaald. Behalve dat het gemakkelijker werken is met een nieuwe centrale, was er geen zakelijke rechtvaardiging voor de investering.

Bij iedere go/no-go beslissing moet de stuurgroep de business case beoordelen, om na te gaan of het project nog levensvatbaar is en het nog gerechtvaardigd is het project voor te zetten. Na een escalatie moet de business case worden beoordeeld om de uitvoering van het afwijkingsplan te autoriseren. Tenslotte zal de stuurgroep de business case moeten vaststellen aan het einde van het project als basis voor de later uit te voeren batenreviews.

Het bedrijfs- of programmamanagement zal op basis van de business case na afloop van het project in een of meer batenreviews moeten nagaan of de verwachte baten ook daadwerkelijk zijn/worden gerealiseerd en of de initiële investering achteraf de moeite waard is geweest. Dit laatste is van belang als leerpunt voor toekomstige beslissingen.

Bevestigen toegevoegde waarde (confirm)

Om baten te kunnen beoordelen, is het noodzakelijk dat:

• Baten worden geïdentificeerd en gekwantificeerd.
• Meetwaarden worden overeengekomen, waarmee de baten worden vastgesteld.
• Een nulmeting wordt uitgevoerd als de business case wordt opgesteld en iedere keer als de business case wordt geactualiseerd.
• Een besluit wordt genomen over hoe, door wie en wanneer de baten zullen worden gemeten.

De omvang van de te realiseren baten wordt vastgelegd in de business case. Hoe en wanneer de verwachte baten zullen worden gemeten en beoordeeld, wordt vastgelegd in de batenmanagementaanpak. De opdrachtgever is verantwoordelijk voor het houden van de batenreviews. Deze verantwoordelijkheid kan echter ook zijn neergelegd bij het bedrijfs- of programmamanagement. De seniorgebruiker is  degene die moet aantonen dat de geprognotiseerde baten worden gerealiseerd.

Opstellen en onderhouden batenmanagementaanpak

De batenmanagementaanpak omschrijft:

• De scope: welke baten moeten worden gerealiseerd en gemeten.
• Wie verantwoordelijk is voor het realiseren van de verwachte baten.
• De benodigde acties om de benodigde veranderingen te realiseren.
• Hoe en wanneer de verwachte baten kunnen worden gemeten.
• De daarvoor noodzakelijke mensen en middelen.
• De nulmeting op basis waarvan de verbeteringen moeten worden gemeten.
• Hoe de prestaties van het projectproduct zelf worden beoordeeld.

De batenmanagementaanpak wordt in de initiatiefase door de projectmanager opgesteld in overleg met de seniorgebruiker en wordt goedgekeurd door de opdrachtgever bij de autorisatie van het project. Bij iedere go/no-go beslissing tijdens het project én op het eind van het project zal de batenmanagementaanpak moeten worden geactualiseerd. De opdrachtgever zal zijn goedkeuring van de batenmanagementaanpak moeten laten bevestigen door het bedrijfs- en programmamanagement.

De baten die al tijdens het project worden gerealiseerd, moeten tijdens de faseover-gangen al in de batenmanagementaanpak worden opgenomen.

Een investeringsanalyse kan worden uitgevoerd op basis van verschillende technieken: ·   Return on Investment (ROI) = Totaal nettorendement / Totaal aan investeringen ·   Terugverdienperiode = Het aantal jaren of maanden na oplevering dat de investeringskosten worden terugverdiend. ·   Netto Contante Waarde (NCW) = het totaal van de netto-opbrengsten minus investeringen, waarbij inkomsten en uitgaven in de toekomst worden teruggerekend naar de waarde nu op basis van een verdisconteringpercentage. ·   Interne rentabiliteit = het verdisconteringpercentage waarbij de NCW van een project = 0. Hoe hoger de interne rentabiliteit, hoe winstgevender het project is. ·   Break-evenpoint = De minimale omzet die moet worden gerealiseerd om de initiële investering terug te verdienen. ·   De meest gebruikelijke techniek is de Netto Contante Waarde in combinatie met de Interne rentabiliteit. Op basis van deze laatste waarde kunnen investeringen eenvoudig op basis van hun winstgevendheid met elkaar worden vergeleken.

4.5 Business case management

De business case kan op verschillende wijzen worden vormgegeven. Het kan een apart document zijn, maar ook slechts een onderdeel van de projectinitiatiedocumentatie. Sommige organisaties kennen een vaste structuur voor het opstellen van een business case, andere organisaties laten dit (gedeeltelijk) vrij. Soms volstaat ook alleen een PowerPointpresentatie of moet een business case in een document én als PowerPoint-presentatie worden aangeleverd.

Een externe leverancier heeft zijn eigen business case. Dat kan zijn de winst op het project maar bijvoorbeeld ook het verkrijgen van een goede positie in de markt of het verkrijgen van een betere relatie met de klant. Als in een project gesproken wordt over de business case, dat wordt daarmee echter altijd bedoeld de business case van de klant.

Anders dan velen denken is voor een project om te voldoen aan nieuwe wet- en regel- geving ook een business case nodig. Er is namelijk altijd een keuze hoe je aan die nieuwe wet- en regelgeving wilt voldoen. We spreken in dat kader steeds van een gouden, een zilveren of een bronzen optie. Ga je voor goud dan moet het management beseffen dat de daarvoor extra benodigde mensen en middelen niet aan andere initiatieven kunnen worden besteed. Dat is een beslissing die niet licht moet worden genomen.

Datzelfde geldt voor projecten voor de overheid. Vaak wordt gesteld dat een business case een typisch bedrijfsproduct is en niet bedoeld is voor overheidsprojecten. De naam zegt het immers al: ‘business’ case. Niets is minder waar. PRINCE2 en daarmee de business case is ontwikkeld door de Engelse overheid en is juist een typisch overheids-product. Ook bij de overheid groeien de bomen niet meer tot in de hemel en daar moet ook steeds meer de keuze worden gemaakt waar het beschikbare geld aan uit te geven. Niet voor niets zijn in de business case niet alleen de financiële maar ook de niet-financiële baten van belang.

Als een project onderdeel is van een programma levert het programma vaak zowel de initiële business case aan voor het project als de structuur op basis waarvan de business case moet worden opgesteld. Ook is dan vaak de batenmanagementaanpak onderdeel van het bovenliggende programma en geen onderdeel van het project zelf.

Als een project agile wordt uitgevoerd wordt een business case vaak opgesteld uitgaande van het optimale, het verwachte en het minimale resultaat. Het minimaal te realiseren resultaat is daarbij het resultaat waarbij de business case voor het project nog net valide is. Daarbij dient rekening te worden gehouden met het feit dat bij agile werken produc-ten iteratief worden opgeleverd. Baten kunnen daardoor vaker sneller worden gereali-seerd dan in traditionele projecten.

Rollen en verantwoordelijkheden

Voor een beschrijving van de rollen en verantwoordelijkheden voor het thema business case, zie tabel 1.

Bedrijfs-/Programmamanagement ·   Levert mandaat en stelt de standaard vast voor de ontwikkeling van de business case (BC) ·   Houdt seniorgebruiker verantwoordelijk voor oplevering van de baten ·   Is eindverantwoordelijk voor de     batenmanagementaanpak (post-project)   Opdrachtgever ·   Is eigenaar van de BC tijdens het project ·   Keurt batenmanagementaanpak goed ·   Verzekert de aansluiting van het project op bedrijfsstrategie ·   Stelt fondsen zeker voor realisatie van het project   Seniorgebruiker ·   Specificeert de baten zoals die in de BC worden opgenomen ·   Stelt zeker dat de gewenste uitkomst is gespecificeerd ·   Stelt zeker dat met de projectproducten de gewenste uitkomst en de daaraan gekoppelde baten worden gerealiseerd ·   Zorgt voor een opgave van gerealiseerde en nog te realiseren baten tijdens de batenreviews   Seniorleverancier ·   Keurt de BC van de leverancier goed (indien van toepassing) ·   Bevestigt dat benodigde producten binnen de geplande tijd en kosten kunnen worden gerealiseerd

Projectmanager (PM) ·   Stelt de BC op namens de opdrachtgever ·   Voert impactanalyses uit op issues en risico’s die invloed kunnen hebben op de levensvatbaarheid van het project ·   Beoordeelt en actualiseert de BC en de batenmanagementaanpak aan het eind van elke managementfase ·   Beoordeelt en rapporteert over project-resultaten bij de projectafsluiting   Projectborging ·   Assisteert bij de ontwikkeling van de BC ·   Reviewt de impactbeoordeling van issues en risico’s op de BC ·   Bewaakt de impact van de veranderingen in het projectplan op de BC ·   Verifieert en bewaakt BC m.b.t. externe gebeurtenissen en de projectvoortgang ·   Stelt zeker dat de toegevoegde waarde van de oplossing continue wordt bewaakt ·   Bewaakt projectfinanciën voor de klant ·   Stelt zeker dat project aansluit op bedrijfs- en programmastrategie ·   Stelt zeker dat de batenmanagement-aanpak in lijn ligt met de bedrijfs- en programmamanagementstrategie   Projectsupport ·   Houdt de BC onder configuratie ·   Adviseert PM over issues en risico’s die gevolgen kunnen hebben voor de BC

Tabel 1 Rollen en verantwoordelijkheden Thema Business Case
(bron: Vis van Heemst, Hedeman, Fredriksz, 2017)

 

 

 

Business Case Management in Programma’s

(o.b.v. Managing Successful Programmes™)

De Business Case geeft de zakelijke rechtvaardiging van een programma. Het omvat informatie over de te realiseren doelen en de bijbehorende baten en de kosten, tijd en risico’s om het programma uit te voeren. De Business Case geeft tevens aan hoe het programma de doelen en strategieën van de bedrijfsorganisatie ondersteunt.

Ontwikkeling Business Case

Gebruikelijk wordt de levensvatbaarheid van een programma al onderzocht voordat het programma wordt geautoriseerd. Meestal vindt een dergelijk onderzoek al plaats voordat het Programmamandaat wordt gegeven aan de toekomstige Programmaopdrachtgever.

Vaak vindt een dergelijk onderzoek plaats als onderdeel van de bedrijfsplanning voor de komende jaren. Soms vindt een dergelijk onderzoek plaats in een aparte haalbaarheidsstudie of ‘masterplan study’. Voor ieder alternatief binnen een dergelijke studie wordt een Business Case op hoofdlijnen vastgesteld. Op basis van de uitkomsten van de studie wordt een ontwikkelrichting gekozen, wordt het initiatief tot het opstarten van het betreffende programma genomen en wordt het Programmamandaat gegeven om het programma voor te bereiden (zie figuur 1).

Figuur 1 Ontwikkeling project en programma Business Case
(bron: Vis van Heemst, Hedeman, 2007)

Programmamandaat

Het Programmamandaat is het initiatief van het Bedrijfsmanagement om een programma te starten. Het initiatief wordt bij voorkeur vastgelegd in één document waarin het programma op hoofdlijnen wordt gedefinieerd en gepositioneerd in het kader van de bedrijfsmissie, doelstellingen, strategieën en andere initiatieven van de organisatie. Het Programmamandaat is de aanleiding om het proces ‘identificeren van een programma’ te starten.

In het Programmamandaat wordt vastgelegd:
• Strategische doelen die met het programma moeten worden gerealiseerd.
• Verbeteringen die moeten worden doorgevoerd
• Baten die mogelijk met het programma kunnen worden gerealiseerd.
• Kritische succesfactoren op basis waarvan het programma zal worden beoordeeld
• Voorgenomen borgingsmaatregelen
• Inschattingen ten aanzien van de investeringen en de duur van het programma
• Hoe de programmadoelen aansluiten op de bedrijfsstrategie en –missie.
• Lopende investeringen die deel (gaan) uitmaken van het programma
• Externe kansen en bedreigingen die aanleiding zijn om het programma te starten.
• Omschrijving van de huidige organisatie als startpunt van door te voeren veranderingen.
• Context waarbinnen het programma moet worden uitgevoerd.
• Mogelijke benaderingen om het programma te realiseren.

Programmavoorstel

In het MSP-proces ‘identificeren van een programma’ wordt op basis van het Programmamandaat het Programmavoorstel ontwikkeld door de toekomstige Programmaopdrachtgever. Het Programma-voorstel omvat een eerste aanzet van de doelstellingen, gewenste baten, risico’s, aandachtspunten, kosten en tijdsraming van het programma. Het Programmavoorstel beschrijft tevens de Business Case op hoofdpunten.

Het Programmavoorstel is de basis waarop de Sponsorgroep het programma goedkeurt en de start van de definitiefase autoriseert. Het Programmavoorstel is ook de basis voor de programmadefinitie en de basis voor de Business Case.

Programmadefinitie

De Business Case voor het programma wordt voor het eerst als afzonderlijk document ontwikkeld in de definitiefase van het programma. De Business Case wordt parallel ontwikkeld met de Blauwdruk, het Batenrealisatieplan en het Programmaplan en wordt verder afgeleid van het Risicoregister, de Capaciteitsmanagementstrategie en het Capaciteitsmanagementplan. Het niveau van detaillering van de Business Case is afhankelijk van de mate van (on)zekerheid van de beschikbare gegevens.

Programmauitvoering en -afsluiting

De Business Case van de afzonderlijke projecten worden afgeleid van de programma Business Case. Bij wijzigingen in het programma wordt getoetst of de Business Case van het programma nog steeds valide is. Bij plateauovergangen wordt de Business Case geëvalueerd en geactualiseerd om de levensvatbaarheid van het programma zeker te stellen. Bij het afsluiten van het programma wordt de Business Case geactualiseerd als basis voor verdere postprogrammabeoordelingen en geëvalueerd ten behoeve van leerpunten voor volgende programma’s.

Inhoud Business Case

De Business Case geeft de toegevoegde waarde van het programma en daarmee de onderbouwing van de investering van het programma voor de organisatie.

In de Business Case worden omschreven:
• de redenen: waarom moet het programma worden uitgevoerd? Wat is de ‘sense of urgency’?;
• de doelen: wat zijn de doelen die moeten worden gerealiseerd en hoe sluiten deze doelen aan op de bedrijfsstrategie?
• de opties: de verschillende alternatieven die zijn bekeken om de strategische doelen te realiseren, inclusief de redenen waarom daar niet voor is gekozen;
• de baten: de te realiseren baten/opbrengsten, die met het programma moeten worden gerealiseerd;
• de risico’s: de belangrijkste risico’s en het totale risicoprofiel van het programma;
• de kosten en tijdsplanning: de te verwachte noodzakelijke investeringen en de overall planning van het programma;
• de uitgave- en liquiditeitsplanning van het programma in totaal;
• een investeringsvergelijking: de vergelijking van de kosten, baten en risico’s van het programma en de beoordeling of het op basis hiervan valide is het programma op te starten of voort te zetten;
• het advies: het advies aan de opdrachtgever op basis van de investeringsvergelijking en mogelijke te ondernemen acties.

Bij de opties moet altijd de nuloptie worden meegenomen: wat gebeurt er als we niets doen? De nuloptie geldt als basisoptie voor de Business Case. De andere opties worden altijd met de nuloptie vergeleken.

De verschillende baten moeten we concreet en meetbaar formuleren. Ook is het belangrijk om een inschatting te maken, wanneer we een bate kunnen verwachten en hoe we deze moeten meten.

Kosten van een programma

In een programma en dus in de Business Case, moeten een veelheid van verschillende kosten worden meegenomen (zie tabel 1).

Tabel 1 Kosten in een programma en negatieve baten
(Gebaseerd op: Vis van Heemst, Hedeman, 2007)

In de veranderkosten worden ook de kosten voor de Bedrijfsverandermanagers en de veranderteams meegenomen. In de programmamanagementkosten worden de kosten van de Programmamanager, de programmaborging en de Programmasupport meegenomen en ook de kosten voor de te houden reviews.

De kosten van een programma omvatten de projectkosten, de batenrealisatiekosten, de transitie- en veranderkosten, de programmamanagementkosten en de kapitaalkosten van het programma. De toename van de operationele kosten zijn negatieve baten die we als negatieve waarde aan de -batenkant in de berekening van de Business Case moeten meenemen.

Nulmeting en toegevoegde waarde

Belangrijk is om aan het begin van het programma een nulmeting te doen om de huidige stand van zaken te bepalen. Op basis van de nulmeting wordt de nuloptie doorgerekend, evenals de verwachte baten ten opzichte van deze nuloptie als het programma wel wordt uitgevoerd. Dit verschil geeft de toegevoegde waarde van het programma. Deze meting moet elke keer dat de Business Case wordt geactualiseerd, worden herhaald met behulp van de stand van zaken op dat moment. Op deze wijze kan worden nagegaan of er nog steeds een zakelijke rechtvaardiging is om het programma voort te zetten. De al gemaakte kosten, de zogenaamde ‘sunk costs’, moeten bij een dergelijke actualisatie niet meer worden meegenomen.

Scenarioanalyse

Bij de inschatting van de baten is het belangrijk meerdere scenario’s door te rekenen (scenario-analyse). Scenario’s hebben betrekking op mogelijke ontwikkelingen in de toekomst, bijvoorbeeld: is er een sterke reactie van de concurrente of juist niet? Deze toekomstige ontwikkelingen zijn niet vooraf vast te stellen, maar kunnen wel worden doorgerekend. Per scenario kan worden bepaald wat de effecten zijn van die ontwikkeling op de te realiseren toegevoegde waarde van de investering. Daarnaast kan worden geschat wat de kansen zijn dat een bepaald scenario zich voordoet. De vermenigvuldiging van de kansen en toegevoegde waarden over de verschillende scenario’s geeft de gewogen verwachte toegevoegde waarde van de investering.

In scenarioanalyses wordt vaak gewerkt met een optimistisch, een gemiddeld en een pessimistisch scenario. Dit wordt ook wel een gevoeligheidsanalyse genoemd.

Investeringsvergelijking

Bij de vergelijking van de kosten en de baten moet worden gerealiseerd dat er in feite wordt gewerkt met verschillende grootheden. Inkomsten en uitgaven in de verschillende jaren kunnen namelijk niet eenvoudig bij elkaar worden opgeteld. Inkomsten over 10 jaar en uitgaven van nu hebben een heel andere economische en emotionele waarde.

Het verschil in economische waarde wordt bepaald doordat toekomstige bedragen met veel kleinere bedragen nu kunnen worden gegenereerd door simpelweg het geld op de bank te zetten of van de bank te lenen. Binnen bedrijven wordt gerekend met een interne verdisconteringsvoet, die gelijk is met het gemiddelde lange termijn rendement van de onderneming. Voor een goede vergelijking tussen inkomsten en uitgaven over verschillende jaren is het daarom gebruikelijk alle bedragen terug te rekenen naar het heden op basis van deze verdisconteringsvoet. Dit wordt de Netto Contante Waarde-methode genoemd (zie voor voorbeeld figuur 2).
Het verschil in emotionele waarde ligt in het feit dat toekomstig geld meer onzeker is en dat er minder direct gebruik van kan worden gemaakt. De flexibiliteit van het ondernemen neemt af.

Het is daarom belangrijk de verwachte inkomsten en uitgaven uit te zetten in de tijd. Pas echter op voor schijnnauwkeurigheid. Bij dergelijke berekeningen moeten veel aannamen worden gemaakt. Het doorrekenen met twee cijfers achter de komma is dan ook niet zinvol. Voor korte perioden kan uiteraard wel met nominale waarden worden gewerkt.

Figuur 2 Voorbeeld investeringsvergelijking o.b.v. Netto Contante Waarde-methode
(bron: Vis van Heemst, Hedeman, 2007)

Link met projecten

Binnen het kader van het programma zijn er afzonderlijke Business Cases voor afzonderlijke (tranches van) projecten. Resultaten die met behulp van projecten worden opgeleverd, kunnen op meer dan één manier worden gerealiseerd en leveren ieder voor zich andere baten op. Ieder project heeft daarom ook weer zijn eigen Business Case nodig, omdat voor ieder project afzonderlijk moet worden vastgesteld of er voldoende rechtvaardiging is om dit specifieke project uit te voeren.

De programma Business Case is echter meer dan de optelling van de Business Cases van de afzonderlijke projecten, zoals de totale kosten voor het programma meer zijn dan alleen de investeringen in de projecten. De totale baten van een programma zijn ook meer dan de baten van de individuele projecten. Het geheel is meer dan de som der delen.

Opstellen Business Case

De Business Case is in principe geen document met een hoge mate van detaillering. De onzekerheden ten aanzien van de omgeving, de bedrijfsdoelen, de te realiseren baten en de kosten en tijd om de benodigde bekwaamheden te realiseren, zijn daarvoor te groot. Weerstanden in de organisatie en kansen in de markt zijn weerbarstige begrippen. Daar is geen eenvoudige formule op los te laten.

Toch moet er aan een programma worden gerekend. Berekeningen zijn nodig om de besluitvorming te faciliteren. Er zijn vele andere projecten en programma’s die ook gouden bergen beloven. Concrete berekeningen leggen nu eenmaal meer waarde in de schaal dan mooie woorden. Een beste schatting is daarbij beter dan helemaal geen schatting. De schattingen moeten echter niet het niveau van berekeningen krijgen, zoals bij concrete projecten of bij boekhoudkundige nacalculaties. Het niveau van berekening zal eerder gelijk zijn aan het niveau van berekeningen die ten grondslag liggen aan de bedrijfsplannen en bedrijfsstrategieën.

Uiteraard leveren de computermodellen die gebruikt worden voor de berekening van de Business Case exacte getallen. Dit is echter een schijnnauwkeurigheid. Kleine veranderingen van de input in deze modellen leveren vaak grote verschillen op in de output. Het is daarom aan te raden meerdere scenario’s door te rekenen. Dit geeft een veel beter beeld over de hardheid van de zakelijke rechtvaardiging, dan een enkele berekening, hoe nauwkeurig ook.

Na afsluiting van het programma eindigt de Business Case niet. De Programmaopdrachtgever moet ook na de afsluiting zich ervoor blijven inzetten dat de organisatie de nog resterende doelen en baten van het programma realiseert.

Beoordelen Business Case

De Business Case is een van de kerndocumenten die moet worden beoordeeld en goedgekeurd, voordat de Sponsorgroep op het eind van de definitiefase het programma goedkeurt en autorisatie geeft voor de uitvoering van het programma. Verder moet de Business Case minimaal worden getoetst en geactualiseerd aan het eind van iedere cluster, maar bij voorkeur ten minste iedere zes maanden.

Bij beoordeling van de Business Case moeten de volgende vragen worden gesteld.
• Kunnen we ons het programma nog steeds veroorloven? Is er voldoende financiering?
• Kan het resultaat nog steeds worden gerealiseerd? Is dit realistisch?
• Levert het programma nog steeds voldoende toegevoegde waarde voor de organisatie?
• Is het programma nog steeds solide? Hoe kwetsbaar is de Business Case van het programma voor kleine wijzigingen en/of vertragingen?
• Zijn de alternatieven serieus beoordeeld? Is het Projectendossier nog steeds de optimale mix van projecten?
• Ondersteunt het programma nog steeds de strategische doelen van de organisatie?

Verantwoordelijkheden

De Programmamanager is verantwoordelijk voor het opstellen en actualiseren van de Business Case en voor het managen van de uitgaven versus het investeringsplan. De Bedrijfsverandermanagers identificeren en kwantificeren de baten en stellen vast wat de beste meetmethode is. Ook zorgen zij voor het doorvoeren van de verandering en het realiseren van de baten. Het Programmabureau verzamelt en onderhoudt de benodigde informatie. De Programmaopdrachtgever is eindverantwoordelijk voor het realiseren van het einddoel van het programma en van het realiseren van de Business Case van het programma en het zeker stellen dat het programma blijft aansluiten op de bedrijfsstrategie.

Programme management – an introduction (part 1)

Change is part of everyday life. People change their place of residence or work, children leave home or the garden is changed; it’s part of life. The increasing social environment appears to bring us more choices, and these lead to more changes, which follow one another in ever-faster succession. This is also the case in organizations. Globalization, increased competition and changes in clients’ demands are just a few examples businesses are faced with. As the saying goes ‘change is the only constant’.

But the implementation of change is not easy. Change always involves risks and disadvantages, as well as advantages. They are dependent on many other factors; as soon as you change one item, you have to change the other factors too. Various parties are also involved, with different interests and priorities. Many changes are unsuccessful, cause much more trouble or are seen with hindsight to be more painful than necessary. There is, therefore, a clear need for a method of implementing change and thus increasing the chance of success. Programme management is such a method for successful and structured change implementation.

Project versus Programme
But first; both projects and programmes deliver change to an organization, but there is a fundamental difference between a project and a programme. Based on the book ‘Project management based on PRINCE2’  the following definition of a project is being used:

A temporary organization created for the purpose of delivering one or more business products according to a specified Business Case

The Executive is ultimately responsible for exploiting the outcome and achieving the projected benefits. The benefits are only realized once the project has been closed.  A programme on the other hand is more than simply delivering an outcome. With a programme there is also the responsibility of achieving the benefits or part of the benefits during the course of the programme. A programme is defined as:

A portfolio of projects and activities that are co-ordinated and managed as an unit to achieve one or more predefined strategic objectives

A programme achieves one or more corporate objectives of strategic importance. A programme is a temporary management structure covering all projects and a temporary management structure in between the projects and the (top) management of the corporate organization in order to ensure that new corporate objectives involving change are achieved in a structured manner.

In general the outcomes of several joint projects are needed in order to achieve specific corporate objectives. The duration time of a programme is longer than the duration time of related projects.

A programme must consciously be stopped. With a programme, the pros and cons concerning the investments in the change and the benefits to be achieved to justify the existence of a separate (programme) organization must be weighed up. In practice, a time will come when it is no longer necessary to manage the changes in a separate organization from a programme, but that this can better be done in the line organization. The programme can then be decommissioned and the programme organization discharged by the Programme Director. The end of a programme must therefore be self-determining and is not a direct consequence of a predefined outcome as with a project, where delivery of the outcome automatically signals the end of the project.

The benefits are defined from the corporate objectives of an organization that must be achieved with the programme. Therefore, a programme must develop a number of activities  besides carrying out a number of projects in order to exploit the outcomes. The organization must be prepared for the changes to be implemented. The outcomes of projects must be implemented in the organization, the organization must work with the new possibilities and it must be ensured that the new method of working is “business as usual” and that the corporate objectives are actually achieved with these new possibilities.

Programme management
Programme management provides a framework for defining and implementing changes in an organization. This framework covers making a view explicit, defining the blueprint and providing the added value of the future situation for the organization, as well as the organization and processes in order to implement changes and achieve the added value.

Within programme management the necessary projects are identified and started, the interrelationship of the projects is coordinated and the project outcomes to be delivered are tailored to one another. In addition, programme management covers identifying the added value of changes for the corporate organization. The added values are made explicit and managed throughout the life of the programme.

The basis for the programme must lie in the contribution of the objectives to be achieved in the programme to the corporate strategy in relation to work to take place. The basis for a programme is laid down in the Business Case. The Business Case must be checked throughout the life span of the programme.

Figure 1. Results of projects and outcome of programmes
(source: Project management based on PRINCE2)

Programme management environment
Corporate strategies can be implemented by individual company sections. Usually several company sections are involved in achieving the corporate strategy. It is recommended therefore to define programmes in order to achieve corporate strategies. Programmes make it possible to implement strategies over several company sections.

Essential to a successful programme is that dominant corporate strategies are established in the corporate organization and that they are supported by management and those carrying out the work. Furthermore, it is important that programmes are able to anticipate change in the corporate strategy and can be changed to the new initiatives.

Programmes trigger projects where new products and/or services are developed that are needed to implement corporate strategies, until the future vision becomes reality and the added value of the programme is achieved.

A clear picture of the future corporate organization needed to develop the new corporate vision is essential for the establishment of programmes. This picture, the blueprint of the new organization, must be clear and unambiguous to all parties and remain so for the duration time of the programme. Figure 2 shows the dependencies between projects and programmes.

Figure 2 Dependencies between projects and programmes
(source: Project management based on PRINCE2)

The programme management structure
The implementation of change in organizations requires a focused vision towards that change and a structured approach, coordination and management of the change activities. Programme management delivers this approach and helps to reach such a vision through a defined organization structure, phasing, processes, activities, products and the method of thinking. The methodology puts the organization and staff in a position to implement changes and to deal in a controlled way with uncertainties and upheavals that will appear during the process. The structure is also a base for development and completion of the necessary skills in order to implement the changes.

Programmes are different from projects. Whereas projects deliver products or services, programme management is based on implementing changes or realizing added value for the organization. Programme management is thus not only based on coordinating projects necessary for the changes, but also on implementing and securing the changes in the organization and realizing the benefits envisaged by the organization.

When should programme management be used?
With many projects and activities in an organization, the relationships between these and their dependencies on the (often complex) environment mean that change management demands a great deal of effort from the line organization and operational management. Carrying out changes with a limited capacity to realize them all has led to a need to find another method of control for managing changes. The characteristics of this approach are that we are dealing with phases characterized with much uncertainty and risk, and also with a clear link to the strategy of the business. Programme management can make a particular contribution in situations whereby:

• There is a lack of clarity as to the goals to be achieved;
• Complex changes need to be implemented;
• There are strong dependencies between many projects and activities;
• The available capacity is limited;
• A turbulent environment exists within which the changes that are to be implemented;
• There are many risks connected with implementing the changes;
• There are various possibilities for implementing the changes;
• The outcome of various projects is needed to make changes possible;
• Management has to spend too much time on implementing the changes;
• Implementing the changes has too great an impact on the primary processes, jeopardizing continuity;
• This requires co-ordination of several initiatives, with common ground with existing business processes.

In summary, programme management can be used in situations where relations between the specialties of groups of projects are complex and where efficient use must be made of the shared capacity. Programme management can also make a positive contribution where the total costs of the change must be limited and managed, and where the focus on the objectives and benefits must be realized without too much disturbance to the primary process. Another reason for switching to programme management can be that senior management has to spend less time on changes.

Advantages of programme management
The benefits of programme management come from co-ordinated change management, governing the mutual dependencies between projects and activities, and a central focus on realizing the benefits. The most important advantages are:

• Effective realization of changes by an integral (planned and managed) approach to various elements of change, without existing business processes being disturbed unnecessarily
• Effective response to strategic initiatives by bridging the ‘gap’ between strategy and the realization of projects and activities
• Focus on the goals of changes by providing a framework for senior managers in the organization whereby they can govern and manage the change process
• Efficient resource management whereby programme management provides mechanisms for project priorities and project integration
• Better risk management by placing the complexity and range of the Project Portfolio in a wider context
• Realization of objectives and benefits by setting-up a formal process of Benefit Management.
• Important steps in the process are: identifying, defining, monitoring and measuring the benefits.
• Effective management of business objectives (Business Case). Setting-up and maintaining the Business Case allows constant appraisal of the best solutions from a business point of view and whether the continued implementation of changes is still desired
• Gradual transition from current to new business processes. The transition from the current organization to the new way of working is a separate aspect of programme management.

Books of Gabor Vis van Heemst

Since 2001 I published several books about project and programmemanagement.

Check my LinkedIn

and the website www.intrprimus.nl

Improving projects by project leadership – part 2

In my blog article of April 26th I wrote about the importance of leadership in organizations and projects. As a result I got a lot of questions and comments.

I want to share a comment of my friend Allard de Ranitz :

“Personally I always enjoy the trivia that is created on any business level when people start using terms like maturity and leadership, without taking time with each other to identify what it is that we’re talking about. We all know what we mean, more or less, but the misunderstanding usually occurs right there in those areas; the more and the less…. Besides that, it is pretty difficult to support people in increasing their leadership and advancing their maturity levels when we don’t know exactly what we’re advancing or increasing, other than better, more and up… which are usually terms that coincide with measurable aspects of What we do and not How we do things.

a

The English language has a great word that helps identify the characteristics of maturity and leadership. ‘Responsibility’ when taken apart there’s two words that provide meaning to the word itself in a continuum. Response and Ability. With increasing ability to respond, you’re better equipped to take responsibility. Responsibility as such is all about the Response one creates as an answer, effect of or counter to a certain influence. The more mature your response the more effective the flow of things continues. Immature responses, therefore create disruptive flows. This is important to recognize, since it looks at maturity in a different way.

a

Most of the maturity models we know, like CMM(i), INK or EFQM consider maturity to be an increasing level of quality based on system borders. Level one deals with activities, projects, singular responses to stimuli where level two is based on repetitive action responses; being capable of repeating the same response to triggers, that worked the first time, when similar stimuli came your way. Level three already starts to recognize a larger scale outside of your own influential sphere to be reckoned with where levels four and five (and possibly beyond that where other models are concerned) increase the view of the system that is influential for and partial to an ‘Able Response’ – being that type of response that supports, possibly increases and not disrupts, the flow of things within that entire system.

a

Maturity therefore, has only to certain limitations to do with the skills with which a (project) manager, person, leader, fulfills there task. Much more so however, it deals with the overall capability to take perspectives; to see the whole picture from all different angles and to be Able to Respond to a trigger in such a way that the entire system flow is maintained. Just as ecological principles only stand up in larger perspectives, because the earth as a whole is one complex, intertwined related system, the same principle accounts for projects having to be viewed in light of business cases and organizational change and the maturity of organization responses to change having to be judged by their larger environment and effects on that.

a

In the smallest sense I respond to triggers, because of me having to respond to make me better; an egotistic, self oriented view on maturity. I can still show prevailing traits of managerial capacity, however since it is merely for my benefit, maturity cabn be considered low! When I can grow beyond ego and look at myself and the others concerned, my perspective becomes more ethnocentric and involves the good of the group. Maturity increases, since I encompass my fellow men / collegues into the course of action, however I can still and will disrupt the flow of my entire life system, merely trying to do what is good for me and the other and make money. The fact that I’m polluting my environment, wreaking havoc on  all other outside my system, is not included in my perspective, causes my ability to respond to only partially create flow, however disrupting it slowly on a larger level. When being able to see the entire system we’re part of and therefore creating perspectives on a system/world centric way, we’re able to make balanced decisions for the good of the entire flow. Possible shortly disrupting smaller streams, however in the end being able to create flow for the entire system and not merely for a partial impact. This is what Responsibility and the ability to Respond is all about.

a

To be able to develop the maturity of your Project managers, therefore is to be able to increase their way of perspective taking into a more systemsapproach and world centric view of responding. How do you do that, I can hear you ask. Well, there’s no simple conventional answer to this question.

a

The way forward lies in developing the consciousness of the Project manager. What research has found, is that the higher the consciousness the more empathic and world centric the being is. I suggest we incorporate a new way of developing people in organizations. Next to developing skills, knowledge and experience in the field and the subjects, which are all extremely necessary to be able to succeed, we should also start developing the personality beyond the ego. The conscious Project manager is someone who possesses all necessary skills and the personality to match it. A conscious human in a conscious mind. That’s Maturity and that is the maturity that creates a Great Response Ability!!!”

Great Event at Atos Origin!

What a great event and an overwhelming number of visitors! Over 100 people came to the competence meeting of AtosOrigin of June 15^th where I gave my presentation about the co-operation between project executive and project manager.

It was a mixed public of project and programme managers, transition managers and other people involved with Atos projects.

foto: Patrick de Goede van Eijk

The title of the event was: ‘Project Managers are from Mars, Executives are from Mercury’. The key question of the evening was if this was really the case and if so what is needed to bridge the differences and make it a successful combination.

I started with a video newsflash about two in itself successful projects, but together were a great fiasco; new street lightning and parking spaces in a street in Rotterdam. The parking spaces were neatly paved and big enough for the cars. The lampposts were standing straight up and working properly….but some of them were standing in the middle of the road or the parking spaces.

Where did this go wrong? How can we prevent ourselves for these kind of fiascos?

In the presentation we took some time to look at the major failure factors for projects and concluded that at least half of them involved the project executive, the project manager and mainly their relationship and co-operation. So naturally, we had to look at what to do about these kind of situations, with the main focus on the project managers site. We can’t order the executives to change, we can only change our own behavior.

What can I, as project manager do, so the project is going to be successful? And what is my responsibility to work successfully with the executive?

Am I professional enough to ask myself the questions ‘Do I start a project while I know it can’t be done? Do I start when no ownership or commitment by the executive is in place?’. The main question is if the project manager is responsible to solve everything.

It is all there in the beginning of the project. We have an idea about what the project should be. Let’s consciously appoint the project executive and manager! It feels to business as usual to say, but the reaction in the audience was clear. This is felt as an issue for their projects. How to get the executive to not only accept the role, but also to fill the responsibility? So he is comfortable with his role and knowing how to co-operate together with the project manager.

The project manager is not a tumbler you can push around and following every move of the executive. We have to be a professional all the time, that’s what the executive may expect from us. Project managers are responsible for managing the project and that’s what we do best. But still things can go wrong or change during the project. Then we have to be clear about the situation, the causes, possible solutions and our advice. It is in these situation where the project is getting exciting and were our project management skills are needed most. This is where we can proof the executive he has a partner in crime and we are working on the same goal.

But to get such a relationship you have to build one. So have a formal but also a informal communication with your executive. This helps to build trust and understanding between the two of you. He will probably make time for you easier, when you have a good relationship. It also makes the formal and more difficult discussions easier to handle, because you both feel your are still on the same page.

In the first half of the presentation I told the story about the fundamentals of the project. Basically it was about creation a common feeling of working on the same goal in a project. There was some small discussion during the first half, but our goal was to have a strong discussion in the second half after dinner. We had some propositions where people could react on by holding up a green or a red card

Some of them felt like a commonly known fact, but still there was lots of discussion about these propositions. For example:

Proposition 1; hiring a (internal) project manager solves all the executives problems.

95% of the people were not supporting this proposition. They claimed that they were there to manage the project but they don’t have the power to solve all possible issues. There the executive is needed.

In the projects they were sometimes feeling the executive is using them as bin. ‘Why should I be bothered with these problems, where do I have you for then?’. It is important to keep the executive committed to the project and aware of his responsibilities. Manage his expectations about your co-operation and make sure he has a quick win every 3 months (for example) to show around.

Another proposition; a capable project manager doesn’t look beyond the borders of his own project.

A common feeling with the project managers in the room was that this was a bad suggestion in a theoretical environment, but a wise suggestion in their daily business. There was more than enough issues in their own project to cope with. It is hard enough to realize the project without managing the interfaces with the ‘outside world’ and by doing so the project would stretch the planning even more.

There was quite a discussion about this topic. Everybody felt this was what really should be done, but how to do this in their project environment? Focus on the projects end result and end goal is good, but don’t forget the stakeholders and other projects and programmes. Like in the short film about Rotterdam. You can’t manage a project with blinkers on.

Finally

It was very rewarding for me to notice all the involvement during the presentation. We had some beautiful discussions and I think some eye-openers for them to work on. I am also glad to see the organization is willing to work on this and we planned some next steps where we can help the organization together. I want to thank AtosOrigin and all attendants for their input and hospitality. Hope to see you all again soon.

Differences in PRINCE2® v2009 versus v2005

In 2009 OGC, the owner of the project management method PRINCE2, has released a new edition of the PRINCE2 manual. In this 2009 edition there are several changes were applied to improve the method. The fundamentals of the PRINCE2 method have not changed. The most important improvement is that the underlying principles of PRINCE2 are now explicit guiding principles for the content of the themes and processes as these are defined within the method (see figure 1).

Figure 1. Differences in PRINCE2TM v2009 versus V2005
(source: Project management based on PRINCE2, 2009 Edition)

a

The principles are also emphatic guiding principles for tailoring the method to a specific project in a given context. It is explicitly stated that deviation from the use presented in the themes and processes is possible, but that if not all PRINCE2 principles are applied in a project, it can no longer be termed a PRINCE2 project. The changes that have been implemented can be distinguished according to methodical changes, changes in the structure of the manual and smaller changes within a specific theme, product or process.

a

Structural changes

The most important structural changes are:

• Firstly, of course, the new chapter that has been added in which the PRINCE2 principles are explicitly named and described.

• More attention has been paid to adapting the method to a specific project in a given context.

• This has now become a separate chapter called Tailoring PRINCE2.

• The method is less prescriptive. With regard to many subjects, it is stated that deviation from the approach described is possible. It is stated that it is better to work according to the spirit of the method than to adhere to the rules of the manual.

• The method is less bureaucratic. Sub-processes have been swapped for activities. Fewer management products have been defined.

• There is now greater emphasis on learning from experience. In the first PRINCE2 process, learning from experience gleaned from previous projects is expressly mentioned as an activity.

• Lessons now come up for discussion in all reporting and meetings. Conveying one’s own experiences to the corporate or programme management is now included during stage boundaries too.

• There is a clearer link to other OGC methods, such as Management of Successful Programmes (MSP) and Management of Risk (M_o_R).

• Strategies have been introduced for risks, quality, configuration management and communication, all in line with MSP.

• There is more reference to techniques to be used. Reference is made to frequently-used techniques, not only in planning but also for risks and (for example) the Business Case.

• Delivery of the results in stages is pointedly assumed.

a

Changes to the manual

• First of all, the manual has been reduced from some 450 pages to around 330 pages, primarily by removing duplication of components and processes.

• The components have become themes and have been put before the processes. As themes they have also become what they are, namely areas for attention, without wishing to create an impression of being integral to a project – the term ‘component’ suggests.

• The eight components have been reduced to seven themes. Configuration management has now been integrated into the Change theme.

• Control aspects have now been renamed as the Progress theme.

• The Techniques section is now defunct. The techniques are now described in the relevant themes, alongside other important techniques.

• The number of processes has been reduced from eight to seven. The Planning process has now been included as a procedure within the Planning theme. This puts planning in line with other procedures, such as those of risk management and change control, which always used to be dealt with like procedures within the components/themes.

• There are more support and guidelines for the members of the Project Board and the senior management. To this end, the OGC has even published a separate manual with a separate exam associated with it.

• The appendix incorporating risk categories has become defunct.

• The health check has now been arranged according to the different steps in the project process.

a

Detailed changes

Themes

• Business Case – The Post-Project Review Plan is now called Benefits Review Plan. This plan is now created during initiation of the project and assessed by the Project Board during project authorization. For each stage, the Benefits Review Plan is brought up to date. Justification of the project is now based on whether the project is wanted, viable and achievable. The lifecycle of the Business Case is now subdivided into developing, verifying and confirming. The Business Case now also contains an Executive summary, dis-benefits and benefit tolerances. In the case of delivery in stages, benefits reviews can be held during the project.

• Organization – The four levels of management are now called corporate or programme management, directing, managing and delivering. The Change Authority has now been included in the organization chart. The configuration librarian is now part of the Project Support. In line with MSP, the Senior User is now responsible for identifying and defining the benefits and the operational or programme management holds this role responsible for demonstrating that the benefits forecasted are being achieved. The agreements on communication are now detailed in a Communication Management Strategy.

• Quality – There is now greater emphasis on the quality of the products. The quality path has been replaced by a quality audit path with overlapping paths for quality planning and quality management and quality control. The ‘project product’ has been introduced, which refers to the project’s final product to be delivered. The Project Product Description contains the customer quality expectations, the acceptance criteria and the quality tolerances at project level. The Project Quality Plan has been replaced by the Quality Management Strategy. The Stage Quality Plan is no longer distinguished separately in the Stage Plan.

• Plans – The method now states that a Product Description is required for all products identified. In contrast to this, the technique focus on products, which is now explained within the Planning theme, is less prescriptive. Thus for external products they only ‘advise’ choosing an anomalous colour or shape, for example.

• Risks – This chapter has been completely revised and therefore ties in heavily with the Management of Risks (M_o_R) method from the OGC. The agreements on approach to risk are now set down in a Risk Management Strategy. The risk process has been modified. Risks are now distinguished according to opportunities and threats. The responsibilities of the risk owner have been extended and the role of a risk-actionee is now recognized. The Risk Log has now become a formal Risk Register, which is created during the initiation of a project.

• Change – The Daily Log is now also used to record issues and risks that can be managed informally. The change procedure has been modified. Formal issues are now recorded in an Issue Register. The configuration management has been fully integrated into the Change theme. The approach to change control and configuration management is now recorded in the Configuration Management Strategy.

• Progress – The Progress theme replaces the Control component. This theme now concentrates entirely on the implementation of the project. The control aspects in the processes Starting up and Initiating a Project and Closing a Project are now no longer dealt with within this theme.

a

Processes

• Starting up a Project (SU) – Now also specifies the review of previous lessons. The project organization, the project approach and the Project Product Description have now been incorporated into the Project Brief. The Daily Log and Lessons Log are arranged in this process.

• Directing a Project (DP) – This process now begins at the end of the SU process in response to the request to commence initiation of the project. Apart from this, the DP process in itself has largely stayed the same. However, whereas in the past the Project Board requested initiation of the process Managing a Stage Boundary and premature closure of a project, this action is now the responsibility of the Project Board itself.

• Initiating a Project (IP) – The first activities of this process are now developing the different strategies for risk management, quality control, configuration management and communication management. The Risk Register is now arranged in this process too. The ‘PID’ is now defined as the Project Initiation Documentation. It now has to be explicitly recorded in the PID how the PRINCE2 method has been tailored to a project in this context.

• Controlling a Stage (CS) – This process has largely stayed the same. Only the sub-processes ‘capture’ and ‘examine issues’ have now been merged and extended into one activity: capturing and examining issues and risks.

• Managing Product Delivery (MP) – This process has largely stayed the same. Only the responsibility for recording the risks and the results of the quality reviews has now been returned to the Project Manager or (as the case may be) Project Support.

• Managing a Stage Boundary (SB) – The name of this process is now in the singular. The action ‘update the Risk Register’ is now part of the ‘update Business Case’ activity. The PID and the Benefits Review Plan are now being updated. The products completed in the project up until that point can already be delivered in stages and transferred to the customer. The formulation of a Lessons Report and recommendations for follow-on actions can now be part of this process.

• Closing a Project (CP) – New here are the activities prepare planned closure and prepare premature closure. Separate activities for handing over projects and recommending project closure have now also been defined. In principle, the Lessons Report and the recommendations for follow-on actions are now part of the End Project Report.

a

Tailoring PRINCE2

This is a new chapter. Whereas previously this aspect was addressed separately in the various processes, it has now been merged into one chapter. This subject has also been expanded considerably with regard to what had been set down in the 2005 version of the PRINCE2 manual. A distinction is made between implementing the method in an organization and tailoring the method to a specific project in a given context. The various aspects of the project and the environment that merit adaptation of the method to the project are examined. In addition to this, the differences between project and programme management are explained and the possible connections between the project and programme organization are examined. Finally it is explained how the method can be tailored to projects of different size and complexity.

a

Appendices

• A. Arrangement of management products – The number of products has been reduced from 36 to 26. Further explanation is now given for each product. How the different management products can best be presented has been added.

• Governance – This is an entirely new appendix in which it is shown how and to what extent the PRINCE2 method covers governance of the principles of project management as published by the British Association for Project Management (not included in this book).

• B. Roles and responsibilities – The role Change Authority has been added. The role project office has become defunct. The requisite competencies for the various roles have been added.

• C. Example of product-based planning – This example has moved from the previous technique focus on products to the appendix. A Project Product Description and an example of a product breakdown structure in the form of a mind map have been added.

• E. List of terminology – This has been expanded in relation to the previous version.

• F. Other information – This contains a brief explanation of the various methodologies supported by the OGC.

a

Conclusion

So quite a lot has changed in the 2009 version, but the fundamental principals are still in place. I think the new edition is a real improvement regarding the 2005 version and easier to work with in practice. The biggest advantage are the explicitly made guidelines for tailoring PRINCE2 to your own situation.

Good luck applying PRINCE2!

PRINCE2® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries

Project managers are from Mars, executives are from Mercury

On Wednesday the 15th of June Atos Origin is organizing a year event for their project and programme managers, titled ‘Project managers are from Mars, executives are from Mercury’.

I am honored to announce that Atos Origin booked me as key note speaker for this event, to talk about the relationship between project manager and project executive.

a

What is the importance of the relationship between project manager and executive? And can a project be successful without a good relationship between those two? How can the project manager keep the executive committed and involved throughout the project? Important questions which will be answered during the event.

a

I have asked the project managers to come up with practical examples regarding their relationship with project executives. For me it’s important to understand what these project managers are dealing with every day, so I can give some hands-on and experienced solutions and advise they can use in their daily work.  Advise is nothing if you can’t use it the next day.

a

An interview with me has been used to tell some more about the presentation and was published on the Atos Origin intranet. You can also see the interview following this link. I am proud to say that we have exceeded the maximum capacity of the event in only a few days. And I am looking forward to meet everybody in Utrecht!

a

If you want to know more about this interesting event or want to organize an event for yourself, please contact us at info@intrprimus.nl.

Our goals for our book “Project Management based on PRINCE2™”

In the last couple of years I published several books about project management and programme management. For most of them I worked with Bert Hedeman, my good friend and fellow guru in this field of expertise. With every book we wrote we had some goals in mind we wanted to achieve. We wanted our books to add value to the books already available. In this article I want to give you some insights on our goals and ideals.

@

The reason for us to think about writing a book about project management was the observation that an increasing number of organizations were working in a project-like manner and were using the PRINCE2® project management method. For these organizations the advantages of using one uniform standard method are obvious: a uniform method of working and terminology makes projects comparable, transferable and orderly. Moreover, PRINCE2 has additional qualities, such as the standard ‘no go’/’go’ decision with each stage, the Business Case at the centre of the project and clear agreements about who is responsible for what.

@

Our book is intended for everyone doing projects in their daily work. It is written for Project Managers, Project Leaders and Team Managers and all others who are involved with the starting up and management of projects. It aligns with the 2009 Edition of the PRINCE2 methodology, with many lists serving as reference material for all project types and sizes. As our book illustrates, PRINCE2 is quite logical and this title demonstrates why it is often referred to as a structured best practice for project management. In addition, the contents of the book meet the majority of the theoretical requirements set for successfully passing the PRINCE2 Foundation exam. It also provides a good reference title as part of the wider reading and practical experience required from those taking the Practitioner exam.

@

In this book, we have tried to combine our long experience in project management and PRINCE2 training. Using this background we explain the PRINCE2 approach in a structured manner, complemented with useful examples to help bring the theory alive. The Themes, Processes, techniques and Management Products as defined in PRINCE2 are explained in an easy-to-read, concise text. In the appendices you will find an example of a Project Brief and a paragraph on how to deal with lessons learned in a project.

Enriching the PRINCE2 Manual

Although this book is based on the manual ‘Managing Successful Projects with PRINCE2™’ from the OGC, which was fully revised in 2009. It is by no means the intention to ’translate’ the manual, but rather to make the methodology more accessible to the reader and to ‘enrich’ it with additions, practical tips and examples. It provides insight into how PRINCE2 can be used to manage projects and thus serves as a practical reference work for the experienced Project Manager. Thanks to its accessibility, the book is also extremely well suited to being used by anyone wishing to acquaint himself/herself with the method or working on a team engaged in projects (PRINCE2 or otherwise).

@

For instance, we wanted to provide the reader with extra information about working in a project management environment. So with Chapter 1 we added an introduction to Project Management. This first chapter provides the reader with insight into what a project is or is not, why projects are ‘different’ and what managing projects entails. In chapter 2  we introduced PRINCE2 and specifically examines what the PRINCE2 method encompasses, the structure of the method, its relationship to other OGC guidelines, what is not included in the method’s scope, the benefits of the method and the differences between the 2005 version and the 2009 version. In the rest of the chapters we go through the fundamental principles, themes and processes of PRINCE2.

Preparation for exams

In the PRINCE2 method, a PRINCE2 Foundation and PRINCE2 Practitioner exam can be taken based on Managing Successful Projects with PRINCE2TM.

@

The PRINCE2 Foundation exam is aiming to measure whether a candidate could be act as an informed member of a project management team on a project using the PRINCE2 method. The PRINCE2 Practitioner exam is aiming to measure whether a candidate could apply PRINCE2 to the running and managing of a non-complex project within an environment supporting PRINCE2. With this book we provide a good basis for both exams.

@

So overall we aimed for a practical, easy-to-read book for project managers with all knowledge of PRINCE2 to pass the examination. But also a comprehensive book about working in a project management environment. Follow this link when you want to know more about the book or buy it.

PRINCE2® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.

Improving projects by project leadership

Last week I was talking to a friend of mine, Peter Milovic, about the significance of the presence of real leadership in organizations. We explored several paths of why organizations are successful in their field of expertise. And every time we concluded that leadership is such a major factor, if not the key factor, for a successful future.

I also experienced this last year when I was coaching a young project managers for improving project management skills. The basic approach for improving project managers is often that a project management method is introduced and as part of the further development, the use of the project management method is regularly discussed. In this situation we hardly talked about the method at all and focussed on the ability to see and feel the projects environment and the wishes of the stakeholders. We focused on what was needed at that moment to maintain a successful course for the project or enhance the chances of success for the project?

In the sessions we worked on several key factors for project management and the way the project managers could transform this into daily practice. It was amazing to see how in a relative short period the project managers developed a feeling for real project management skills. Not the management of the documents or following the project process steps because it’s prescript. No, they made the step from project management to project leadership. As a result the effectiveness as project manager increased enormously as well as the value for the organization. The project managers developed a genuine motivation to be successful and the skills to match that. Isn’t that the development we all want for our (junior) project managers?

My dream is that a increasing group of coaches and leaders will join in this development. I’m convinced it will bring more passion in organizations and will help to lower operational cost and increase the benefits enormously. Do you want to join? Please leave a comment with your thoughts.