Do we need preparation time for a project?

How successful will you be as a project manager or organization if you immediately start with the execution of your project? Why do you want to spend so much time in starting up, in initiating your project? Your project executive, your sponsor would be happy if you say, that you will directly start with the delivery in stead of creating documents, plans etcetera or not? I hope your executive knows that in the preparation you will build the foundations for success. And this has nothing to do with an agile or waterfall approach. When your scope of what is to be done isn’t clear, when you have no plan how and when products will be delivered and at what costs, when risks are not identified or when you have not thought about the proper risk responses, there is one thing you will know for sure. Your approach is a guarantee for failure.

How many projects are in progress without a business justification, without clear roles and responsibilities defined, without processes to manage risks, issues and changes or to monitor and control progress?

If you can manage a project without setting your project objectives, your project controls, in terms of Cost (€), Time, Scope, Quality, Risk and Benefits, you will be a genius. I wish I could watch a discussion between you and your project executive if he wants you to have the project ready two months earlier. How are you going to convince him, without knowing your project objectives? Good luck I would say. For me it’s not a question, proper thinking or proper preparation will be key to be successful.

Photo is from Andrzej Buryan (http://aburyan.com)

Project boards, a play for three roles and a project manager

A great picture from Vivian Sassen, a Dutch photographer. What does it show? Three project board members running away or coming together for a swift decision? Are they available, do they have authority and credibility?

Three people, three roles, representing the Project Executive, the Senior User and the Senior Supplier, answering the questions: is it still worthwhile to continue with the project, will it bring the projected benefits, and can we build it?

What will happen is swift decision making is not guaranteed? Look at Cheetah’s law supporting the second Chaos report success factor of executive support, which states that swift decisions are typically better than analysis paralysis. Project success depends heavily on fast and decisive decisions. Three roles accountable for project success, providing unified direction, ensuring effective communications and providing visible and sustained support. What about you, your project, your project board? Do they bring added value to your project?

Project in trouble, who is to blame: Project Manager or Project Owner?

I came across a picture of one of my favourite photographers Gilbert Garcin called consequences. This reminded me of last week’s project board awareness workshop which I facilitated. We discussed among other things roles and responsibilities of the project executive.

Who has to leave when a project is in trouble, or at risk? When the situation can’t be solved? In most cases you see that it’s the project manager who will be accused. But is this always correct?

Before you can take such a step, you must ask yourself:

• Did the project owner, the sponsor, enough to support the project manager?
• Was the project owner available when the project manager needed him?
• Was the project owner aware what kept the project manager awake? Did the project owner make a step forward to help solving the issue?
• Did the owner enough to communicate the business case to the organization to create a sense of urgency fort his project? to generate commitment for the project?
• Did the project owner made decisions when needed?
• Could the project owner explain what is happening in the project?
• Did the project owner give a clear mandate to the project manager?
• Did the project owner control the project manager?

If one or more of these questions are answered with no, you have to ask yourself if replacing the project manager will solve the problem.

A dinner for two, or two separate one’s?

This is my contribution to the second #PMFlashBlog focusing on Project Management in the Netherlands. I see in the Netherlands some focus points.

• More and more organizations look at or work with agile approaches (e.g. Scrum) besides the use of waterfall methods (e.g. PRINCE2) or use a combination of PRINCE2 and Agile.
• The same organizations are struggling with the governance for projects using agile. How to direct, how do we know where we are standing, are we still in control, when will we get the requested products?
• Where are we standing with the benefits? Are we getting the benefits?

In this blog post I will look at the governance part (applicable for agile as well as waterfall approaches) and I will use the picture Menu à deaux, from frank Kunert, published in the book Wunderland. To make this picture, frank created “an arrangement of two people who have nothing to say to one another, who avoid all points of contact, even avoiding eye contact. They nevertheless maintain a token coexistence by opting for a table for their ‘shared’ meals built so cleverly around a corner that neither sees the other, though they can see their own television. The only thing the two share visually is a candle in the middle of the table.”

Where have I seen this situation? Have you ever been in the situation that it’s difficult, or almost impossible to meet your project executive or sponsor? If there is no possibility to have informal meetings, have a cup of coffee or dinner together, how would one knows what the other one is thinking, what keeps one awake? How can you react if you don’t know? What will happen if your view on the project is a different view than the other has?

They have to work together; they have to become a team. Of course you could argue that not every project manager can do the job for each project owner. One size fits all is definitely not the case. If possible the project owner has to choose the right project manager. But let’s be honest for many organizations this is not that simple, there are just a few project managers and the one who just finished his/her job will be the first candidate for the next project. And be careful, one of the project success factors is the match between project owner and project manager. Not all leadership styles from the project manager as well as the project owner will lead to a successful project owner – project manager combination.

I see more and more emphasis on having the right combination of project owner and project manager. Do you see this too?

About “#PMFlashBlog – Project Management Around the World”

This post is part of the second round of the #PMFlashBlog where over 50 project management bloggers will release a post about their view of project management in their part of the world. Beginning with North America then followed by Europe & Australia bloggers will post their view each Monday for several weeks until we have gone around the world.

The complete list of all participating blogs is found here so please go and check them out!”

boekrecensie: De stuurgroep aan het roer

Zojuist de laatste boekenaanwinst van KWD Resultaatmanagement via Luuk Ketel ontvangen. Een vlot lezend boekje over De stuurgroep aan het roer. Voor en door projectmanagers. Precies lang genoeg om tijdens de vlucht van Amsterdam naar Luxemburg uit te lezen. Het boekje is geschreven door Ir. Eugene Penders, Drs. Arjan Jonker, Drs. Ing. Gerard Meijer en Prof. Dr. Ir. Fred Heemstra. Het boekje is opgebouwd in een 7-tal hoofdstukken en een literatuurlijst. Mocht je denken dat literatuur over stuurgroepen beperkt is dan brengt deze lijst je wellicht op andere gedachten.

Het eerste hoofdstuk laat zien dat theorie over en praktijk van stuurgroepen vaak ver uit elkaar liggen. Kijk maar naar projecten met meerdere opdrachtgevers, opdrachtgeverhiërarchie, onduidelijke mandaten voor klankbordgroepen, en (niet sturende) stuurgroepen bemand met een leger aan meepraters, tribunezitters en mandaatlozen. Kortom genoeg stof die een boekje rechtvaardigt.

In het tweede hoofdstuk komen een 9-tal karikaturen van stuurgroepen, zoals de dictatoriale, de over aanwezige of de bijpraatstuurgroep, aan bod die op ironische wijze laten zien hoe het niet moet en gelukkig ook een, de sturende stuurgroep, die wel effectief kan werken. Het hoofdstuk wordt afgesloten met dertien manieren om als stuurgroep lid een stuurgroep te saboteren, die je uiteraard moet vertalen in gedrag dat juist het succes van het project moet vergroten.

Het derde hoofdstuk beschrijft waarom we een stuurgroep nodig hebben, wat is een stuurgroep, wat zijn de taken, verantwoordelijkheden en bevoegdheden van de stuurgroep, en hoe ziet de samenstelling van de stuurgroep eruit. Uiteraard komt hierbij de theorie over stuurgroepen zoals beschreven in PRINCE2 aan bod. Het hoofdstuk wordt afgesloten met een overzicht dat taken en samenstelling van de stuurgroep afzet tegen de fase (definitie, ontwerp, …) waarin het project zich bevindt. Waarbij uiteraard aangegeven wordt dat continuïteit van een aantal leden van de stuurgroep wel gewaarborgd moet blijven.

In het vierde (inleiding tot) en het vijfde hoofdstuk komen de valkuilen en het verbeteren van het functioneren van de stuurgroep aan bod. Aan de hand van een verbeterframework kan de stuurgroep haar eigen volwassenheid bepalen en wat men moet doen om naar een volgend volwassenheidsniveau te gaan. Dit model wordt uitgebreid beschreven in een ander boekje van nagenoeg dezelfde auteurs: Professionaliseren van projectmanagement. (zie ook: https://hennyportman.wordpress.com/2009/12/11/boek-review-professionaliseren-van-projectmanagement/ ). Ik zelf gebruik dit framework als discussiekatalysator bij mijn project board awareness workshops die ik regelmatig houd met managementteams. Hierbij plotten de MT leden, als stuurgroeplid of opdrachtgever, het volwassenheidsniveau van de stuurgroepen waaraan zij deelnemen. Parallel daaraan vraag ik alle projectmanagers om hetzelfde te doen voor de stuurgroepen waaraan zij rapporteren. Beide resultaten leg ik over elkaar heen en de verschillen vormen een dankbaar instrument om de discussie met de stuurgroepleden mee aan te gaan.

Het zesde hoofdstuk gaat in op het kenmerk opdrachtgever en projectmanager uit het verbeterframework. Voor zowel de opdrachtgever als de projectmanager worden een aantal stijlen weergeven en daarnaast een overzicht met zinvolle combinaties van opdrachtgever- en projectmanager stijlen. Hierbij is de best performende combinatie een geboren leider als opdrachtgever met een democratische projectmanager. Jammer alleen dat we in de praktijk het niet altijd voor het kiezen hebben.

In het laatste hoofdstuk komen een aantal nuttige tips in de vorm van do’s en don’ts voor alle betrokkenen aan bod. Bij de PM zitten deze do’s en don’ts o.a. op de relatie, op communicatie, en op verwachtingen management. Op een PM congres opende Gerrit Koch eens met vanuit Aikido afkomstigde statements:

• Those who are skilled in combat do not become angered.
• Those who are skilled at winning do not become afraid.
• Thus the wise win before the fight, while the ignorant fight to win.

Kortom organiseer als PM de besluitvorming en waak voor verassingen in de stuurgroep.

De opdrachtgever moet op zijn of haar beurt onder andere zorgen voor een zo klein mogelijke stuurgroep die is afgestemd op de projectomgeving waarbij de juiste leden zijn geselecteerd en die hun rol en verantwoordelijkheid nemen.

Conclusie het lezen meer dan waard en bruikbaar voor zowel het stuurgroeplid als de projectmanager.

Boekrecensie: Sturen op projectsucces

Dit is het eerste deel uit een reeks praktijkgerichte boekjes; de KWD reeks voor en door projectmanagers. In dit boekje Sturen op projectsucces, geschreven door Fred Heemstra, Luuk Ketel en Arjan Jonker, staat succes centraal en dat vinden we terug in vijf hoofdstukken: Een succesvol project, Succes: een multi-dimensionaal begrip, De succesactoren en hun beeld van projectsucces, Invulling van het begrip projectsucces en Sturen op projectsucces in de praktijk.

De schrijvers stellen terecht dat er verschillende visies zijn op projectsucces. Vanuit een procesbenadering kijk je naar de procesdoelen zoals tijd, geld en specificaties en vanuit de productbenadering wordt succes bepaald door de toegevoegde waarde voor de organisatie, de benefits voor gebruikers en de tevredenheid van gebruikers en lijnmanagers. En uiteraard kunnen deze twee visies elkaar aanvullen.

De eerste visie omschrijf ikzelf als de OTOBOS benadering (On Time, On Budget, On Scope) en wordt ook wel gebruikt om het succes van de projectmanager aan te tonen, de tweede visie relateer ik o.a. aan de realisatie van de business case. Kan dus veelal nog niet bepaald worden bij afsluiting van het project maar pas een x aantal maanden na oplevering. Wat ik mis in dit hoofdstuk is een beschouwing over gedrag van een projectmanager als een organisatie kiest voor de procesbenadering. Als opdrachtgevers en projectmanagers worden afgerekend op OTOBOS, werk je in de hand dat overmatige slack in de planning wordt opgenomen, dat budgetten te ruim gepland worden, om maar te bereiken dat projecten binnen tijd en budget worden opgeleverd. Wat is succesvoller een project dat precies binnen de planning van 9 maanden blijft of een project dat een escalatie heeft gehad waarin de einddatum drie weken is opgeschoven en uiteindelijk 7 maanden en 3 weken heeft geduurd. Conform OTOBOS moeten we kiezen voor het eerste project maar als opdrachtgever ben ik uiteindelijk nog steeds vijf weken eerder op de markt met het tweede project.

Het volgende hoofdstuk gaat in op Kritieke Succes Factoren (KSF) en succesactoren. De schrijvers hebben een link gelegd tussen de KSF en de persoon, de succesactor, die uiteindelijk verantwoordelijk is voor het juist inregelen van de KSF. Bij de meeste projectrapportages zien we een informatiestroom van projectmanager naar stuurgroep en stakeholders. hierbij geeft de projectmanager zijn op feiten gebaseerde waarheid weer (geld, tijd, scope, risico’s), waarop vervolgens de stuurgroep besluiten gaat nemen. Stuurgroepleden en stakeholders zitten dan veelal in een reactieve modus. De schrijvers zien graag, en daar ben ik het helemaal mee eens, dat alle betrokkenen, meer actief bij het succes van het project betrokken worden. Hoe? Door het ze te vragen. Ipv de projectmanager die een voortgangsrapportage invult, neemt het PMO het initiatief om alle stakeholders uit te vragen en op basis van de antwoorden ontstaat een veel completer beeld van het succes van het project. Deze nieuwe rapportage is de Project Balanced Scorecard (PBS). In de PBS komen de volgende perspectieven aan bod: Product/resultaat, Beheersing, leren en business waarde. De specifieke KPIs kunnen uiteraard per organisatie verschillen maar de schrijvers geven op basis van hun eigen ervaring met de PBS een grootste gemene deler van mogelijke KPIs.

Vervolgens wordt een praktijkvoorbeeld inclusief implementatie van de PBS uitgewerkt.

Tenslotte vinden we in de bijlage een literatuurlijst en een overzicht van ruim 60 mogelijke KPI’s voor het succes van een (IT-)project.

Het boekje heeft mij in ieder geval aan het denken gezet en de vraag opgeroepen wat ik uit dit boekje in mijn eigen praktijk kan implementeren. Terecht stellen de schrijvers dat je niet met alle projecten tegelijkertijd moet beginnen. Kies 1 of 2 projecten of, denk ik dan zelf, kies een paar KPIs waarbij je periodiek de stakeholders gaat bevragen naar hun visie op het succes van een project.

Wat mij betreft een prima initiatief van KWD Resultaatmanagement en ik ben benieuwd naar de volgende deeltjes.

Het boek is voor projectmanagersbazen gratis aan te vragen bij KWD en voor andere geïnteresseerden voor € 9,95 te koop. Via KWD Resultaatmanagement.

Boek recensie: De Projectsaboteur en PRINCE2

Zojuist het boekje ‘De Projectsaboteur en PRINCE2’ van Dion Kotterman en Jeroen Gietema gelezen. Je leest het in één keer uit. Dion en Jeroen schreven in 2007 al het boek ‘De projectsaboteur’. Dit laatste boek stelde de saboteur centraal. Hoe je als saboteur een project efficiënt, effectief maar vooral professioneel saboteert. In dit boekje kijken we vanuit de projectmanager naar de saboteur. We volgen Simon, een jonge projectmanager, die een aantal saboteurs in zijn eigen project weet te ontmantelen. De lezer wordt meegenomen bij de stappen die Simon zet om zijn project te initiëren en de problemen die hij tegenkomt bij het managen van zijn project. Zoals uit de titel blijkt hanteert hij hierbij de methode PRINCE2. Het boek gaat echter niet over PRINCE2 zelf, Simon had iedere andere projectmanagementmethode kunnen gebruiken. Dat doet aan het verhaal verder niets af. Projectmanagement is echter meer dan het toepassen van methoden en technieken. Aandacht voor intermenselijke aspecten, te beginnen bij een goede stakeholderanalyse, en andere gedragsvaardigheden zijn minstens zo belangrijk. We zien wat het betekent als je als beginnende projectmanager overlopen wordt en toegeeft aan druk van buiten om niet gedragen documenten en voorstellen ter goedkeuring aan te bieden. Het verhaal laat ook goed zien wat het betekent als je met een stuurgroep te maken krijgt die niet de juiste mensen bevat. Er wordt niet gestuurd, beslissingen worden niet genomen er is alleen aandacht voor het reviewen. De ervaren projectmanager laat zich zo’n stuurgroep niet opdringen. Daarnaast krijgen we een kijkje hoe projecten schijnbaar door belanghebbenden ondersteund worden terwijl het tegenovergestelde, projectsabotage, bewerkstelligd wordt. Projecteer je deze verhaallijn op je eigen projecten dan hoop ik dat er geen lichtje gaat branden. Is het wel het geval dan zal je onmiddellijk in actie moeten komen om je eigen projectsaboteur te ontmaskeren. Kortom ik kan dit vlot leesbare boekje van harte aanbevelen. Niet om meer te weten te komen van PRINCE2 maar om je eigen stakeholdervaardigheden en intermenselijke aspecten beter onder de knie te kunnen krijgen.
Bestellen:De Projectsaboteur en PRINCE2

PRINCE2: Project Organization

From time to time I receive requests to explain the project governance structure. Based on some video’s I found on YouTube I created a small video explaining the set up of a Project Management Team structure (PRINCE2 2009).
I would like to hear your comments and if you see a need for more of these simple videos to explain other PRINCE2 themes or principles.

Book review: Directing Successful Projects with PRINCE2

At this moment I am facilitating Project board awareness workshops for senior managers from different business units in Central and Eastern Europe.
The theory in these workshops is based on Michiel van der Molen’s book ‘PRINCE2 for the Project Executive’.
During these project board awareness workshops we discuss governance principles of PRINCE2. Based on the 2009 version we now must say the PRINCE2 principles. Explaining the theory of these principles is not enough. What are the current governance issues? How will those principles help us? The discussion of the current set up of project boards and compares those project board compositions with the theory regarding the roles and responsibilities of the executive, the senior user and the senior supplier will give a lot of clearness. And as a result project board compositions will change.

Now, with the new PRINCE2 2009 version, there is a new book Directing Successful Projects with PRINCE2. As stated in the introduction, a manual designed;
–    For managers taking on senior project roles
–    As a reference guide for managers who wish to check the detailed guidance on specific topics
–    As a source of information on PRINCE2 for senior managers considering adopting the method.

What does this mean? Can I skip my project board awareness workshops and buy an distribute copies of this book to senior managers?

The book itself starts with an overview of PRINCE2 and the project board duties and behaviours. Next it describes standard intervention moments and corresponding actions during the project. It follows the sequence starting up a project, authorize initiation, authorize the project, authorize a stage or exception plan, gives ad hoc direction, authorize project closure and reviewing benefits.
Especially the project board duties and behaviours and the set up of the project board are very useful. It gives for each role a nice overview of all responsibilities. For all steps it clearly described what the focus must be from every role within the project board. I missed some more detailed guidance regarding the size of the project board. Now it’s very briefly discussed within the seventh PRINCE2 principle ‘Tailoring’ but this is an issue where lots of organizations are struggling with. The appendix contains product description outlines of the baseline management products and most of the report management products. This is a subset of all baseline, record and report management products as described in the ‘Managing Successful Projects with PRINCE2’ guide.
Does this mean that the manual can replace the workshops? I don’t think so. I think that having discussions with senior management about existing PRINCE2 principles issues like the current set up of project boards is much more valuable than only read this book. For me it’s even the question if senior management will read this 160+ page book. Is this really a book designed for senior managers or must we say that the content is very important for managers taking on senior project roles but they will not find time for reading. It’s complex material with lots of lists, actions to perform etcetera. Maybe this was also the reason why corresponding parts from chapter 13: ‘Directing a Project’ from the ‘Managing Successful Projects with PRINCE2’ guide, are not reflected here. Take e.g. the overview of directing a project (fig 13.1) or the responsibility matrices with the producer, reviewer and approver of the management products. I would say that the manual is especially designed for those people in an organisation who are responsible for the implementation of PRINCE2 throughout the whole organisation. Thus training/coaching of project managers as well as senior managers who will have senior project roles like executive, senior user or senior supplier. And for this purpose I will definitely recommend this manual.

In a next article I will discuss the PRINCE2 management documents and I will make a comparison between the 2005 and 2009 documents.