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.

MSP of Sturen op Samenhang; waarom kiezen!?!

MSP of Sturen op Samenhang; waarom kiezen!?!

het beste van 2 werelden

Strijd

In 1996 barstte er een strijd los rondom projectmanagement. Prince2[1] drong zich binnen de ring van gevestigde projectmethoden als Projectmatig Werken, SDM en Probaat. Een aantal jaren later verschenen Sturen op Samenhang en MSP[2] (Managing Successful Programmes) als aanpakken voor programmamanagement. Ook in deze arena werd lustig gevochten om de gunsten van de programmamanager. Maar wat is nu eigenlijk de strijd?

Zijn er nu wel zoveel verschillen en bijten de methoden elkaar nu echt?

De strijders

Sturen op Samenhang is ontwikkeld als aanpak voor het aansturen van programma’s vanuit de gedachte dat alles tegelijk moet worden gedaan en alles morgen klaar moet zijn. Projecten en andere activiteiten buitelen over elkaar heen: er komt voortdurend werk bij, er gaat niets af. Klanten, leveranciers, overheden en bestuurders: iedereen heeft zijn wensen in contacten met organisaties. Men wil resultaten zien en afrekenen op prestaties: het moet in één keer goed, het moet nu klaar zijn en ‘ik wil er niet te veel voor betalen’.
Een samenhangende aanpak is nodig om aan dergelijke verlangens tegemoet te komen.

 

MSP is een programmamanagement methodiek, ontworpen door de Organisation of Governance Commerce (OGC) van de Britse overheid. Het geeft een ‘best practice’ voor het managen van programma’s en helpt organisaties bedrijfsstrategieën en bedrijfsdoelstellingen in hun organisatie te verwezenlijken, innovaties te realiseren, nieuwe bedrijfsvoeringen door te voeren en de geplande toegevoegde waarden zeker te stellen. Belangrijke aspecten binnen MSP zijn het organisatiemodel, het management van de toegevoegde waarde en het procesmodel.

 

Vanuit de interestgroep Programmamanagement (IPMA NL) is vaker aandacht besteed aan deze strijd en werd de vraag gesteld of niet gewerkt kon worden aan een best practice vanuit beide methoden. Toen de gemeente Rotterdam met dezelfde vraag kwam hebben Theo van der Tak (Twynstra Gudde), Bert Hedeman (Insights International BV) en Gabor Vis van Heemst (intrprimus bv)  zich verdiept in dit onderwerp.

 

Boeiend om te merken dat ook aan de kleine tafel eerst het stof moest neerdalen voordat begonnen kon worden met het aanschouwen van de methoden zoals zij werkelijk een bijdrage leveren. Deze exercitie leverde een mooie samenwerking op tussen de sterke kanten van beide aanpakken.

Omsmeden tot ploegscharen

Als definitie voor een programma hebben wij gekozen voor:

Uitgangspunt blijft dat programmamanagement het raamwerk is waarbinnen op een georganiseerde en gestructureerde manier de gedefinieerde strategische doelstellingen kunnen worden gerealiseerd. Dit raamwerk omvat zowel het expliciet maken van de visie, het definiëren van de blauwdruk en de toegevoegde waarden van de toekomstige situatie voor de organisatie, alsmede de organisatie en de processen om de veranderingen door te voeren en de toegevoegde waarden te realiseren.

 

Management van de toegevoegde waarde

Waar het bij een programma uiteindelijk om draait, is het realiseren van de baten. Batenmanagement is daarmee een fundamenteel onderdeel van het management van een programma en is een continue activiteit die zelfs doorloopt na het einde van het programma. De projecten en activiteiten zijn de inspanningen (enablers) die resultaten opleveren, die als de bedrijfsorganisatie daar ook daadwerkelijk mee aan de slag gaat, nieuwe of verbeterde bekwaamheden (capabilities) leveren voor de bedrijfsorganisatie. Met deze nieuwe of verbeterde bekwaamheden kan het management van de organisatie hun doelen bereiken en de bijbehorende baten realiseren (zie figuur 1).

Figuur 1: Positie batenmanagement binnen een programma

 

Batenmanagement start met een baten- of doelenidentificatie. Dit kan bottom-up vanuit de verschillende geïdentificeerde projecten, maar ook top-down vanuit de einddoelen. Voor het top-down identificeren van baten wordt gebruik gemaakt van een zogenaamde doelenboom. Dit is een visualisering van het einddoel uitgesplitst via tussenliggende doelen naar subdoelen. Een doelenboom kan worden aangevuld door aan de doelenboom de noodzakelijke projecten en activiteiten (inspanningen) te koppelen. (zie figuur 2).

Figuur 2: Doelenboom inclusief  de noodzakelijke inspanningen

 

Alle doelen moeten zo mogelijk worden gekwantificeerd. Het is belangrijk doelen expliciet te maken en voor ieder doel kritische prestatie-indicatoren en bijbehorende doelstellingen te koppelen.

Tenslotte

Aanleidingen voor organisaties om te kiezen voor een programmamanagementmethode lijken helder. De aanpak programmamanagement:

• Faciliteert heldere besluitvorming en mandatering bij het maken van keuzes en stellen van prioriteiten
• Kent een heldere verdeling van taken, verantwoordelijkheden en bevoegdheden
• Levert een kapstok om complexe, strategische veranderingen te managen
• Heeft een expliciete focus op het managen en realiseren van de baten
• Geeft de mogelijkheid in te kunnen spelen op een veranderende omgeving.

 

Het is dan ook logisch dat in het bedrijfsleven de aandacht voor programmamanagement sterk toeneemt. Het is mijn wens dat de focus steeds verder ligt op het versterken van programmamanagement. Daartoe moeten we als programmamanagers met elkaar in gesprek blijven en onze kennis en ervaring delen en benutten. De programmacommissie Programmamanagement is daar een goed platform toe. En gelukkig hoeven we niet meer te kiezen tussen MSP of Sturen op Samenhang. Je gebruikt ze gewoon allebei!

 

 

Auteur

Gabor Vis van Heemst is programmamanager bij intrprimus bv (www.intrprimus.nl), dat zich richt op project/programmamanagement en professionalisering en is auteur van meerdere boeken en artikelen op het gebied van programma- en projectmanagement, alsmede het in dit artikel gebruikte boek ‘Programmamanagement op basis van MSP – een introductie’.

Bronnen

Hedeman B., Vis van Heemst G.

Programmamanagement op basis van MSP

Van Haren Publishing, 2005

 

Wijnen G., Van der Tak, T.

Programmamanagement, Sturen op samenhang

Kluwer, 2006

[1] Prince2^TM is a trade mark of the Office of Government Commerce

[2] MSP^TM is a trade mark of the Office of Government Commerce

 

Artikel in pdf: Artikel MSP of SoS_Waarom kiezen_Pgmgt v005

Projectmanagement en certificering

Een artikel in het magazine Informatie (SDU uitgeverij) van Bert Hedeman en mijzelf over de certificering van projectmanagement professionals (2007).

0702-38Hed

Leadership – an introduction

On April 26^th I wrote an article about leadership in project management. In response, I was asked whether I could explain a little more about leadership in general. What is leadership really about and what should you know about it as project manager? The following article is based on my book, “Projectmanagement op basis van NCB versie 3”.

Introduction
Leadership is the ability to get people to move into effective roles and tasks, to achieve (project) goals. Project managers often have limited formal powers. They work with team members and user representatives, but are not hierarchically driven. This means that in task- and relationship-oriented management to their team, they have to rely on other sources of power than their formal position. Like power by knowledge or power by relationships. The coaching management style can be used to give direction to the task and relationship orientation. The definition of leadership and the main other terms are:

• Managing people: The performance of managerial tasks such as setting goals, determine the necessary tasks and enforce.
• Leadership role: A behavioral ability according the specific needs of a project.
• Situational leadership: Leadership style of management which is based on the degree of ability and willingness of people in practical situations.
• Coaching leadership: leadership attitude focusing on learning ability of staff and making their potential qualities available to achieve the highest possible performance.
• Power: The ability to exert effective influence on reality.

Management vs. leadership
In this article we are consistently taking the project managers point of view. The person who, through proper planning, organization and management of work, ensures that project results are met within the prescribed conditions. That is the essence of the role of the project manager. Leadership is the connecting, stimulating, aligning and guiding force of the project manager, so the project stakeholders are intrinsically motivated to pick up the project planning and excel in the work, so the desired project results are realized. In this article I describe a number of role-oriented and task- and relationship-oriented leadership theories.

Leadership theories
There are several theories about leadership.

Covey (1993) emphasizes the features that a project manager has to develop, to achieve such an independent and reliable impact on the environment that synergy – as directed energy – in this environment is created.

In this article, the following leadership theories are described:

Quinn’s theory of management skills emphasizes the various roles that a project manager can perform. These roles are both internally focused or externally oriented and focused on flexibility of action, or control over the action. By deliberately choosing specific roles, the seemingly opposite values (internal / external, flexible / managerial) can be bridged.

The Managerial Grid of Blake & Mouton emphasizes the control given to the project manager. Their assumption is that project managers are focusing on task and relationship. The approach of Paul Hersey and Kenneth Blanchard is based on situational leadership. They indicate that a project should be based on the situation, and you should choose an appropriate leadership style. The style can be chosen depending on the qualifications of the person.

This article is concluded with a section about two instruments; delegating and coaching. A project manager can use those to encourage employees to a higher qualification.

Figure 1 – Value perspective and leadership roles

Leadership Roles and value development (Quinn)
In the leadership model of Quinn, competing values play a key role, as shown in Figure 1. Opposite the value ‘internal focus’ is the value ‘external orientation’. In terms of project management, this means that the project manager has an eye for both the internal organization of the project and for the project environment, for which the project outcome is realized.

Opposite the value ‘flexibility of action’ is on the vertical axis ‘control of action’. For project managers this means that they focus on the individuality of project staff, and also in what way other project tasks can be realized in a controlled manner.

A project manager can choose the following leadership roles and skills:

• Internal focus / Control of action – The project manager acts as a coordinator, through planning, organization and ensures that the project results will be realized. The project manager fills the role of controller, by means of a tight internal organization, established procedures and clear indicators to ensure that the project can enroll. Within this area, the project pays much attention to modeling and controlling of internal processes.

• Internal focus / Flexibility of action – The project manager plays the role of stimulator. He will ensure that conflicts do not develop into an uncontrollable level and encourages the development of the team and joined decisions. He also fulfills the role of the mentor, aimed at developing individual team members and enhance interpersonal communication. Within this field, the employee is focused on the most efficient way of resourcing the project staff.

• External focus / Flexibility of action – The project manager plays the role of innovator. He and his team ensures that changes are effectively identified, and exploring ways to realize these changes. The project manager fulfills the role of a target minded mediator, who uses all his ability to influence to obtain sufficient professional resources and capacity in order to meet the customers demand. For the project manager the project organization is an open and flexible system, which should be exploited to achieve the wanted project outcome.

• External Focus / Control of action – The project fulfills the role as a producer for the customer. He makes sure that the required products meet the agreed quality criteria according and focuses on encouraging and motivating people to make it happen. The project manager fulfills the role of director, by means of setting goals, taking initiative and effectively delegate work in a controlled manner for the customer. From this area the project will look like a rational goal model in which the focus is on achieving, by the client accepted, project outcomes in a controlled way.

Within the framework of this project management model the project is firmly anchored in the internal organization, without losing focus on the users of the project result. Simultaneously, the attention is on developing project staff, within clearly identified management criteria.

By taking those four management areas in a account as project manager you:

• have the internal organizations confidence in the professional execution of the project;
• are able to motivate and challenge experienced team members of the project;
• are able to keep team members focus on the interests of the user of the project results;
• have a fine balance between the demands of the commissioning organization and the demands of the customer of the project results.

Factors that disturb the balance also lie in the focus of the project manager himself.

Task-and relationship-oriented leadership (Blake & Mouton)
Blake & Mouton focus their thinking on the attention project managers tend to give to themselves. They make a distinction:

• Task orientation – the extent to which the task of the employee and the interests of the organization are important to the manager.
• Human orientation – the extent to which the human aspects, such as the interests of the involved employees, are important to the manager.

These two dimensions combined, create a infinite number of leadership styles. Blake and Mouton distinguish five dominant styles, see Figure 2.

Figure 2 – Management Grid (Blake & Mouton)

Separation-oriented manager (Easy Rider)
For this manager is neither the role nor the human aspects of the work of real importance. In practice, this manager manages little. What does he do? There is no direct leadership present and achieving the project outcome is highly dependent on the professionalism of the project team. This area should not be assessed in advance as negative. Project managers who are able to ensure that results are established by the self-steering ability of a team, can focus on tasks that also matter. To reach that point, the project manager will have a more then average separation-oriented attitude.

Human-oriented manager (the Country Club Chairman)
A high score on “relationships” and little attention for the realization of tasks. This manager focuses on the importance of the employees. Preferably, this manager focuses on the harmony and a pleasant working atmosphere. The task gets little attention. If this atmosphere orientation leads to higher motivation and task-oriented professionalism of employees is high, then you have the right manager in place.

Task-oriented manager (commander)
“Only the result counts”. This is the motto of a manager who scores high on task orientation and low on human orientation. Everything serves the business interests, aimed at the project outcome. Concern for employees is based on achieving the needed results. Especially in situations where rapid, adequate or high pressure performance is to be delivered, this task-oriented attitude is of great value. By the clarity of direction, everyone knows what to do.

Integration-oriented manager (the captain)
This manager focuses on team building. Good teamwork balances attention to relationship and tasks. In most cases, this is the right attitude in projects. People feel recognized and understood and the results will be realized. Two aspects that will lead to increased motivation.

The golden mean (the mediator)
This manager divides his attention between people, organization and personal goals. The manager strives for an acceptable balance between organizational performance and personal needs. Also his own.

Developing task- and people-oriented leadership
The position of project managers in the Managerial Grid is not fixed. Through personal development, changes in the environment and/or the company, the project manager may adopt another position. By learning the project manager to change his style according the situation, he can be highly effective in managing projects.

Finally
So far about leadership for now. In a future article I will take situational leadership a step forward. If you have any question please do not hesitate to write me a comment. For more information, please visit our website www.intrprimus.nl.

Programs are finite, too

A project has an ending, a program sometimes has two.

Since the nineteen nineties many debates have been waged on the ending of projects and the way in which this should be achieved. Meanwhile, the fact that projects are finite has been accepted amongst project managers, although the actual ending of projects still does not always go smoothly.

But how about programs? Even to this day, some managers still hold to the believe that programs are infinite and could go on forever. And even when a program is ended, often the reason for stopping the program and the terms and conditions under which the decision was made, all too often remain unclear.  This article aims to answer some of these question, by means of a case study. Because programs are finite, too.

At the beginning of the year, in which our case study is situated, a large IT-company has entered into an agreement with a semi-governmental organization to outsource its mainframe-activities. The deal included multiple computer systems, including all related datacenter services. The program “Professionalization Outsourcing Relationship”  lies at the base of the case study described in this article. A program with not just one, but two endings.

The case study

The changes, involved in the transitional phase, are concluded in the fall of the same year except for a number of remaining issues. In the subsequent professionalization phase, in which performance goals, as agreed upon by way of Service Level Agreements (SLA’s), are being achieved, both organizations conclude improvements  are in order. To this end a survey is conducted into ways of improving the cooperation between the two organizations. The results of the survey are compiled in a report, the main body of which consists of an improvement plan, comprising some twenty separate activities. The activities range from small to large, from simple to complex and from easily achieved to requiring planning over several years.

The recommendation from the report, to implement all the defined activities, has been accepted. For the implementation a program-approach is selected, because simply implementing the various solutions as separate projects, will not guarantee the achieving of the common strategic goal. The goal of the program “Professionalization Outsourcing Relationship” is the professionalizing the cooperation of the client and IT-business organizations. Which translates in improved performance, transparency, mutual understanding and trust. The activities, as defined in the survey report, are deemed (suitable) means to these ends.

MSP in stages

The program-approach is based upon the Managing Successful Programs (MSP) methodology and consists of a number of phases or stages (figure 1)

FIGUUR 1: Program stage planning based on MSP

Stage 1 Preparation
Focus, in this stage, is on validating the survey report and setting up the initial program organization.

Stage 2 Benefit selection
In this stage the main objective is on determining quantifiable goals for the program

Stage 3 Determine Blueprint
Here the so-called Blueprint of the future organization is presented. The Blueprint describes the future organization (as goal for the program). In this case this organization is a ‘virtual’ organization, an organization on the coupling plane of Client-organization and IT-organization.

Stage 4 Defining projects
Based on predefined (and quantifiable) benefits as well as the blueprint, in this stage projects and activities will be started. These will be documented in the program planning.

Stage 5 Executing Projects
This is the stage where projects and activities are actually executed.

Stage 6 Closing down the program
The program is closed down with an evaluation of the goals and benefits achieved and the formal communication about the end of the program.  The program organization is dismantled and program documentation is archived.

Figure 1 gives an overview of the different stages in general. The chosen approach and structure of the program ensure that along the way the program requires less and less involvement of program management and results are embedded more and more in the regular organization. This article does not go into details on the actual management of the program, but instead focuses on the end, the closure of the program.

Programs are finite.

Looking at the case study we will now try to address the questions of why programs are finite and when and how they should be ended. In order to do that, we will zoom in on the factors that determine the end of a program and that necessary to round off a program smooth and successful.  We will start with the question: “Are programs finite, or should they be?”

The term ‘program’ is used in many different meanings. It is, therefore, important to use a clear and decisive definition. For this article we will use the following definition for the term ‘program’:

“A temporary and flexible organization formed  especially for coordinating and managing the implementation of a coherent set of projects and activities, aimed at realizing benefits related to the strategic goals of an organization.”[1]

This definition clearly states the temporary nature of a program. But are there any logical arguments to be found for this statement? In order to answer that question, we have to look at the basic question: Why was the change instigated through a program, as opposed to changing (the organization) as part of everyday (management-) activities?

Separate management.

In order to realize changes in standing organizations, extra efforts (above and beyond normal day-to-day activities) have to be made. Efforts which, all too soon start to exhibit all the characteristics of projects.  The many projects and activities in a line organization, the relationships between activities and influences from (often complex) surroundings set high demands, in terms of effort, on company management and their co-workers. For the implementation of organizational changes, the existing line management and implementation capacity are insufficient. In organizations, set on realizing serious changes, the need has arisen for some other way of managing the implementation of these changes.

Program management is such a way, when it comes to managing the implementation of a coherent set of projects and activities. With the creation of a separate program-organization dedicated to achieving the strategic goals set, the line organization saves itself time and money. The savings possibly achieved by means of a program approach, know many aspects. One of these aspects is the fact that, the moment the biggest change is achieved, the major gains (partially) have been realized and the overall impact on the regular organization is reduced, a choice can be made to hand-over the remaining, outstanding, activities to the line organization. In any situation there will come a time when the costs of maintaining a separate (program-) organization does no longer outweigh the benefits of such a decision. This may well be the most important reason for ending a, otherwise successful, program.

“When the objectives of the program have been achieved, or when it is concluded that the remaining benefits do not merit the maintaining of a separate program-organization, the program should be terminated.”

If the above answers the question of whether a program should be ended, there still remains the question of how to do so. In the program from this case study, “Professionalization Outsourcing Relationship”, this question was addressed very conscientiously. Lessons learned during this process have become references for future programs.

Assurance.

The program “Professionalization Outsourcing Relationship” has reached the stage where the standing organization can direct en finish the ongoing activities, without the support of program management. This situation has been reached in accordance with the initial program planning, due to the combined effort of the program organization, which has focused on this goal. Based on the situation, the program board has decided to end the program and hand-over the remaining program activities to the standing organization for completion.

Business change management ensures that the changes, brought about by the program, become embedded into the standing organization. In this program the role of BCM was fulfilled by line managers from both organizations.  This was a deliberate choice, since the process continues after all projects and activities are completed. In the end ‘maintenance and control’ as well as further optimization will be carried out completely by line management. In this way parts of the program structure remain present in the line organization, even after termination of the program.

Figure 2 shows assurance in the line organization, after termination of the program.  Control transfers from the program organization to the line organization. The ‘relation escalation board’ remains unchanged and consists of the senior management of both organizations. The regular strategic meetings are supplemented with members from the program board. Program management is transferred to the contract manager and the service manager who take part in the service management meetings. The contract manager and the service manager performed as Business Change Managers during the program.

FIGUUR 2: Assurance of program results after the formal end of the program

Closing down the program (1)

Just like projects, programs are finite. The criteria for closure as described in this article are recognizable for stakeholders and easily identified at the start of the program. This makes the program tangible and provides insight.

In fact there are two reasons for ending a program:

• When the blueprint and benefits have been realized, or
• The organization is capable of continuing the changes in the line organization,

The program is complete and the program organization can be dismantled.

Closing down the program (2)

The actual program has now been terminated but, as mentioned, there are still a number of activities form the program being carried out by the line organization. At some point in time these too will be embedded in the standing organization and the last remaining elements of the program organization will merge with the line organization. At that point the program will be completed entirely.

Finally some recommendations that may prove useful in the execution of a program;

• Keep in mind that the difference between programs and projects is not always immediately clear of all participants and it takes time for people to get used to this;
• The demarcation between program and line management is a fine line and needs to be monitored. This is particular true because both operate in the same context. Division is important because the goals of the program (professionalization) differ from the (daily) line management goals.
• Ensure ample capacity (time) for Business Change Management. The program and the line organization come together at Business Change Management. This double function demands for extra  effort outside normal duties.

Literature
Hedeman B., Vis van Heemst G.

Program management, an introduction based on MSP

Van Haren Publishing, 2009

Hendriks T., Vis van Heemst G.

Programs can end

Projectie Augustus 2005

---

[1] Hedeman, Vis van Heemst, 2009

Symbision organiseert klantevent:

PMO

De volgende stap in project- en programmabesturing.

Gabor, Expert in het aansturen van projecten zal vertellen over ‘hoe snel toegevoegde waarde te creëren met een PMO’ en programma- en portefeuille expert Mark de Goeij vertelt over het belang van Project Portfolio Management.

Wanneer: 14 april 2011

Aanmelden: pmo@symbision.nl

Meer informatie? Bekijk hier de uitnodiging!

 

Programme management – an introduction (part 2)

Projects in programmes
As indicated earlier a programme has only one or a number of projects including several activities. Think, for example, of setting and starting up a warehouse as a programme, where all sorts of projects are necessary in order to develop it. The objective of the programme is then formulated in terms of profit figures, stocks, number of customers (per time unit), etc. Projects can therefore be: starting up a shop, laying car parking spots, contracting in personnel, etc. Yet, activities are needed, such as purchasing and selling of products, to develop this and to achieve  the benefits

Depending upon the organization structure, the Project Boards of the various projects are acquired with the programme organization. Usually the role of Executive will be filled by the programme manager or a person directly delegated to do so. In most cases a coordinating Project Support and Project Assurance will be set up. This provides great support to the communication in the programme and across the projects. In this way the underlying projects will get much of the required information from the programme. And vice versa, for issues beyond projects, the information flows more easily to others involved in the programme.

When starting a project within a programme there is usually a good overview of the main points of what has to take place. The Project Mandate will contain a large part of the information required to make a Project Brief. Even if it concerns planning, a project will have to aim at the expectations of the programme. However, this must not be taken literally just like that. It is still important to continually assess how realistic this information is. That is the responsibility of project management. During the programme project tolerances will be defined that are recorded in the Project Brief and in the PID.

The Project Brief is supplied by the programme. The Business Case and the project outcomes are linked to the benefits that must be achieved by the programme. The project is controlled upon the basis of the deliveries related to the benefits upon which the programme is calculated.

Each change that influences areas outside the project must be tailored to programme management strategy and where necessary programme management must make the decisions. An example here can be the change of objectives or of predefined project outcomes, as well as changes to the Business Case.

Types of programmes
Each programme is unique in what it aims to deliver and the circumstances under which this is carried out. Figure 3 shows examples of types of programmes and areas where changes are carried out.

Construction, engineering and ICT
It is characteristic of this environment to be unambiguous and the results to be delivered are often clearly described and specified. It is clear what must take place and often how much time and energy will be required. There will be few major changes while the project is being carried out. This will involve the preparation and completion of products, with the focus more on result-oriented work rather than just the objectives of the project.

This type of programme differs from projects in the distribution of tasks, authority and responsibilities. With a project, the manager (the Project Manager) is responsible for producing project results that are within the budget, produced on time and can be used by the client to realize the Business Case. With a programme, the manager (Programme Manager) is responsible for the above, as well as for delivering the results and (partial) realization of the Business Case.

This may, for example, deal with the implementation and development of a new computing centre, or the introduction of a new product where development will be reviewed after a few months to see if it can be included in the standard range.

Change management
This concerns programmes for carrying out changes in an organization from a strategic viewpoint, with effectiveness and efficiency as starting points for the change. Consideration is therefore given to the realization of benefits. This type of change is often less clear than the previous type of programme, but there is still a reasonably good vision of what must be done.

The chances for change are greater, but the changes will generally be across the board and dealt with reactively. More components will become clear throughout the implementation period and these can be managed as projects.

Examples of this type of programme may include changing a department to accommodate the demands of a new market, or the reorganization phase following a merger or takeover.

Figure 3 Types of change
(source: Programme management based on MSP)

Policy and strategy
A strategic programme consists of a set of projects and individual activities for realizing an organization’s strategic objectives. This is also based on a vision, but deals much more with reaching the higher strategic goals than just the benefits.

The environment is ambivalent, so there is no clear picture of what must be done. Negotiations are often carried out in this case to find clarity for the procedure that follows. The frameworks are more flexible and the entire scope of the changes is dealt with carefully. While this is being done, parts of the tasks will become clearer and they can also be managed as a change phase. What is remarkable is that the objectives from the various projects might conflict with one another, but they will still support the coordinating goals in the wider context. The challenge here is to have the various objectives balanced in such a way that the strategic objectives can be achieved.

An example of a strategic programme is setting-up an e-business. Implementation is often only driven by a vision of the final outcome. A lot of uncertainties exist in the beginning and the Programme Manager will react pro-actively to possible future developments. The programme could involve the setting-up of systems, motivating clients to work with e-business, preparing the organization for e-business and setting-up a helpdesk.

Multi-organization programmes
This type of programme is characterized by the co-operation of various organizations in managing or sponsoring the programme. These organizations might have the same or different backgrounds (industry or market). The reason for the co-operation is the joint goals and benefits, which the organization cannot achieve on its own.

Such programmes are common in the logistics sector, where the concept ‘providing the complete package’ is becoming more and more important. Far-reaching co-operation is required here in supply chain management, to serve the final consumer efficiently. In these programmes, each partner supplies the input for realizing the joint vision. Each participating organization maintains its own business goals that are to be achieved, as well as the joint vision of the partnership.

Other well-known examples include the private-public ventures where local government and private businesses work together to develop areas that would be much more difficult to launch without direct co-operation.

Critical success factors
There must be a good reason for carrying out the changes. An accepted image of the solution needs to be put in place by the most important people in the organization and this must be seen to be done. The Programme Manager should be involved and want the change without this being forced on him. He must be seen to work quickly and this should be a fixed feature of daily operations. Only then can changes actually be implemented and show their added value for the organization in the long term.

The following steps are conditions for successful implementation:

Make the necessity clear
Changes cost energy. This energy can only be released if there is a clear need for the change. This can be a possible threat or an opportunity, so it is also important to state and share this need for urgency.

Involving senior management
The choice of implementing changes depends largely on the image and experiences of the most important players within the organization. It is not sufficient for the need for change to be felt lower down in the organization or in middle management. The change is not viable if senior management cannot be convinced of the need for it; they must be behind the change and regard it as their problem.

Looking for an owner within senior management
Someone has to take responsibility for the change at senior management level. If everyone is the owner, then no-one is the owner, and nothing or very little will get done. It must be possible to address the owner at the appropriate management level; he’s the figurehead, the ‘champion’, owner or standard-bearer of the change.

There are several names, but they all mean the same, important thing: that this ‘Senior Responsible Owner’ bears managerial responsibility for the programme and is the real owner of the change. The change will have the best chance of success if the owner is also the primus inter pares (first amongst equals) from within the leading coalition of senior managers.

Clear and consistent vision of the final outcome
It is important that everyone involved in the change has the same image of the future and of why the change must take place. By sharing the vision and the Blueprint of the change, the parties involved can identify themselves more with the programme and what is happening. This is also the case with procuring and maintaining the use of staff and resources.

Clear tasks, responsibilities and authorities
One of the most numbing factors with project and programme management is that those involved do not know who is responsible for what, or who can be approached about what. Normally, nothing will happen if several people seem responsible, so establishing clear roles is a must.

Focus on added value
Realizing the benefits is a programmes primary objective. Managing the benefits, from identification through to receiving and measuring the added value, may cost a lot of time, money and management effort, but it is essential for implementing the change. Without this focus on the benefits, the change will have no drive and will soon get bogged down in haggling about what should happen.

Focus on the justification and the risks
There must be practical justification in order to implement a programme and there is no change without uncertainty. The justification and the risks must be established at the beginning of the programme and be tested and managed regularly during the programme.

Empowerment
Empowerment is an important condition for success. Empowerment means that those involved in the programme can make decisions and have sufficient powers and authority within the framework of the programme. This does not mean that each person might decide his own direction, but that all those involved may give as much of their own personal interpretation as possible within the business limitations necessary for realizing the objectives.

Planning, governing and monitoring the process
A structured change is not possible without process management. Changes must also be planned and require governing and monitoring.

Generating and celebrating quick wins
It’s great to see that on paper the new way of working should improve the situation, but nothing is more convincing than these improvements actually happening. Celebrate the success and reward the successful. Do not leave this to chance, but consciously seek short-term successes; these are energy for the motor of change.

Communicating
Nothing is more frustrating than those involved not knowing what is going to happen. What does the change mean for the organization, how far ahead is the change, has the change already had an effect, and what does the change mean for me? It is not enough for the message to be spread but it is important that management acts in accordance with its own message, as a good example is worth following. Furthermore, it is essential to repeat the message again and again.

Securing the new work method
Changes that are not secured in the organization tend, after a time, to return to their original state. It can take years before new work methods become ‘business as usual’. It is therefore essential to embed the changes into the organization’s procedures and control systems.

Basic principles of MSP
MSP endorses all the mentioned success factors for implementing changes. Specific issues of MSP in relation to other methodologies are:

• A description of the vision and a Blueprint of the new organization must be defined before starting to implement a programme and these are the main elements in planning and realizing the programme;
• Identifying and establishing the added value for the organization, and ensuring they are measurable and then managing the added value so that this can be realized;
• A focus on the justification and the risk: this is essential within the MSP philosophy and is the leading principle for programmes. MSP also has a defined organizational structure with clearly described roles, each with their own set of tasks, responsibilities and authority. In the organization model, the Management Team is offered a structure to help guarantee as far as possible the involvement of senior management and stakeholders.

Finally
Based on all information you can conclude that MSP (Managing Successful Programmes) is a best practice approach for changes and useful to apply. The MSP method gives a pragmatic approach to managing programmes. It helps organizations to realize corporate strategies and goals in their organizations, as well as achieving innovation, implementing new management and ensuring planned added value. The principles for managing programmes have been developed over several years and applied within several fields. These principles can be applied to all sorts of programmes, from developing complex housing problems to corporate reorganizations and e-commerce services.

Questions? More information?
gabor.visvanheemst@intrprimus.nl

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.

Tailoring Different kind of PRINCE2 projects (part 3)

In my last two articles about tailoring I was writing about tailoring of PRINCE2 and specifically tailoring projects within programmes. Every time I try to focus on those aspects that truly increase our chance of success. What do I have to do to be successful?! In this article I have searched for ways to tailor PRINCE2 projects within different kinds projects and context.

Lifecycle models
PRINCE2 is a project management method; it helps with the management of a project. There are many other methods that address the content approach of a project and the delivery and testing of specialist products. Examples are the waterfall method and agile methods (for example DSDM Atern). Because PRINCE2 stands apart from these aspects, it is possible to connect with these specialist lifecycle models. This is achieved by:

• Enabling the phasing of the management stage to connect with the development lifecycle (for example design, building, testing, handover).
• Using tolerances, such as limited tolerances for time and money and a more generous tolerance for range and quality with the application of an agile model or repetitive models.
• Integrating specialist roles in the Project Management Team. It is often unclear what these roles should be called. This is not a problem. It is only important to be clear about the responsibilities, so that these can be understood by all involved.
• Lifecycle models can also prescribe project management products. In similar cases it is important to avoid double work or breaks in activity. It is also important to make a conscious choice for an unambiguous approach.

Different kinds of projects
The management of projects is essentially the same, irrespective of the sector in which the project is executed. However, in practice it seems that the approach differs for each sector. So, for example, project management in the IT sector is likely to be different from that for cultural projects. The organization and direction of large and small projects, or single disciplinary and multidisciplinary projects differ. However, in all cases the basic process scheme is the same. The basic scheme can, however, be tailored for each project. Examples of different kinds of projects are:

• Commercial customer-supplier projects;
• Multi-organization projects;
• Development projects;
• Feasibility projects;
• Projects in the private or public sector.

Commercial customer-supplier projects
If a commercial relationship exists between the customer and the supplier, it is important to realize that there are at least two reasons (one for the customer and one for the supplier) to execute the project, two management systems, two structures and two corporate cultures. The customer and the supplier also have their own Business Case. If one of the Business Cases no longer applies, the project runs into trouble and will most likely go wrong, even if the Business Case of the other party is still valid. The Business Case of one party is often (partly) not unavailable to the other party.

The appointment of the role of Senior Supplier is a major decision in a commercial relationship. Should the supplier fill this role or leave it to a manager in the customer organization? And what if there is more than one supplier? If there are more than four suppliers, it is recommended that a main accepter be appointed as Senior Supplier. If there is a purchasing stage in the project, an experienced person from the purchasing department can fulfill this role until the supplier has been chosen.

In most cases the Project Manager will be appointed by the customer, while the supplier fills the role of Team Manager. If the project is initiated by the supplier, the corporate representative of the supplier is the Executive, and the head of the department who has to realize the project result is the Senior Supplier. So, who is the Senior User? That is usually the sales manager as they represent the customer within the supplier organization.

It should be indicated in the strategies whether this design emanates from the customer, the supplier or from a combination of the two.

If the project is managed stage by stage, stage assignments can be given, or a contract can be awarded for the entire project with part assignments concluded. The Team Plan of the supplier cannot be made public to the customer. A good Checkpoint Report then forms the basis on which the Project Manager should monitor and control the relevant Work Packages.

The Risk Register can also be confidential, since some risks are relevant to one party only. If a combined Risk Register is kept, then it must be indicated who the owners of the individual risks are.

The change procedure should link up with the purchasing procedures of the customer and the approval procedures of the supplier. The manner in which the progress of the project or the stage is reported, should tie in with the control demands of both organizations.

For the sake of the supplier the processes must be tailored. The Starting up a Project process will take place pre-contract in response to the request of the customer for a tender. Some of the Initiating a Project process will be pre-contract whilst contract negotiations continue. At the end of the initiation stage a contract is subsequently put in place for the delivery. If at the end of SP a contract suddenly has to be placed for the entire project (initiation and delivery), it is advisable that the first stage (the initiation stage) is executed on the basis of hours times price and a definite agreement reached on the contract soon after approval of the Project Initiation Documentation.

The Project Initiation Documentation must fit in with the liabilities and contractual responsibilities. Between the customer and the external supplier a Work Package can be regarded as a legal contract.

Multi-organization projects
It has already been indicated that a project is typically run on the basis of a customer/supplier relationship. However, it can also happen that multiple organizations are involved, such as joint ventures and inter-departmental projects or partnerships. In such a situation the ownership is shared by several organizations. It is advisable to organize similar projects with a programme control as the dominant structure above the actual project and to stick to a single Executive for the project itself.

Development projects
Projects usually start without a rigidly defined output, but with specifications that are developed further during the project. The specifications that have been prepared during the initiation stage are only adequate for making a ‘good and agreed’ prediction about the business justification of the project. In each stage or with every stage boundary the necessary specifications are defined for the next stage and the specifications of the project products are refined to safeguard the permanent business justification of the project. Similar projects are totally supported by the PRINCE2 method by the drawing up of the Stage Plan and the Business Case at the end of every management stage.

Feasibility projects
A feasibility project or study can be necessary to examine a situation and to develop the options further. A similar study is a project in itself, since such a study is in itself a business product with its own business justification to execute this study (see figure 1).

A feasibility study produces an advice report containing the recommendation in each case for the future. The Project Board can take a decision on the basis of the advice report. Policy projects look like feasibility studies; the output has an immediate value, but contributes to reaching a reliable decision. Executing the decision taken is a project in itself.

Figure 1. Example of feasibility lifecycle
(Source: Project management based on PRINCE2)

Projects in the private or public sector
There are different sectors, each with their own dynamics and qualities. However, the characteristics of a project apply whether the organization is in the public sector or the private sector. Despite the fact that there may be differences in the approaches taken to the development of a Business Case, nevertheless the importance of knowing ‘what we do it for’ is applicable everywhere.

The Business Case in the private sector is usually based on a return on investment, even if that is still not the case in some instances. In the public sector the concept of political decision taking often comes up, though the main questions revolve around: what is the added value? Is it realistic and do we want to spend so much money for the proposed solution or are other, less costly solutions available? Even the authorities cannot always get what they want and also their money can only be spent once.

In the public sector as well as the private sector it is notably important that the different stakeholders are involved in the project. The choice of whether to adopt a Project Board depends more on the culture and the scale of the organization and the importance, size and complexity of the project, than on the sector. In the public sector another consultation body is sometimes involved, for which the responsibilities and the competencies are not clear beforehand. Whatever the method, this is a situation to be avoided.

When considering the public responsibility, it is likely that the various reports and decisions are typically recorded more formally in the public sector than in the private sector. In the PRINCE2 method it is entirely up to the customer to complete the necessary documentation.

Finally
This was the last article in the series about tailoring PRINCE2 in different circumstances. I hope you enjoyed the articles and were able to apply it in practice.

Please feel free to comment on my articles. I’d love to get into remarks and questions.

For any other information, please mail me (gabor.visvanheemst@intrprimus.nl).