Computable.nl
  • Thema’s
    • Carrière
    • Innovatie & Transformatie
    • Cloud & Infrastructuur
    • Data & AI
    • Governance & Privacy
    • Security & Awareness
    • Software & Development
    • Werkplek & Beheer
  • Sectoren
    • Channel
    • Financiële dienstverlening
    • Logistiek
    • Onderwijs
    • Overheid
    • Zorg
  • Computable Awards
    • Overzicht
    • Nieuws
    • Winnaars
    • Partner worden
  • Vacatures
    • Vacatures bekijken
    • Vacatures plaatsen
  • Bedrijven
    • Profielen
    • Producten & Diensten
  • Kennisbank
  • Nieuwsbrief

Projectmethodes zijn louter papieren tijgers

30 oktober 2009 - 10:007 minuten leestijdOpinieGovernance & Privacy
Ben van Wijk
Ben van Wijk

Projectmanagement methoden zijn al tientallen jaren gemeengoed binnen deict- omgeving en worden constant geperfectioneerd. De documenten die, conform de methoden, worden opgeleverd zijn vaak omvangrijk. Alle denkbare aspecten zijn benoemd en omschreven. Toch zijn er nog veel projecten die niet of gedeeltelijke slagen en een slecht rapportcijfer kennen. De projectmethode met bijbehorend projectplan blijkt een papieren tijger!

In beginsel moet er veel meer gekeken worden naar de bron van het falen van een project. Veelal ligt het falen aan de voorbereidingen en sturing van een project. Weet de opdrachtgever wel of alle componenten voor een succes aanwezig zijn en zo niet wat de echte risico's zijn en hoe dit dan te managen.

De opdrachtgever is primair verantwoordelijk maar kan niet alles zelf en is afhankelijk van de kwaliteit van de mede stuurgroep- en projectleden die de opdrachtgever moeten ondersteunen. Een opdrachtgever dient minimaal de vaardigheden te hebben om een goede basis voor een succes af te dwingen. Veelal ontstaat, door de onervarenheid, hier het eerste probleem al, omdat de opdrachtgever niet in staat is alle componenten op de juiste waarde in te schatten. De opdrachtgever kan tijd kopen door meer tijd aan de voorbereiding en communicatie te besteden, echter dit wordt te weinig gedaan. Hier wordt de papieren tijger geboren.

Inzicht

Een goede voorbereiding begint bij het opstellen van een business case. Een juiste business case geeft inzicht in de problematiek en de kosten. Hierdoor wordt een project tastbaar en communiceerbaar. Ook kan de maximale investering worden bepaald. Door een volledige uitwerking te maken ontstaat er tevens een begrenzing voor een project. Een begrenzing geeft duidelijk aan wat wel en niet onder het project valt. Bij eventuele discussie kan men hier op terug vallen. Daarnaast geeft een begrenzing de contouren van een project weer en is bekend welke managers betrokken moeten worden. Een goed plan heeft daarnaast meetbare componenten, zodat bepaald kan worden of het project succesvol is.

Indien men over ketens heen gaat dan dient elke ketenbeheerder/manager zich te confirmeren. Gebeurt dit niet dan is er een dilemma, doorgaan of stoppen. Hetzelfde is van toepassing binnen een keten. Als dan het machtsspel gaat spelen loopt men extra risico. Bij een of meerdere afhankelijkheden is het beter te investeren in consensus. Het project en alle betrokkenen dienen goed samen te werken aan het gezamenlijke doel. Het is belangrijk alle key spelers bij een projectinstallatie te betrekken en het confirmeren af te dwingen.

Lukt dit niet dan kan de vraag gesteld worden; 'Gaan we verder' en in de praktijk wordt deze vraag te weinig gesteld. Is men bang voor incompetent of negatief te worden aangezien? De papieren tijger groeit.

Ook communicatie is een van de succesfactoren. Zorg dat alle betrokkenen continue en correct op de hoogte blijven en vergeet ook een stuk marketing niet. Een project moet gaan leven. Daarnaast elimineert een goede communicatie spraak- en begripsverwarring en dat is nodig voor een juiste voortgang.

Vanuit kennis en ervaring wordt ook wel intuïtief gekozen voor een project. Het draagvlak en de voorbereiding in deze context wordt op alle fronten dan nog belangrijker. Als randvoorwaarde moet vooraf alle materiekennis aanwezig te zijn om het project en de aanpak op haar juiste waarde in te schatten.

Stuurgroep

De inrichting van een project start met het benoemen van de stuurgroep. Een stuurgroep is eindverantwoordelijk voor een project en dient adequaat te opereren. Met name bij de start (beoordeling alle risico's) dient de stuurgroep een duidelijke go/no go af te geven. In de volle breedte (kwaliteit business case, risico's, bemensing, commitment, documentatie, communicatie, kosten, besparing, architectuur) dient gekeken te worden of het project haalbaar is. Gebeurt dit niet of half, dan is de kans dat het project slaagt gering. Men gunt zich veelal te weinig tijd in deze cruciale fase.

Ook de benoemde projectmanager zal bovenstaande activiteiten uitvoeren en zich dienen te confirmeren. Zorg, afhankelijk van het type project, voor een juiste invulling van de projectmanager. Een projectmanager moet het lef hebben om nee te zeggen als de start van een project onvoldoende kwaliteit heeft. Dus niet afvangen met randvoorwaarden en/of uitgangspunten maar managen!

Denk ook eens aan een project-fasemanager. Vooral bij grotere projecten kan het zinvol zijn per fase een specialist te plaatsen. Denk hierbij met name aan de inrichting, techniek en implementatie. Elke fase heeft specifieke eisen en wensen. Verder zorgt een juiste fase overdracht met bijbehorende producten er voor dat de kwaliteit en daardoor het risico wordt beperkt. Daarnaast dient een projectmanager tussentijds een beroep te kunnen doen op de stuurgroep. Deze dient dan snel bij elkaar komen. Een goede projectmanager dwingt dit af. Lukt dit niet dan stelt hij zijn functie uiteindelijk beschikbaar. Maar ja, hoe legt die (externe) projectmanager dat aan zijn baas uit. Dus het zal wel een memo worden waarin de risico's worden afgedekt en de papieren tijger wordt nog groter!

Sfeer

De projectmanager zal het project verder inrichten (mensen en middelen). Hij is zich bewust dat een zwakke schakel op een kritiek pad rampzalig kan zijn voor de kwaliteit en voortgang. Bij het aanvragen van ondersteuning is hij zich hiervan bewust.

Medewerkers die met plezier naar het werk gaan en kwalitatief goed zijn zorgen voor een juiste sfeer, betrokkenheid en kwaliteit. Hierdoor worden alle projectregels op een natuurlijke manier ingevuld waardoor het managen eenvoudiger wordt en de risico's teruglopen. Daardoor wordt een goede basis gelegd voor het slagen van een project en voor het toekomstig onderhoud.

Is een projectlid niet goed dan zonder pardon vervangen! Helaas gebeurt dit in de praktijk te weinig. De projectmanager moet vaak roeien met de riemen die er zijn. Als hij een papierentijgertje moet schrijven om dit event af te vangen moet hij zich afvragen of hij en het project wel serieus genomen worden.

De projectmanager is verder verantwoordelijk voor een plan van aanpak, inclusief planning. De planning is met alle relevante betrokkenen opgesteld. Is dit niet het geval dan wordt het project lastiger te managen omdat een uitvoerder twee weken nodig heeft en conform planning maar een week krijgt. Daarnaast zorgt de abstractie er voor dat er fouten in de planning kunnen zitten die niet zichtbaar zijn en veelal te laat worden gesignaleerd. Ook is er een relatie tussen het percentage fouten en toename tijdsdruk.

Meedenken

In de praktijk gebeurd het te vaak dan een te beperkte groep een planning opstelt en worden de uitvoerders hiermee confronteert. Een goed planningstraject zorgt er juist voor dat het project voor de medewerkers gaat leven. Men ziet wat er allemaal moet gebeuren en krijgt de kans om mee te denken. Daarnaast krijgt de projectmanager gedurende dit proces inzicht in de medewerkers en hun kwaliteit. Indien een project kan worden opgedeeld in deelprojecten dan moet dit de voorkeur hebben omdat de risico's worden beperkt. Ook zal een deelproject er voor zorgen dat het project binnen de gebruikersorganisatie sneller gaat leven.

De projectmanager is zich bewust van de risico's en heeft deze vooraf afgestemd met de stuurgroep en acties gedefinieerd om deze te managen. Hierdoor wordt het project stabieler en beheersbaar. Dit dient een continue proces in de planning te zijn. Bij te veel of te grootte risico's moet er voor gekozen worden een project (nog) niet te starten en de risico's vooraf te slechten.

Toekomst

Door ontwikkelingen en integratie van SOA, workplace on demand, contentmanagement, BPM en kennismanagement wordt de druk op een juiste voorbereiding en het managen van projecten nog belangrijker. De impact bij falen wordt alleen maar groter.
Kortom, tijd om de papieren tijger te slechten, want ik heb onlangs gelezen 'Papieren tijgers fokken papieren tijgers' en als dit gebeurt worden de projectplannen alleen nog maar dikker.

Het antwoordt is vooraf meer investeren door goed voor te bereiden, instemming met alle betrokkenen, kwaliteit bij de uitvoerders, communicatie, flexibiliteit, creativiteit, daadkracht en managen! Daarbij dient men zich te realiseren dat geen enkel project probleemloos verloopt. Het is de kunst om tijdig te anticiperen op evenementen. Hierbij is flexibiliteit en creativiteit gewenst.
Dit laatste geldt ook voor een opdrachtgever, want een Arabisch gezegde luidt: 'Een stokpaardje is duurder dan een Arabische hengst'.

Ben van Wijk, verandermanager

 

Meer over

Projectmanagement

Deel

    Inschrijven nieuwsbrief Computable

    Door te klikken op inschrijven geef je toestemming aan Jaarbeurs B.V. om je naam en e-mailadres te verwerken voor het verzenden van een of meer mailings namens Computable. Je kunt je toestemming te allen tijde intrekken via de af­meld­func­tie in de nieuwsbrief.
    Wil je weten hoe Jaarbeurs B.V. omgaat met jouw per­soons­ge­ge­vens? Klik dan hier voor ons privacy statement.

    Whitepapers

    Computable.nl

    GenAI: Veiligheidsrisico of wapen tegen dreiging?

    Wat AI betekent voor jouw securityaanpak? Alles over de risico’s en strategieën om GenAI verantwoord in te zetten.

    Computable.nl

    Bouw de AI-organisatie niet op los zand

    Wat is de afweging tussen zelf bouwen of het benutten van cloud?

    Computable.nl

    Beveiliging en IT samen sterk tegen bedreigingen

    Deze paper geeft concrete strategieën en handvatten om IT en Security effectiever te integreren.

    Meer lezen

    AchtergrondSecurity & Awareness

    Dit gaat NIS2 jouw bedrijf aan tijd en geld kosten

    compliance
    OpinieGovernance & Privacy

    Waarom Dora- en NIS2-compliance beginnen met assetmanagement

    grens België - Nederland
    ActueelData & AI

    Ai in de Benelux: veel strategie, weinig uitvoering

    ActueelGovernance & Privacy

    Microsoft: we zijn geen hulpsheriff

    OpinieCloud & Infrastructuur

    Opkomst van soevereine clouds: stel dataportabiliteit centraal

    big tech
    ActueelOverheid

    Na ingreep Microsoft bij ICC: kabinet waarschuwt voor afhankelijkheid Amerikaanse tech

    9 reacties op “Projectmethodes zijn louter papieren tijgers”

    1. MCroon schreef:
      1 november 2009 om 23:08

      Dit is een CINO (Column In Name Only). Het hele stuk komt op mij over als een onhandig verstopte sollicitatiebrief. Alle genoemde eisen waar een project(leider) aan moet voldoen komen voor in de eerste de beste projectmethodiek die ouder (en daarmee meer volwassen) is dan, laten we zeggen, een jaar of twee. Er wordt geen enkel argument of voorbeeld genoemd waarom de inhoud van een methodiek niet goed zou zijn, hoogstens wordt het gebruik ervan bekritiseerd.

      Een stuurgroep moet worden opgericht, een business case geschreven. Communicatie is van belang en? ?denk ook eens aan een project-fasemanager?. Tsjonge jonge.

      Het is gemakkelijk om een stapel papier de schuld te geven als dingen niet gaan zoals we ze hebben afgesproken. Maar ligt dat nu aan de papieren tijger of zijn de medewerkers die er gebruik van moeten maken bange muisjes, laffe teckels en angsthazen. Om maar niet te spreken van de mensen door wie die medewerkers aangestuurd zouden moeten worden.

      Het hele stuk is wat mij betreft een gemiste kans om aan te kaarten hoe je dan om kunt gaan met het wegsturen van een niet functionerende medewerker, een niet gestelde go/no go vraag of een verkeerd sturende opdrachtgever. De auteur noemt zichzelf verandermanager maar maakt dat wat mij betreft niet waar.

      Aan het eind van het artikel wordt opeens gesproken over ?SOA, workplace on demand, contentmanagement, BPM en kennismanagement? als factoren die de druk verder opvoeren bij projecten. Dit komt op mij volstrekt willekeurig over, ik kan me hier nog honderd andere / betere redenen bij bedenken.

      Overigens is de tekstuele kwaliteit van het stuk niet al te hoog. Grammaticaal rammelt er hier en daar een zin en de spelling had even gecontroleerd mogen worden.

      Login om te reageren
    2. Edward Koops schreef:
      2 november 2009 om 11:05

      De negatieve reactie van MCroon kan ik niet plaatsen. De strekking van het artikel lijkt mij niets te wensen over te laten: het gaat om de wijze waarop mensen met methodes omgaan en niet om het produceren van documenten an sich. Eigenlijk gaat het in de kern over de vraag ‘hoe kom je gezamenlijk tot goede besluitvorming’. Een methodiek helpt daarbij, maar vraagt wel om kennis en kunde van degenen die ermee werken. Ik pleit voor interactieve werkmethoden om besluiten voor te bereiden, zodat draagvlak wordt gecre?erd, want daar gaat het tenslotte om.

      Login om te reageren
    3. John schreef:
      2 november 2009 om 12:35

      Verwijt de hamer niet dat je naast de spijker slaat.

      De genoemde aandachtspunten, kritische succesfactoren, enzovoorts zijn al gauw 15 jaar expliciet onderdeel van de bekende projectmanagement methoden. Natuurlijk gaat het te vaak mis (en niet alleen in de ICT). Maar dat is omdat de mensen onvoldoende vaardigheden hebben, of de organisatie nog niet rijp gemaakt is, of doordat de methode niet goed wordt toegepast (bijvoorbeeld PINO), of bijvoorbeeld om redenen zoals die terecht door de auteur zijn aangeven. Maar dan zijn participanten bij de projecten papieren tijgers en niet de methoden.

      Een dikke duim is gemakkelijker te raken dan een dunne spijker.

      Login om te reageren
    4. Martin van de Wardt-Olde Riekerink schreef:
      2 november 2009 om 13:22

      Volkomen eens met het artikel van Ben. Waarom zou je met een hamer slaan als je een plank door wilt zagen?

      Natuurlijk is het niet de schuld van de methode als iets mislukt. En als het wel lukt is dat ook niet dankzij de methode.

      Maar de methode leidt in de huidige praktijk wel vaak af van het eigenlijke doel. Veel te veel discussies gaan over het hoe en niet meer over wat we eigenlijk wilen bereiken.

      En ja, ook dat is in methodologienland al vaker uitgewerkt, maar toch.

      Login om te reageren
    5. Harm schreef:
      2 november 2009 om 13:32

      Het is mij onduidelijk waar de schrijver van dit artikel heen wil en wat zijn boodschap is. Methodes afschaffen? Of de documenten verminderen/afschaffen?

      Daarnaast is het artikel in mijn ogen niet consistent.
      “In beginsel moet er veel meer gekeken worden naar de bron van het falen van een project.” Is de schrijver niet bekend met het feit dat veel van de (zo niet alle) projectmanagementmethoden juist op de lessons learned (van het slagen maar ook falen van projecten) zijn gebaseerd?

      Het lastige aan projecten is dat geen enkel project hetzelfde is. Wat vandaag goed gaat, kan morgen volledig mis gaan. Ook al wordt dezelfde methode gehanteerd. Hiervoor kunnen honderden redendn worden aangedragen.

      Is het project mislukt omdat de methode niet goed is toegepast en/of de documentatie niet is opgesteld/bijgewerkt? Onzin, het is naief om te denken dat wanneer een methode tot in de puntjes wordt gehanteerd, inclusief het opstellen/bijhouden van alle voorgeschreven documentatie, het project automatisch succesvol wordt beeidigd.

      Is al die documentatie dan noodzakelijk? Ik vind van wel, al is het maar om aan te tonen waarom een project in specifiek die situatie al dan niet succesvol was.

      Login om te reageren
    6. Coen Berghegen schreef:
      2 november 2009 om 14:34

      Projectmethodes kunnen als vertrekpunt prima handvaten geven voor de praktijk. Maar je moet (als projectmanager) wel zelf blijven nadenken en kijken welke ingredienten van de methode je gaat gebruiken en waarom. Projecten zijn altijd maatwerk en een methode kan nooit in alle voorkomende situaties voorzien. Daarom is er altijd menselijke creativiteit nodig om projecten te laten slagen. Dat maakt het juist zo leuk!
      Wat volgens mij vaak veel te weinig aandacht krijgt is de procesmatige kant van projecten.(zorgen voor juiste gemeenschappelijke focus, draagvlak en betrokkenheid bij stakeholders)

      Login om te reageren
    7. Frank van de Kant schreef:
      2 november 2009 om 19:35

      Een projectmethode kun je volgen, maar dat is hooguit een best-practice. Een methode is een handleiding en daar zit geen actieve component in. De projectleider stelt een projectplan op wat gevolgd wordt.
      Ieder project heeft eigen kenmerken en zal daarmee eigen afhankelijkheden en verantwoordelijkheden hebben. Het gevolg is dat de projectinvulling en uitvoering naar eigen kunnen zal wordt ingevuld.
      Het succes van een project is gekoppeld aan het goed kunnen overzien van de projectgrootte en projectinhoud. Daarom is belangrijk vooraf te bepalen wat de grenzen van het project zijn. De projectleider behoort te bewaken dat het hele project uitgevoerd wordt, en dat er ook niet meer dan dat gedaan wordt.

      Zo heb ik in mijn projecten meermalen nee verkocht aan de klanten. Niet omdat ik die functionaliteit niet wilde leveren, maar omdat wat de klant tijdens een project alsnog graag wilde toevoegen niet binnen de grenzen van het project viel. Als het succes van het project afhankelijk is van iets wat buiten de grenzen van het project valt is het natuurlijk zaak dat dit toch opgepakt wordt. Dit wordt dan een aparte activiteit. De budgethouder van het project wordt op dit moment wel ingeseind zodat er budgettair in elk geval verantwoordig bestaat voor de niet begrootte activiteit.

      De kunst om geen activiteiten buiten de grenzen van het project te ontwikkelen is en blijft lastig. Het is verleidelijk om meer te doen en daarmee persoonlijk nog succesvoller te zijn. Er is echter geen budget voor de extra activiteiten en er bestaat ook geen toestemming voor. Het risico wat ontstaat is dat het project niet voldoende aandacht krijgt waardoor het niet volledig of niet op tijd opgeleverd wordt.

      In het artikel noemt Ben projectfasemanagers. Hij kiest er voor specialisten in te zetten op verschillende fasen van een project. Prima idee, maar dit neigt naar een oplossing kiezen terwijl het probleem nog niet duidelijk is.
      Naar mijn idee is een project altijd onder te verdelen in verschillende fasen. Deze fasen horen sequentieel doorlopen te worden. Na iedere fase bestaat er weer een beslismoment om wel of niet door te gaan met de volgende fase. Dit betekent dat een project uitvoeren een cyclisch proces is. Het totale project wordt in stukken geknipt en zo uitgevoerd.

      De conclusie is dat projecten succesvol doorlopen kunnen worden met behulp van methodes. Kies wel de juiste methode en begin vooral door de projecten zo klein mogelijk te maken.

      Login om te reageren
    8. Ben van Wijk schreef:
      3 november 2009 om 12:07

      Hierbij wil ik een ieder bedanken voor een reactie.
      Voor mij is een methode slechts een hulpmiddel. De rest is aan alle uitvoerders. Een gedegen voorbereiding en de gezamenlijke kwaliteit van de uitvoerders bepaalt het succes (kwaliteit, kosten, tijd en acceptatie).

      Projectfasemanagers kunnen, door de tussentijdse overdrachten en de controle op de aangeleverde informatie, een extra kwaliteitgarantie geven.

      Geniet en veel succes!

      Login om te reageren
    9. Melle de Vries schreef:
      13 mei 2010 om 20:24

      Afgezien van de soms inconsistente inhoud en de grote hoeveelheid taalfouten, was ik wel geboeid door het artikel. Wat is nu eigenlijk de problematiek achter het falen van projecten? Als de auteur het artikel opent met een klacht over de omvangrijke documenten en aan het eind van het artikel pleit voor een betere voorbereiding van de projecten, heeft hij het probleem dan te pakken?

      Ik ben het ermee eens dat sommige projectmanagement methodes het risico met zich meebrengen dat ze een doel op zich worden, maar een project zonder methodische aanpak is tot mislukken gedoemd, lijkt mij. Ook ben ik allergisch voor een overvloed aan papier in een project, maar bij een veelheid aan belangen en voorwaarden aan een project zal er toch het een en ander vastgelegd moeten worden. In het digitale tijdperk onthoudt men immers niet zoveel.

      Wat dan wel? Ik denk dat twee essentiële kenmerken van een project gehonoreerd moeten worden, namelijk 1) dat het iets tijdelijks is dat afwijkt van de reguliere bedrijfsvoering en 2) dat het een verandering wil bewerkstelligen. Dat betekent volgens mij dat het belangrijk is om enerzijds voortdurend doel en noodzaak van het project voor ogen te houden en anderzijds te zorgen voor een krachtige en toch flexibele aansturing van het project. Flexibel vanwege de genoemde kenmerken en de vele belangen die vaak spelen. Al het andere in een project is daarvan afgeleid.

      Overigens ben ik van mening dat iedere projectleider zijn plan en ook zijn rapportages moet kunnen samenvatten in 1 A4-tje en zelfs in een tweet!

      Login om te reageren

    Geef een reactie Reactie annuleren

    Je moet ingelogd zijn op om een reactie te plaatsen.

    Populaire berichten

    Meer artikelen

    Uitgelicht

    Partnerartikel
    AdvertorialInnovatie & Transformatie

    Ontdek de toekomst van IT-support en m...

    Op 16 september 2025 vindt in de Jaarbeurs in Utrecht een gloednieuw event plaats dat volledig is gericht op IT-professionals:...

    Meer persberichten

    Footer

    Direct naar

    • Carrièretests
    • Kennisbank
    • Planning
    • Computable Awards
    • Magazine
    • Abonneren Magazine
    • Cybersec e-Magazine
    • Topics

    Producten

    • Adverteren en meer…
    • Jouw Producten en Bedrijfsprofiel
    • Whitepapers & Leads
    • Vacatures & Employer Branding
    • Persberichten

    Contact

    • Colofon
    • Computable en de AVG
    • Service & contact
    • Inschrijven nieuwsbrief
    • Inlog

    Social

    • Facebook
    • X
    • LinkedIn
    • YouTube
    • Instagram
    © 2025 Jaarbeurs
    • Disclaimer
    • Gebruikersvoorwaarden
    • Privacy statement
    Computable.nl is een product van Jaarbeurs