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

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

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

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

Great Event at Atos Origin!

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

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

foto: Patrick de Goede van Eijk

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Finally

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

Differences in PRINCE2® v2009 versus v2005

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

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

a

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

a

Structural changes

The most important structural changes are:

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

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

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

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

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

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

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

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

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

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

• Delivery of the results in stages is pointedly assumed.

a

Changes to the manual

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

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

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

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

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

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

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

• The appendix incorporating risk categories has become defunct.

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

a

Detailed changes

Themes

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

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

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

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

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

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

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

a

Processes

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

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

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

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

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

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

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

a

Tailoring PRINCE2

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

a

Appendices

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

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

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

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

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

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

a

Conclusion

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

Good luck applying PRINCE2!

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

Project managers are from Mars, executives are from Mercury

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

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

a

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

a

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

a

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

a

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

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

A Clarifying moment

Recently one of my trainees, a bright young guy at an energy company, gave me some feedback on my work. He said: ‘you allowed me to make progress and let me grow, just by asking the right questions’. Besides being honoured with this comment, it was a clarifying moment for me.

I mean, how often are we, as a committed coach, not tempted to get personally involved with the candidate and his/her problem. Most of the times we can relate to the problem and get enthusiastic about the content or context. From experience we know, or maybe we think we know, what the problem is all about and what ‘the’ solution should be. But do we really? Aren’t we painting our own picture based on assumptions? And does it matter if we really know the problem from our own experience?

The remark of this candidate that I asked the right questions reminded me off my role and position as coach. It was an eye opener that helped me to realize again what my goal is as a coach. I am not there to be prejudice about the case or candidate. It is not about me, it’s about the other to be able to give authentic answers to his/her challenges. It’s about giving room to grow and feeling the victory of coming up with own answers and booking results in practice. When I think about this, I suddenly recognize the positive feeling and the driving energy accordingly. This is what it’s all about!