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
Ik zou dat graag nog even "theoretisch" verder onderbouwen. Bij projectmanagement (bijv. Prince 2) wordt slechts een output, projectresultaat, opgeleverd. Er wordt wel een planning gemaakt van "Benefit management", dus hoe je de baten incasseert; maar dat incasseren zelf behoort niet tot de scope van projectmanagement. Weinig mensen, en zelfs weinig projectleiders, weten dit. Laat staan dat opdrachtgevers, directeuren en lijnmanagers dit weten. En zich realiseren wat dit impliceert!
Het realiseren van de baten wordt in Programmamanagement gerealiseerd. Zie bijvoorbeeld MSP, Managing Succesful Programmes https://www.axelos.com/certifications/propath/msp-programme-management.
In MSP wordt expliciet de Business Change Manager opgevoerd, die er voor verantwoordelijk is om de baten van het programma te realiseren. Een cruciale taak, die buiten de scope van projectmanagement valt. Doe je dat niet, dan mislukt je project vrijwel zeker; c.q. levert niet de geplande baten uit de businesscase op. In masterclasses Portfoliomanagement, Programmamanagement en Projectmanagement (https://www.ncoi.nl/opleiding/masterclass-programmamanagement.html ) wijs ik hier altijd zeer nadrukkelijk op.
Ik hoop dat vooral overheden hier ook nog eens heel goed naar kijken; want juist dat gaat daar heel vaak vreselijk mis.
Een waarschuwing over "meedenken van teams" tijdens de ontwikkeling is wel op zijn plaats.
Gebruikers hebben heel vaak onvoldoende abstractieniveau om de nieuwe/verbeterde processen en bijbehorende ICT functionaliteiten te visualiseren en dus als specificaties aan IT-ers door te geven. Daarom is dit heel vaak een extreem zwak punt in ontwikkeltrajecten; maar zelfs ook in implementatie trajecten van standaard software, waarvan de parameters netjes moeten worden ingesteld op basis van die specificaties. Ook daarvoor is een 100% scherp beeld noodzakelijk van hoe de nieuwe werkwijze er uit moet gaan zien. Is die kennis er niet, dan leidt zowel ontwikkeling als implementatie van nieuwe SW tot een grote teleurstelling.
Het is dus van cruciaal belang dat er zowel
1. een verantwoordelijk gehouden business change manager aanwezig is,
2. als een proceseigenaar/senior user/product owner die echt voldoende abstractievermogen heeft, de strategie en tactiek van de organisatie begrijpt en dit kan vertalen naar nieuwe processen, taken van medewerkers en de daarvoor optimale ondersteunende functionaliteit van software (schermen, invoer, uitvoer, etc.)
Het kan ook zo maar zijn dat het nieuwe systeem krakkemikkig is of dat het nieuwe systeem slechter is dan dat de mensen al gebruiken. Dat laatste speelt vaak bij fusies of overnames waar omwille van standaardisatie het overgenomen bedrijf gedwongen wordt het systeem te gaan gebruiken van het aankopende bedrijf. Er zal dan weinig enthousiasme zijn bij het overgenomen bedrijf. Een change manager zal dit niet kunnen compenseren. Ik vind een change manager in het algemeen geen goed idee. Veranderkunde dient een integraal onderdeel te zijn van de competenties van een projectleider.
Het idee dat het lijnmanagement een prominente rol moet spelen bij het invoeren van een nieuw IT-systeem ondersteun ik. Dit is zelfs een cruciale voorwaarde voor acceptatie van het systeem. Een afdelingsmanager heeft ooit eens tegen me gezegd, bij het invoeren van een nieuw ERP-systeem, dat hij in het begin van het project niet goed begreep waarom hij zich hiermee moest bezig houden. Pas gedurende het project werd dit voor hem duidelijk. Hij vond het geen leuk werk maar voelde zich in de loop van het project er (steeds meer) verantwoordelijk voor dat zijn afdeling het systeem op de juiste manier ging gebruiken. In totaal waren (+/-) acht afdelingsmanagers betrokken bij het project waarbij elke manager voor een module of deel van het ERP-systeem verantwoordelijk was.
PS: Leuk om weer eens te lezen over IT-projecten :-)