Managed hosting door True

Tijdsplanning ICT-projecten rammelt

 

Meer dan de helft van de ict-projecten duurt langer dan gepland. Veertig procent is duurder dan gepland. De reden die het meest wordt genoemd voor het uitlopen van ict-projecten, namelijk door 36 procent van de ondervraagden, is een te krappe tijdsplanning.

56 procent van de ict-projecten waarvoor consulants worden ingehuurd duurt langer dan gepland. Veertig procent van alle ict-projecten is duurder dan gepland. Dat blijkt uit onderzoek door TNS NIPO in opdracht van Computable onder ruim tweeduizend ict'ers.

Van de projecten die duurder uitvallen dan gepland, is zes procent uiteindelijk minstens twee keer zo duur als aanvankelijk begroot. Ruim een kwart (zesentwintig procent) van de vertraagde ict-projecten loopt meer dan een half jaar uit.

De reden die het meest wordt genoemd voor het uitlopen van ict-projecten, namelijk door 36 procent van de ondervraagden, is een te krappe tijdsplanning. 26 procent schuift de schuld van de tijdsoverschrijding deels in de schoenen van de opdrachtgever: die zou niet duidelijk genoeg zijn. 23 procent noemt als medeoorzaak dat er te weinig rekening is gehouden met gebruikers.

Te weinig overleg met de opdrachtgever wordt door vijftien procent van de ondervraagden genoemd. Een zelfde percentage vindt dat vantevoren onvoldoende is nagedacht over het contract, met tijdsoverschrijdingen tot gevolg. Dertien procent van de ondervraagden wijt het mislukken van tijdsplanningen mede aan het feit dat de dienstverlener onvoldoende kennis en vaardigheden in huis had.

Wisselende consultants

Twaalf procent van de ondervraagden voerde andere redenen aan die ervoor hadden gezorgd dat hun laatste ict-project vertraagd was. Vaak blijkt er sprake van afhankelijkheden op allerlei gebied: van externe partijen en vanuit andere projecten. Ook hebben projecten te lijden onder capaciteitsproblemen. Zo meldt een respondent: "We hebben veelvuldig te maken gehad met wisselende consultants. Eerst werd het project volledig gerund door een Indiaas bedrijf. Daarna werd de analyse en ontwikkeling lokaal gedaan, bijgestaan door consultants van het adviesbedrijf." Andere respondenten noemen ‘ziekte bij dienstverlener', ‘te weinig capaciteit/prioriteit bij werkgever' of melden: ‘gedurende het project is de consultant twee keer gewisseld door de detacheerder'.

Capaciteitsproblemen worden ook op andere fronten gemeld. Zo is er ‘te weinig tijd om dienstverlener te ondersteunen door eigen mensen', of ‘een verdeling van de focus door andere ict-projecten' In sommige gevallen lijken ingehuurde bedrijven misbruik te maken van een gebrek aan sturing vanuit de opdrachtgever. Zo meldt één respondent dat zijn bedrijf te weinig ‘kennis in huis had'. Hierdoor ‘kon de dienstverlener alles voorstellen wat hij wilde'.

Onderschatting is een ander euvel dat veel door respondenten wordt genoemd als oorzaak van het vertragen van projecten. Respondenten hebben het over ‘onderschatting van de dienstverlener over de grootte van het project', ‘onderschatting van de documentatie en het testwerk'en ‘de dienstverlener schatte het project gemakkelijker in dan het was'.

Ook wordt vertraging opgelopen doordat opdrachtgevers in eerste instantie niet tevreden zijn met de voortgang van ict-projecten. Zo melden respondenten dat projecten uitlopen vanwege de ‘kwaliteit van het geleverde product', of omdat ‘de leverancier onvoldoende kennis had van wat er precies werd verwacht'.

TNS NIPO

In augustus 2008 voerde TNS NIPO in opdracht van Computable een onderzoek uit naar de ervaringen van ictprofessionals en -beslissers met consultancy. Hiervoor werden circa 20.000 ict'ers benaderd en reageerden er 2167 op het verzoek om online een enquete in te vullen over hun ervaringen met consultants. De deelnemers werden verwezen naar een speciale website waarop zij de vragenlijst konden invullen. Vervolgens werd de deelnemers een serie vragen voorgelegd over hun motieven om en de omstandigheden waaronder zij een ictadviesbedrijf hebben ingehuurd.

Consultancy Guide 2009

Dit artikel is onderdeel van de Consultancy Guide 2009. Deze gids geeft een overzicht van de trends en ontwikkelingen op de Nederlandse markt voor consultants. Daarnaast bevat de gids de resultaten van een onderzoek, uitgevoerd door TNS NIPO, naar de ervaringen van ict'ers met consultants. De Consultancy Guide 2009 verschijnt op 19 december 2008 in druk.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/2793407). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Ik mis voor mijn gevoel een oorzaak:

De meeste afgegeven planningen en/of offertes zijn verre van realistisch. Veel bedrijven zetten laag in (op prijs) om zodoende een opdracht binnen te halen.

Of, zoals onlangs mooi verwoord werd op een lezing waar ik was:

"You lie yourself in, and negotiate yourself out"

Op het moment dat een softwarehuis een offerte af gaat geven gebaseerd op realistische kostenschatting en planning, halen ze niets meer binnen.....

IN die zin zijn ICT bedrijven gewoon aannemers. En we weten hoe goed aannemers met hun deadlines en budgetten omgaan?! Noord Zuid lijn? Betuwelijn? Rijksmuseum?

Ik ga voor degelijke goede duurzame productem en kwaliteit.Dat betkend ook in de ICT dat je een ruim kader en kosten berekend en dan krijg je kwaliteit wat uiteindelijk een degelijker resultaat en kostenbesparend resultaat geeft.Als je alles op de milimeter afsnijdt gaat het mis.Je kunt 1 dure jas kopen of drie keer naar de markt.Uiteindelijk ben je met die dure jas goedkoper uit dan met die 3 maak goedkoop op de markt, als je inmiddels al niet aan de vierde jas van de markt toe bent


L.S.,

Wat mij opvalt is dat er geen 100% uit de aangedragen redenen tot uitlopen op de planning van projecten komt. Het gaat slechts om 128% van de 100%, hoe kan dit?

Met vriendelijke groet,

A.Sigterman

@Arie Sigterman. Goed gezien. De reden hiervoor is dat respondenten meer dan een reden mochten aankruisen uit een lijst.

In Nederland in de ICT wordt gewoon te langzaam gewerkt en te weinig gebruik gemaakt van agile programming technieken. Zo worden we weggeconcureerd door India en China. Bij ons zijn alle producten altijd op tijd af, en als dat niet lukt, dan werk je door in je eigen tijd want het is, terecht, jouw verantwoordelijkheid. Kan je niet op tijd leveren, dan ben jij de eigenaar van het probleem, niet de klant.

Ik vind dit artikel wel erg eenzijdig de schuld leggen bij de leverancier. De klant (lees opdrachtgever) speelt ook een grote rol bij het slagen dan wel falen van een project. Vaak genoeg zie je dat een opdrachtgever aan een project begint zonder een helderde doelstelling voor ogen. M.a.w. je kunt niet sturen als je niet weet waar je uit wilt komen. Daarnaast komt het maar al te vaak voor de projecten door de opdrachtgever zelf gesaboteerd worden, vanwege interne belangen verschillen.

Ja het is ook geen stenen leggen, software maken!! Het maken van een software oplossing is misschien meer als het maken van een puzzel. Je weet niet precies wanneer je de juiste oplossing gevonden hebt. Je kunt dat wel enigzins schatten, maar meer niet. Het is geen rechtlijnig productie proces waar alle invoer en uitvoer en doorstroming van te voren bekend is. Het is niet te voorkomen dat planningen de mist in gaan. Dat is inherent aan ICT, je hebt pro def te maken met nieuwe tools die je nog niet helemaal kent, problemen die je nog niet helemaal hebt geanalyseerd. Alsof Einstein wist wanneer ie de relativiteits theorie af had, om maar eens een wat rare, maar zeker niet zinloze, vergelijking te maken.

Uit ervaring kan ik de volgende oorzaken:
- Slechte projectmanagers
- Incompetentie projectmedewerkers
- Te veel vergaderen ivp. aan het werk te gaan
- Consultants die altijd denken dat de opdrachtgever dom is terwijl dat vaak andersom is.
- Handhaven van ouderwetse ontwikkelmethodieken

groet,

Om onduidelijke wensen en te strakke tijdsplanningen te voorkomen moeten de opdrachtgever en de leverancier eerst samen om de tafel om alles duidelijk te krijgen. Met het maken van een business case wordt duidelijk wat het project omvat. De opdrachtgever kan zijn wensen goed verwoorden en de leverancier kan realistische verwachtingen scheppen. Uit onderzoek van Pecoma Business Technology blijkt dat slechts in 57 procent van de gevallen altijd een business case wordt opgesteld, waardoor er nog in te veel projecten onduidelijkheid bestaat over de te verwachten resultaten.
De opdrachtgever en de leverancier committeren en investeren door middel van een business case beiden in een goed gedefinieerd probleem en een duidelijk plan van aanpak. Als leverancier moet je dan ook je verantwoordelijkheid nemen, mocht hier verandering in komen. Bij ons geldt afspraak = afspraak; als we ??n dag te laat zijn, betalen we de helft van het afgesproken bedrag terug. Je moet als dienstverlener echt voor een project willen gaan, anders moet je er niet aan beginnen.

Nog iets wat ik mis: wat is "te laat"? Als een project ongepland en ongestuurd uitloopt is er een probleem. Als er gedurende het project wijzigingen zijn en de opdrachtgever heeft inzicht in het gevolg van zijn wijzgingen en kan keuzes maken dan kan een project 2x zo lang duren dan initieel begroot maar toch een succes zijn. Met de ontwikkelstraat Endeavour van Info Support heeft de opdrachtgever continu zicht op de voortgang en kan hij waar nodig bijsturen. Daar is hij meer bij gebaat dan domweg op tijd opleveren terwijl voortschrijdend inzicht (en marktontwikkelingen) vragen om bijsturing.

Als we even gefocused blijven op de planning: het kan zijn dat er inderdaad te krap gepland is. Dit kan gebeuren om een project er toch "door te drukken". Opdrachtgever en opdrachtnemer zullen elkaar goed moeten begrijpen om tot een optimale en realistische planning te komen.
Een tweede belangrijke reden is tijdens de uitvoering van het project: te weinig aandacht is er voor het zogenaamde scope management. Gedurende het gehele traject zullen constant afwegingen moeten worden gemaakt over de scope. Continue de extra's strippen en bewaken van de kwaliteit Het hoeft niet direct perfect te zijn, maar wel werkbaar. Wederom een belangrijke taak voor opdrachtgever en opdrachtnemer (lees projectmanager).
Slechts 2 voorbeelden waar de relatie opdrachtgever/opdrachtnemer van cruciaal belang is. Zonder dat de opdrachtgever verstand van ICT hoeft te hebben overigens. Wij doen momenteel onderzoek naar de relatie tussen beide sleutelfiguren en hierin wordt bevestigd dat er een wereld van verschil is, maar krijgen ook een beter inzicht op welke onderdelen en waarom.
Wat betreft de wisselende adviseurs: zelf heb ik jaren in de rol van opdrachtgever gezeten maar ook in de rol van opdrachtnemer. In het laatste geval weet ik uit ervaring dat de opdrachtgever veel kansen laat liggen om bepaalde zaken af te dwingen richting (interne) leverancier. Hij of zij stelt zich te afhankelijk op en laat dit gebeuren. Iets strakkere regie en iets meer op je strepen staan levert veel op.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×