Eigen straatje schoonvegen

In deze tijd van sneeuwval nemen veel mensen de sneeuwschuiver ter hand en vegen hun tuinpad en het trottoir voor hun huis schoon om te voorkomen dat ze uitglijden of veel sneeuw naar binnen lopen.

Toen ik met de kinderen op de slee naar de supermarkt liep, viel het me op dat veel mensen alleen het gedeelte van het trottoir voor hun eigen huis schoonvegen. Terwijl ik de slee voortrok vroeg ik me af wat daar nu het nut van is om alleen je ‘eigen straatje’ schoon te vegen. Wanneer je de deur uit loopt heb je de eerste meters schone voeten maar vervolgens stap je weer in de sneeuw en maak je kans om uit te glijden.

Enkele straten verder kwam ik een trottoir tegen dat helemaal schoon gemaakt was over tientallen meters. Hier hadden ze blijkbaar met elkaar afgesproken om gezamenlijk het trottoir schoon te maken. Veel effectiever.

Ik kon het niet laten deze situatie door te trekken naar de ‘zakelijke wereld’.

Helaas kom ik maar al te vaak tegen dat medewerkers in een project alleen hun ‘eigen straatje’ schoonvegen. Hiermee bedoel ik dat ze alleen hun eigen werkzaamheden doen en die met schotten afbakenen om het resultaat vervolgens over de muur gooien. Andere medewerkers moeten maar zien wat ze er mee doen. Ik heb mijn werk gedaan, lijken ze te zeggen. Ze denken daarbij niet na over de context waarin hun werkzaamheden plaatsvinden en stemmen ze niet af op de werkzaamheden van anderen.

Deze houding waarbij alleen in ‘eigen straatje’ wordt gedacht is verre van effectief.

Wanneer je breder kijkt en je eigen werkzaamheden afstemt met die van je medewerkers, dan heeft het veel meer effect. (zoals bij het afstemmen om gezamenlijk de straat schoon te vegen) Dus: overleg met elkaar wat de ander doet, pak het gezamenlijk aan, bedenk hoe je kan samenwerken met het beste resultaat.

Ik hoop dat we dat als voornemen meenemen het nieuwe jaar in: niet meer in het ‘eigen straatje’ denken, maar vanuit gemeenschappelijke doelen samenwerken.

Zullen we met elkaar de weg hier naar toe schoon vegen?

Door de bomen het bos niet meer zien.

Ik liep vorige week in een bos waar Staatsbosbeheer bezig was met werkzaamheden.
Op het betreffende landgoed zag je bijna letterlijk door de bomen het bos niet meer.
De oorspronkelijke structuren van het terrein waren niet of nauwelijks meer zichtbaar. Om deze structuren weer zichtbaar te krijgen is Staatsbosbeheer ‘zichtlijnen’ aan het creëren. Dit doen ze door doorgegroeide bomen te kappen, doorgewoekerde struiken en beplanting te snoeien en te veel aangeplante begroeiing weg te halen.

Ik kon het niet laten om deze vergelijking door te trekken naar projecten. Ook al heb je het project goed voorbereid en lijkt het alsof je alles onder controle hebt, toch is het mogelijk dat door omstandigheden het project vastloopt of dat er een ander problematisch issue wordt geconstateerd. Je ontdekt dat het project helemaal ‘vergroeid’ is. Je weet even niet meer wat je moet doen. Je ziet door de bomen het bos niet meer. Wat nu?

Zichtlijnen creëren natuurlijk!

Even pas op de plaats maken, terug naar de basis van het project. Waarvoor is het project opgezet, wat was ook al weer de scope van het project, wat wilden we bereiken? Met andere woorden: wat waren de structuren zoals je die aan het begin hebt gedefinieerd?

Daarna kijk je naar de huidige situatie. Welke richting gaan we nu op met het project, wat is de huidige scope, welke mensen en middelen zijn er in de loop der tijd aan het project toegevoegd?

Als laatste beoordeel je de veranderingen op hun meerwaarde ten opzichte van het project. Dan kan het zijn dat je bijvoorbeeld de scope moet bijstellen, moet snoeien in de middelen of afstand moet doen van mensen die onbewust in het project zijn gekomen. Op deze manier creëer je weer ‘zichtlijnen’ die je zicht geven op de structuren van het project.

Ik ben benieuwd wat jullie ervaringen zijn met vastgelopen werkzaamheden of projecten. Wat heb jij gedaan toen je door de bomen het bos niet meer zag. Welke tips heb jij? Deel je ervaringen hieronder.

Dit is pas representatief

Vorige week publiceerde dagblad De Pers een artikel over de samenstelling van het nieuwe kabinet Rutte. Er zouden te weinig vrouwen, veel te veel hoogopgeleiden en hockeyers in het mannenkabinet Rutte zitting hebben; geen juiste afspiegeling van de maatschappij (rokers, drinkers, gescheiden mensen, lager opgeleiden, sporters etc.) Vervolgens beschrijft het artikel waaruit het nieuwe kabinet dan wel zou moeten bestaan waarmee wordt aangetoond dat het onmogelijk is om een juiste afspiegeling van de bevolking te bewerkstelligen.

Hoe is dat eigenlijk bij projectteams? Waar let je op bij de samenstelling van een nieuw team? Welke afspiegeling moet daarin zichtbaar zijn? Is het mogelijk een representatief team neer te zetten zonder dat dit ten koste gaat van de kwaliteit van het team? Al deze vragen spelen een rol bij het opzetten van een projectorganisatie en het samenstellen van een projectteam.

Bij een projectteam zijn representatie en kwaliteit geen afzonderlijke factoren. Sterker nog, een team dat bestaat uit een goede afspiegeling van opdrachtgever, eindgebruiker en leverancier is een belangrijke factor voor de kwaliteit van het team. Is de opdrachtgever onvoldoende vertegenwoordigd dan is de kans groot dat het project iets oplevert wat niet aan de verwachtingen voldoet. Is de leverancier niet goed vertegenwoordigd dan is het moeilijk het projectresultaat efficiënt te realiseren. En als de eindgebruiker afwezig is in het team dan is de kans groot dat het project iets oplevert wat niet door de organisatie wordt geaccepteerd.

Maar er zijn meer factoren belangrijk bij een representatief team. Denk hierbij eens aan de verschillende fasen die een project doorloopt van opstarten tot uitvoeren. In de eerste   fase(n) zijn vooral denkers in het projectteam nodig en in de volgende fase(n) vooral doeners. Naast de denkers en de doeners is het ook wenselijk dat er specialisten vertegenwoordigd zijn voor het inbrengen van inhoudelijke kennis, generalisten voor het overzicht, controllers voor de kwaliteitscontrole, ondersteuners voor de administratie en ga zo maar door.

Zo zie je dat het nog niet zo eenvoudig is een optimaal projectteam samen te stellen met een goede afspiegeling van de verschillende functies, rollen en karakters. En dan heb ik het nog niet eens gehad over verschillende teamrollen zoals bijvoorbeeld de Belbin rollen.

In theorie kunnen we onze voorkeur over de samenstelling van een projectteam aangeven maar in de praktijk moeten we het doen met de mogelijkheden (mensen) die er zijn. Dan is het zoeken naar de meest optimale samenstelling waarbij de theoretisch gewenste afspiegeling niet haalbaar is.

Ben jij een goede opdrachtgever?

Wat doe jij als opdrachtgever met je project(en)? Besteed je ze volledig uit aan de projectmanager(s) en zie je het eindresultaat wel, of ben je er actiever bij betrokken?

In de praktijk kom ik helaas erg veel de eerste situatie tegen, een blindelings vertrouwen in de projectmanager op een goede afloop. Een gezond vertrouwen in de vakkundigheid van de projectmanager is natuurlijk een goede instelling maar daarmee ook de handen van het project afhalen en afwachten tot het projectresultaat wordt opgeleverd is een risicovolle onderneming.

Ten eerste is de opdrachtgever eindverantwoordelijk voor het project. Alleen deze verantwoordelijkheid zou al een grote mate van betrokkenheid moeten initiëren.

Ten tweede is de opdrachtgever verantwoordelijk voor de businesscase. Regelmatig wordt deze verantwoordelijkheid doorgeschoven naar de projectmanager. Dit is onterecht. De opdrachtgever is eigenaar van de business(case) en verantwoordelijk dat deze wordt opgesteld. De projectmanager kan hierin zeker ondersteunen maar kan nooit de verantwoordelijkheid overnemen.

De opdrachtgever is eveneens verantwoordelijk voor het ter beschikking stellen van voldoende middelen om het project uit te voeren. Denk hierbij bijvoorbeeld aan tijd en geld. Daarnaast staat ook de Stuurgroep onder leiding van de opdrachtgever en is hij verantwoordelijk dat hierin de juiste beslissingen worden genomen zo mogelijk gevoed door de projectmanager.

De projectmanager is verantwoordelijk voor het opleveren van het projectresultaat, maar de opdrachtgever is er voor verantwoordelijk dat de gedefinieerde doelstellingen met het projectresultaat worden behaald.

Deze opsomming van verantwoordelijkheden is zeker niet compleet maar het is duidelijk dat het opdrachtgeverschap een actieve rol is waarbij het rustig achterover leunen met de gedachte dat je het project hebt uitbesteed zeer ongepast is. Sterker nog: een afzijdige opdrachtgever rapporteer ik als risico.

Schaap met vijf poten

Als projectmanager wordt er veel van je gevraagd. Je moet passende opleidingen hebben gevolgd en zo mogelijk hiervoor certificaten hebben behaald, kennis van de betreffende branche bezitten en niet te vergeten een flinke dosis ervaring meenemen. Nu is dit op zich nog niet zo bijzonder want dit geldt voor de meeste functies maar als projectmanager zijn er ook nogal wat verwachtingen waar je aan moet voldoen.

Je vervult een coördinerende rol, je bent de spin in het web van het project waardoor je met veel mensen te maken hebt. Door je coördinerende en sturende rol hebben al deze mensen bepaalde verwachtingen van je. Stuk voor stuk vinden ze dat je over bepaalde vaardigheden moet beschikken om het project goed te kunnen besturen. Hiervan zou je kunnen zeggen: ‘dat is toch logisch?’ en daar moet ik je deels gelijk in geven. Maar als we kijken naar de verschillende verwachtingen die de projectmedewerkers hebben met betrekking tot de persoonlijke vaardigheden van de projectmanager zien we iets opmerkelijks: de individuele verwachtingen lopen zo uiteen dat de projectmanager een schaap met vijf poten moet zijn. Hij moet een bestuurder zijn, een mentor, een stimulator, een controleur een bemiddelaar, een innovator en ga zo maar door.

Tijdens praktijkdagen van de leergang ‘Succesvol Projectmanagement’ doe ik vaak één van de vele testjes over teamrollen en persoonlijke vaardigheden. We laten de betreffende test invullen met de gedachte waaraan de projectmanager moet voldoen vanuit de visie van de deelnemer. Daarna werken we de individuele resultaten centraal uit en zien we daar altijd het profiel van het schaap met de 5 poten uit komen: de projectmanager moet over alle mogelijke vaardigheden beschikken om door het projectteam als competent te worden bestempeld. Geen realistische weergave natuurlijk.

Toch is deze waarneming niet nutteloos. Ten eerste kan inzichtelijk worden gemaakt waar binnen het projectteam de meeste behoefte aan is zodat daar nadrukkelijk op kan worden gestuurd. Ten tweede is het voor de projectmanager interessant wanneer hij zijn werkelijke persoonlijke profiel vergelijkt met het ‘gemeenschappelijke’ gewenste profiel en daarbij zijn minder sterke punten inzichtelijk maakt. Op deze ontbrekende vaardigheden kan hij extra mensen of middelen inzetten om het project toch te optimaal te besturen.

Samengevat is het belangrijk om je als projectmedewerker bewust te zijn van de verwachtingen die je hebt van je projectmanager en dat andere teamleden daar zeer waarschijnlijk andere verwachtingen bij hebben. Als projectmanager moet je je bewust zijn van de gewenste vaardigheden en duidelijk inzichtelijk maken waar je minder sterke kanten zitten zodoende hier extra op te sturen.

Vergeet vooral het belangrijkste niet: een projectmanager is ook maar een mens.

De informateur

Tijdens de informatieronde voor de vorming van een nieuw kabinet onderzoekt de informateur de mogelijkheden voor samenwerking tussen politieke partijen. Hij treedt op als verkenner en onderzoekt of er een stevig fundament ligt voor toekomstige samenwerking bij de besturing van ons land om de kans op succesvolle resultaten te vergroten.

Als we het begrip samenwerking doortrekken naar het werken in projecten kunnen we meerdere soorten van samenwerking onderscheiden:

• Samenwerking binnen het projectteam, projectmedewerkers onderling;
• Samenwerking met externe partijen;
• Samenwerking met derden zoals eindgebruikers, stakeholders;

Hebben we voor deze vormen van samenwerking ook een verkenningsfase waarin een informateur (wel of niet in de rol van projectmanager) de mogelijkheden onderzoekt voor een succesvolle samenwerking?

Als we kijken naar de eerste vorm van samenwerking, binnen het projectteam, dan moet ik vaak concluderen dat hier geen verkenningsfase aan vooraf gaat, waarbij wordt onderzocht of de komende projectteamleden wel goed met elkaar kunnen samenwerken. In de meeste gevallen krijg je de mensen toegewezen en daar moet je het mee doen.

Bij de tweede vorm van samenwerking, met externe partijen, is er regelmatig sprake van een verkenningsfase. Deze informatieronde is echter voor een groot gedeelte gericht op economische gronden waarbij het financiële aspect de belangrijkste factor is.

De samenwerking met derden als eindgebruikers en stakeholders wordt zelden onderzocht. Sterker nog, deze samenwerking wordt vaak onderschat waardoor de kans op acceptatie van projectresultaten door de omgeving wordt verkleind.

Samengevat, daar waar bij de (in)formatie van een nieuw kabinet de mogelijkheden van samenwerking eerst worden onderzocht, is dit bij het voorbereiden en uitvoeren van projecten juist onderbelicht terwijl de belangen niet minder groot hoeven te zijn.

Concluderend ligt er voor de projectmanager dus een zware taak de samenwerking met alle medewerkers en partijen mogelijk te maken, niet alleen in de voorbereidingsfase maar gedurende het hele project. Ik durf te beweren wanneer er meer aandacht wordt gegeven aan samenwerken bij projecten, resultaten vanzelf worden neergezet. Samenwerking werkt motiverend, waarbij de stimulans zich als een olievlek verspreid.

Een projectmanager zal dus over de juiste vaardigheden moeten beschikken om samenwerking tot stand te brengen en mogelijk te optimaliseren. Misschien moet in een verkenningsfase van een project eens een informateur worden benoemd die de juiste vaardigheden van een projectmanager onderzoekt voor een stevig fundament van de besturing van een project ?

Waar staan de gebruikers?

Afgelopen weekend was het onderwerp ‘Gecompliceerde portofoons brandweer levensgevaarlijk’ in het nieuws. De belangrijkste problemen met de C2000 portofoons zijn de kleine knopjes, veel te geavanceerde instellingen en vooral de soms wegvallende verbinding.

Als ik alleen al kijk naar de eerst genoemde problemen, de kleine knopjes en de veel te geavanceerde instellingen, dan kan ik als projectmanager mijn verbazing niet onderdrukken.Hoe is het mogelijk dat een project een (deel)product oplevert dat door de eindgebruikers nauwelijks hanteerbaar is. Iedereen kan bedenken dat je met handschoenen aan geen portofoon kan bedienen met kleine toetsen.
Zeker bij zo’n project als C2000 wat een essentiële bijdrage moet leveren aan het veilig en effectief functioneren van de hulpverleners is het van belang dat er een eindproduct (portofoon) wordt opgeleverd die volledig wordt geaccepteerd en gedragen door de gebruiker.

Als projectmanager komen bij het lezen van dit nieuwsbericht de volgende vragen naar boven: 

• Is er in de organisatie van de Stuurgroep een Senior User opgenomen die de rol van eindgebruiker heeft vervuld en zo ja is deze rol goed ingevuld door een juiste vertegenwoordiging van de eindgebruikers?
• Zijn de eindgebruikers betrokken geweest bij gebruikerssessie of geraadpleegd in klankbordgroepen? Van deze laatstgenoemde organisatievorm ben ik niet direct voorstander maar wanneer de taken, verantwoordelijkheden en bevoegdheden hiervan duidelijk zijn voor alle deelnemers kan een klantbord in deze situatie een absolute meerwaarde hebben.
• Is het Programma van eisen en wensen ook vanuit een operationele invalshoek opgezet of is er alleen gekeken naar de functionele eisen
• Welke resultaten zijn er naar voren gekomen uit de testtrajecten, zijn de eindgebruikers daarbij betrokken, zijn de resultaten van de testtrajecten verwerkt in een aangepast product?
• Is de projectuitvoering regelmatig getoetst aan de Business Case van het project?
  Zonder deze inhoudelijk te kennen kan ik me voorstellen dat deze een soortgelijke formulering moet hebben: ‘De resultaten van dit project moeten een essentiële bijdrage leveren aan het veilig en effectief functioneren van de hulpverleners.’
  Wanneer je het opgeleverde product (portofoon) afzet tegen de Business Cas moet volgens mij geconcludeerd worden dat het project hieraan geen bijdrage levert en de voortzetting van het project op deze manier niet gerechtvaardigd is.
• Is er een volledige risicoanalyse uitgevoerd in het project? Gezien de lange doorlooptijd van dit project en de snelle opeenvolgende vernieuwingen in de ICT zou dit risico toch zeker geïnventariseerd moeten zijn om vervolgens te koppelen aan een beheersmaatregel.

Het zijn slechts vragen die naar voren komen als ik een dergelijk project onder ogen krijg. Ik heb het dan nog niet eens over de problemen met de slechte verbinding.

Ik wil geen kortzichtig inhoudelijk oordeel geven over dit project maar vanuit het oogpunt van projectbesturing heb ik wel het vermoeden dat het een en ander verbeterd kan worden.

Laten we hieruit in ieder geval onze lessen trekken en zo nodig verbeteren in toekomstige projecten.