Het aantal ict-vacatures is in het tweede kwartaal van 2012 gedaald met 22 procent. Na groei in het eerste kwartaal was in maart het aantal vacatures vrijwel gelijk aan dat van dezelfde maand in 2011. Daarna is het aantal vacatures fors gedaald. Alleen de vraag naar projectmanagers blijft overeind. Dit blijkt uit een analyse van detacheerder Yacht.
Het aantal vacatures voor de meeste ict-functies groeide begin dit jaar nog. Meest gezochte functies waren projectmanager, engineer en ontwikkelaar. De vraag naar projectmanagers blijft echter stijgen. Dit komt volgens onderzoeker Erik-Jan Monshouwer van Yacht doordat het voorjaar de periode is om projecten te starten. 'Het lijkt er op dat er meer projecten worden gestart dan een jaar geleden. Organisaties willen vervanging van systemen niet langer uitstellen. Juist nu willen ze de concurrentie voor blijven.'
De overheid staat volgens Moshouwer op het punt nieuwe ict-projecten te starten om te besparen en diensten digitaal aan te bieden. Er wordt een tekort aan goed gekwalificeerde ict-medewerkers op securitygebied gesignaleerd. 'Wij zijn van mening dat er voldoende capaciteit beschikbaar is in de ict-arbeidsmarkt en dat er ook voldoende ict'ers in zijn voor een nieuwe uitdaging. Het is echter de kunst ze te vinden, te investeren in eventuele opleidingen en ze naast goede arbeidvoorwaarden de juiste ontwikkeling aan te bieden in een arbeidsmarkt die minder fluïde is geworden', zegt Monshouwer.
Daling in alle branches
Vanaf april is de vraag naar ict'ers weggezakt en lijkt alleen nog de projectmanager (+30 procent) veel gevraagd. Vanaf begin dit jaar is er vooral een terugval in de vraag naar ict-managers (-46 procent), informatieanalisten (-41 procent) en testers (-30 procent). De functie ontwikkelaar neemt af met 3 procent, wat opmerkelijk is, omdat er in de eerste maanden van 2012 nog sprake was van een flinke toename. De daling van het aantal ict-vacatures doet zich voor in alle branches.
Verder blijkt dat er een verschil is in het aantal vacatures voor de functies projectleider en projectmanager. Volgens Monshouwer betekent dit dat er meer vraag is naar werknemers met een zwaarder profiel, met meer ervaring en specifieke kennis van een branche.
@Reza
Wellicht vakgenoten met gelijke inzichten? :p
Succes met je artikel! Ben benieuwd.
@PaVaKe @Reza ik ben het helemaal met jullie eens, maar alleen denk ik dat de scope breder is. Zo zijn aanvragen voor ontwikkelaars/testers/programmeurs/architecten ook steeds meer branche gericht en met indirecte verwijzingen naar het soort cultuur wat er heerst.
Dit betekent voor project managers, maar ook voor de andere beroepen die ik noem heel belangrijk is om een focus te hebben en niet te breed inzetbaar te zijn, want dan val je uiteindelijk overal buiten de boot.
Volgens mij is dit ook vaak een issue bij outsourcing. Requirements zijn zelden zo goed dat cultuur en branche kennis hierin al opgenomen is, waardoor je een grotere faalkans introduceert.
De basis van bovenstaand artikel kloppen wel maar het type projectmanager wat men vraagt is geheel afwijkend van hoe projectmanagement in mijn ogen ooit bedoeld is. Een projectmanager managet het project met zijn management vaardigheden. De projectmanager was een generalist die net genoeg van zijn projecten wist om zijn specialisten aan te sturen en een goed eindresultaat te behalen. De projectmanager die men op dit moment zoekt zijn specialisten die een project moeten gaan managen. Dat is mijn ogen een groot verschil. Samenvattend wil men in principe 2 voor de prijs van 1 en eigenlijk maar 1/2 betalen. Dit type technische projectleiders zoals men ze vroeger noemde zijn nu eenmaal beperkt. Een specialist met een Prince II opleiding of IPM is nog steeds geen projectmanager, deze vaardigheid moet je verkrijgen door ervaring. Helaas wordt de term projectleider/manager te pas en te onpas gebruikt waardoor de waarderingen ook zeer scheef lopen.
Er is niks mis met een breed inzetbare projectmanager als hij/zij maar zorgt dat hij de taal van zijn specialisten en klanten spreekt.
Het blijft een leuke discussie die alleen maar heviger gaat worden omdat de markt van generalisten naar specialisten gaat. Nog even wachten en we krijgen we het tegenovergestelde.
Vanwege de recessie is het een tijd waar veel bedrijven en organisaties de bakens moeten of willen verzetten en dus een tijd waar veel veranderingen geïnitieerd worden. Veel organisaties zoeken daarom veranderingsmanagers die goed in people management zijn, goed in business processen kunnen denken en goed kunnen communiceren. En dat kunnen instrumenteren via procesaanpak van moderne projectmanagement technieken.
Maar dus wel in die volgorde. Een projectmanager die slechts in het laatste kundig is is minder interessant. De relevantie van Prince2 versus IPMA is dus beperkt.
@zomaar anoniem:
wellicht was mijn reactie wat te kort voor je, maar wat het toevoegt, is het volgende, en het gaat dan met name om het manangen van communicatie-infrastructuur projecten:
Projecten managen allen op basis van proces en procedure is risicovol wanneer binnen tijd, budget en kwaliteit gebleven moet worden en wanneer het gaat om innovatieve projecten.
Projecten managen allen op basis van proces en procedure is ook risicovol wanneer het project ook als opleidingstraject voor de mensen zelf is bedoeld, als een soort training on the job, zodat ze later het beheer van het eindresultaat ook zelf kunnen doen ipv overgeleverd te zijn aan die “externe(n)”.
Gaat het om “commodity projecten”, de 20 krentenbollen in een dozijn dus, dan zal het wel lukken met de procedure principes van Prince 2 e.a. projectmanagement gereedschappen.
Daarnaast, en dat geldt niet alleen voor dit soort type projecten, ook het aansturen van een leverancier vanuit de klant kost niet alleen tijd, maar voor al ervaring, soms is het meer een schaakspel, wie kan de meeste zetten vooruit kijken …
Mocht je daar meer over willen weten dan zie ik dat wel in een zm. ano. comment van je, ook weer goed voor de “ranking” waar je je zorgen over maakte.
Er wordt erg weinig om projectmanagers gevraagd, des te meer om technisch teammanagers (in PRINCE2 termen). Hierdoor ligt de nadruk op de techniek en technische vaardigheden, niet op het managen van de omgeving en de lange termijn. In het beste geval zal de operatie slagen maar is de patient overleden.
Bovenstaand wordt PRINCE2 nog al eens aangehaald. Een ICT projectmanager bestaat om de redenen die ik genoemd heb niet. Ook een PM van de leverancierskant heeft weinig tot niets te maken met PRINCE2, wat veel van PRINCE2 “specialisten” uit de ICT hoek ook beweren.
Tenslotte is het in de PRINCE2 visie terecht volslagen onlogische onzin dat een project op tijd en binnen budget moet eindigen om geslaagd te zijn.
Ten eerste is een project relatief onvoorspelbaar, en daarmee is de tijd en geld planning ook niet meer dan dat: een planning. Nooit volledig correct dus.
Ten tweede gaat PRINCE2 uit van niet de drie bekende variabelen tijd geld en kwaliteit (waarbij kwaliteit meestal het kind van de rekening wordt), maar van zes. Naast de drie genoemde variabelen moet er een gezonde balans zijn tussen scope, risico en verwachte baten. Alleen al om deze reden zijn er geen ICT projecten of ICT projectmanagers.
Wisselende reacties op een simpel artikel. De enige zinnige reactie is die van Wil. Vreemd genoeg blazen de “huisreageerders” hier volledig aan voorbij met standpunten over projectmanagers die inhoudelijk onderlegd moeten zijn, onderbetaald worden en allerlei blabla over branchekennis, moderne managementtechnieken etc.
Laten we even terug gaan naar de basis, de definitie van een project (Bron: De ISM Methode, Hoving en Van Bon): Een tijdelijke organisatie met mensen en producten, om een doelstelling mee te realiseren. Met o.a. de toevoeging: Een project is eenmalig, gericht op de verandering van een situatie.
Het realiseren van een doelstelling lukt alleen als alles er op gericht is aan de voorwaarden te voldoen om die doelstelling te kunnen halen. Dat begint bij het vaststellen wat je wilt veranderen, hoe je het wilt veranderen, waarmee je het wilt veranderen en wat het resultaat moet zijn. Het doorvoeren van de verandering zelf is een tamelijk generiek proces dat altijd en overal op hetzelfde neerkomt. Een projectorganisatie op zichzelf maakt daar een afspraak over, levert wat is afgesproken, documenteert wat is gedaan en wordt weer opgeheven.
De ideale situatie is dus dat van te voren vaststaat wat het resultaat zal zijn, dat de juiste beslissingen zijn genomen, c.q. keuzes zijn gemaakt, dat de juiste mensen beschikbaar zijn en dat het budget toereikend is.
De werkelijkheid is dat ergens in het traject, doorgaans aan het begin, onvoldoende aandacht wordt besteed aan de te maken keuzes en vooral aan de consequenties daarvan. Als gevolg daarvan is er een soort cultuur ontstaan die zegt dat projectmanagers vooral goed moeten kunnen manoeuvreren binnen de organisatie waar zij actief zijn. Het komt dan minder aan op de managementkwaliteiten en meer op het vermogen (politieke) verhoudingen in te schatten en in staat te zijn de oorspronkelijke projectdoelstelling zo pijn- en geruisloos mogelijk bij te stellen.
Dus in plaats van het probleem aan te pakken aan de basis (de te maken keuzes) gaan we andere eisen stellen aan degenen die het project moeten managen, in de verwachting dat we dan een project alsnog tot een goed einde kunnen brengen, ook al is dat niet wat er oorspronkelijk was bedoeld. Goed beschouwd is dat waanzin en wordt het paard achter de wagen gespannen.
Toch komt in de reacties naar boven drijven dat dit allemaal heel normaal is. De ongetwijfeld professionele projectleiders weten inmiddels niet beter meer dan dat het managen van een project vaardigheden vraagt die eigenlijk helemaal niet bij een projectmanager horen. Door dit iedere keer te bevestigen zullen bedrijven de fouten blijven maken die tot deze situatie en stellingname hebben geleid en verandert er dus in wezen niets. De kans dat het erger wordt is eerder groter dan kleiner.
De oplossing is even eenvoudig als dat ze lastig is om te realiseren: zorg dat bedrijven aan begin van het traject volledig zicht hebben op de consequenties van de keuzes die ze maken. Dat vraagt om awareness, om “het begrijpen van”. Het begrijpen van de eigen organisatie en met name de wijze waarop zij werkt, het begrijpen van de eisen die die werkwijze stelt aan ICT en de wijze waarop ICT die werkwijze kan ondersteunen en tot slot wat de effecten van wijzigingen hebben op de eigen werkwijze zowel als op de wijze waarop de ICT de organisatie ondersteunt.
Wie dit weet te bereiken kan straks bij een project weer een “ouderwetse” projectmanager inzetten zoals Wil die beschrijft.
@hk: Als huisreageerder wil ik je best van wat repliek dienen.
Ten eerste, de reactie van Wil was *na* de reactie van de huisreageerders, niettemin een heerlijke opmerking 🙂
Je reactie is interessant, doch off topic. Je haalt overigens de definitie van een project aan, maar vervolgens laat je het na om een definitie te geven van een projectmanager en verwijs je naar een vaag begrip “projectorganisatie”.
Ik vind de definitie van een project aardig en treffend en je betoog is overtuigend, alleen verschil ik wat van mening en inzicht en ga je voorbij aan de realiteit zoals deze nu is. Als je alle voors en tegens van een project afgekaart wil hebben (en voortschrijdend inzicht wil voorkomen), wordt er geen project meer gestart. Een project leiden tot een goed eind kan generiek zijn en zou in mijn ogen ook bepaalde vaste kenmerken moeten hebben. Maar projecten waarbij de managers van een project geen inhoudelijke kennis hoeven te hebben, leidt zoals Wil schrijft tot situaties waarbij de opdrachtgever 2 voor de prijs van 1 wil hebben. In de praktijk zie je zelfs dat projectmedewerkers hun werk in de lijn ook nog gewoon erbij moeten doen. Is dat onhandig? Zeker. Draagt het bij aan het mislukken van projecten? Absoluut! Maar het is wel de realiteit dat enerzijds de budgetten krap zijn en Nederlanders een volk zijn met een groot oplossend vermogen. Ik ken zeer veel projecten die niet de schoonheidsprijs winnen, maar wel geleid hebben tot (positieve) veranderingen en dat er met minder budget meer werk verzet is.
Je kunt dus wel vinden dat projecten volgens het boekje worden opgezet en afgewerkt, maar uiteindelijk (en nu kom ik weer terug on topic) zul je dus waarnemen dat de generieke project manager steeds minder werkt heeft en er gezocht word naar mensen met specifieke (branche) kennis.
Wat je eigenlijk beschrijft is het verschil tussen het waterfall model versus agile. En tegenwoordig -dit is misschien en op en neergaande trend- is agile toch echt populairder.
@Henri Koppen: Dank voor je reactie. Mbt de verwijzing naar Wil heb je gelijk – ik moet mijn eigen redactie wat beter doen. Overigens, ik had niet het idee dat ik “off topic” reageerde.
Het artikel vermeldt dat het aantal projecten stijgt omdat organisaties hun systemen willen vernieuwen. Als we ons op dat gegeven concentreren dan is het belang dat de juiste kennis en knowhow wordt gereserveerd of ingehuurd. Dan hebben het nog steeds over specialisten, maar nog steeds niet over de projectmanager… tenzij je die verantwoordelijk maakt voor de werving en inzet van resources voor het project en van hem verwacht dat hij ook de (tussen)resultaten inhoudelijk kan beoordelen (naast dat hij politiek correct handelt en iedereen tevreden houdt). Ik blijf erbij dat dat verder gaat dan de essentie van projectmanagement: het aansturen van projecten en dus niet het uitvoeren ervan).
De definitie van een projectmanager is tamelijk generiek: verantwoordelijk voor het resultaat van een project door het aansturen (managen) van de projectmedewerkers, het zorgdragen voor planning en coördinatie van en communicatie over het project.
Het in kleine iteraties opdelen van projecten om snel werkende functionaliteit op te leveren verandert weinig aan het proces. Het proces wordt slechts sneller en in kleinere sequenties herhaald, al dan niet door meerdere kleine en parallel werkende teams. Daarmee blijft overeind dat de basis van elke sequentie in orde moet zijn, er inzicht is in de consequenties van gemaakte keuzes en daarmee zicht op het te behalen resultaat.
Ik ga er in mee dat agile populair is. Een van de voordelen ervan is dat er op basis van de resultaten uit de eerste sequenties, sneller gereageerd kan worden op (onverwachte) impact van het resultaat. Je zou ook kunnen stellen dat agile een natuurlijke oplossing is op het onvermogen om in grote projecten adequaat te reageren op voortschrijdend inzicht. Mijn observatie is dat agile neerkomt op het ontrafelen van een beoogd resultaat in kleine wijzigingen in functionaliteit (terwijl in projecten juist sprake is van een bundeling van wijzigingen). En dat uit zich in het continu doorlopen van het changeproces. Welbeschouwd heb je daar geen projectmanager meer voor nodig en kun je volstaan met een goede changemanager.
Tenslotte, niet alle projecten lenen zich even goed voor agile en dat heeft sterk te maken met de aard en grootte van het project: wordt er nieuwe software gebouwd, een nieuwe infrastructuur neergelegd, is het een conversie, een migratie of gaat het om de verandering van (beheer)processen. Daarnaast speelt de doelstelling of het beoogd resultaat van het traject een rol: is het wel of niet scherp gespecificeerd, van buitenaf vastgesteld of opgelegd (wet- en regelgeving) etc.
Boeiend blijft het, dat is zeker.