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)

 

 

 

Tailoring (part 2) – Projects in Programmes

Introduction

As I wrote in my last article about tailoring, it’s all about making choices! What do I have to do to be successful. This article I will getinto tailoring PRINCE2 to fit for projects within a programme and large projects versus small projects.
a
As was indicated earlier, one programme recognizes one or more projects and a number of activities. Think, for example, of an organization that is starting up a warehouse as a programme, where all kinds of projects are necessary to bring about its utilization. The aim of the programme is then formulated in terms of profits, stocks, number of customers (per time unit), etc. Examples of projects could be: the organization of the shop, constructing the parking bays, hiring of staff, etc. Nevertheless activities are still required to enable development and to realize benefits , such as the buying and selling of products.
a
With the tailoring of a project as a part of a programme, a few aspects are adapted: themes, processes and management products. For the programme management aspects reference is made to ‘Managing Successful Programmes’ (MSP) from the OGC.
a
With Starting up a Project within a programme there will usually be a good overview in place of what must happen in outline. The project mandate will mainly contain the information that is necessary to enable a Project Brief . Sometimes the complete Project Brief has already been delivered by the programmes. However, this Project Brief must not simply be accepted. It remains important to check again every time whether the delivered particulars are consistent and realistic. That is the responsibility of the Project Manager .
a
The Business Case of the project is defined on the basis of the standards of the programme. Sometimes the Business Case is provided by the programme or it can be a reduced level of content. The responsibility for realizing and monitoring the benefits of the project lies with the programme. The Benefits Review of the project can be a part of the benefits realization plan of the programme.
a
The organization structure is about an optimal connection being created between the programme and project organization for an efficient manner of reporting and reviewing. Often the role of Executive will be filled by the programme manager or a direct delegate. In this way coordinated Project Support and Project Assurance is also organized in most cases. This helps enormously with communication in the programme and across projects. In this way the underlying projects will get the necessary information of the programmes much more directly. And vice versa, with information about, for example, a project experiencing scope creep reaching other parties involved in the programme more seamlessly.
a
Another example of the possible integration of roles is that the change manager(s) in the programme can fill the role of Senior User(s) in the project. The design authority, or the architect of the programme, can also fill the role of Project Assurance or Change Authority in the project (see figure 1). What is important is that there is a clear division of responsibilities and that overlap is prevented.

Figure 1. Project and Programme management roles
(Source: Project management based on PRINCE2)

With any project that exceeds the planned level of change, coordination with programme management must take place and, where necessary, programme management will have to take decisions. Here one can for example think of not only changing of the objectives, but also changing the Business Case.
a
Another aspect is that the programme can supply the Quality Management Strategy for the project. In this way the programme can give advice about quality methods and provide help with the execution of quality control and quality assurance activities. With the planning of the project, care must be taken that the standards of the programme monitoring and control are followed. In the Project Plan dependencies with other projects within the programme must be covered.
a
When determining a project’s strategies, the strategies of the programme should form the starting point. It also has consequences for the techniques and classifications to be used, in the project. The issue solution strategy of the programme is used as a guideline for the issue and change procedures of the project.

a
The information management strategy of the programme will be a guideline for the Configuration Management Strategy of the project. In the same way the monitoring and control strategy of the programme is a guideline for reporting and monitoring activities of the project. In addition the programme determines the project tolerances and the number and length of the stages.

Scale of the project
The scale of a project doesn’t only relate to its size, but also the complexity, the risk and the importance of the project. For all PRINCE2 principles it must be established how they can be used instead of not using certain principles. The use of PRINCE2 can be regarded as the reduction of project failure. If an element of PRINCE2 is taken less seriously, it must be regarded as a risk.

Table 1. Examples of projects of different scales
(Source: Project management based on PRINCE2)

Large versus small projects
Medium-sized and large projects recognize several delivery stages in addition to the initiation stage. With short-running, non-complex projects with limited risks, the project may only consist of two management stages: the initiation stage and the delivery stage. With small and straightforward projects the Starting up a Project and Initiating a Project processes are sometimes combined (see figure 2).
a
In such cases the two processes can be informally dealt with together in a single discussion. It is advisable in such instances to record the decisions in a discussion memo. For example this could be possible where the project involves a small internal move within one department or something similar.

For small projects the Controlling a Stage process can be summarized in the following activities:

• Allocating work to be executed;
• Monitoring the progress;
• Ensuring that the agreed quality is realized;
• Ensuring that changes are carried out after approval;
• Monitoring risks;
• Reporting the progress of the work;
• Keeping a watchful eye for changes occurring to the plan.

a
These activities must be carried out even in the smallest projects. The question is, however, whether reporting on these activities must always be done by means of bulky reports. In small and informal projects quite simple reports are adequate, or reporting can even be done verbally or via e-mail. However, the project management team must realize that verbal reports have inherent risks. An argument may develop about what had been agreed. And what happens if the Project Manager is temporarily unavailable or leaves the organization? The other themes can also be completed in a simpler manner, which results in smaller overheads.

Figure 2. Phasing projects
(Source: Project management based on PRINCE2)

For smaller projects and for those projects with only one team that reports directly to the Project Manager, the coordination between the Project Manager and the Team Manager can also be less formal. The Project Manager and the Team Manager may be one and the same person. The work of the Team Manager can be summarized as:

• Setting up agreements on work that must be done;
• Planning the work;
• Supervising the execution;
• Keeping an eye on the progress;
• Reporting the progress;
• Having the product s tested;
• Recording the results;
• Keeping up with the changes;
• Ensuring that the products are checked;
• Delivering the products to the Project Manager.

The role of Project Support can also be undertaken by the Project Manager.
a
For small projects the Closing a Stage process can be summarized in the following activities:

• Checking whether everything has been delivered and accepted;
• Checking that there are no loose ends;
• Recording outstanding points;
• Archiving the project file for later assessments;
• Signing off people and resources.

Small projects and bureaucracy
Sometimes small projects are choked by too much paper and bureaucracy. Most procedures and templates in organization s that are developed to organize and manage projects, are based on large and complex projects. For organizations that have ISO certification, it is applicable for management and specialist activities to be thoroughly undertaken. That requires additional paper work and the accompanying signatures. This is not a PRINCE2 requirement, however.
a
PRINCE2 can reinforce all of this because the method is complete and is underpinned by a large number of templates. All available PRINCE2 templates are often also used to guarantee a feeling of maximum control over the project. The result is an overkill of documents. This can detract attention from what is really important and can create an aversion to all documents, including instances when a document is in fact important. An overkill of documents in any case costs a lot of time and attention to produce and study. This time and attention can often be better spent on other matters.
a
All PRINCE2 processes must be adhered to in every project. However, the question is whether all processes in a given project are so important that specific procedures and templates for the execution of these processes are necessary. It is important to use only those procedures and templates in a project that are really important in the given circumstances and provide added value for organizing and managing that project. For small projects certain processes can be gone through and completed quickly and informally.

Project Manager versus Team Manager
Small projects typically use one project team. Only members of the project team itself work on the project, reporting directly to the Project Manager. In addition two situations can arise:

• Separate Work Package es are to be differentiated, but these Work Packages are still undertaken by one person. This person is then simultaneously a member of the team and Team Manager. In such a case the Project Manager and the Team Manager are separate people.
• The Project Manager does not direct the team member at the level of Work Packages, but at the level of activities. That is also the case if the team member is not yet sufficiently senior to execute the Work Package independently and the Project Manager has sufficient subject content expertise about the work area to be executed. In such a case the Project Manager and Team Manager are one and the same person.

In small projects both situations can occur simultaneously. The second option, however, has the inherent danger that the team member concerned feels insufficiently involved and will sit back, “The Project Manager tells me what to do anyway. It is their project/problem and not my project/problem.” This develops especially when a team member (in their own estimation) has sufficient expertise to function as Team Manager, but is not given this responsibility. This is not good for team building and commitment in the team and only reinforces the risk that the Project Manager will still interfere with the content. Too often the Project Manager strongly interferes ‘out of habit’ with the content of the activities. It could be that the Project Manager is not used to directing on the basis of Work Packages and remains stuck in the old procedure. Coaching by a senior Project Manager is then necessary to avoid similar situations.

Large projects
There is essentially no difference between a ‘small’ and a ‘large’ project. A product or service still has to be delivered. A large project, however, is regarded as a project with several project parts where each is directed as a project, for example with its own Executive , Project Board and Project Manager. A Project Board that coordinates all the different Project Boards is responsible for the entire project. The building of the space shuttle is a huge project, just like the building of the Channel Tunnel. However, the result that is delivered is nonetheless still a product. It is for the customer to use the product and to realize their objectives with it. So, it remains a project and not a programme .
a
The difference between a portfolio of projects and a large project is that in a portfolio of projects the different projects sometimes deliver several results, sometimes solitary and sometimes in clusters, with each being capable of delivering added value for an organization; with a large project, one inextricably bound total result is delivered.
a
With a large project one can naturally use the same methods and techniques as with multi project management and with managing a portfolio of projects, and these techniques are found again in the management of programmes.

Finally
In the next article I will go into tailoring PRINCE2 for different kinds of projects and in different context. All kinds of projects have their own characteristics and possibilities to tailor it towards success!
a
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).

PRINCE in Practice meeting – 30th of June

I was looking forward to this event, the Prince in Practice meeting about portfolio management with Liander, titled ‘portfolio management and Liander, a good combination’. Liander/Nuon is a client for over 10 years now and I carry the organization and colleagues in my heart. It is a interesting environment with all kinds of elements that makes it dynamic and challenging. The approach was to share some knowledge and experience about (implementing) portfolio management based on our own experience in the last couple of years.

We had some 20+ project and programme managers joining us in this event. For starters I gave a presentation about the theoretical side of portfolio management; what is it about, how does it look like and how can you employ this in an organization. So we looked at different definitions of the item from several organizations and choose one of them as leading for this evening.

the management of a group of projects and programmes that collectively provide the new capabilities that are necessary to realize one or more strategic corporate objectives

Basic question was how to use portfolio management and also what the main reasons are to implement portfolio management. We discussed this from the perspective of both the organization as well as the project manager. Why should he choose for such approach or at least how can he profit best from this situation. It was a lively discussion and it was most interesting to see the balancing of disadvantages and advantages of implementing a management structure that is both increasing power for projects, but also feels like losing individual power as project manager. This is exactly what happens in organizations implementing portfolio management.

Next I explained more about the ways portfolio management can be positioned in the organization and the role of portfolio manager and portfolio  board. Also we looked at the factors that can determine a successful implementation and working portfolio management. This was the starting moment for Ben Tubben, manager Projects of Liander, to give some insights in the way portfolio management is being used within the Uitvoering- organization of Liander. He was very clear on the choices they made along the way and how this worked out for them.

Ben explained the roadmap to us, used by Liander for all their developments and how this interacts with portfolio management. He told us about the different aspects they used as pillars for implementation; Organization, Processes, Resources and People.

Finally Ben shared his dreams for portfolio management and his Projects department with us. It was a cloudy sky, but the sun was shining through the clouds. Ben, thanks so much for your open and meaningful presentation!

As I said, I was very excited to do this presentation with Liander. There was lots of interaction with the group and good discussions. Several of them continued during the closing drink. I want to thank all attendants for their contribution and inspiring feedback!

Download presentation: Presentatie_intrprimus_PiP Portfoliomgt en Alliander_v100

Introducing tailoring PRINCE2® (part 1)

Introduction basic principles

One of the characteristics of a project is that the change is unique, or in any case unique enough not to be managed under a line management function but to be started as a project. This means that, in principle, no project is the same as another. Just think of the different sizes of projects, the varying organizations, and the differences in respect of the types of product. Put alongside this the fact that no Project Manager, Executive or project environment is the same and the basis is established for ‘tailoring’.

Figure 1. Effects of tailoring (Source: Project management based on PRINCE2)

Naturally it is so that a number of types of change, projects and environments can be distinguished to get more insight into all this complexity. This is useful to determine the approach to the project or the selection of the Project Manager who will execute the project. It is important to look at what the project and sometimes even the stage requires. With every project or every stage the Project Manager and the Executive should check what the specific characteristics of the project and the environment are (see figure 1). The Project Manager must organize the project accordingly. In this PRINCE2 offers structured guidance to enable the organization of the project to be adapted for every required situation. As such it is a generic method of project management and the method can be used as the start point for organizing and managing all types of projects.

Tailoring a PRINCE2 project is all about making the application of PRINCE2 fit a particular project, so that the correct means of planning, controlling, directing and the use of processes and themes can be adopted.

On the other hand PRINCE2 is embedded with a method for organizing products. This refers to the assurance of the PRINCE2 method throughout the entire organization. The table below indicates all the interim changes and tailoring (see table 1).

Table 1. Embedding and tailoring (Source: Project management based on PRINCE2)

In tailoring the project organization all aspects of the project must be considered, thus all themes and processes of PRINCE2. What can be used and what not? Can processes be combined (think of Starting up a Project and Initiating a Project in a small project)? How does the terminology link up with the standard corporate terms? Which roles can be combined by one person? How is a link obtained between the programme and the project organization? Which project approach fits which type of project best at the moment? How are the templates and the management products used?

In this article I will give an illustration of a number of specific situations and the application of PRINCE2 that can be used. The aim of tailoring the method must always be that what is done is precisely what the project requires to be successful.

Nothing more and nothing less!

Context

Projects never stand alone and are always executed in conjunction with many factors – whether these are environmental factors or project factors. In figure 1 a few examples of such factors have been included. So, tailoring is also about the application of PRINCE2 bearing in mind the external factors.

PRINCE2 has a number of generic principles, themes and processes, but also a few specific topics such as terminology, management products and roles. The principles are universal starting points for project management and in this sense must always be applied in a PRINCE2 project. The themes are the aspects of project management that must be addressed continually and integrally during the entire lifecycle of a project. These aspects must be tailored for the specific project and for the specific circumstances. This often happens in the different project strategies. In a formal organization the risk strategies will, for example, be much more formally structured than in a more vision driven organization. Also the way of directing the line organization to the projects will differ in similar organizations and this will have an impact on the plans and strategies.

The PRINCE2 processes consist of connected activities that must be executed at certain times in the lifecycle of the project. It is therefore not advisable to leave these activities out or to skip them. The art is in the application of these process activities, giving each the attention that it deserves. It is thus more a question of how extensively and formally an activity must be executed, or the extent to which activities can be combined, rather than omitting activities altogether.

The same applies for the roles within PRINCE2. The starting point is that the correct person must fulfill the correct role in terms of the appropriate tasks, responsibilities and qualifications, and that everyone is clear what these roles, tasks, responsibilities and qualifications are, and not there is a signed role description available for every party. That can be necessary in critical projects with external parties, but that will more likely work counterproductively in other projects.

The terminology of PRINCE2 is one of the great plus points of using it as standard methodology. By all using the same terms and knowing what they mean, there is much less miscommunication, making the hand-over of work easier. That does not mean that the PRINCE2 terminology must always be insisted on. If everyone in an organization has been used to referring to a project contract instead of a Project Brief and the meaning is the same, then it is probably advisable to continue to use the existing terms.

In principle this also applies to the application of management products. It is sometimes advisable to keep on using existing documents or lay-outs and to enrich these on the basis of the set-up of the management products of PRINCE2, rather than replacing them altogether. One should take care that all aspects are addressed.

It is always advisable to pay attention to all the parts. Make a conscious choice if it is necessary and, if yes, to what extent it is necessary to describe the part. Avoid bulky plans in which all aspects are described in detail, when this does not contribute to the success of the project. This costs unnecessary energy, time and money.

Whatever an example is given, there will always be a unique situation in a project, so on the basis of that, choices are made for its organization. It is all about the purpose, not the means! Just think: There are no bureaucratic methods… only the bureaucratic applications of methods. Bureaucracy is a choice!

The above example ends with the most important starting point in the tailoring of PRINCE2. CHOOSE CONSCIOUSLY!

Finally

In the next article I will go into tailoring PRINCE2 for projects within a programme. This project environment has its own characteristics and possibilities to keep PRINCE slim and lean! So it seems to probably become a interesting article again :-).

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).

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

Differences in PRINCE2® v2009 versus v2005

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

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

a

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

a

Structural changes

The most important structural changes are:

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

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

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

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

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

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

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

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

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

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

• Delivery of the results in stages is pointedly assumed.

a

Changes to the manual

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

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

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

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

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

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

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

• The appendix incorporating risk categories has become defunct.

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

a

Detailed changes

Themes

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

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

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

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

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

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

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

a

Processes

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

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

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

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

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

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

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

a

Tailoring PRINCE2

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

a

Appendices

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

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

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

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

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

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

a

Conclusion

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

Good luck applying PRINCE2!

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

Books of Gabor Vis van Heemst

Since 2001 I published several books about project and programmemanagement.

This year my new book ‘Project Balanced Scorecard, Passion For Aligning Projects With People’ will be published.

Check my LinkedIn
and the website www.intrprimus.nl

Seminar PUG – Improving pm at Liander

In June I will present a case study for the Prince User Group about portfoliomanagement with Alliander NV. End 2008 I was asked by Alliander  to help them with the improvement of project management and the implementation of portfolio management. Alliander is one of the biggest network companies in the Netherlands and consists of the business units Liander and Liandon. Liander manages the gas and electricity networks in its service area.

During this event I will give a presentation about portfoliomanagement and the way Liander has implemented portfolio management, what they accomplished so far and their plans for the future.

 Interested? Please look at the flyer: PiP uitnodiging_v04[1]

The flyer is in Dutch, if you want an English version or if  you have any question, please contact me at info@intrprimus.nl.