Een mislukt project kan jou of andere leidinggevenden immers de verkeerde conclusies laten trekken. Zoals William Yasnoff, een projectmanager bij een Amerikaans ziekenhuis, in een college aan de Universiteit van Washington zegt in zijn inleiding: Je moet een motorblok niet door je coureur laten ombouwen, hoe ervaren die coureur ook moge zijn.

Als concreter, waargebeurd voorbeeld noemt hij een geval waarbij een van de tandartsen van een zorginstelling verantwoordelijk werd gesteld voor de implementatie van een systeem voor beeldscanning. Gevolg: niets werkte, en het project was een waar afvoerputje voor budget.

Voor beide voorbeelden geldt dat al snel de verkeerde gevolgtrekking wordt getrokken: 'Het ombouwen van een motorblok is riskant' of 'beeldscanning-technologie is riskant'. Nee: voor beide projecten geldt dat ze riskant zijn als niet de juiste mensen op het project worden gezet.

Om die reden noemt Yasnoff vijf bekende valkuilen die je als projectmanager beter kunt omzeilen. Allemaal hebben ze te maken met je interactie met de ict'ers in je projectteam.

Valkuil 1: 'Het kan niet.'

Je zult niet de eerste zijn die nagaat bij een ict'er of een project uitgevoerd kan worden, om als antwoord nul op het rekest te krijgen. Maar de beruchte woorden 'Nee, dit kan niet' of 'Onmogelijk' zijn zelden accuraat.

Dikwijls bedoelt de ict'er in kwestie een van de volgende vier dingen te zeggen:

“Ik weet niet hoe het moet.”

“Dit project vergt te veel werk.”

“Ik ben bang dat het gaandeweg een zootje wordt."

“Het gaat te veel kosten.”

Deze opmerkingen zijn een stuk minder definitief dan de frase 'Het kan niet'. Vraag dus een beetje door: Waarom niet? Waar zie je beren op de weg? Wat moet er in jouw ogen veranderen?

Weet deze persoon domweg niet hoe het moet, dan ga je op zoek naar iemand die het wel weet. Bij het eigenlijke antwoord nummer twee volstaat een simpele uitbreiding van het team (of een goede schop onder de kont als deze persoon bewezen heeft lui te kunnen zijn). Bij de derde optie gaat het domweg om geruststelling, terwijl het bij de laatste antwoordmogelijkheid simpelweg niet de positie van de ict'er is om te bepalen of iets te veel kost. Deze persoon moet slechts uitvoeren. Laat iemand anders zich bekommeren over het budget. Bijvoorbeeld een consulent.

Valkuil 2: Geen of verkeerd gebruik van consulenten

Er zijn goede redenen om een externe consulent in te schakelen, en niet alles over te laten aan je team ter plekke. Om te beginnen heeft een consulent een bepaalde expertise die maar weinig bedrijven in-house hebben. Het zal wel heel toevallig zijn als je binnen je bedrijf iemand hebt die bijvoorbeeld alles weet van ERP-software (enterprise resource planning) terwijl je deze nog niet eens hebt geïmplementeerd.

Dat is vaak dé reden om een consulent in te huren, maar het is zeker niet de enige en misschien niet eens de belangrijkste. Je moet niet vergeten dat werknemers bijvoorbeeld niet graag slecht nieuws overbrengen naar het management. Een consulent draait daar zijn hand niet voor om. Deze 'onpartijdigheid' kan een enorm positieve uitwerking hebben op het project.

Zorg er wel voor dat de consulent echt, écht, ECHT weet wat hij doet.

Valkuil 3: Verdrinken in technisch jargon

Niet alle projectmanagers hebben een achtergrond in de ict. Hoewel dit handig is, is het ook niet per se nodig. Maar je moet niet vatbaar zijn voor wat Yasnoff 'technische obfuscatie' noemt. Ict'ers drukken zich niet uit in functionele termen (zoals: 'we doen dit om deze reden') maar in technische termen (dus: 'we voeren techniek huppeldepup door om service X verder af te stemmen op engine Y').

Deze techniek wordt volgens Yasnoff door ict'ers toegepast zodat zij zelf kunnen bepalen wat ze gaan doen. Dat kan zijn omdat ze alleen dingen willen doen die ze leuk vinden, of om de werklast te verminderen. In ieder geval verlies je als projectmanager de controle over jouw project.

Om dit te voorkomen dien je heel duidelijk om uitleg te vragen. Eventueel neem je een consulent in de arm die het naar mensentaal vertaalt. Willen de ict'ers het niet uitleggen of kunnen ze het niet? Dan is er echt iets loos en kun je beter anderen op het project zetten.

Valkuil 4: 'Ik WIL het niet weten'

Deze hangt een beetje samen met valkuil 3. Een fout die vast zal hebben meegespeeld bij het voorbeeld van de tandarts die aan het begin van dit artikel is genoemd. Sommige managers zijn er namelijk trots op dat ze echte managers zijn, en geen techneuten. Van hun vakgebied weten ze alles, maar de techniek ontgaat ze. Dat is jammer, niet alleen voor henzelf en hun omgeving (niemand werkt graag samen met een arrogante kwal), maar vooral voor het project.

Iedere projectmanager moet ten minste een poging ondernemen een paar boeken te lezen over wat de techniek inhoudt. De bekende '...for Dummies'-boeken kunnen je al een heel eind op weg helpen. Nee, je bent niet automatisch immuun voor 'technische obfuscatie' (valkuil 3), maar je krijgt hierdoor wel een iets betere bullshit-voelspriet.

Valkuil 5: Een groot ict-team opsluiten in een ivoren toren

Het is schandalig, maar deze fout wordt nog steeds gemaakt. Ja, je moet ervoor zorgen dat je team groot genoeg is om het project aan te kunnen, maar je kunt ook overdrijven. Een klein team zorgt voor korte communicatie-lijntjes. Bovendien hoeft er minder doorgespeeld te worden omdat ieder teamlid automatisch een groter gebied bestrijkt van het project.

Daarbij moet je iets doen tegen de neiging van sommigen om 'niet gestoord' te willen worden: laat de teamleden vooral veel interacteren met de eindgebruikers. Vraag naar hun werkwijze, hun voorkeuren, hun wensen. Immers, een systeem waar de gebruikers niet mee overweg kunnen, is per definitie weggegooid geld.