Bert Overbeek is trainer, coach en interim manager, maar tegenwoordig kan je ook zeggen: organisatiedokter en -innovator. Opgeleid door NS en Schouten en Nelissen, besloot Jongebazen-oprichter Bert Overbeek na 25 jaar loondienst om voor zichzelf te gaan werken. Hij wilde zijn klanten meer op maat bedienen, de basis van zijn werk verdiepen en de kwaliteit van zijn werk vergroten en had het gevoel dat hij daarvoor onafhankelijk moest kunnen opereren. Hij is er gelukkig van geworden. (Website met filmpje: www.pitchersupport.jimdo.com)
Prof. dr. Mastenbroek van Managementsite ‘ontdekte’ dat Overbeek meer kon dan bedrijven helpen met verbeteringen van resultaat en sfeer. Hij vroeg de schrijvende organisatieontwikkelaar of hij een weblog voor jonge managers wilde bijhouden, als partnerlink van het grote ManagementSite. Dat was tien jaar geleden. Sindsdien schreef Overbeek bijna 1500 artikelen en zes boeken. Ze werden uitgegeven door Haystack en door Futuro Uitgevers. Twee boeken werden bestsellers en eindigden in de top 10 (‘Het Flitsbrein’ en ‘Mannen en/of vrouwen’).
Overbeek vindt kosteloze kennisdeling en informatie-uitwisseling zo belangrijk, dat hij hier op jongebazen.nl nu 10 jaar de finesses van het managementvak deelt met vakbroeders en collega’s. Daarmee liep hij voor op de moderne social media trends waarin het ‘geven’ van gratis informatie een marketing tool is geworden.
Meer dan 100 000 mensen bezoeken Jongebazen per jaar. En het heeft hem veel respect opgeleverd in managementland. Alles wat te maken heeft met het verbeteren van organisaties, teams en mensen boeit hem. 21 jaar ervaring en intensieve studies helpen hem daarbij. Zijn humor leidt er toe dat mensen hem graag inhuren als spreker en inspirator, en zijn veelzijdigheid heeft hem het compliment van een topvrouw opgeleverd, dat hij altijd een eigen gezichtspunt kiest en je daardoor aan het denken zet.
Organisaties weten de weg naar hem te vinden. Hij zei daarover in een interview: ‘Het is niet altijd makkelijk om mijn werk te combineren met jongebazen, omdat je op zo’n blog wel eens inzichten los wilt maken die strijdig zijn met wat gangbaar is in mijn vak. Wat zegt hij daar nu weer?, denken opdrachtgevers dan. Maar ik kan ze gerust stellen. In mijn werk kan ik me goed op een opdracht richten.’
Bert twittert op Goeroetweets, een titel die is afgeleid van zijn boek ‘Goeroegetwitter’. Het woord ‘goeroe’ is duidelijk met een knipoog. Want hij is wars van goeroeneigingen, en prefereert laagdrempeligheid. Jongebazen heeft een eigen groep op Linkedin.
Correspondentie met Bert Overbeek via pitcher.support@hetnet.nl Zijn website is www.pitchersupport.jimdo.com
Toch nog wat kritische kanttekeningen:
* er wordt wel snel gesprongen van blauwdruk-denken (De Caluwe) naar rooddrukdenken. Ik denk dat het situationeel is. Fase van ontwikkeling van het bedrijf en cultuur is sterk bepalend.
* ik denk dat de projectmanager ook meer de moed moet hebben om een project stil te leggen. Vaak blijven beslissingen inderdaad in de stuurgroepen hangen. Wanneer de projectmanager een project stil legt (als laatste redmiddel) is dat mijn inziens een professioneel middel om hier druk achter te zetten.
* in het verlengde van mijn vorige opmerking is het ook van belang om bij de start van een project stil te staan bij de rol van het beslisorgaan (de stuurgroep). Mijn ervaring is dat veel stuurgroepen worden bezet door lijnmanagers die geen projectmanagement-ervaring heeft en daardoor niet in staat zijn om het project slagvaardig te sturen.
Nogmaals, verder helemaal eens.
Gr,
Richard
Boeiende materie waarover je schrijft. Ook enorm herkenbaar. Je voorbeelden spreken tot de verbeelding. De klassieke technische projectmanager die afspraak=afspraak roept en planningen in beton giet. Typische projecten van de eerste orde (zie projectmatig werken van Gert Wijnen c.s.) of het blauwdrukdenken (uit Leren Veranderen van de Caluwé c.s.) van dezelfde firma. Wat ik mis in je analyse is de rol van de opdrachtgever. In de projectmanagement methodes (bijvoorbeeld PRINCE2) wordt hier ook nauwelijks aandacht aan besteed. De projectmanager is altijd de actieve figuur die het project trekt, maar er is minstens zo'n grote rol weggelegd voor de opdrachtgever. Goed opdrachtgeverschap houdt m.i. ook in dat de opdrachtgever niet klakkeloos alles accepteert wat de projectmanager voorstelt (bijvoorbeeld onrealistische planningen en dat je juist betrokkenheid toont. De praktijk is helaas vaak anders. Juist de opdrachtgever moet investeren in de samenwerking en coachend optreden als de projectmanager daar te weinig aandacht aan besteed. Er zijn twee titels op de markt (zover ik weet) die dit onderwerp verkennen, te weten: PRINCE2 voor opdrachtgevers van Michiel van der Molen en Help, ik heb een opdrachtgever van Nicoline Mulder.
Met vriendelijke groet,
Richard Puyt
Meer dan eens heb ik discussies gevoerd met stakeholders danwel projectmanagers die de planning als een heilig iets beschouwden. Of nog erger de project documentatiemethode (Ja maar volgens Prince......).
En als (extern) adviseur mbt projectmanagement krijg ik tijdens discussies wel eens te horen dat ik niets van Prince 2 begrijp. Nu heb ik ca 20 grote IT projecten geleid, van redelijk straight tot zeer complex en allemaal min of meer succesvol. Maar het gaat daarbij vooral om betrokkenheid, kennis van zaken en veel communiceren. En met dat laatste bedoel ik dus niet dat je vooral veel emailt. En de PM methode is daaraan ondergeschikt. Een hulpmiddel, niet meer en niet minder, maar zeker geen toverstafje voor succes.
Mijn complimenten voor dit artikel. Een knappe analyse en uitwerking. Daarbij heb ik een kleine aanvulling. In de titel en de uitwerking leg je de nadruk op falend projectmanagerschap en gegeven de voorbeelden die je gebruikt lijkt dat ook aannemelijk.
Mijn ervaring is dat deze benadering te eenzijdig is. Er is namelijk ook de kant van de opdrachtgever. Eén van de verantwoordelijkheden van de opdrachtgever is het vinden en contracteren van een projectmanager ‘capable for the job’.
Ik zie te veel om me heen dat opdrachtgevers en inkopers van interim personeel bij de selectie van projectmanagers niet meer functie-eisen weten op te hoesten dan inhoudelijke materie kennis/ervaring aangevuld met Prince 2 en bijvoorbeeld ITIL. Met alle respect, dat zijn natuurlijk zwaar onvoldoende criteria voor de selectie van een projectmanager op het juiste niveau. Een personeelsbaas waar ik ooit mee werkte zei:”vraag je een aap dan krijg je een aap”.
Met andere woorden. Eens met je artikel met de kanttekening dat als er sprake is van falen dat de opdrachtgever dan evenveel blaam treft.
Vriendelijke groet,
Koos
Ik kan me vinden in de conclusie:
"Investeren in afstemmen en verbinding tussen IT-project, IT-beheerorganisatie en gebruikersorganisatie is een andere manier van leiding geven aan organisatieverandering waarbij ICT een belangrijke rol speelt."
Echter de meeste projectmanagers ontberen één of meerdere essentiële basisvaardigheden als communiceren, relaties aangaan, overtuigen, enthousiasmeren etc. om complexe organisatie/ICT projecten tot een goed eind te brengen. Teveel projectmanagers weten veel van ICT maar weinig van management. Hierdoor faalt nog steeds meer dan 60% van alle ICT projecten in Nederland.
I don’t believe in doing estimates by myself: the project teams are the technical experts, and they should have the biggest say in how the project should be structured, and how long each activity will take. The project manager should be the facilitator in this process, as described in the article. As an added bonus, you will also get their buy-in and commitment.
The project manager should focus on scope. Most business users have the idea that it is quick and easy to change software. Focus on scope protects the team from these changes. That said, the project manager should not be inflexible. Scope change should be allowed to happen, but in a controlled way. This should lead to update cost and delivery dates.
Thanks for the thought provoking article.
Nico
Wanneer bij de start van een poject de tijd wordt genomen om met elkaar vast te stellen wat er moet gebeuren, hoe dat wordt gemanaged, met welke middelen en door wie dan blijkt in praktijk dat 95% van het project op rolletjes loopt. De rest vormt een dagtaak voor de projectmanager door gewoon te luisteren naar de medewerkers en de voorliggende problemen in onderling overleg onmiddellijk met elkaar op te lossen.
IT is een middel , geen doel (tenzij je voor een IT leverancier als Logica werkt natuurlijk). PRINCE2 geeft ook zeer duidelijk aan dat als gevolg van het bovenstaande en de daaraan gerelateerde conflicterende business cases, niet de leverancier, maar de klant het project dient te managenen. Helaas wordt dit stukje PRINCE2 meestal genegeerd, vooral door leveranciers (zoals Logica). Voor mij is dit een zeer belangrijke oorzaak waarom zoveel projecten falen: ze worden immers gezien als IT projecten met de leverancier aan het stuur...
(2) Problemen of veranderuitdagingen in organisaties ontstaan in de huidige kennismaatschappij onvermijdelijk in het licht van het conventionele managementdenken zoals dat op onze universiteiten en hogescholen wordt gedoceerd.
Ditzelfde denken ligt ook ten grondslag aan ICT-oplossingen.
(3) Hier ligt daarom een onvermijdelijke valkuil voor managers die met ICT-oplossingen problemen of veranderuitdagingen in organisaties willen aanpakken.
(4) De toepassing van nieuwe ICT-oplossingen zal dan ook alleen op een soepele manier kunnen verlopen als deze op een onconventionele wijze tot stand komt of in het bijzondere geval dat er in een bedrijfsvoering geen sprake is van noemenswaardige problemen of veranderuitdagingen.
(5) Als het in het artikel genoemde “investeren in leren en samenwerken” niet voldoende vergaand ‘out-of-the-box’ gaat (lees: in de betreffende situatie onvoldoende onconventionele consequenties heeft), blijven bovenstaande beweringen van kracht en de huidige praktijksituatie van teveel tegenvallende ICT-projecten ongewijzigd.
Met name in organisaties waarin het zogenaamde diversiteitsdenken (met een open oog voor zachte aspecten)reeds is doorgedrongen, is het van belang hier niet lichtzinnig aan voorbij te gaan (zie hiervoor de column van Pierre Mellegers op deze website: http://www.managementsite.nl/columns/1385/Diversiteitsdenken-een-organisatie-onderzoek-naar-verschillen-in-en-buiten-ons-zelf.aspx).
(6) Het in ICT-projecten conventionele samenspel tussen leveranciers en klanten is gebaseerd op een diepgewortelde conditie van ‘gecontroleerd wantrouwen’.
Zolang daar sprake van is, is “investeren in leren en samenwerken” een fars (zie in dit verband ook mijn reactie “CRM is geen ICT: eye opener of open deur” op deze site van 22-07-08; http://www.managementsite.nl/352/ICT-en-Internet-CRM-is-geen-ICT.aspx).
(7) Deze beweringen zijn kort door de bocht geformuleerd, maar de praktijk van zoveel mislukkingen waarover ook het artikel spreekt, maakt het aanbrengen van nadere nuances slechts tot een activiteit voor liefhebbers.
Zelfs als bovenstaande stellingen niet gelden voor alle ICT-projecten, blijven er nog teveel ICT-projecten over, waarvoor deze stellingen in hoofdlijnen wel gelden.
Deze situatie bestaat al minstens dan 20 jaar!
De kern van ieder project bestaat uit: mensen en verandering. Ieder project hoe klein, groot, simpel of complex brengt een verandering teweeg in de werksituatie van mensen in een organisatie.
Het is ontstellend te zien hoe weinig aandacht hieraan gegeven wordt in de bekende projectmanagement methodieken. Alhoewel het uitvoeren van projecten een blauwe verander interventie is, zegt dat niets over de meerkleurige aanpak die binnen het project (onder bepaalde condities) gekozen en ingezet kan worden om de verandering echt te laten beklijven en zo tot echt project resultaat te komen.
Waarom dan toch zo blauw? hoor ik u denken. Het antwoord is volgens mij even simpel als ontluisterend: methoden leiden tot een schijnzekerheid en schijntastbaarheid, mensen niet. De projectmanagers van tegenwoordig kiezen voor de makkelijkste weg: weg van de mensen. Mijn betoog luidt dan ook dat we dit soort projectmanagers niet meer nodig hebben. We hebben een grote behoefte aan projectleiders: mensen die andere mensen leiden in de verandering.
Wat een mooi vak is dat zeg!!!
De vergelijking met het projectmanagement in het onderwijs gaat niet helemaal op, maar wel herkenbaar.
In het innovatie-en onderzoeksproject van Expeditie Durven Delen Doen (www.expeditiedavinci.nl en www.durvendelendoen.nl) gaat het juist over 'leren innoveren'. De 7 C's (commitment, community, consistentie etc.) van Sietske Waslander kunnen fungeren als evaluatiekader voor de proceskant van innovatie/projectmanagement.
Het Da Vinci College in Leiden doet daar op dit moment prachtige ervaringen mee op. Sturen op resultaat en op proces. Onderzoek naar de innovaties wordt door de docenten zelf gedaan.
Kernbegrippen zijn: eigenaarschap, uitgaan van passie, betekenisvol, samenwerken en participatie. De insteek is dat de innovaties en onderzoek daarnaar duurzaam zijn en een blijvende plek krijgen binnen de onderwijsorganisatie.
Binnenkort verschijnt een artikel in Opleiding&Ontwikkeling hierover.
In de bouw blijkt het mogelijk te zijn om uit te rekenen hoeveel agendatijd besteed zou moeten worden aan te voorziene verstoringen. Het zogenaamde PSU product (Project Sense of Urgency) is het product van de door het team ingeschatte complexiteit index (van 1 = eenvoudig, tot 5 is meest complex) en een door het team ingeschat potentieel aan verstoringen in vier categorien: Techisch, Organisatorisch, Samenwerking en Externe Dynamiek. Maximaal mogen 10 punten worden toegekend aan deze index. Index x Factor = PSU product. Bij eenvoudige projecten kunnen maximaal 10 PSU product eenheden worden gescoord, bij een meest innovatief complex project 50 PSU product eenheden.
Één PSU eenheid komt ongeveer overeen met 20 minuten agendatijd op een werkconferentie zoals een projectstartup of een projectflollow up. Een PSU van een eenvoudig project duurt dan ongeveer 200 minuten = 3 uur 20'. Een innovatief groot en complex project vraagt om een PSU van 50 x 20 minuten = ruim twee dagen.
Als je deze berekening een aantal keren gebruikt, valt op dat de geagendeerde tijd voor teambuilding en voorkomen van escalatie drastisch toeneemt en dat de planning al snel aangepast wordt aan realistische uitgangspunten en niet meer op opportunisme van de projectleider en opdrachtgever kunnen worden gebaseerd.
Tijdens de werkconferentie kun je bovendien het leervermogen vergroten en de creativiteit bevorderen door unanieme besluitvorming op basis van geen bezwaar (consent) in te voeren. Daarmee maak je het mogelijk dat teamleden op basis van gelijkwaardigheid met elkaar omgaan. Dat vergroot het probleemoplossend vermogen van het team drastisch!
christoph maria ravesloot
lector Innovatie Bouwproces en Techniek
Avans Hogeschool
Hogeschool Zuyd
het is inderdaad zo dat projecten met veel proces en creatieve imput ook niet te betonneren zijn. Nochtans durf ik ook wel eens diegene te zijn die bij de medewerkers hamer op mijlpalen en deadlines, maar dan vooral in functie van het niet uit het oog verliezen van de doelstellingen. Een creatief proces durft nogal eens uit te waaieren (te veel perceiving om het in MBTI termen te noemen). Het spreekt vanzelf dat mijlpalen dan geformuleerd worden op wat ik in eigen vakjargon "veranderingsknopen" zou noemen.
Gelijkenissen tussen IT en creatieve processen een toeval? Streven computer en IT niet voortdurend de technische perfectie van de menselijke hersenen na?
Heb het artikel met interesse gelezen inclusief andere commentaren!
thanks
Anne-Mie
Wat ICT-projecten onderscheidt van andere projecten is de complexiteit van problemen en oplossingen, de veranderlijkheid van de omgeving en van de wensen en eisen.
In het begin van een ICT-project is er nog zo weinig bekend over de details in de eisen die gesteld zullen gaan worden, dat het onmogelijk is een planning op te stellen die ergens op slaat. De klanten kunnen zich er geen voorstelling maken hoe ze straks zullen gaan werken. Dat groeit wel tijdens de duur van het project, als de eerste resultaten worden getoond. Maar dat kan ook betekenen dat er grote wijzigingen komen in de eisen en wensen.
Als er in het project gebruik gemaakt zal worden van nieuwe technologie, dan zal er geexperimenteerd moeten worden, en doodlopende wegen bewandeld worden.
Dit alles kost tijd, en hoeveel tijd dat gaat worden, is maar moeilijk in te schatten, zeker niet bij de start van het project.
In een ICT-project moet wel rekening gehouden worden met onzekerheid en verandering. Daarom wordt PRINCE 2 vaak aangevuld met een softwareontwikkelingsmethode zoals RUP (Rational Unified Process), en een AGILE projectmanagementaanpak.
RUP bevat de best practices van vele projectmanagers, gaat uit van structured prototyping, en stelt dat met het vaststellen van het projectplan een raming van het project kan worden gemaakt met een onzekerheidsmarge van 400 %...
De kern van Agile is dat klanten en ICT'ers samen in kleine stapjes toewerken naar een steeds beter resultaat, en dat verandering goed is. De nadruk ligt dus op de zachte kant van projecten uitvoeren.
1. Rol van de opdrachtgever
Als ik deze belicht vanuit mijn eigen kennis en kunde valt me op dat de opdrachtgever regelmatig op de achtergrond verblijft. Vaak wordt de projectmanager / leider door projectmedewerkers gezien als verlengstuk van de opdrachtgever. Als de projectleider onafhankelijk opereert en bewust als verlengstuk van de opdrachtgever acteert dan is de opdrachtgever geen kritieke succesfactor voor het investeren in leren en samenwerken. Hij kan lekker het project volgen in de luwte.
2. Training en opleiding
De (h)erkenning van het probleem doet me concluderen dat projectmanagers / leiders de verkeerde training krijgen. Het ontwikkelen van vaardigheden in het hanteren van instrumenten krijgt voldoende aandacht. Het trainen van vaardigheden om leren en samenwerking te stimuleren is het grote manco in deze trainingen en opleidingen. Dus, aanpassen die trainingen en opleidingen voor projectmanagers / leiders is dan het devies!
Nogmaals dank voor jullie bijdrage,
Leon Dohmen
Pas als we op die vragen naar de oorzaken achter de oorzaak van falen de antwoorden weten te achterhalen, kunnen we echt maatregelen bedenken.
Dit is de aanloop tot mislukking, zeker als de gewenste veranderingen de actieve inzet van de lijnorganisatie vragen. En dat is zeer vaak het geval! Elders https://www.managementsite.nl/organisatierot beschrijf ik de volgende ervaring:
“Onlangs vertelde de baas van een grote productie-afdeling mij met zichtbaar genoegen dat het kwaliteitsproject op zijn laatste benen liep. Eindelijk kon er weer normaal gewerkt worden. Jarenlang was hij, naar zijn idee, afgeknepen met verzoeken (lees: opdrachten) om medewerkers in projectgroepen te laten participeren. Daarbij kwamen nog allerlei onderzoeken van externe figuren, die zijn medewerkers voor de voeten bleven lopen. Vooral het rapport over de vermijdbare kwaliteitskosten was bij hem en zijn mensen verkeerd gevallen. "Alsof we ons hier niet uit de naad werken!" Enfin, de projectgroepen hadden hun werk gedaan. Er waren nog wel bijeenkomsten om de resultaten over te dragen. "Nou, ze zoeken het maar uit, misschien iets voor de coördinatoren."
Ik zie te vaak hoe een goed opgetuigde projectorganisatie de verantwoordelijkheid voor verbetering uit de lijnorganisatie haalt. Niet gepland of bedoeld maar het gebeurt! De sturing en betrokkenheid van de top verdwijnen naar de achtergrond en het leidinggevende kader wordt onvoldoende aangesproken op de eigen verantwoordelijkheid.
De projectaanpak is in tal van organisaties verworden tot een chronische kwaal. Zijn er problemen oftewel ‘uitdagingen’; we lossen het op met een project. Kordaat en doelgericht! Dat is de routine. Velen geloven hier kennelijk in. Zeker als tal van verstandige mensen een gezicht trekken alsof het zo hoort.
Soms is men zo gewend aan deze aanpak dat men zich niets meer voor kan stellen bij het alternatief van "Hou het in de lijn!" Vaak ook wordt het idee om het verantwoordelijke management de zaken op te doen pakken afgedaan met: 'Geen tijd' of 'Men kan het niet aan'.
Mijn stelling is: Dat kan gebeuren. Maar dan moeten we elkaar niet wijsmaken dat we dit met de projectaanpak oplossen. Dan is dat het probleem wat we onder ogen moeten zien en waaraan we wat moeten doen.
De punten die in het artikel terugkomen zijn heel herkenbaar.
Het probleem van projectmanagement is dat men zich altijd op het proces richten en veel minder op de inhoud.