In onze ‘Training projectmanagement  in de praktijk’ zien wij de projectmanager als degene die verantwoordelijk is  voor de tijdige realisatie van een beoogd resultaat binnen budget en niet als een projectadministrateur die hecht aan compliance en die  altijd een ander de schuld kan geven van mislukking. Nee, met projectmanager bedoelen we iemand die een project kan managen zonder macht. De projectmanager richt de leveringsketen in en verkrijgt draagvlak bij zowel de vraagkant als de toeleveranciers. Bij de vraagkant door meer te leveren dan verwacht, bij de toeleveranciers door ook hun belangen te managen. Uitgangspunten voor zulke projectmanagers zijn:

• Eerst worden de goede dingen gedaan en dan de dingen goed.
• Een besluit is goed en geldig tot er een beter besluit wordt genomen.
• Projectrisico’s worden proactief aangepakt; een projectmanager heeft altijd een plan B.
• Een projectmanager zit altijd in zijn helikoptertje en wisselt continu in hoogte.
• Een project is geen democratie; een projectmanager streeft er niet naar altijd aardig te worden gevonden.
• Een projectmanager laat zijn opdrachtgever en zijn team scoren; niet ceremonieel, maar met echte resultaten.
• Een projectmanager zorg ervoor dat fouten maar één keer gemaakt worden.
• Een projectmanager laat zich niet gek maken, en vooral niet als het tegenzit.

Natuurlijk zijn voor dergelijke projectmanagers methodieken als PRINCE2, IPMA, MSP, RISMAN leuke achtergrondkennis.  Ze hebben echter allang ontdekt dat deze methoden op zich de kans op een goed projectresultaat niet vergroten. Het is niet voor niets, dat het aantal mislukte projecten in de afgelopen 30 jaar niet is afgenomen, ondanks alle investeringen in het verbeteren van projectmanagement.

Op genoemde methodieken gaan we dan ook niet in tijdens deze training. We willen u vooral inzicht geven in:

• hoe u een project afbakent, opdat het überhaupt kansrijk is;
• hoe u de behoefte van de opdrachtgever vertaalt naar een toeleveringsketen (intern en extern) die in staat is om gezamenlijk het resultaat te leveren, waarmee u aan die behoefte kunt  voldoen, welke eisen u moet stellen aan partijen en hoe u dit contractueel regelt met de externe partijen;
• hoe u de samenwerking in de keten organiseert zonder te vervallen in een poldermodel;
• hoe u zelf moet  functioneren om bovengenoemde uitgangspunten te realiseren en hoe u  daartoe omgaat met uw omgeving; hoe u erin kunt  slagen uw zin te krijgen ook al heeft u geen macht;
• wat het projectplan is dat u moet managen en hoe dat eruit ziet;
• wat de projectrisico’s en valkuilen zijn en hoe u deze kunt omzeilen;
• hoe u omgaat met grotere projecten, die per definitie een verandering betekenen.

Kortom, wij vinden het belangrijker, dat u een tiental waardevolle praktijktips krijgt waardoor uw functioneren als projectmanager daadwerkelijk verbetert, dan dat we u een methode of vaardigheden aanreiken die zonder uw persoonlijke kwaliteit toch niet gaan werken. De toon in de cursus is pragmatisch. Het gaat om de praktijk, met hier en daar een vleugje theorie.

Doelgroep

Doelgroep van de cursus zijn managers, projectmanagers en programmamanagers die complexe projecten moeten managen vanuit het belang van de opdrachtgever en waarbij naast externe leveranciers ook interne partijen moeten bijdragen aan het projectresultaat waarmee voldaan wordt aan de behoefte van de opdrachtgever. De training is ook geschikt voor projectmanagers van leveranciers die als hoofdaannemer de opdrachtgever willen ontzorgen.
Programma van de training

Dag 1

• Rondvlucht in uw helikopter boven het projectlandschap en zijn omgeving ofwel de basisbegrippen
• Afbakenen van het project met de opdrachtgever
• Managen zonder macht

Dag 2

• Inrichten leveringsketen
• Inkopen externe diensten
• Werkend maken van de leveringsketen
• Creëren budgetruimte zonder pijn
• Uw rol en welke andere spelers

Dag 3

• Welk projectplan u moet managen
• Hoe om te gaan met projectrisico’s en valkuilen
• Flexibiliteit en voortschrijdend inzicht
• De besturing van uw helikopter

Organisatie

De training wordt gegeven door Wiebe Zijlstra. Hij heeft bijna 30 jaar ervaring in het managen van projecten en programma’s, waarbij hij meestal  optrad namens de opdrachtgever. Niet het afzonderlijke projectresultaat stond daarbij centraal, maar het geïntegreerde resultaat van meerdere projecten. Veel projecten hadden een ICT-component. Dit zal tijdens de cursus merkbaar zijn. Vooral ook omdat ICT-leveranciers vaak moeilijk zijn te managen. De cursus is echter zeker niet specifiek gericht op het managen van ICT-projecten. Daarnaast heeft Wiebe  ruime ervaring met het doceren van allerlei projectmanagementtrainingen en opleidingen.

Deze driedaagse training wordt gegeven op 17, 18 en 19 april in de Reehorst in Ede. De Reehorst is uitstekend bereikbaar per auto en met de trein en biedt ook gelegenheid om te overnachten. Cursustijden zijn van 9.30 uur tot 16.30 uur. De maximale groepsgrootte is 12 deelnemers. De kosten van deze cursus inclusief cursusmateriaal en lunch bedragen € 1495,-.

U kunt zich aanmelden voor deze cursus via het inschrijfformulier. Aanvullende informatie of meer informatie over het in-company geven van deze training kunt u krijgen via het contactformulier of door ons te bellen op 0318 641 898.

Visie op projectmanagement tijdens de training

Als u zich een beeld wil vormen van onze visie op projecten en programma’s en dus  van wat u kunt verwachten tijdens de training, dan verwijzen we u graag naar de volgende artikelen in de ZBC kennisbank:

• Bij projectmatig werken zijn afspraken beter dan procedures
• Een project is toch geen democratie
• Verandermanagement, ego’s en cognitieve dissonantie
• Hoe baten realiseren met programmamanagement
• Zeven tips voor het inkopen van ICT-projecten
• Wilt u een Smart, Golf, Mercedes of Rolls
• Opdrachtgevers ICT-projecten zijn of worden bedonderd
• Tips voor een begrijpelijk SLA of ICT-contract
• Waarom goede projectmanagers vaak slechte programmamanagers zijn
• Waarom veel organisaties niet met projecten kunnen omgaan
• Prince 2 geeft de projectmanager vooraf al decharge
• Risman project risico management: de spelers en het spel

Download:       

No related posts.

De werkwijze van ‘het onmogelijke doen we direct, wonderen duren iets langer’ is in de huidige tijd niet meer vol te houden. Ook al wordt er intern nog zo hard gewerkt aan verbetering van de communicatie- en informatiestromen, de klant zal dan steeds voor verrassingen komen te staan. En meestal zijn dat geen verrassingen waarop hij zit te wachten.

Gaat het bij u ook als volgt?

• Allerlei zaken worden in spreadsheets bijgehouden, omdat het zo lekker overzichtelijk is. Soms lijkt uw bedrijf wel een spreadsheetfabriek. Elke individuele medewerker gebruikt echter vaak zijn eigen spreadsheet. De spreadsheets dragen daardoor niet bepaald bij aan het verminderen van miscommunicatie.
• Uw medewerkers noteren afspraken vaak op geeltjes. Als dat er echter teveel worden, dan blijven die geeltjes gewoon hangen en blijven acties uit.
• Er wordt veelvuldig gebeld, er worden sms’jes verstuurd, er wordt gemaild. Afspraken die op die manier gemaakt worden, leiden echter veelal tot dubbele invoer en vooral tot het ontbreken van een overzicht van verplichtingen die u als bedrijf bent aangegaan.
• Uw verkopers hebben de wereld aan kaartjes van klanten die ze bezocht hebben. Als anderen in uw bedrijf de gegevens op die kaartjes nodig hebben, bijvoorbeeld voor nabellen of factureren, dan kunnen zij meestal de verkopers niet bereiken. Verkopers zijn immers ‘buiten’ bij de klant. Daar horen ze te zijn. Maar omgekeerd kunnen ook de verkopers niet checken of de verplichtingen die ze aangaan bij de klant, waargemaakt kunnen worden.
• Uw medewerkers in het primaire proces werken eveneens projectmatig. Ook zij zijn vaak buiten de deur. U hebt informatie nodig over de uren die zij hebben besteed. Misschien heeft u hiervoor een prachtig papieren systeem. Ook dat betekent echter weer dubbele invoer. En als er afspraken worden bijgesteld, dan worden de gewijzigde verplichting zelden vastgelegd waar het hoort, wat betekent dat uw leverbetrouwbaarheid vermindert en de planningen onbetrouwbaar worden.

Als u dit herkent, is het misschien tijd geworden om deze problemen structureel aan te pakken. Een geïntegreerde bedrijfsdatabase is een must.

Misschien heeft iemand u al eens voorgesteld om naar een ERP-oplossing te kijken. Maar u heeft geen zin in:

• investeringen in software, die vaak direct ook investeringen vergen in de infrastructuur;
• complexe implementaties, die vaak duurder uitvallen dan beloofd;
• een nieuw boekhoudpakket, want het bestaande pakket is goed genoeg.

Als u bovenstaande problemen ervaart en uw organisatie weer in control wilt brengen en u wilt niet investeren in ICT, dan kunnen we u een geïntegreerde oplossing bieden. Download hiertoe onze whitepaper via de Wordbutton hieronder. U kunt ook direct een online demo aanvragen via het reactieformulier.

Download:     

No related posts.

ICT in organisaties is tegenwoordig steeds meer confectiewerk. ICT-systemen worden steeds minder gebouwd: men koopt en implementeert standaardsoftware en assembleert de gewenste oplossing. Keuze is er te over. Een manager echter die een ERP-pakket moet selecteren en in de eigen organisatie laat implementeren, heeft daar meestal weinig ervaring mee. Hetzelfde geldt voor een directeur van een zorginstelling die aan de slag gaat met een veelbelovend ZIS (Ziekenhuis Informatie Systeem). Geen opdrachtgever zal vaker dan één of twee keer in zijn leven met zo’n selectie te maken krijgen. Dit hoeft geen probleem te zijn, mits de opdrachtgever maar wel zorgt, dat hij het overzicht behoudt en zeker stelt, dat de business en ICT matchen.
‘Van ICT-projecten heb ik géén verstand en dat wil ik gráág zo houden’ is een veelgehoorde grap onder managers. Misschien begrijpelijk, maar niet erg slim. Als u als opdrachtgever niet zelf in staat bent een oordeel te vormen, schakel dan iemand in die dit wel kan. Iemand, uiteraard, die onafhankelijk is, want opdrachtgever en opdrachtnemer hebben een tegenstrijdige businesscase. Voor een goede samenwerking moet met beider belangen rekening gehouden worden. Anders wordt het project meer een gevecht met alleen verliezers. Misschien dat uw CIO in aanmerking komt, als die tenminste meer is dan de baas van de ICT-manager. En anders kunt u iemand van buiten halen.

Eerste faaloorzaak: een vaag en steeds veranderend doel

Wanneer we wat dieper ingaan op de oorzaken van het mislukken, blijkt dat er twee monumentale faalfactoren zijn, die beide zijn terug te voeren op een gebrekkige invulling van het opdrachtgeverschap. Een vaag en steeds veranderend doel is één van de twee. Maar hoe kan een project dan vage en steeds veranderende doelen hebben? Dikwijls komt dat door de manier van denken en werken in de ICT, in combinatie met afwezig leiderschap. ICT’ers zijn geneigd ICT-projectvoorstellen te doen die bij aanvang een onduidelijk of globaal doel hebben. Ze vertouwen erop dat ze het doel van het project gaandeweg kunnen verhelderen. Dit van ‘grof naar fijn’ werken ziet men als heel gangbaar in een projectmatige IT-aanpak. En bij maatwerkprojecten werkte dit ook vaak uitstekend. Maar nu er tegenwoordig overwegend met standaardsoftware wordt gewerkt, kom je niet meer weg met een globaal beeld, dat later verder ingevuld wordt. Veel ERP-projecten mislukken, doordat men denkt dat alles wel in een ERP-systeem gegoten kan worden. In wezen kan dit ook, maar de aanschaf van een pakket kost dan eerst al handenvol geld en vervolgens zal blijken, dat wanneer het pakket aangepast moet worden aan veranderende bedrijfsprocessen, het nog veel meer gaat kosten. (Zie ook ‘Hoeveel ERP wilt u hebben ’.) Veel opdrachtgevers echter zullen niet eens onderkennen, dat hun doelen vaag zijn. Toch betekent het voor de ICT een wereld van verschil.

Tweede faaloorzaak: de stevige managementaanpak

De tweede grote faaloorzaak is ‘de stevige managementaanpak’. Eindverantwoordelijke opdrachtgevers hebben doorgaans erg weinig ervaring met grootschalige pakketimplementaties. Daardoor ontbreekt het ze vóór aanvang van een omvangrijk project met standaardsoftware aan voldoende visie op het omgaan met onzekerheid in het project. Een manier om met die onzekerheid om te gaan is de typische, stevige managementaanpak. Er staat veel op het spel en er mag niets misgaan. Dus de scope, het budget en de planning moeten vooraf 100% duidelijk zijn. Aangemoedigd door juristen en inkopers zet de opdrachtgever pas zijn handtekening onder een contract met de IT-leverancier als alle specificaties van het te realiseren IT-systeem 100% bekend zijn. Opdrachtgevers hebben daarnaast niet zelden een voorkeur voor een zogenaamd ‘fixed price contract’. Dit lijkt immers maximale duidelijkheid te geven. Dat is echter schijn. De enige zekerheid die men dan creëert, is dat het project een vechtcultuur krijgt en iedere flexibiliteit eruit wordt gezogen. Voortschrijdend inzicht is zo een doodlopende weg en samen als opdrachtgever en opdrachtnemer zoeken naar oplossingen bij problemen is niet meer aan de orde. (Zie ook ‘Bij projectmatig werken zijn afspraken beter dan procedures’.)
De meeste stevig gemanagete fixed price contracten gaan mis. Dit komt door dat het fixeren van scope, budget en planning niet alleen gevolgen heeft voor de prijs en de andere condities van het project, maar óók voor de samenwerking met het externe ICT-bedrijf dat de implementatie begeleidt. Bij het fixeren van een projectbudget wordt de onzekerheid over het verloop van het project niet weggenomen, ze wordt alleen overgeheveld naar de ICT-leverancier. Dit heeft allerhande nare bijwerkingen, die een goede samenwerking in de weg staan. De ICT-leverancier gaat achter een façade van schijnzekerheid aan de slag. De kwaliteit van de samenwerking is lager, doordat de informatievoorziening vanuit ICT-leverancier naar de opdrachtgever onvolledig is. Uit onderzoek blijkt, dat projecten die in zijn geheel gefixeerd zijn in tijd en geld, vaker teleurstellen dan projecten waarbij die fixatie op voorhand niet plaatsvindt. (Zie ook ‘Tips voor een begrijpelijk SLA of ICT-contract’.)

ICT-dienstverleners hebben boter op hun hoofd

Helaas zijn er maar weinig ICT-leveranciers die klantgericht werken. De toegevoegde waarde van de leverancier voor de klant zou heel groot kunnen zijn, maar aandeelhouderswaarde telt vaak toch zwaarder. Onderzoek heeft de volgende ‘normale gebruiken’ van ICT-dienstverleners aan het licht gebracht:

• Veel ICT-dienstverleners geven onomwonden toe dat de projecten die zij doen meestal NIET goed gealined zijn met de businesskant van hun opdrachtgever.
• ICT-bedrijven laten na de doelen van een investering te checken. Ze brengen doodleuk een offerte uit, ook wanneer het businessdoel bij een klant NIET duidelijk is.
• Door de klant opgestelde business cases worden door ICT-bedrijven niet of nauwelijks gecontroleerd.
• ICT-bedrijven krijgen (en nemen) veel te weinig tijd voor offertes.
• Projecten worden door ICT-bedrijven niet goed op voortgang gecontroleerd en vaak slecht, en door sommigen zelfs geheel niet, geëvalueerd. Een gerenommeerd Nederlands ICT-bedrijf legt stelselmatig alleen de ‘projectsuccessen’ vast, zodat gevreesd moet worden dat daar al jaren dezelfde fouten gemaakt worden.
• Maatregelen die ICT-bedrijven nemen om projecten op de rails te houden beslaan meestal uitsluitend ICT-technische of projectmanagementaspecten, terwijl daar de uitdaging niet in zit. Projecten met standaardsoftware mislukken immers niet door technische problemen, maar door miscommunicatie en het in beton gieten van het samenwerkingsproces.

Het is dus een combinatie van onkunde en plat commercieel opportunisme in de ICT-sector. Klanten van ICT-bedrijven hebben dan ook een significant lagere klanttevredenheid dan die van andere zakelijke dienstverleners. Deze situatie bestaat al jaren en zal pas verbeteren als opdrachtgevers een betere invulling geven aan hun rol.

Common sense en ICT zijn vreemden voor elkaar

Opdrachtgevers zullen nooit de tijd krijgen om voldoende ervaring op te doen met grote pakketimplementies. Gelukkig worden ze omringt door mensen die die ervaring wel hebben. In alle sectoren buiten de ICT geldt een aantal normale spelregels:

• Natuurlijk is de opdrachtgever verantwoordelijk, net als een CEO of voorzitter van de RvB verantwoordelijk is voor alles wat er in zijn /haar bedrijf door medewerkers wordt gedaan (of nagelaten).
• Natuurlijk dient de gebruikersorganisatie een samenhangend pakket van eisen op te stellen, waaraan de gewenste oplossing moet voldoen.
• Natuurlijk vereist de ethiek dat een project- of programmamanager zijn/haar opdrachtgever helpt en ook beschermt tegen ‘missons impossible’.
• Natuurlijk is een zichzelf respecterende IT-leverancier verplicht om zich te verdiepen in het probleem van de klant en met een passende oplossing te komen.

De praktijk echter laat zien dat deze ‘vanzelfsprekendheden’ eerder uitzondering dan regel zijn en dus is het aan te bevelen om te kiezen voor een opdrachtgever die niet alleen verantwoordelijk is, maar ook verantwoordelijkheid neemt. Zo’n opdrachtgever zal zich doorgaans omringen met deskundigen op het terrein van de gewenste ICT-oplossing, op het terrein van de organisatie waarbinnen het project zich afspeelt en op het terrein van het uitvoeren van het project zelf. Want van de ICT-leverancier zijn deze deskundigheden niet te verwachten.
Resteert nog het kiezen van de minst slechte ICT-leverancier, de leverancier die bereid is mee te denken met de opdrachtgever en zijn verantwoordelijkheid als leverancier te nemen. In ‘Zeven tips voor het inkopen van ICT-projecten’ kunt u lezen hoe u tot een juiste keuze kunt komen. Het belangrijkste effect zal zijn, dat u als opdrachtgever een project opzet dat de volgende kenmerken heeft:

• een nauwe samenwerking;
• het samen oplossen van problemen;
• het samen zoeken naar naar de beste prijs-prestatie;
• een prettige werksfeer;
• een resultaat dat de bedrijfsprocessen verbetert.

Dan is het zwartepietenspel over wie schuldig is aan het falen van het project ook niet meer aan de orde. Het project wordt gewoon een succes en daar wordt iedereen beter van.

Bron:
Nico Beenker, ‘Opdrachtgever grootste risico bij IT-projecten’. Managementsite.nl. 18 mei 2010.

Download:       

No related posts.

Natuurlijk kunt u bovengenoemde artikelen bij de hand houden. Maar misschien heeft u ook voldoende houvast aan het volgende schema om de toepassing van het enneagram te begrijpen. (U kunt op het schema klikken en vervolgens kunt u het liggend afdrukken.)

Enneagramtype 1: De Perfectionist

De Perfectionist is als efficiënte doener uitstekend bruikbaar in projecten. Als projectmedewerker, als meewerkend voorman of als rechterhand van een projectmanager. Af te raden is om de Perfectionist te belasten met de kwaliteitscontrole. Daarvoor is hij te precies en teveel geneigd om zelf aangetroffen problemen op te lossen. Ook als projectmanager is hij minder geschikt. Want als hij in de stress schiet, dan jaagt hij via zijn stresstype, de Romanticus, zijn hele projectteam in de stress. Wel fungeert hij uitstekend als rechterhand van een programmamanager of een projectmanager, die hem uit de wind houdt en ervoor zorgt dan hij ontspannen zijn ding kan doen. In die rol kan hij zelfs grotere projecten uitstekend runnen, want hij is dan relaxed, sociaal en precies.

Enneagramtype 2: De Helper

De Helper is geschikt als projectmedewerker, want hij is efficiënt en wil graag voorzien in de behoeften van zijn superieuren. Voor waardering en complimenten is hij bereid zich volledig in te spannen, mits de projectleider zijn waardering voor de Helper ook maar communiceert naar personen binnen de organisatie, die de Helper hoog aanslaat. Anders schiet de Helper in de stress en krijgt hij de slechte eigenschappen van de Baas. Hij wordt onbestuurbaar en recalcitrant. Als projectleider is de Helper weinig geschikt. Hij zal dan waarschijnlijk te weinig waardering uit zijn omgeving krijgen, zodat hij de neiging krijgt om op te willen vallen, waartoe hij emotioneel, veeleisend en manipulatief gedrag zal gaan vertonen. En dat wordt noch door opdrachtgevers noch door het projectteam gepikt.

Enneagramtype 3: De Performer

Voor de meeste projecten is het te hopen, dat de Performer ontbreekt. Hij is te veel gefocust op prestaties en resultaten, zodat hij de overige projectleden in permanente staat van stress houdt, waardoor geen van de projectleden ook maar bij benadering goed zal functioneren of presteren. De Performer is een einzelgänger en geen teamplayer. Slechts in een aantal situaties kan de Performer bijdragen aan het succes van een project:

• Het is een project voor slechts één persoon.
• Er moet een belangrijke missie uitgevoerd worden binnen het project, die min of meer losstaat van het project.
• De Performer is projectmanager van een groot project zonder veel aandacht en sturing vanuit de opdrachtgever en heeft zeer zelfstandige en sterke projectleiders (bij voorkeur loyalisten) onder zich met elk hun eigen deelproject.
• Er is sprake van een noodsituatie, die linksom of rechtsom in zeer korte tijd opgelost moet worden en waarbij het doel de middelen heiligt.

Alleen in het laatste geval is succes bijna verzekerd. Het is zelfs nauwelijks denkbaar, dat een ander enneagramtype zo’n situatie beter tot een goed einde kan brengen.

Enneagramtype 4: De Romanticus

De Romanticus voelt zich absoluut niet thuis in een project waarin een concreet resultaat opgeleverd moet worden binnen gestelde randvoorwaarden. Dat is zo in strijd met zijn behoeften, dat hij zich hier totaal niet door uitgedaagd zal voelen of gemotiveerd zal meewerken. Sterker nog, je kunt hem beter niet dan wel aan boord hebben, omdat hij stressverwekkend is voor iedereen die wel resultaatgericht is, waardoor ook resultaatgerichte projectleden minder zullen gaan presteren.

Enneagramtype 5: De Analist

Ook de Analist is ongeschikt om in projecten te werken. Hij houdt niet van druk en is te weinig resultaatgericht. Dat maakt hem voor de meeste projecten ongeschikt als projectleider en projectmedewerker. Hierop is eigenlijk maar één uitzondering: de Analist heeft zijn eigen onderzoeksproject of deelproject en er is geen deadline.

Enneagramtype 6: De Loyalist

Vaak worden loyalisten ingezet als projectmanager bij overheden en grote organisaties. Het zijn tenslotte probleemoplossers, die in vredestijd risicobewust en aimabel zijn en in oorlogstijd hoe dan ook overleven. Dat klinkt natuurlijk geweldig, maar is het in de praktijk lang niet altijd. Laten we de feiten eens op een rijtje zetten. Als projectmedewerker zijn loyalisten vaak ongeschikt. Ze werken meestal vertragend, doordat ze uitstellen en bij elke actie aandacht vragen voor de risico’s. Dat schiet niet op. Voor detacheringbureaus zijn het echter geweldige projectmanagers. Ze komen in vredestijd aimabel, risicobewust en bij problemen daadkrachtig over. Maar loyalisten dekken zich, en dus ook hun werkgever, perfect in. Loyalisten laten in en om het project iedereen aan het woord en ontlopen zo hun verantwoordelijkheid. (Zie ook ‘Een project is toch geen democratie’.) Graag hanteren ze als methodiek Prince2, want daarmee is het eenvoudig om de opdrachtgever de schuld te geven, als er iets misgaat. (Zie ook ‘Prince 2 geeft de projectmanager vooraf al decharge’.) De opdrachtgever heeft tenslotte de vorige milestone geaccordeerd. De Loyalist is wel zeer mensgericht (zijn ontspanningstype is de Bemiddelaar) als hij ontspannen is. En in tegenstelling tot de Bemiddelaar is de Loyalist in staat keuzes te maken anders dan het compromis. Zodra een project in slecht weer geraakt, lijkt hij daadkrachtig. Op de korte termijn werkt dit ook wel. Op de langere termijn echter wordt zichtbaar wat het stresstype van de Loyalist, de Performer, met zijn slechte eigenschappen heeft aangericht. Met manipulatie en zo nodig bedrog blijkt hij zijn zin te hebben doorgezet, en vaak ook te hebben gekregen. Maar daarna wordt hij wel door iedereen uitgekotst. Prima als deze projectleider een passant is en steeds weer gedetacheerd wordt, maar als vaste medewerker binnen dezelfde organisatie is hij nauwelijks te handhaven. Voor zijn werkgever is deze projectmanager natuurlijk een perfecte werknemer. Want hij scoort goed in de intake en heeft doorgaans een perfect CV.

Enneagramtype 7: De Levensgenieter

Als probleemoplosser is de Levensgenieter wel degelijk geschikt voor projecten, maar alleen in een beperkt aantal rollen. Want al is hij een probleemoplosser, hij is weinig gefocust op concrete resultaten en daarom totaal ongeschikt als projectmedewerker of projectleider. Pas in de rol van programmamanager of projectmanager met veel projecten, komt de Levensgenieter tot bloei. Als geen ander houdt hij het overzicht en de regie. Hij heeft onderaannemers of deelprojectleiders die daadwerkelijk de kastanjes uit het vuur slepen. Bij voorkeur zijn dit perfectionisten, die de rommel opruimen, die de Levensgenieter achterlaat. Door zijn helikopterview maakt de Levensgenieter de bij de perfectionisten ontstane irritatie meestal weer meer dan goed. En hectiek is voor de Levensgenieter juist een uitdaging. Hij ontspant hierdoor en neemt de tijd om alles op zijn gemak eens onder de loep te nemen. Hij dringt snel door tot de kern, maar daarna is de uitdaging eraf. Een project is leuk, zolang het maar niet op werk gaat lijken. Werk moet gedaan worden door anderen.

Enneagramtype 8: De Baas

De Baas is beperkt inzetbaar in projecten. Hij is enthousiasmerend en sterk, maar tegelijk ook een jonge hond. Als projectleider is hij, zolang het goed gaat, stimulerend en behulpzaam voor zijn team (zijn ontspanningstype is de Helper), maar als het tegenzit dan zondert hij zich af en trekt zich terug. Het projectteam wordt dan glad vergeten. Dat zoekt het verder maar uit. Een projectleider heeft voor de Baas als projectmedewerker een gebruiksaanwijzing nodig. Zorg ervoor dat de Baas zich goed voelt en hij zal er alles aan doen om zijn bijdrage te leveren (de Helper). Wanneer je de Baas onder druk zet of wanneer je wat anders wilt dan hij, dan schiet de Baas in de stress en onthoudt hij anderen gierig alles wat ze nodig hebben. De enige projectleider die hier goed mee om kan gaan is de Bemiddelaar. Een Performer of Levensgenieter als projectleider staat garant voor bonje.

Enneagramtype 9: De Bemiddelaar

De Bemiddelaar is uitermate geschikt voor projecten waarin het belangrijkste doel is alle stakeholders te vriend te houden. Hij is tenslotte zeer sociaal en erop gericht om het ieder naar de zin te maken. Consensus is de heilige graal. Als hij ontspannen is, dan wordt deze doener ook nog heel praktisch en dat maakt hem tot de perfecte projectmedewerker. Ook als projectleider of projectmanager is hij zeer geschikt. Als hij in de stress gejaagd wordt, dan wordt hij voorzichtig en procedureel (zijn stresstype is de Loyalist), wat ook van een projectleider verwacht mag worden. Het loopt echter fout als consensus niet meer toereikend is, als hijzelf keuzes moet maken. Hij wordt dan geheel risicomijdend en besluiteloos en als een opdrachtgever voor hem geen knopen doorhakt en keuzes maakt, dan loopt het project hier dood of het loopt zware vertraging op. De Bemiddelaar is niet in staat om impasses te doorbreken door keuzes te maken die voor bepaalde stakeholders negatief uitpakken. Echter met een goede opdrachtgever, die snapt hoe een Bemiddelaar in elkaar zit en die dus zelf waar nodig keuzes maakt, is de Bemiddelaar vaak een uitstekende projectleider.

Enneagram versus Belbin

We zien dus dat de probleemoplossers het best fungeren als projectleider of projectmanager, maar dat geen van deze enneagramtypen een garantie is voor succes. Dat hangt mede af van het team dat om de projectleider heen geformeerd wordt, van de invulling die de opdrachtgever geeft aan zijn rol en van de aard en de randvoorwaarden van de projectopdracht. Het Enneagram biedt wat meer houvast dan de Belbin-teamrollen. Bij Belbin is het voldoende de rollen in te vullen met verschillende typen. Bij de invulling van het team als geheel is dit heel nuttig. Het Enneagram benoemt ook rollen, maar beschrijft daarnaast de negatieve effecten die de inzet van bepaalde personen kan hebben op de teamprestatie en zegt daarbij ook meer over de keuze van de projectleider. Bij Belbin is de voorzitter (die lijkt sterk op de Bemiddelaar) vaak de geëigende persoon om projecten te leiden, of soms ook de vormer (dit is een soort kruising tussen de Performer en de Baas) Met het Enneagram kun je heel nadrukkelijk afwegingen maken, rekening houdend met verschillende omstandigheden. Belbin beschrijft bijvoorbeeld onder meer de noodzaak om binnen een succesvol team een plant te hebben. In het Enneagram vinden we deze plant terug als Romanticus of als Analist, juist de typen die minder geschikt geacht worden voor een projectteam. Voor een managementteam geldt een ander verhaal. Belbin is een goed hulpmiddel voor de samenstelling van dit team. Toch biedt ook dan het Enneagram aanvullende waarde om voorspellingen te kunnen doen over de chemie en dus over de effectiviteit. (Zie ook ‘Herkennen van enneagramtypen en hoe ze reageren bij stress en ontspanning’.)

Bron:
Joost van der Leij,  ‘Het Neurogram®; Je persoonlijkheid neurologisch verklaard met het Enneagram.’  Attrakt BV. april 2010.

Download:       

No related posts.

Waarom is een project een project?

Een project is een organisatievorm die zich onderscheidt van de lijnorganisatie. Een project is een tijdelijk samenwerkingsverband met een bepaald budget, een doelstelling en een beoogd resultaat. Er zijn organisaties die incidenteel een project uitvoeren, er zijn er die heel veel projecten uitvoeren en er zijn er die alleen maar projecten uitvoeren (een zogenaamde projectenorganisatie). Voor het opstarten van een project maakt dat nogal wat uit. Als uw organisatie veel projecten doet, heeft u de know how in huis, evenals ervaren projectmanagers en een projectmanagementaanpak. Als uw organisatie maar zo nu en dan een project uitvoert, is het zaak om bij de start goed na te denken. Want juist bij de start worden de meeste fouten gemaakt.
Nogal vaak zijn projecten niet succesvol. In de literatuur en op internet kunt u talloze lijstjes vinden van succes- en faalfactoren. De vraag is of projectorganisaties beter of slechter zijn dan lijnorganisaties. Ook lijnorganisaties presteren vaak onder de maat (kijk naar de jaarcijfers en vergelijk die met die de “best in class”). Het verschil zit er vooral in dat een project eenmalig is: van een mislukt project kun je natuurlijk leren, maar de situatie is een volgende keer weer anders. Als je daarentegen in een lijnorganisatie van je fouten leert, wordt de organisatie volwassener en succesvoller.
Elk project is in zekere zin uniek. Dat houdt in dat er een zeker risico is dat een project niet succesvol is, dus een zeker risico dat het project uitloopt in tijd, uitloopt in geld, dat de projectdoelstelling niet of niet volledig wordt behaald of dat het beoogde resultaat niet of niet volledig wordt gerealiseerd. Er bestaan allerlei maatregelen die bedoeld zijn om een project succesvol te krijgen. Eén daarvan is de projectaanpak oftewel de projectmanagementmethode. In dit artikel gaan we in op de veelgebruikte projectmanagementaanpak Prince2. Een andere veel gebruikte projectmanagementaanpak is PINO: Prince In Name Only!

Wat is Prince2?

Prince staat voor PRojects IN Controlled Environments en is een gestructureerde methode voor effectief projectmanagement. De methode is gebaseerd op praktijkervaringen en is gedetailleerd uitgewerkt in projectprocessen, projectorganisatie, componenten, principes, projectmanagementproducten, checklisten enzovoorts. Voordelen van Prince2 zijn:

• Het is een internationale en open standaard.
  Prince2 creëert een gemeenschappelijk begrippenkader, waardoor opdrachtgevers, projectmanagers en projectmedewerkers elkaar beter begrijpen.
• Prince2 is een erg volledig beschreven methode.

Dat laatste is meteen het nadeel. Veel gehoorde kritiek is dat Prince2 te uitgebreid is, te zwaar en te bureaucratisch. Het geeft weinig ruimte voor veranderingen en maakt een project star en inflexibel.
Omdat elk project uniek is, is ook elke projectorganisatie uniek. De projectaanpak moet daarom altijd afgestemd worden op de specifieke projectsituatie. Dogmatisch toepassen van Prince2 leidt dan ook niet tot succes. De kunst is om Prince2 op maat te snijden voor uw specifieke projectsituatie.

Waarom PINO?

PINO is lekker makkelijk. PINO gebruiken is Prince2 situationeel gebruiken. Maar waar ligt de grens tussen PINO en “op maat snijden” ? Al snel wordt PINO een vrijbrief om maar alles weg te laten wat lastig wordt gevonden. In de praktijk leidt dit vaak tot het hanteren van de typische Prince2-begrippen als projectbrief, PID, projectboard, business executive, highlight report en exception report, zonder de achterliggende principes en uitgangspunten.
Op maat snijden is natuurlijk prima, maar het moet wel gebeuren op basis van goede argumentatie. Als u niet het antwoord hebt op de volgende vragen, is de kans groot dat u PINO doet:

• Wat gebruiken we uit Prince2 en waarom zijn die onderdelen voor dit project belangrijk?
• Wat gebruiken we niet uit Prince2, of in afgeslankte vorm, en waarom zijn die onderdelen voor dit project niet belangrijk?

De kwaliteit van Prince2

Onder kwaliteit verstaan we in dit artikel: voldoen aan afspraken en aan impliciete eisen en verwachtingen. Stelt u zich een IT-project als volgt voor:

U kunt dan de kwaliteitsaspecten voorstellen als hieronder aangegeven. (Zie ook het artikel ‘Betere software door product- of proceskwaliteit?’)

Kwaliteitsaspecten

Wat u uiteindelijk wilt, is een kwalitatief goed eindproduct op tijd en binnen budget afleveren. Hiertoe moeten met kwalitatief goede input de projectprocessen effectief en efficiënt worden uitgevoerd.
Als u op deze manier naar Prince2 kijkt, vallen de volgende onderwerpen onder de noemer “kwaliteit”:

• Business case
  Een business case is de onderbouwing van de voorgenomen verandering. De verandering wordt in alle aspecten in kaart gebracht: de voordelen, de risico’s, de noodzakelijkheden, de kosten en de andere implicaties. De business case bevat de business requirements, de verbeteringen die de business wil realiseren in een nieuw of bestaand proces. (Zie het artikel ‘Requirements staan aan de basis van succes’.)
• Project quality plan
  Het project quality plan is onderdeel van het projectinitiatiedocument (PID). Hierin staan onder meer de kwaliteitsverwachtingen van de klant, de acceptatiecriteria en de verantwoordelijkheden met betrekking tot kwaliteit.
• Productbreakdown structuur
  Het eindproduct wordt vooraf concreet en eenduidig gedecomponeerd naar behapbare brokken.
• Productbeschrijving
  Van alle op te leveren producten wordt een productbeschrijving gemaakt. Hiermee wordt het product concreet en eenduidig gedefinieerd. De kwaliteitscriteria worden vastgelegd, samen met de wijze waarop de kwaliteit van het product wordt vastgesteld.
• Quality in a project environment
  De Prince2 component Quality in a project environment beschrijft projectkwaliteit in relatie tot het kwaliteitsmanagementsysteem (ISO 9001) van de organisatie.
• Kwaliteitslog
  De kwaliteitslog is een vastlegging van alle kwaliteitstoetsingen die hebben plaatsgevonden, samen met het resultaat van de toetsing.
• Duidelijke gedefinieerde processen en formats voor managementproducten
  Prince2 heeft de projectprocessen en bijbehorende projectmanagementproducten (plannen, rapportages, logs etc.) uitgebreid beschreven. Het is zinvol deze in een grootschalig project te gebruiken. Soms zijn er organisatiestandaards die de Prince2 standaards (gedeeltelijk) vervangen. Gebruikt u dan de organisatiestandaards. Dubbel is bureaucratisch! Bij kleinschalige(re) projecten is het zinvol de Prince2 standaard te downsizen.
• Risicomanagement
  Risicomanagement  gaat om het onderkennen van risico’s en het tijdig nemen van maatregelen.
• Configuratiemanagement
  Configuratiemanagement houdt het beheer in van de alle componenten waaruit het projectresultaat (ICT-systeem) bestaat en de daaraan gerelateerde documenten ter ondersteuning van de service managementprocessen (incident management, problem management en change management).
• Healthcheck
  Prince2 bevat een checklist om vast te stellen of Prince2 goed wordt toegepast.
• Quality review
  Een beschrijving van de quality review kunt u lezen in het artikel ‘Een kwaliteitsreview verhoogt de kwaliteit meetbaar’.
• Projectassurance
  Projectassurance gaat om de expliciete verantwoordelijkheden van de leden van de projectboard.
• Lessons learned log
  De nuttige leerervaringen worden gedurende het project vastgelegd in een log, zodat hier voor volgende keren lering uit getrokken kan worden.

Als het op maat snijden van de projectaanpak inhoudt dat bovenstaande elementen worden weggesnoeid, wordt het dus Prince 2 -/- kwaliteit = PINO. Het gevolg is dat uw project minder kans heeft op een succesvol resultaat.

Wat kost u die kwaliteit?

Kwaliteit kost u minder dan u denkt, maar méér dan u hoopt. De praktijk ziet er zo uit:

De rode lijn geeft aan hoe projecten (met een vergelijkbare omvang en complexiteit) gemiddeld verlopen. Vaak wordt een projectplan gebaseerd op een onrealistisch optimistisch scenario. Een plan dat wordt gebaseerd op ervaringscijfers kost al snel 20 tot 40 % meer tijd en geld. Als u in het begin van het project voldoende kwaliteit inbrengt, kost dat gemiddeld zo’n 5 % projectbudget. Daar staan tegenover: een realistisch plan, een beheersbare uitvoering en een kwalitatief goed resultaat waarmee uw klant zijn business case realiseert.
Ook voor de kwaliteitsaspecten geldt dat deze op maat moeten worden toegepast. Zie voor een pragmatische aanpak het artikel ‘Quality Assurance in projecten’.

INQA ondersteunt organisaties in hun streven naar duurzame kwaliteit,  zodat de klanttevredenheid toeneemt zonder grote investeringen. Vragen over dit artikel of de dienstverlening van INQA kunt u stellen via het reactieformulier.

Download:       

No related posts.

Voorbeelden van mislukte overheidsprojecten zijn er legio. Maar laten we het daar niet over hebben. Ik wil nu ingaan op de oorzaak van deze mislukkingen. Veelal is die gelegen in het misverstand dat inspraak belangrijk is. Eisen en wensen worden dan niet bepaald door de opdrachtgever, maar door de afnemers van de dienst. Dat leidt nagenoeg altijd tot een dik boekwerk van eisen en wensen, waarbij niemand nog zicht heeft op het werkelijke belang van al die eisen en wensen en natuurlijk nog minder op het waarom ervan en op de criteria waaraan afgemeten kan worden of daadwerkelijk aan een eis is voldaan. Zo kan van iedere mug een olifant gemaakt worden. En dat gebeurt dan vaak ook vrolijk. (Zie ook ‘ERP selectie en implementatie: eerst van een muis een olifant maken en daarna omgekeerd’.)

Projecten platform voor sabotage

Projecten zijn meestal gericht op verandering. En vaak willen mensen geen verandering. Juist een democratisch opgezet project biedt dan de gelegenheid om obstructie te plegen tegen de verandering. Onder het mom van risico beheersing kunnen een aantal uitstekende sabotagetechnieken worden toegepast.
Een eerste mogelijkheid is om meer informatie te vragen. Alsof meer informatie leidt tot betere beslissingen. Besluitvorming is primair een emotioneel proces. Een overdaad aan informatie staat ervoor garant, dat rationele besluitvorming niet meer mogelijk is. De sprekers met de grootste demagogische talenten kunnen dan hun wil doordrukken.
Een tweede optie is de vraag naar representativiteit: ‘Vertegenwoordigen we wel iedereen die hier wat van moet vinden? Zijn we wel bevoegd?” Vaak leidt dat tot de vraag om weer meer informatie.
Als derde kan gewezen worden op de snelheid van de implementatie. Er komt al zoveel op de mensen af en ze moeten niet overvoerd worden. De impact van de verandering voor de mensen mag niet onderschat worden. We willen tenslotte, dat het project ook daadwerkelijk het beoogde effect heeft.
De vierde techniek is het ter discussie stellen van de randvoorwaarden. Dit is legitiem. Maar het wordt schimmig als gesproken gaat worden over veranderende randvoorwaarden, die misschien geldig zijn op het moment waarop tot daadwerkelijk implementatie wordt overgegaan. Het minste wat er gedaan moet worden is het opstellen van verschillende scenario’s om de mogelijke risico’s beter te beheersen.
Als vijfde is natuurlijk ook de veranderingsaanpak een punt van aandacht. Veranderingen moeten draagvlak hebben, vooral op de werkvloer. Anders gaat de verandering niet lukken. Een perfecte truc. Van de werkvloer vallen weinig sensationele veranderingen te verwachten. Maar als je gaat vragen wanneer veranderingen gedragen zullen worden, neemt de lijst met eisen en wensen natuurlijk wel toe.
Bovenstaande sabotagetechnieken werken het best als besloten is een werkgroep of commissie in te stellen, om een onderzoek te doen. Dan is uitstel gegarandeerd. Ongetwijfeld kent u ook nog wel een paar andere trucs. Maar uiteindelijk gaat het daar niet om.

Regie is het managen van verwachtingen

Vaak wordt gezegd, dat een grammetje visie meer waard is dan 1000 kilo eisen. Dat geldt zeker in projecten. Als product-en processpecificaties gedetailleerd worden vastgelegd, dan zie je alleen nog maar bomen, maar het bos ben je kwijt. Achter iedere boom zie je een risico schuilen. Voor ieder risico definieer je maatregelen. Dat tot grote tevredenheid van de projectterrorist, die hiermee volledig in de kaart wordt gespeeld. (Zie ook ‘Bij projectmatig werken zijn afspraken beter dan procedures’.) Als immers de bezwaren over één van zijn bomen met veel moeite onder het tapijt zijn geveegd, dan neemt hij  toch gewoon de volgende boom. In het bos zijn er tenslotte genoeg.
De echte regisseur echter gaat uit van zijn eigen visie: wat moet er bereikt worden en welke zijn de knock-out criteria die er echt toe doen (meestal minder dan tien). Dat is ook het verhaal naar alle betrokkenen op ‘wat’-niveau. En voor het hoe verwijst hij naar bestaande standaards en best practices. Hij weet, dat niets zijn project zo erg vertraagt als het opnieuw uitvinden van wielen en het maken van uitzonderingen op standaards. Dat communiceert hij ook. Zoals geldt voor iedere regisseur, zo telt er voor hem in het project maar één beeld van de werkelijkheid en dat is zijn beeld. Hij maakt alle keuzes die er toe doen en via verwachtingsmanagement overtuigt hij een ieder die het beeld van zijn werkelijkheid wil zien. (Zie ook ‘Projectinrichting en opdrachtbeheer’).
En de betrokkenen die het niet willen zien? De regisseur erkent simpel, dat er ook andere werkelijkheden kunnen bestaan, alleen niet in dit project. En hij zorgt ervoor, dat de betrokkenen niet te lastig worden.
Dan is er natuurlijk één essentiële randvoorwaarde: het projectteam (intern of extern) moet waarmaken wat de regisseur belooft. De regisseur moet daarom de nodige tijd besteden aan de afstemming met zijn projectteam met als belangrijkste stelregels:

• Er is maar één visie en werkelijkheid in het project en dat is die van de regisseur.
• Als er alternatieven zijn, wordt de regisseur om een keuze gevraagd.
• Als toekomstige gebruikers sputteren, dan wordt dit gerapporteerd aan de regisseur, want die heeft dan blijkbaar de verwachtingen niet goed gemanaged.

Kortom, democratisch beginselen moeten niet op projecten worden toegepast. Daarom pleit ik weer voor de benaming opdrachtgever. De rol van opdrachtgever is precies de rol die een regisseur moet invullen.

Download:       

No related posts.

1. Is projectmatig werken wel ingeburgerd?
2. Projectmatig werken ‘back to the basics’
3. Afspraak is afspraak
4. PINO
5. Waar dienen procedures voor?
6. Kunnen we zonder procedures?
7. Projectmatig werken is primair een cultuur 

1. Is projectmatig werken wel ingeburgerd?

Projectmatig werken is routine geworden binnen veel organisaties. Of moeten we misschien zeggen, dat het sleur is geworden? Als men in een organisatie wat wil, wordt er een project gedefinieerd om het te realiseren. Natuurlijk wordt er een plan van aanpak gemaakt met, in een Prince 2 omgeving, waarschijnlijk ook nog een bijbehorende businesscase. Zodra het project is goedgekeurd, wordt er van start gegaan, van start met de ellende die al jaren speelt rond projecten: bureaucratie die troef is, procedures die heilig zijn.
De tijd waarin de projectmanager verantwoordelijk was voor het projectresultaat ligt al weer jaren achter ons. Tegenwoordig heeft de projectmanager een inspanningsverplichting.  En zolang hij administratief maar kan verantwoorden, dat tekortkomingen niet zijn schuld zijn, is hij gedekt. (Zie ook ‘Prince 2 geeft de projectmanager vooraf al decharge’.) De grootste fout die een projectleider tegenwoordig kan maken, is tevoorschijn komen vanachter de zorgvuldig opgebouwde beschermingswal van methoden en procedures om zijn nek uit te steken, teneinde, ‘links om of rechts om’, het afgesproken resultaat te realiseren. Dat maakt hem ineens kwetsbaar.  Hij loopt dan het risico, dat hij alle zwarte pieten toegespeeld krijgt, die nu nog bij anderen geparkeerd zijn.
Kortom, projectmatig werken is ingeburgerd in veel organisaties, maar nog allerminst geïntegreerd. (Zie ook ‘Waarom veel organisaties niet met projecten kunnen omgaan’).

2. Projectmatig werken ‘back to the basics’

Lang geleden werd een project als volgt gedefinieerd:

‘Een project is een geheel van activiteiten met een bepaald doel, buiten de gewone bedrijfsvoering om, waarbij het gaat om het realiseren van iets nieuws door een team van meerdere verschillende specialisten’.

In diet tijd was het zo, dat als men een project opstartte, het erom ging iets bijzonders te realiseren, iets buiten de normale bedrijfsvoering en dus buiten de bestaande routine om. De logge lijnorganisatie was daarvoor ongeschikt. Een project werd in die tijd geleid door de projectmanager, die vaak moest managen zonder macht. Kortom, de taak van projectmanager was een taak voor doordouwers die goed konden samenwerken, goed konden motiveren en voor de duivel niet bang waren. Tegenwoordig kampen projecten met een overmaat aan regels en procedures en is een projectorganisatie minstens zo log als de lijnorganisatie. De ideale projectmanager is getransformeerd tot boekhouder.
Waar gaat het in essentie om bij een project? Het gaat om het bereiken van een specifiek doel dat is afgesproken. Belangrijk is dat alle partijen zich vervolgens inspannen om dit doel te realiseren. Mensen kunnen heel veel, mits ze maar niet worden gehinderd. Het kenmerkende van projectmatig werken is dat er geïmproviseerd kan worden. In organisaties vormen procedures vaak de belangrijkste hindernis om doelen te bereiken. Juist omdat deze hindernis onderkend wordt, wordt een project opgestart, waarin de normale bedrijfsvoering niet van toepassing is. Dat biedt de mogelijkheid om nieuwe wegen te zoeken, te vinden en deze te bewandelen, zonder de gebruikelijke rapportage en besluitvorming en zonder lobby om consensus te bereiken. 

3. Afspraak is afspraak

Een project heeft de gebruikelijke overhead dus niet. Het loopt daardoor wel eerder het risico om te ontsporen. Vaak valt dat echter erg mee, doordat mensen zich committeren aan de afspraak. Ze kunnen zich tenslotte niet verschuilen. Om nu te voorkomen dat te gemakkelijk ingebroken kan worden op deze afspraak, zijn er een beperkt aantal procedures. Als alles goed gaat, dan zijn ze overbodig en worden ze niet gebruikt. Dan telt gewoon de afspraak en kunnen doelen bereikt worden met een minimum aan overhead.
Toch kennen we ze allemaal, de projectmanagementmethodieken met bijbehorende procedures. We leren ze op allerlei cursussen en trainingen en proberen ze na terugkomst van de training toe te passen in de praktijk. Maar wat een frustratie! Wat een bureaucratie! Wat een administratieve rompslomp! Iedereen wordt “gedegradeerd” tot een administratieve kracht, die minstens de helft van zijn tijd rapporten zit te maken en de andere helft van zijn tijd rapporten zit te lezen.
Wetenschappelijk is door Teun van Aken “bewezen”, dat projectsucces vooral afhankelijk is van de werkstijl van een projectmanager en dat allerlei procedures en technieken vaak alleen maar storende factoren zijn. Instrumentgebruik is vooral intern gericht, terwijl de projectmanager zich met name extern zou moeten richten. 

4. PINO

Wat betekent PINO? Het acronym PINO staat voor Prince (of Projectmanagement) In Name Only. Wanneer organisaties beweren dat ze projectmatig werken of Prince2 hanteren als projectmanagementmethodiek, blijkt vaak dat de methodiek als volgt is geïmplementeerd: de templates van de op te leveren (management)producten, zoals voorgeschreven door de betreffende methodiek, staan netjes op een algemeen toegankelijke directory en dat is het dan wel zo’n beetje. Richtlijnen waarin staat aangegeven in welke situaties managementproducten toegevoegde waarde leveren, of een uitleg over de daadwerkelijke doelstelling die een organisatie ermee wil bereiken, zijn er meestal niet. Het gevolg is dat de organisatie braaf altijd, voor alle projecten en in alle situaties, alle gedefinieerde (management)producten oplevert. Vaak is het zelfs zo dat, om welk willekeurig projectplan het in de organisatie ook gaat, hoofdstukken op dezelfde generieke manier zijn ingevuld (gekopieerd, bedoelen we eigenlijk). De toegevoegde waarde van een methodiek is in dit soort gevallen nul. Weer een reden waarom projectmanagementmethodieken vaak het stempel “administratieve rompslomp” krijgen, en door de organisatie worden beschouwd als een blok aan het been. Terecht natuurlijk, als ze op deze manier worden gebruikt! 

5. Waar dienen procedures voor?

Reden om binnen projecten procedures te hanteren, die we steeds weer zien terugkomen zijn:

• Het geeft een gevoel van zekerheid voor de opdrachtgever.
• Het geeft een gevoel van beheersbaarheid voor de projectmanager.
• Het geeft een gevoel van kwaliteit voor de afnemer/gebruiker.
• Het geeft een gevoel van veiligheid voor de leverancier.

Iedere partij heeft dus zo zijn eigen reden om sterk de nadruk te leggen op het hanteren van (standaard)procedures bij het uitvoeren van een project. De redenen hebben allemaal te maken met eigenbelang en met angst van de betreffende partij: “Als we maar procedures hebben, zullen onze belangen zeker gewaarborgd zijn.” Maar is dit ook zo?
In de praktijk zien we dat men procedures vooral gebruikt om zich aan vast te klampen als dingen niet gaan zoals ze zouden moeten gaan. Wanneer projecten niet meer volgens het oorspronkelijk uitgestippelde plan verlopen, hebben alle partijen de neiging meteen naar de (standaard)procedures te wijzen en vooral aan te geven waaraan de andere partij zich niet heeft gehouden. Er ontstaan oeverloze discussies of men zich nu wel of niet heeft gehouden aan de beschreven en afgesproken procedures. Men zou zich echter beter kunnen richten op het probleem zelf en dit oplossen. Maar juist in dit soort situaties richt men zich vaak overdreven op de afgesproken procedures. Onwerkbare situaties zijn meestal het gevolg. En dat is dan meteen het bewijs dat procedures zoals beschreven dus niet werken!
Procedures moeten ondersteunen, een hulpmiddel zijn, en mogen nooit de oorzaak zijn dat men zijn energie gaat verplaatsen van het echte probleem naar datgene wat ondersteunend zou moeten zijn. Hoeveel discussies binnen projecten gaan er niet over de vraag of de procedures wel goed zijn gevolgd? Hoeveel tijd is men niet bezig met indekken en met vastleggen van van alles en nog wat, voor “als het fout gaat, kan ik in ieder geval aantonen dat ik de procedures heb gevolgd”? Hoeveel tijd gaat er niet verloren om procedures op te stellen die men vervolgens gewoon aan zijn  laars lapt? Hoeveel tijd kost het niet om iedereen uit te leggen hoe de procedures moeten worden gebruikt? Kortom, het opstellen van procedures enkel en alleen om zich er aan te kunnen vastklampen zal zeker niet leiden tot het gewenste projectsucces. Dat werkt eerder blokkerend dan ondersteunend. 

6. Kunnen we zonder procedures?

Voor het organisch laten ontstaan, groeien en afsterven van een project, kortom voor het doorslaan naar de andere kant (er zijn stromingen die hiervoor pleiten), krijgen we in onze Nederlandse bedrijfssituatie de handen (nog) niet op elkaar. Maar denkt u zich eens in, een project kunnen uitvoeren zonder allerlei regeltjes en afspraken over hoe de projectactiviteiten moeten worden uitgevoerd, wat een winst in tijd en wat een vermindering van frustratie zou dat geven.
Er zijn voorbeelden van projecten die op deze wijze succesvol zijn afgerond. Uit onderzoek blijkt dat vooral de teamspirit en de leiderschapsstijl van zowel de opdrachtgever als de projectmanager hierbij doorslaggevende factoren zijn. Het is echter ook een feit dat dit projecten waren met weinig tot geen betrokken externe partijen. Het betrof interne projecten binnen innovatieve bedrijven met een hoge betrokkenheid van alle medewerkers. Wellicht niet een representatief beeld van de gemiddelde Nederlandse bedrijfscultuur. 

7. Projectmatig werken is primair een cultuur

Blijkbaar hangt het vermogen om succesvol projectmatig te werken af van de cultuur van een organisatie, van het hebben van lef om onbegaande wegen te bewandelen, van commitment aan gemaakte afspraken en van het bestaan van een ‘gezonde foutencultuur’, waarbij mensen niet worden afgerekend op hun fouten, maar op hun successen. Dat vereist echter ook een adequate managementstijl.
Misschien is het voor veel organisaties verstandig om weer eens te beginnen bij de basis ‘afspraak is afspraak’. Managers maken afspraken met hun medewerkers, medewerkers maken onderling afspraken. En als afspraken nagekomen worden, dan wordt daar uiteraard waardering voor uitgesproken. Als medewerkers ‘beren op de weg’ tegenkomen, dan wordt hun de vraag gestel: ‘Onder welke condities kun je wel je afspraak nakomen?’ Vervolgens wordt gekeken of aan die voorwaarden voldaan kan worden. Hoogst waarschijnlijk zullen veel overbodige procedures dan begraven worden. Dat is niet erg. Ze zijn immers alleen van belang als niet geldt: ‘Afspraak is afspraak’.
Het belangrijkste is, dat managers en medewerkers weer leren om afspraken na te komen, weer leren dit te waarderen, dat ze weer gaan nadenken over oplossingen, dat ze hindernissen uit de weg ruimen, dat ze simpele actielijstjes maken in plaats van ellenlange projectplannen en dat ze een risico als een uitdaging zien en niet als iets waarvoor ze zich moeten indekken.
Als deze cultuur weer omarmd wordt door managers en medewerkers, dan kunnen ook grotere projecten opgepakt worden. Dan is ook invoering van pragmatische best practices mogelijk zoals beschreven staat in ‘Projectinrichting en opdrachtbeheer’ en ‘Opdrachttypen voor projecten’.Tot die tijd moeten projecten opgeknipt worden in simpele hapklare brokjes, waarbij zowel voor de manager als de medewerker volstrekt duidelijk is welk resultaat, wanneer en tegen welke inspanning is afgesproken. Dat is immers de kern van projectmatig werken. Helaas wordt dat vaak vergeten.

Herziene versie: 28 mei 2010

Download:       

No related posts.

1. De theorie van aanbestedingen
2. Nu de praktijk: de overheid zelf
3. Inkoop door de overheid
4. De praktijk: de aanbieders
5. Nut en noodzaak van Europees aanbesteden 

1. De theorie van aanbestedingen

De theorie van aanbesteden is simpel:

Aanbesteding is de procedure waarbij een opdrachtgever bekend maakt dat hij een opdracht wil laten uitvoeren en bedrijven vraagt om een offerte in te dienen. In die offertes staat onder andere welke prijs het bedrijf voor de uitvoering van de opdracht vraagt. Op een vooraf bepaalde datum wordt de inschrijving gesloten en vervolgens selecteert de opdrachtgever het bedrijf dat de opdracht krijgt, meestal de laagste inschrijver. Het verlenen van de opdracht aan één van de inschrijvers wordt gunning genoemd.

De opdracht kan zijn:

• een ‘werk’, bijvoorbeeld het bouwen van een fysiek, bouwkundig of civieltechnisch object, zoals een gebouw of een tunnel;
• een ‘dienst’, bijvoorbeeld het uitvoeren van een verhuizing, het verlenen van juridisch advies of het uitvoeren van een ingenieursopdracht;
• een ‘levering’, het leveren van (een partij) goederen, zoals bijvoorbeeld koffieautomaten, auto’s, en dergelijke.

Bij aanbesteding gaat het meestal om relatief grote opdrachten. Bij kleinere opdrachten wordt vaak een beperkt aantal leveranciers of aannemers uitgenodigd om een offerte te doen. Dit noemt men wel ‘onderhands aanbesteden’.
Aanbesteding wordt vooral door overheidsinstanties toegepast. Daarvoor zijn een aantal redenen:

• Overheden verlenen vaak grote opdrachten (bijvoorbeeld wegenaanleg en andere infrastructurele werken).
• Overheden moeten hun uitgaven publiek verantwoorden. Door een heldere aanbestedingsprocedure toe te passen, kunnen ze aannemelijk maken dat ze de opdracht integer aanbesteden en een niet te hoge prijs betalen.
• Er wordt voldaan aan de EU regelgeving met betrekking tot de vrije markt.
• Het MKB krijgt meer kansen (maar zie ook ‘Inkoopstrategie overheid en grote bedrijven remt herstel werkgelegenheid in Nederland’).

Verdere details over soorten aanbestedingen, drempelwaarden en overige regelgeving zullen we u hier besparen.
Bij Europese aanbestedingen dient de opdrachtgever te werken volgens het volgende stappenplan:

1. bepalen aard van de opdracht (werken, diensten of leveringen);
2. bepalen geraamde, totale waarde van de opdracht;
3. bepalen aanbestedingsprocedure;
4. aankondiging opdracht (inclusief bestek, bidbook of lastenboek);
5. keuze selectie- en gunningscriteria;
6. gunning opdracht.

Het bestek of bidbook (stap 4) is in veel gevallen met name de hete aardappel in dit traject. Hierin wordt vastgelegd wat er geleverd moet worden en onder welke condities. Als het gaat om schoonmaakwerkzaamheden voor een ministerie, dan zijn deze vrij eenvoudig te specificeren. Als het echter gaat om de aanleg van de Betuwelijn, dan ligt dit een stuk complexer; je hebt dan te maken met zaken als:

• voortschrijdend inzicht en nieuwe materialen en technieken;
• beroepsprocedures en politieke druk;
• veranderende wet- en regelgeving enzovoort.

Voorts staat bij aanbestedingen de relatie tussen de opdrachtgever en de opdrachtnemer op scherp, want meestal is er geen ruimte voor win-win situaties, maar is het vrijwel altijd een win-lose situatie. In goed overleg oplossingen zoeken is meestal geen optie. 

2. Nu de praktijk: de overheid zelf

Europese aanbestedingen kosten de Nederlandse overheid jaarlijks veel geld en ze dragen zeker niet bij aan het verlichten van de administratieve lasten voor de overheid zelf. Niet voor niets wordt er in de praktijk ondanks de verplichting toch vaak niet aanbesteed. Blijkbaar wordt de overheid er zelf vaak ook niet beter van en dan vervalt natuurlijk het argument van publieke gelden.
Dat de Europese aanbestedingsvoorschriften slecht worden nageleefd, weten wij al lang. De afgelopen jaren zijn er ruim driehonderd kamervragen over niet of onjuist Europees aanbesteden gesteld. Onder andere uit onderzoek van de Universiteit Twente blijkt dat in 2004 het gemiddelde nalevingspercentage van het aanbestedingsplichtige inkoopvolume zo’n 30 procent bedraagt. Daarmee is Nederland één van de slechtste leerlingen van het Europese klasje. Dat lage percentage wordt vooral veroorzaakt door gemeenten (25 procent), waterschappen (25 procent), hogescholen (15 procent ) en rijksmusea (15 procent).
Maar ook de organisaties die met wettelijk toezicht zijn belast doen het slecht: Algemene Rekenkamer (40 procent), Autoriteit Financiële Markten (35 procent), Opta (12 procent) en NMa (3 procent). De SER en het College Tarieven Gezondheidszorg (de Zorgautoriteit) hebben in het geheel geen opdracht Europees aanbesteed. Na de Nederlandsche Bank (80 procent) hebben de ministeries de hoogste percentages (70 à 80 procent). De Tweede Kamer (waarde inkoopvolume in 2005 ruim 43 miljoen euro) besteedde 65 procent van het aanbestedingsplichtige inkoopvolume Europees aan. De pot verwijt de ketel dat hij zwart ziet. Dat geldt ook voor de Europees aanbestedingsplichtige NOS, die in 2005 geen enkele Europese aanbesteding uitschreef en in 2006 slechts één. 

3. Inkoop door de overheid

Uit kamerstukken blijkt dat de totale inkoopkosten van de hele overheid in 1996 op 51,2 miljard gulden werden geraamd. Hiervan kwam 17,6 miljard gulden voor rekening van de rijksoverheid. Het ontwerpregeerakkoord van 18 juli 1998 wilde een jaarlijkse besparing op de inkoopkosten van de rijksoverheid van 1 procent, oftewel 250 miljoen gulden. De waarde van het inkoopvolume bedroeg dus 25 miljard gulden. Dit was exclusief 4,5 miljard aan grond-, water- en wegenbouwkundige werken van Rijkswaterstaat en 6 miljard voor aanschaf door Defensie.
De staatssecretaris van Economische Zaken meldde in 2006 dat de Nederlandse overheid voor een bedrag van circa 50 miljard euro inkocht, waarvan circa 15 miljard voor het Rijk. Dat betekent bijna een verdubbeling ten opzichte van 1997!
Het wordt nog zorgelijker. De Europese Commissie heeft in 2002 berekend dat 21,5 procent van ons bruto binnenlands product – 465,2 miljard euro – betrekking had op overheidsopdrachten; oftewel 100 miljard.
Kortom, de overheid heeft geen zicht op haar inkoopkosten. Door de inkoopkosten onder controle te krijgen, kunnen besparingen van twintig procent of meer worden gerealiseerd, blijkt uit diverse onderzoeken. De overheid moet dan de totale inkoopkosten inzichtelijk maken, een integraal inkoopmanagement voeren, inkoopvragen multidisciplinair en procesmatig benaderen en een actief leveranciersmanagement ontwikkelen. 

4. De praktijk: de aanbieders

De hele adviessector verknoeit tijd en geld aan de aanbestedingsgewoonten van de overheid. Neem een gemiddelde kleine opdracht van € 50.000 tot € 70.000. Of het nu een gemeente is of een ministerie, vaak worden 20 bureaus uitgenodigd om een offerte in te dienen.
Uiteindelijk is het de goedkoopste die de opdracht krijgt, ongeacht welke aanpak hij voorstelt. Dat komt doordat de aanbestedingen bijna altijd worden afgehandeld door een centrale inkoopafdeling, niet meer door de uiteindelijke opdrachtgever binnen de ambtelijke dienst. En de inkopers maakt het weinig uit met wat voor aanpak je komt.
Omdat de meeste bureaus wel bijna 3 weken aan hun offerte werken, wordt er gemiddeld ruim 50 weken creatief offertewerk verricht, voor een uiteindelijke opdracht die misschien maar 50 weken werk behelst.’
En die verspilde tijd zonder opbrengsten zullen de bureaus toch weer ergens op moeten verhalen. Voor hen is dit overhead en de kosten ervan worden doorbelast aan de klant.
Volgens aanbestedingsdeskundige Ireen Hardenbol van MKB-Nederland gaat het ook nog eens  bij 70% van alle aanbestedingen mis. ‘Nu eens gaat de opdracht naar een vriendje en doen andere ondernemers voor spek en bonen mee, dan weer wordt de klus onterecht niet aanbesteed. En soms zijn de criteria zo opgesteld dat maar één bedrijf de aanbesteding kan winnen.’ (Zie ook ‘Europees aanbesteden leidt vaak tot minder marktwerking en hogere prijzen’.)

4.1 Ook Twynstra Gudde pikt het niet meer

Zelfs de directie van adviesbureau Twynstra Gudde werd het uiteindelijk zat. Zo’n vijftig keer per jaar deed het bureau mee aan een ‘tender’ (een openbare inschrijving) van een gemeente, een provincie of een departement. Het opstellen van een realistisch doorberekende offerte, inclusief plan van aanpak, kostte gemiddeld zo’n drie weken. En iedere keer bleek het weer de goedkoopste adviseur te zijn die met de opdracht ging strijken. Ongeveer 30% van de opdrachten waarvoor Twynstra Gudde zich inschreef, werd binnengehaald. En dat was niet goed genoeg. Het woog onvoldoende op tegen het werk dat werd gestoken in al die andere offertes.
De vraag is dan of  een goedlopend commercieel adviesbureau het nodig heeft om mee te doen aan de tijdrovende en kostbare aanbestedingspraktijk van de overheid. Als groot bureau dat veel werk doet voor de overheid, werd dat gevoeld  als een soort maatschappelijke plicht. Ruimschoots de helft van alle opdrachten krijgt Twynstra Gudde van de overheid, waaronder ziekenhuizen en zorginstellingen. Tot voor kort deed Twynstra Gudde mee aan elke overheidstender waarvoor het adviseurs beschikbaar kon maken. Waar men echter uiteindelijk mee gestopt is, is het soort tenders waarvoor de enige reden van afwijzing is dat je niet de goedkoopste bent. Binnen Twynstra Gudde is afgesproken dat het alleen nog inschrijft  bij een opdrachtgever die het kent als iemand die een echte afweging maakt tussen prijs en kwaliteit. Bovendien moet de opdracht tegenwoordig passen bij de kerncompetentie van het bureau. In de praktijk heeft dit een reductie betekend met 50% van inschrijvingen op overheidsopdrachten. 

 5. Nut en noodzaak van Europees aanbesteden

Als zowel opdrachtgevers als opdrachtnemers veelal ontevreden zijn over het in regels vastgelegde mechanisme van aanbesteding, wordt het misschien toch tijd om gewoon weer eens het gezonde verstand te gebruiken. (Zie ook ‘Waarom veel organisaties niet met projecten kunnen omgaan’.)
Ik heb me altijd verbaasd over die Europese aanbestedingsregels. Het is de taak van de overheid om marktwerking te stimuleren. De overheid moet ervoor zorgen dat de consument over voldoende informatie beschikt en dat hij niet wordt geschaad door kartelvorming. Maar waarom zou de overheid burgers verplichten alvorens een auto te kopen altijd bij drie garages een offerte aan te vragen? Persoonlijk heb ik er helemaal geen zin in om in zo’n aankoop zo veel tijd te steken. Bovendien, niemand kan mij toch het recht ontzeggen om ‘te veel’ te betalen. Als ik maar, mocht ik dat willen, in staat ben om de prijs-kwaliteitverhouding van te koop aangeboden auto’s te vergelijken. De overheid heeft dus te waken voor de transparantie van de markt en moet niet treden in de rechten van de consument. Dat is betutteling. De consument moet de vrijheid hebben zelf te beslissen hoe economisch verantwoord hij handelt.
Waarom zou deze redenering ook niet opgaan voor de overheid, waar die als klant op de markt opereert? Waarom zou de ‘Europese overheid’ aan de lidstaten moeten voorschrijven dat ze bij de aanschaf van een paar stoelen drie bedrijven om een offerte moeten vragen? Natuurlijk gaat het uiteraard om meer dan een paar stoelen, maar dat maakt voor het principe niets uit. Er is geen doorslaggevende reden waarom Brussel de lidstaten tot prijsvergelijking zou moeten verplichten. Overigens bestaat in de Kamer een overtuigende meerderheid voor het verlichten van administratieve lasten. Waarom zou dat niet voor de overheid gelden?
Ik ontken niet dat het bij de overheid om publieke middelen gaat en dat de burger er recht op heeft dat daarmee zuinig en zorgvuldig wordt omgesprongen. Elke minister heeft in tijden van krapte veel baat bij zuinigheid. Zomaar een opdracht geven is om die reden uit den boze. De overheid moet zich goed informeren alvorens te beslissen met welke partij ze voor een opdracht in zee wil gaan. Maar dat kan ook zonder Europese aanbesteding. (Zie ook ‘Hoe voorkomt u een Europese aanbesteding bij ICT-outsourcing’.)
Maar die zoektocht moet wel in verhouding staan tot de winst die ermee wordt geboekt.  Waarom altijd drie offertes aanvragen als vooraf al duidelijk is welk bedrijf het beste uit deze schijnwedstrijd te voorschijn komt? Daarmee worden niet alleen bedrijven onnodig op kosten gejaagd, maar dreigt de markt voor de overheid ook tot een bureaucratische aangelegenheid te verworden. Dat geldt zeker voor opdrachten waarbij vertrouwen een grote rol speelt. (Zie ook ‘Wat mogen bedrijven tegenwoordig van hun adviseurs verwachten’.)
De kritiek zou zich dan ook ergens anders op moeten richten. De echte vraag is waarom Gerda Verburg mensen moest inhuren om het informatiebulletin ‘Gerda’ uit te brengen. Konden haar ambtenaren deze klus zelf niet klaren? Er heerst momenteel in Den Haag een uiterst dure mode: uitbesteden. Deze heeft als neveneffect dat het werk voor de zittende ambtenaren steeds minder leuk wordt en dat de goede mensen uiteindelijk hun heil elders gaan zoeken. Waarom investeert de overheid niet gewoon in haar eigen mensen? Dan hoeft ze al die dure mensen ook niet meer in te huren.
Of durven ministeries momenteel zelf geen projecten meer op te starten? Is het afbreukrisico van imagoschade misschien te groot? Ben je misschien beter ingedekt als je conform de aanbestedingsregels een gerenommeerde leverancier binnenhaalt? (Zie ook ‘Waarom stuurgroepen vaak het roer niet kunnen vasthouden’.) Dat de overheid zelf de competenties niet zou hebben, wil er bij mij niet in.
Wie durft eindelijk eens aan te schoppen tegen dit heilige huisje?

Herziene versie: 6 mei 2010

Bron:
Het Financieele Dagblad. 21 mei, 26 mei, 2 augustus, 4 augustus 2007

Download:       

No related posts.

1. Doelstellingen ellende voor projecten
2. Verantwoordelijkheden en bevoegdheden
3. Bedrijfsmatige inzet van projectmatig werken 

1. Doelstellingen ellende voor projecten

Er is tegenwoordig vrijwel niemand meer, die niet ooit eens te maken heeft gehad met projectmatig werken. Iedereen heeft wel eens meegedaan in een projectgroep. En de meesten zijn er ook achter gekomen, dat projecten zelden het beoogde doel realiseren binnen de gestelde randvoorwaarden.
Vaak is het grootste misverstand tijdens een project het misverstand over de doelstelling; men realiseert zich te weinig dat het projectresultaat slechts een middel is voor de organisatie om bedrijfsdoelstellingen te bereiken. Een projectresultaat dient een zodanig effect te hebben op de lijnorganisatie, dat die lijnorganisatie de bedrijfsdoelstellingen kan bereiken.
Als daar misverstand over is, is dat het begin van veel ellende. Want waar begint en eindigt de verantwoordelijkheid van de projectmanager? Is hij onderdeel van een black box, die het vooraf gedefinieerde projectresultaat realiseert of is hij verantwoordelijk voor het bereiken van het effect. In feite gaat het om de vraag of de projectmanager verantwoordelijk is voor het doen van de goede dingen of voor het goed doen van de dingen.
Als we kijken naar Prince 2, dan wordt de indruk gewekt dat de verantwoordelijkheid van de projectleider beperkt wordt tot de realisatie van het projectresultaat, waarbij hij wel activiteiten moet uitvoeren, die gericht zijn op de lijnorganisatie (businesscase en implementatieplan), maar de lijnorganisatie is en blijft verantwoordelijk. (Zie ook ‘Prince 2 geeft de projectmanager vooraf al decharge’.)
In onze optiek is de projectmanager verantwoordelijk voor het beoogde effect op de lijnorganisatie en voor alles wat er onderweg naar het bereiken van dit effect mis gaat, zelfs al is het zijn schuld niet. De ervaring leert tenslotte, dat de meeste managers deelname aan stuurgroepen zien als een noodzakelijk kwaad (zij hebben toch niet voor niets het probleem uitbesteed in de vorm van een project). Bovendien weten stuurgroepleden vaak nauwelijks wat hun rol is, en wat hun verantwoordelijkheid. (Zie ook ‘Waarom stuurgroepen vaak het roer niet kunnen vasthouden’.) Daarbij komt dat veel managers projecten zien als een gemakkelijk mogelijkheid om problemen te delegeren. En als dit niet het beoogde effect oplevert, dan is de zondebok direct voor handen,in de vorm van de projectmanager. (Zie ook ‘Goed groeien door slim snoeien; minder is meer’.)
Projectmanagers willen zich indekken tegen het risico, dat de schuld al te gemakkelijk op hun afgeschoven kan worden, als er iets mis gaat. Zij introduceren daartoe methoden en technieken, zodat zij zich achter procedures kunnen verschuilen. In feite is hierdoor niemand meer verantwoordelijk voor het effect van het projectresultaat op de organisatie. (Zie ook ‘Projecten als permanente stiptheidsacties’.) Het gevolg is, dat in veel bedrijven projectmatig werken meer een vuilnisbelt geworden is voor problemen, waarvan niemand probleemeigenaar wil zijn. 

2. Verantwoordelijkheden en bevoegdheden

Belangrijkste oorzaak dat projecten de mist in gaan, is onduidelijkheid over verantwoordelijkheden en bevoegdheden. Dit begint al op strategisch niveau.
Vaak is onduidelijk wie de opdrachtgever is, en wie de opdrachtnemer. Dit zijn beide lijnfuncties, van respectievelijk de business organisatie en de interne of externe dienstverlener. Deze beide partijen moeten er zorg voor dragen, dat het project goed ingebed wordt. (Zie ook ‘Projectinrichting en opdrachtbeheer’.) Zij beheren het projectcontract en zij zijn verantwoordelijk voor de inrichting van het project en de kwaliteitscontrole van hun kant.
Als beide in een stuurgroep plaatsnemen (in feite dus ook geen lijnfunctie), die als opdrachtgever voor de projectmanager optreedt, dan ontbreekt de rollenscheiding en heeft de projectleider in feite geen baas; iedere stuurgroep is per definitie een orgaan waarin gepolderd wordt en maar zelden ook gestuurd. Voor de projectmanager betekent dit, dat hij niemand kan aanspreken op zijn lijnverantwoordelijkheid. Hij is overgeleverd aan de goden, als hij een beroep moet doen op de lijnorganisatie voor het leveren inspanningen.
Daarom is het van belang dat op het niveau van opdrachtgever en opdrachtnemer afspraken gemaakt worden over verantwoordelijkheden en bevoegdheden tijdens het project. Per fase van het project moet bekeken worden hoe deze verdeling komt te liggen. Tijdens een haalbaarheidsonderzoek moeten natuurlijk de gebruikers aan het roer zitten, terwijl bij bijvoorbeeld de technische uitwerking van het concept de dienstverlener de verantwoordelijkheid heeft. (Zie ook ‘Opdrachttypen voor projecten’.)
Door per opdrachttype verantwoordelijkheden en bevoegdheden aan elkaar te koppelen en in balans te brengen, worden oeverloze discussies voorkomen. De discussie kan eenvoudig beperkt worden tot de vaststelling van het opdrachttype per fase en daarmee ligt de verdeling in verantwoordelijkheden en bevoegdheden vast. Dit geeft voor de projectmanager duidelijkheid. Hij hoeft niet continu zijn rechten en bevoegdheden te bevechten om het project af te kunnen ronden met toegevoegde waarde voor de organisatie. Hij hoeft zich niet te verschuilen achter methodes als Prince 2, om zich bij voorbaat in te dekken. Het is duidelijk wie waarop aangesproken kan worden. Dit kan vastgelegd worden in een handboek, dat dit simpel als standaard gecommuniceerd kan worden. (Zie ook ‘Voorbeeld opzet handboek voor ICT kwaliteit deel 3′.) Aan de hand van voorbeelden kunnen organisaties keuzes maken, en die op maat snijden voor de organisatie. De discussie hoeft dan niet bij ieder project opnieuw gevoerd te worden. De overheadkosten worden daarmee beter in de hand gehouden. Dat geldt zeker voor organisaties en afdelingen waarin het uitvoeren van het werk projectmatig plaatsvindt. (Zie ook ‘Hoe manage ik een projectenfabriek?’.) 

3. Bedrijfsmatige inzet van projectmatig werken

Zodra we dus in staat zijn om projectmatig werken te beheersen en duidelijk is waar verantwoordelijkheden en bevoegdheden liggen, kunnen we via de principes van een matrixorganisatie werken. Een technische dienst bijvoorbeeld heeft vaak een soort bedrijfsproces dat sterkt afwijkt van het primaire proces in het bedrijf. Een technische dienst kan dan ook vaak slecht uit de voeten met het bedrijfssysteem dat voor het primaire proces wordt gebruikt. (Zie ook ‘Organisatie van uw Technische Dienst’.)
Probleem is dan nog, wat pak je projectmatig aan en wat routinematig. Een projectmatige aanpak is per definitie duurder dan een routinematige aanpak, als het gaat om routinematige productie. Hierbij maakt het geen verschil of het gaat om de industriële productie van artikelen of halffabrikaten, het draaien van een lesrooster of het standaard afgeven van een paspoort.
Essentieel hierbij is waar het klantorder ontkoppelpunt (KOOP) ligt in de leveringsketen. Als het gaat om een product in de supermarkt, dan ligt dit in de winkel. Als het gaat om standaard onderwijs, dan ligt dit bij het tevoren opgestelde rooster met een volledig ‘take-it-or-leave-it’-principe. Als dit gaat om contractonderwijs, dan ligt dit veelal in de productie (de docent). (Zie ook ‘Valkuilen in de toepassing van kennismanagement en de impact op het goede onderwijs’.) Als het gaat om een vergunning voor het organiseren van een popconcert, dan ligt dit vaak bij de behandelende ambtenaar, of, als een gemeente hiervoor duidelijke richtlijnen heeft, bij de front-office. Als het gaat om het organiseren van het popconcert zelf, dan is dit een project, waarbij echter gebruik gemaakt wordt van meestal volledige producten, die geassembleerd worden tot het evenement, dat je voor ogen hebt. Als het gaat om organisaties, die gebruik maken van een call centre zien we vaak een glijdend KOOP. Via voorlichting of de website kan de klant zelf de antwoorden vinden (het KOOP ligt bij de klant) of krijgt de klant de gelegenheid om een service nummer te bellen (het KOOP ligt bij het callcentre) en als het service centre hier niet uit komt, dan ligt het KOOP in de veel duurdere back-office. (Zie ook ‘Ons intranet is net een omgevallen boekenkast. Hoe orde scheppen in de chaos?’.)
In principe geldt, dat je alles voor het klantorder ontkoppelpunt routinematig aanpakt en alles wat voorbij het KOOP ligt, projectmatig. Juist door dit KOOP zo dicht mogelijk bij de klant te leggen, kun je sterk besparen op de leveringskosten.
Projectmatig werken moet geen doel zijn, maar een middel. Organisaties, die alles projectmatig aanpakken, moeten zich eens achter het oor krabben of hun productieproces niet veel te duur is en zo ja, of ze hun concurrentiepositie naar de klant nog wel kunnen behouden. Zolang echter alle concullega’s hieraan meedoen, kan deze meerprijs domweg doorbelast worden aan de klant. Helaas onderneemt het NMa tegen dit soort stilzwijgende afspraken geen actie.
Als je als bedrijf begint met schroefjes, moertje, boutjes en plaatstaal en je eindigt met op maat gemaakte apparatuur, dan moet je je toch afvragen of je niet beter op voorraad gemaakte halffabrikaten kunt inkopen om je productiekosten te verlagen. (Zie ook ‘Facility management: uitbesteden aan specialisten?’.)
Uitzendbureaus doe het goed; de klant kan direct het goede halffabrikaat inkopen als resource voor werkzaamheden. Meer administratief georiënteerde instellingen (zie ook ‘Service overheid koploper in frustratie van de Nederlander’) zijn daarentegen geneigd om ieder probleem vanaf het begin projectmatig op te pakken om tot een uitspraak dan wel een aanpak te komen. Juist bij deze organisaties zou het KOOP veel dichter bij de klant kunnen komen te liggen, als bijvoorbeeld gebruik gemaakt wordt van kennismanagement. (Zie ook ‘Kennismanagement is een bedrijfsproces en dus geen voer voor ICT’ers’.)
Kortom, als je gebruik moet maken van projectmatig werken, doe het dan goed. De taak van de opdrachtgevers is te bepalen of activiteiten projectmatig aangepakt moeten worden en of het mogelijk is om dit te vermijden, door het klantorder ontkoppelpunt (KOOP) dichter bij de klant te leggen. Projectmatig werken is dus een middel en geen doel. Als u het zo benadert, is het mogelijk een belangrijk onderdeel van uw innovatieve mogelijkheden. (Zie ook ‘Kanseconomie opvolger van kenniseconomie’.)

Download:       

No related posts.

Oorspronkelijk eind 80′er jaren ontstond dit model als OPAFIT. Later werd dit COPAFIT en midden 90-er jaren werd dit verder uitgewerkt tot COPAFIJTH.

We zullen volstaan met het aangeven van waar de letters voor staan. Zelf kunt u dan ongetwijfeld verzinnen wat de impact hiervan is voor uw organisatie:

ls u als bedrijf bepaalde aspecten niet goed managed, loopt u risico’s waardoor de winstgevendheid en de klanttevredenheid vaak afneemt.

Download:       

No related posts.