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
"Simonse, A., Tijdens, K. en Reijnen, M.H., Meer energie voor sociale verbetering: de sociale gevolgen van een logistiek informatiesysteem bij een energiebedrijf, Wetenschapswinkel van de Universiteit van Amsterdam, januari 1988."
Marcel Reijnen
senior trainer/adviseur medezeggenschap
www.depijl-mz.nl
De ellende begint al met het label wat je op een project plakt. Semantiek is belangrijk en mensen gedragen zich naar hun perceptie die door semantiek wordt beïnvloed. Houd daarom op met gebruik van het label “ICT project”. Praat voortaan over verbeterprojecten (waar misschien ook wel een stukje ICT aan te pas komt). Het label ICT project zorgt automatisch voor een technische, instrumentele perceptie.
Dan de opmerking dat projecten bij de leverancier niet falen. Dat herken ik. Ik heb ooit een PRINCE2 cursus gegeven war het volgende zich afspeelde. Een van de aanwezigen, een redelijk ervaren project manager van een ICT leverancier, vertelde heel trots dat projecten van zijn organisatie vrijwel nooit faalden. Vervolgens vroeg ik hem of zijn klanten er ook zo over dachten. Het antwoord? Nee, zijn klanten hadden altijd wel wat te zeuren…
Nu we toch bij PRINCE2 zijn. Alle ICT leveranciers passen deze aanpak toe. Zeggen ze…
Wat vrijwel iedereen negeert, zeker ICT leveranciers, is dat PRINCE2 een klantenaanpak is, geen leveranciersaanpak. De aanpak stelt expliciet dat een projectmanager het beste van een klant kan komen. Waarom? Vanwege de twee conflicterende business cases. Het wordt in dit artikel “een combinatie van onkunde en plat commercieel opportunisme” genoemd dat een leverancier niet goed met de Business Case van een klant omgaat. Dat is helaas erg naïef. Een leverancier moet nooit verantwoordelijk worden gesteld voor de business case van een klant, kan dat ook niet, moet dat ook niet willen. De kostenkant van de klant is de omzet van de leverancier. Ook hier is PRINCE2 weer heel duidelijk, dit is de reden dat een projectmanager van de klant zou moeten komen of, wanneer niet mogelijk, onafhankelijk zou moeten zijn. De realiteit is dat de PM vrijwel altijd van de leverancier komt en daarmee introduceer je een gigantisch risico. De opdrachtgever weet dit niet en de leverancier wil dit niet weten.
Dan komt het bij veel klanten, zeker bij de overheid, steeds vaker voor om een sterke CIO aan te stellen. Deze CIO neemt dan het opdrachtgeverschap voor de rekening van ICT projecten. En daar gaan we weer. Dit middel is vrijwel altijd erger dan de kwaal.
1. Het label ICT projecten komt in alle hevigheid terug
2. De CIO is natuurlijk niets anders dan een leverancier. Weliswaar een interne, maar nog steeds een leverancier. Zou je een externe leverancier ook zo veel macht geven? Een interne leverancier heeft ook een tegenstrijdige Business Case, alleen zal deze vaak politiek zijn.
3. Een CIO, net als andere C-level functies, is een uiting van de functionele organisatie. Iedereen die goed op de hoogte is van deze materie, zal stellen dat de functionele organisatie verandering in de weg staat en projecten bedreigt.
Nico Viergever
Management consultant, trainer
PRINCE2/MSP trainer
Ik herkende wat in het artikel was geschreven: een opdrachtgever die zich afzijdig houdt omdat het toch over ICT, iets technisch gaat. En dat moet je vooral aan de ICT overlaten.
Misschien even terugdenken aan het commentaar van een SAP directrice, een paar jaar geleden. Zij klaagde erover dat de gebruikers niet voldoende betrokken waren en dat daarom zoveel SAP implementaties faalden. Natuurlijk snapte deze dame het niet echt. Gebruikers zijn per definitie niet betrokken als een project een technisch lading krijgen (dus in jouw en mijn visie geen goed opdrachtgeverschap hebben) en wanneer, zoals bij ERP, je als gebruiker overal een mening over mag hebben maar het pakket dicteert de structuur.
Denk even aan de UWV casus van een paar jaar geleden. Het project was oorspronkelijk gepland voor, ik dacht, 6 miljoen. De stekker werd eruit getrokken bij een besteding van bijna 90 miljoen terwijl de laatste onzekere raming uitging van 125 miljoen.
Het project werd beschreven als integratie van IT systemen en het falen werd toegelicht door de hoogste ICT baas. Voor mij geen verdere toelichting nodig: doel en middel zijn weer eens verward.
PS: n.a.v. jouw op tijd en binnen budget opmerking. Randstadrail en Heathrow T5 leverden op tijd en binnen budget op. Vervolgens brak de hel los. In zijn standaardwerk over Project Based Work schreef J.Rodney Turner over een onderzoek in Australië, begin jaren 1990. De conclusie was dat ALLE bekeken projecten die op tijd en binnen budget eindigden na vijf jaar werden gezien als mislukt! De kosten/tijd discussie is goed voor routine werk, dat is betrouwbaar te plannen. In een project moet je ook andere factoren in ogenschouw nemen.
Zoals Randstadrail, Heathrow T5, Betuwelijn en vele andere voorbeelden aantonen: een project sturen op ALLEEN tijd en geld is dodelijk.
Natuurlijk weet de opdrachtgever meestens niet precies hoe zijn wensenboekje zodanig in te vullen dat zowel zijn businesscase als het IT project er ondubbelzinnig in zijn gevangen. Van zijn businesscase mag je veronderstellen dat ie alles af weet, alhoewel dat ook niet altijd zo is.
De eerste eis die je aan een GOEDE leverancier van een GOED IT-product mag stellen is dat ie de opdrachtgever helpt bij het goed formuleren van zijn wensen. Hij let daarbij op cause & effect, plausibiliteit en consequenties in tijd, geld, capaciteit en proces-performantie. De performantie van de businessprocessen van de opdrachtgever die IT ondersteund moeten gaan worden bedoel ik dan. Indien noodzakelijk laat hij zich bijstaan door terzake deskundige proces engineers, marketeers etc.
Als de IT leverancier dat niet kan moet ie zijn huiswerk doen. Als ie het wel kan maar denkt in uren x tarief (werkgelegenheid & kassa) of "na ons de zondvloed", dan verdient ie solide strafpunten. Het kan betekenen dat ie een van zijn concurrenten moet adviseren.
De IT leverancier heeft dan gewoon goed verdiend (uren x tarief) en de klant moet snappen dat het voorwerk noodzakelijk en critisch en 100% resultaatbepalend is en dat daarvoor gewoon betaald moet worden. Als ie dat snapt betaalt ie ook gewoon. Als ie het niet snapt kun je wel leveren, maar da's nie mooi en keert zich op den duur tegen de IT leverancier. Als je het niet doet, ben je gewoon een boormachine verkoper: "Hier heb je je boor, de gaten moet je zelf maken".
Dames & heren IT-ers: doe dat nou gewoon, want je hebt als groep al een slechte naam.
Groet,
Jos Steynebrugh
Marketing & Innovatie Consultant
Al die open deuren, maar de gemiddelde ICT-er blijft maar met zijn neus tegen die dichte deur aanlopen...
Trouwens, ook die inkoper van een overheidsinstelling die volgens (zijn versie van) de Europese aanbestedingsregels werkt. Een vage beschrijving van de verwachtingen maar toch een fixed time/price eisen. En natuurlijk heel, heel veel nadruk op onbelangrijke eisen (grootte leverancier, omzet van de afgelopen jaren, etc).
En uiteindelijk afrekenen op prijs alleen: de goedkoopste!
En er dan van staan te kijken dat projecten niet veel opleveren, na afloop veel onderhoudskosten eisen en (!) ongewenst gedrag van leveranciers wordt afgedwongen (bouwfraude affaire), dit alles door (de toepassing van) aanbestedingsregels.
Dus nog een gezellige open deur. Het blijft tochten. En er blijven mensen tegen gesloten deuren aanlopen...
En wat dat precies weten van de Business Case betreft: dat is de boekhouders perceptie. Die willen altijd een sluitende business case, zoals de minister van Financien bij de Betuwelijn. Maar met gezond verstand weet je dat een business case flexibel is en zich tijdens een project zal ontwikkelen. En zolang zaken binnen de tolerantie blijven, is dat acceptabel.
In het artikel wordt gemeld dat het falen aan opdrachtgever of aan IT-leverancier ligt. Er mist gewoon een laag.
Tussen opdrachtgever en IT-leverancier zit een projectmanager. De projectmanager is vanuit de business kant verantwoordelijk voor het project en het slagen ervan. Business cases worden door de (business) projectmanager gecheckt, niet door de IT-leverancier. De projectleider moet de bedrijfssituatie kennen en met de projectmanager aan de IT-kant kunnen sparren.
En het is geen CIO, want dan schuift de verantwoordelijkheid weer naar de IT-hoek.
Frappant is dat vaak de projectmanager aan leveranciers kant gezien wordt als DE projectleider. Zoals Viergever al duidelijk aangeeft, heeft een leverancier andere belangen dan een klant. Het enige gemeenschappelijke is het succes van het project en hoe dit succes ervaren wordt is voor de klant anders dan voor de leverancier.
Als een klant geen krachtige en ervaren projectmanager aan de business kant heeft, dan huur een goede in die onafhankelijk van de IT-leverancier is. Een projectleider die ook bij de opdrachtgever de focus op het project houdt, want achteroverleunen als de IT-leverancier na veel moeite gekozen is, is er tijdens het project niet bij.
Verder vind ik dat het niet alleen aan de opdrachtgever is om duidelijker te zijn, maar ook aan de leverancier om duidelijkheid te eisen. Beter langer doorgaan op helder krijgen wat het resultaat moet zijn dan maar beginnen en wel zien. En als een opdrachtgever echt niet weet wat hij/zij wil, stel een prototype voor als start. Dat geeft vaak op snelle wijze een goed idee van wat er gewenst is.
Jeanine Hendrikx
Business consultant
wat ik bedoel met “Businesscase” is de het strategisch marketingplan van de opdrachtgever. Hij moet weten wat zijn klanten EN potentiële klanten in 2000-nu willen en een goed vermoeden over wat die over 3 jaar waarschijnlijk zullen willen. En of ie daar in wil voorzien. Dat zijn strategische keuzes die zich 1:1 vertalen in ondersteunende bedrijfsprocessen. Pas daarna komt IT als ondersteunende functie aan de orde. Volgend dus en niet leidend.
Ik heb gezien dat veel IT leveranciers de cruciale topics uit een branche niet kennen en TOCH hun software plus diensten willen slijten. Maar ik heb ook gezien dat een bedrijf vindt dat zijn processen zo bijzonder zijn dat ze niet naar de software toe wil reorganiseren. Dat, terwijl de softwareleverancier soms (bijvoorbeeld SAP) het probleem al vele (of vele duizenden malen) heeft getackled en daaruit een brancheoplossing heeft geboetseerd. Als de opdrachtgever hardnekkig niet willen “volgen” dan is dat vaak eigen schuld, dikke bult.
Paradoxaal hierbij is dat hoe slechter het afgeleverde product, hoe meer de kassa tikt door ondersteuning (uren x tarief). En dat laatste is een héééle kwalijke zaak.
Groet,
Jos Steynebrugh
Het is toch vreemd dat we zo veel geld spenderen aan het ontwikkelen of aanschaffen van een projectmanagementmethode, aan het certificeren van al onze projectmanagers en last but not least aan het aanschaffen van de meest geavanceerde projectmanagement software. En toch gaat er na al die jaren nog zoveel mis. Ligt dat inderdaad grotendeels aan de opdrachtgever?
Wel hier komt mijn nieuws: Het falen van projecten ligt aan de factor mens in het project! Ofwel de mate waarin de soft skills in balans zijn met de hard skills van projectmanagement.
En we kennen veel mensen in een projectorganisatie: inderdaad de opdrachtgever maar ook een scala aan andere stakeholders. We kennen programma managers, project managers, projectleden en project sponsoren. En vervolgens groeperen we al deze mensen, die vaak nog nooit met elkaar hebben samengewerkt, in een tijdelijke (project)organisatie en verwachten we de grootste wonderen.
Waarom kennen we in elke reguliere organisatie een scala aan (HRM) instrumenten die er op gericht zijn om een organisatie effectief te laten functioneren en verwachten we dat een tijdelijke (project)organisatie dat vanaf dag 1 vanzelf doet?
Terug naar de strekking van het artikel. Als het falen van projecten inderdaad grotendeels ligt aan de opdrachtgever, dan heb ik de volgende mens-georienteerde projectvragen:
- hoe heeft de projectorganisatie de opdracht van de opdrachtgever vertaald naar een goed doorleefde projectmissie inclusief de vertaling naar projectresultaat en resultaat voor de opdrachtgever?
- hoe hebben we de besluitvormingscriteria waarmee het project door de opdrachtgever is goedgekeurd vertaald naar projectvoortgangscriteria, zodanig dat deze criteria centraal blijven staan in de projectbesturing?
- hoe hebben we de opdrachtgever betrokken in projectbesturing en besluitvorming?
- hoe hebben we de belangen van de opdrachtgever en die van de andere stakeholders vertaald naar een gemeenschappelijk belang?
- hoe hebben we dit gemeenschappelijke belang centraal gesteld tijdens alle projectfasen en bij alle projectbetrokkenen?
- hoe hard hebben we de opdrachtgever durven sturen op 'scope creep'?
- welke afspraken hebben we met de opdrachtgever gemaakt en welke verwachtingen hebben we naar elkaar uitgesproken? Hoe hebben we dit gedurende het gehele project bewaakt?
- in hoeverre hebben we op basis van vooraf gedefinieerde criteria de projectafsluiting met de opdrachtgever doorlopen?
- in hoeverre hebben we de projectorganisatie begeleid om uberhaupt met de opdrachtgever te durven en kunnen communiceren?
Moraal van dit verhaal: vindt een balans tussen de project hard- en soft skills om de projectslagingskans substantieel te vergroten.
Stef de Bont
www.effectif.nl
Natuurlijk is dit een punt. Zeker bij de overheid mislukken projecten door slecht opdrachtgeverschap waardoor al niet zo best opererende leveranciers gedwongen worden nog slechter te presteren. O.a. aanbestedingsregels lokken dit uit, dwingen dit zelfs af.
En inderdaad, Jos, ik heb het zelf meegemaakt bij een grote ICT consultancy dat ik een verliesgevende offerte moest opstellen. Dat maakte niet uit, de eisen waren zo vaag en zacht dat de leverancier met rommel zou wegkomen. De winst zou later bij het onderhoud wel gemaakt worden.
Echt gebeurd en ik vond / vind het schandalig. Maar dat werd destijds door de aanbestedingsprocedure en de inkoopafdeling afgedwongen.
Zowel opdrachtgever a;s leverancier gedragen zich slecht. Probeer het maar eens te doorbreken. Ik zou niet weten hoe. Maar het initiatief moet, denk ik, bij de opdrachtgever liggen.
Als onafhankelijke heb ik het jaren vergeefs geprobeerd; geen doorkomen aan.
De verantwoordelijkheid ligt toch echt bij de leverancier om ervoor te zorgen dat de klantvraag in eerste instantie duidelijk wordt geformuleerd en vervolgens passend wordt ingevuld. Wanneer je aan de slag gaat zonder zeker te weten wat een klant nodig heeft en vervolgens ook niet in staat bent dat snel te achterhalen, geef je gewoon een brevet van onvermogen af. Wat dat betreft ben ik het volledig met Jos eens en spreekt vooral de formulering van Stef zijn "projectvragen" aan, want hij heeft het over "we" en slaat daarmee terecht de spijker op de kop van de opdrachtnemer.
En laten we nou niet gaan klagen over inkopers die de duimschroeven aandraaien. Dat is gewoon hun vak en het is de verantwoordelijkheid van een leverancier om duidelijk aan te geven wanneer de eisen conflicteren met de gevraagde oplossing.
Groet,
Mike Moolenbel
Wel eens met een openbare aanbestedingsprocedure te maken gehad? Duidelijk niet. Bij mijn eerste keer had ik dezelfde reactie tot iedereen om mij heen begin te lachen om mijn naïviteit.
Ik kreeg een pakket van eisen wat enorm abstract en boterzacht was, dus ik wilde een afspraak maken om duidelijkheid te verkrijgen. Maar als onderdeel van de procedure is overleg verboden! Alle potentiële leveranciers mochten hun vragen inzenden waarna in een open zitting antwoord werd gegeven. Geheel voorspelbaar leek deze sessie op een pokertoernooi; alle potentiële leveranciers lieten niet het achterste van hun tong zien om hun concurrenten niet wijzer te maken. Deze sessie was dus zinloos en de eisen bleven vaag.
Het resultaat: weer een falend project.
. . . . De winst zou later bij het onderhoud wel gemaakt worden . . . schrijf je
Dat is BLOEDLINK!!!
Case (echt gebeurd)
Keurige offerte voor 600 hele dikke moddervette PC's bij een account dat we al hadden, maar waar we de deur naar de concurrentie hermetisch wilden afsluiten.
Gesprek tussen inkoper en verkoper. Jullie zitten te hoog. Intern overleg. Verkoper nogmaals naar inkoper, nu met de instructie WAAR zitten we te hoog?
Passen, meten en nogmaals. Lang verhaal met als slotsom: hardware met negatieve marge, software met een forse korting en diensten idem. Offerte wordt bijgewerkt. Totale prijs ONDER de kostprijs. Geeft niet, halen we wel terug met helpdesk en opleidingen.
Sure kregen we de opdracht, maar dan zonder de opleidingen. Die gingen ze zelf doen (train the trainer programma). Dikke vette niet-coole pech. Resultaat: wèl de omzet, maar met zwaar negatief resultaat. De verkoper bleef er stoïcijns onder: "Diebinnebennebennebinne".
Dat beaamde de verkoopleider, maar NIET de financiado.
De flessen bubbeltjes gingen open, maar géén echte champagne deze keer.
Groet,
Jos Steynebrugh
Marketing & Innovatie Consultant
Outsourcing, maatwerksoftware ontwikkeling, standaardsoftware implementatie zijn drie typen projecten die alle een eigen dynamiek en dus ook een eigen besturing vragen.
Maar wat altijd geldt is dit:
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 'natuurlijkheden' eerder uitzondering dan regel zijn en dus is het pleidooi voor een opdrachtgever die niet alleen verantwoordelijk is, maar ook verantwoordelijkheid neemt, volledig op zijn plaats.
Een dergelijke opdrachtgever zal zich dan ook omringen met deskundigen op het terrein van de gewenste IT oplossing, op het terrein van de organisatie waarbinnen het project zich afspeelt en op het terrein van het uitvoeren van het project zelf.
In Prince2 termen noemen we dit een stuurgroep of project board waarin behalve de opdrachtgever (Business Executive) ook de Senior User (vertegenwoordiger met mandaat van de gebruikersorganisatie) en de Senior Supplier(s) (vertegenwoordiger(s) met mandaat van interne en externe leveranciers) zitting hebben.
Deze personen dienen zodanig gemandateerd te zijn dat zij zelfstandig alle beslissingen die in de loop van het project aan de orde kunnen komen kunnen nemen zonder te worden teruggefloten.
De projectmanager/leider treedt in dit gremium op als procesbegeleider en zorgt dat alles wat ter tafel moet komen voor een succesvol verloop van het project, ook daadwerkelijk wordt besproken en besluitvorming plaatsvindt.
Ethiek wordt 'natuurlijk' als je in een project board keihard met de gevolgen van eventueel on-ethisch gedrag wordt geconfronteerd en je ten overstaan van je 'peers' met de billen bloot moet.
Verantwoordelijkheid wordt 'natuurlijk' als de gevolgen van onverantwoordelijkheid elke vergadering expliciet worden gemaakt.
Weten wat je wil/nodig hebt wordt 'natuurlijk' als de gebruikers scope-creep of 'zwabberen' elke keer weer moeten uitleggen en onderbouwen.
Afwijken van de oorspronkelijke doelstellingen en eisen wordt natuurlijk als het voor iedereen in deze groep aannemelijk en aanvaardbaar wordt gemaakt waarbij de gevolgen (zowel financieel als organisatorisch als in de tijd) door een ieder worden onderschreven.
Zo leiden we toch ook onze bedrijven??!
Ben het met de stelling eens dat slecht lopende projecten (en niet alleen in de ICT) voor een belangrijk deel zijn terug te voeren op een gebrek een Goed Opdrachtgeverschap. Maar zolang een Business Manager niet wordt afgerekend op het invullen van de rol van opdrachtgever, zullen deze misstanden blijven bestaan. Bestuurders hebben dan ook zelf de sleutel in handen om hier verandering in aan te brengen. De “Sense of Urgency” ontbreekt echter. Blijkbaar hebben organisaties de financiele ruimte om deze misstanden te laten bestaan. In ieder geval wordt het belang van een goede invulling van de rol van opdrachtgever zwaar onderschat. Bij de Business Managers en bij hun bestuurders!
Hoewel de Business Managers, die de rol van opdrachtgever vervullen, geen verstand van ICT hoeven te hebben, moeten zij wel in staat zijn verandering én continuïteit te managen. Een opdrachtgever bevindt zich op het snijvlak van een staande- en een projectorganisatie. En hiervoor is wat meer kennis en ervaring nodig dan het managen van een afdeling. Te veel geld en energie wordt gestopt in het verbeteren van de kwaliteit aan uitvoerende (lees projectmanagement) kant. Beter is het om een deel hiervan te besteden aan het verbeteren van de kwaliteit aan opdrachtgevende kant. Dit levert aanzienlijk meer rendement op. Helaas nog teveel een taboe.
Derk Kremer - Specialist in Goed Opdrachtgeverschap
Ik ben van mening dat het doel van een onderneming het genereren van geld is nu en vooral in de toekomst. Dus, elk project moet erop gericht zijn om geld te genereren. Echter, de mogelijkheid om geld te genereren wordt beperkt door bestaande belemmeringen in de bedrijfsvoering. Dus, de meerwaarde van projecten moeten komen uit het feit dat het beperkingen opheft. Echter, om meerwaarde te realiseren, een bottom-line resultaat, is technologie noodzakelijk, maar niet voldoende. Immers, de grootste belemmeringen om de prestatie van de onderneming te verhogen en dus geld te genereren, zijn regels en procedures. Deze komen vaak voort uit huidige paradigma's. Eén van de grootste paradigma's is die van de kosten orientatie en de daarmee gemoeide locale efficienty syndroom. Alle onderdelen moeten efficient verlopen volgens dit paradigma. Maar, is dat wel noodzakelijk. Een bedrijfsketen is als een ketting en de sterkte van die ketting wordt bepaald door de sterkte van de zwakste schakel. Dus, alle andere schakels hebben een grotere sterkte, oftwel overcapaciteit. Dit is het eerste type belemmering waarmee bedrijven te maken hebben; fysieke belemmeringen. De belangrijkste les hiervoor is wat Deming ons trachtte duidelijk te maken en wel dat 'optimaliseren tot op ruisniveau niet alleen zinloos is, maar zelfs schadelijk. Zolang het systeem oscilleert binnen de grenzen van de ruis, zal elke vorm van ingrijpen de fluctuaties aleen maar groter maken'.
Een project moet er dus op gericht zijn oo de zwakke schakels en niet op alle schakels. Dit kostenparadigma heeft ertoe geleid dat projecten niet goed gescreened en geprioritiseerd worden en veelal gericht zijn op teveel schakels in de gehele keten. Het gevolg is een te brede scope, complexiteit en teveel "configuratie" en "features".
Met betrekking tot ERP Systemen, is het helaas ook nog eens zo, dat bedrijven één op één hun oude manier van werken overzetten op het nieuwe systeem. Mijn ervaring is dat dit dus niet leidt tot optimale bedrijfsprocessen. Men moet hierbij inderdaad best practice bedrijfsprocessen overnemen indien dit geen impact heeft op de competitive advantage en daar aanpassen waar nodig. Een van de belangrijkste reden voor het één op één overnemen van bestaande methodes en werkwijzen is het feit dat er in het verleden hiermee work-arounds zijn gevonden voor toen bestaande belemmeringen. Deze belemmeringen worden vaak veroorzaakt door bestaande regels en procedures. Dit is het tweede type belemmering. Dus, indien een project succesvol wilt zijn en de onderneming er profijt van kan hebben, moet er ook gekeken worden naar alle regels en procedures en indien nodig aangepast en/of zelfs verwijderd worden. En dit gebeurt dus vaak niet, met alle nare gevolgen van dien.
Indien dan ook nog niet de goede medewerkers op een project worden gezet en/of dat de meest capabele medewerkers slechts part-time worden ingezet, dan kan men er gif op innemen dat projecten ook nog eens niet op tijd en boven budget worden opgeleverd. Dit heeft te maken met het feit dat mensen die op projecten werken niet aan multi-tasking moeten doen, omdat het gevolg hiervan is dat men alle taken uitsmeert en dus de totale doorlooptijd toeneemt.
Een project kan dan ook alleen maar succesvol uitgevoerd worden, indien de juiste mensen op de juiste manier gepland en ingezet worden. Anders, krijgt men altijd te maken met overschrijdingen in tijd en geld.