Managed hosting door True

'ICT-project wordt verkeerd aangestuurd'

 

Doordat ict-projecten voornamelijk gestuurd worden op tijd en geld, zijn bedrijven vaak ontevreden over het eindresultaat. Dit blijkt uit onderzoek van Blue Bricks in Research onder ruim negenhonderd managers. Het bureau deed onderzoek naar het succes van ict-projecten.

Ict-projecten worden als succesvol ervaren als aan de doelstellingen en verwachtingen wordt voldaan. Tijd en geld blijken minder belangrijk voor het resultaat van het project. Eerdere onderzoeken van Gartner en Ernst & Young wezen al uit dat meer dan de helft van de ict-projecten niet succesvol is. Blue Bricks in Research onderzocht de achterliggende oorzaken.

Succesvolle projecten

Op de vraag waarom een project succesvol is, geeft ruim 70 procent van de deelnemers aan dat het project aan de doelstellingen heeft voldaan. Het is opvallend dat slechts 20 procent van de projecten die als succesvol wordt gezien, binnen budget blijven. Net zo opmerkelijk is dat het overschrijden van een tijdslimiet zelden reden is om een project als minder succesvol te beschouwen. 75 procent van de succesvolle projecten wordt namelijk niet afgerond binnen de gestelde tijd.

Uit het onderzoek blijkt dat geld en tijd als weinig belangrijk worden ervaren. Dit zijn echter wel de belangrijkste stuurmiddelen bij projecten. Naast onderzoek naar stuurmiddelen als tijd en geld, onderzocht Blue Bricks in Research ook de invloed van verschillende managementstijlen op het succes van projecten. Tevens werd gekeken naar de invloed van methoden en technieken op het succes.

Methodiek en managementstijl

Op de vraag welke methodieken er worden toegepast bij ict-projecten, noemt ruim 89 procent van de deelnemers project- en programmamanagementmethoden als Prince 2 en MSP. Deze methoden richten zich voornamelijk op de formele kant van projectbesturing. Aanvullende methoden die zich meer richten op de inhoudelijke kant van projectbesturing, en daarmee meer bijdragen aan de realisatie van de project doelstellingen, worden in minder dan de helft van de gevallen toegepast.

Op de vraag welke managementstijl toegepast wordt bij de besturing van het project, geeft 86 procent van de ondervraagden aan primair een managementstijl te hanteren die gericht is op beheersing en controle. De managementstijl die primair gericht is op de inhoud en daarmee meer op realisatie van de doelstellingen, werd in minder dan de helft van de gevallen toegepast. Ook hierin bevestigt het onderzoek het beeld dat de praktijk van projectbesturing sterker gericht is op het behalen van resultaat dan op het behalen van succes.

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

?


Lees meer over


 

Reacties

Ter informatie: Het volledige onderzoeksrapport is opvraagbaar bij research@bluebricks.nl

Schokkende uitkomst, tenminste voor de projectmanagers die zich volledig vastklampen aan de methodiek en eigenlijk alleen aan procesmanagement doen. Als geld en tijd niet meer de belangrijkste stuurmiddelen zijn dan worden deze managers toch eigenlijk een beetje de projectlijders.

Opmerkelijke uitkomst! Fixed prijs en laagste prijs, zijn twee eisen die meestal door de opdrachtgevers aan de leveranciers gesteld worden. Wanneer je als leverancier je project hierop moet bouwen dan kun je zeker niet scope creep voorkomen. En als je met scope creep te maken krijgt dan heb je het over uitloop van de werkzaamheden dus niet afronden binnen gestelde tijd.

Als 70% zegt dat een project niet aan de doelstellingen (van de klant) heeft kunnen voldoen, dan zou de opdrachtgever moeten kijken of hij de juiste doelstellingen gesteld heeft en of ict als een middel deze had kunnen realiseren.
Vervolgens is de vraag, wat heb je als opdrachtgever gedaan om dit te voorkomen? Vanuit je luie stoel roepen dat doelstelingen niet door project behaald zijn en alles op ict afschuiven is ook niet terecht!

De vraag is wat de redenen zijn voor het overschrijven van tijd en budget, dit kom ik niet tegen in het artikel, maar ook niet op de pagina waar naar gelinkt wordt vanuit dit artikel.
Ook vraag ik me af wat het bereik is waaronder deze projecten vallen.

Bij veel projecten komt er extra werk naar voren, doordat de eisen van de klant worden aangepast, of doordat de inventarisatie niet voldoende details bevatte.
Een projectmethode als Prince2 voorziet hier dan ook in door de business case tussentijds te wijzigen.

Als het overheidsprojecten zijn, kan ik me voorstellen dat het voldoen aan opgelegde wetgeving belangrijker is dan de tijd en geld die het project kost. De werkzaamheden moeten immers worden uitgevoerd.

Als laatste is een goede vraag om te stellen: wanneer is een project mislukt?
Meestal is dat wanneer de uitkomst niet voldoet aan de verwachtingen.

Als door het toevoegen van tijd en geld de uitkomst wel voldoet, is een project dan mislukt? Hoogstens wanneer de kosten hoger zijn dan de baten.

Kortom, het is lastig om zonder de extra informatie het artikel te kunnen waarderen. Er zijn inderdaad projecten waar de oplevering belangrijker is dan de tijd en geld die ermee gemoeid zijn. Net zo goed kunnen projecten tijdens de looptijd veranderen.

Mijn beste onderzoekers, mijn beste criticasters. Zie mijn input hier niet als klaagzang, nog kritiek naar al die PM's die roepen hoe succesvol hun projecten wel niet zijn geweest in het verleden. Als IT PM heb ik in menig reeds lopende projecten ingestapt, projecten opgestart, 'doorgegeven', 'voortijdig beëindigd' of pas later kunnen opleveren, PID's geschreven, gereviewd, asssesset, gecorrigeerd, u zegt het maar.

Als ik u hier een weergave van feiten zou moeten geven verword ik, hoogstwaarschijnlijk in uw ogen althans, tot een soort excuustruus. Tenminste, zo noem ik mensen die heel graag alle stof van zichzelf afvegen maar waar het nooit aan de persoon zelf heeft gelegen.

Waar gaat het dan wel om? Als we naar het artikel kijken komen wat gedachten richtingen naar voren maar ik ga graag even terug naar het stuk VOOR aanvang van ......

IT als materie
IT is een lineaire materie die een lineaire manier van kijken verlangd. Niet alleen van alle leden die zich in IT begeven maar juist ook van hen die zich er niet in begeven.

Neen, als u een prince2, een Itil of een MSP of EDDD cursus met goed gevolg heeft doorstaan, wil het niet zeggen dat u nu in staat bent elk IT project vorm te geven of op te tuigen laat staan uit te voeren. Waarom niet? Omdat u geen idee heeft van de Lineaire wereld van de materie IT. Gevolg? Lees het artikel nog eens.

Aanvullend hier op moet ik u even verhelderen dat er nogal wat IT'ers rondlopen die dat ook niet hebben. Neen, het maakt namelijk geen onderdeel uit van een standaard van een curriculum. Men kan zich moeiteloos, doorgaans bekwamen voor allerlei IT disciplines, en geen jota begrijpen van de materie IT. Hetzelfde geld dat niet elke PM in de IT beschikt over een helikopterview.

Is dit laatste te leren? JA! Ik roep het al jaren, voel me regelmatig een roepende in de woestijn wat dit betreft maar Tjé, Hé, ik hoef de rekeningen uiteindelijk niet te betalen. Zo eenvoudig is het. Er zit een commerciele gedachte achter die ik niet aan wil hangen.

Redenen? Twee!
1. De gedachtegoed heeft een aanmerkelijk commercieel belang waardoor men concessies doet waarna in de 'aftermath' men denkt geld te kunnen gaan verdienen
2. Men heeft geen enkel idee hoe de 'Klant' helder en inzichtelijk te maken waarom de materie IT beweegt zoals die zich beweegt en daarom ...
Daarom zou het ook wel eens kunnen zijn dat je een klant NEE zou moeten verkopen, op bepaalde punten.

Een andere, niet onbelangrijke, die kunt u zo uit een standaard Prince2 PID halen. Doe het eens, Google even op Prince2 en PID, het is een standaard gratis document, en u ziet vast ergens een sectie staan die handelt over de manier van communiceren. Mooi. Dames en heren hier de grootste valkuil die eveneens in het artikel naar voren komt, en waar menig grap over te vinden is op internet.

Klaarblijkelijk zijn commerciële IT'ers helemaal niet in staat de vertaalslag te kunnen maken tussen IT of non IT, dit met alle gevolgen van dien. Je zal maar als welwillend PM worden geconfronteerd met zaken die eigenlijk helemaal niet eens kunnen. Je bent gewoon het haasje.

Gestelde vragen;
Er zijn twee vragen die men een IT'er of NON IT'er nooit stelt. Gewoon omdat men er niet eens aan denkt.
1. Waarom automatiseer je?
2. Waarom ga je automatiseren?

Menig onzin zal tot u komen, test het zelf maar eens uit. Maar diegenen die u hier niet rechtstreeks en in alle eenvoud op kunnen antwoorden? Die hebben of een aanmerkelijk belang in het verhaal of vinden zichzelf 'zwaar' genoeg om een hele grote vinger in het traject te willen hebben. Gevolgen? Leest u het artikel zelf maar.

Hoe dan wel?
Die vraag is zeer eenvoudig te beantwoorden. Tenminste, het lukt mij wel in een seminar van pakweg 4 uur voor IT'ers en NON IT'ers. En anders surft u maar naar http://bit.ly/x8nwIr en haalt daar gratis de Civile Matrix. Wie weet dat u dat in ieder geval een duidelijker beeld geeft van de lineaire werking van de materie IT. Makkelijker kan ik het niet voor u maken.

En alle excuses en redenen van falen ten spijt, geef ik u dan ook nog graag mee dat de materie IT aan 'Wetmatigheden' is gebonden. Beste lezer, 'don't blame me', Ik heb ze niet bedacht, maar heb er wel altijd oog voor gehad en dat heeft mij in elk geval heel veel 'bespaard'.

IT, een prachtig vak, nu nog willen begrijpen en accpepteren waarom het zich zo beweegt. Dan gaat u heel veel besparen.

Als een ICT-project faalt door de te hoge verwachtingen, dan zul je (als bijv. projectmanager) iets moeten doen om die verwachtingen beter te managen. Wat je vaak ziet in projecten is dat tijd en geld vaststaan, maar dat de verwachtingen verschuiven of pas helderder worden gedurende de rit.

Mijns inziens zou menig project baat hebben bij een meer agile-achtige aanpak. Het uitgangspunt van Agile projectmanagement is dat de elementen tijd, kosten en kwaliteit vast zijn en het element scope variabel is. Het resultaat wordt dus niet vooraf geheel dichtgetimmerd. Dit in tegenstelling tot de traditionele PM methodieken waarbij de scope vast is en daardoor verwachtingen minder goed gemanaged kunnen worden.

Een Agile projectaanpak kenmerkt zich door ontwikkeling in afgebakende perioden (timeboxes) met een vastgesteld budget en resultaat, de zogenaamde iteraties. Bij de start van elke iteratie wordt in gezamenlijkheid bepaald welke zaken ontwikkeld worden. Na iedere iteratie is er een functionaliteit beschikbaar die daadwerkelijk in productie genomen kan worden. Op deze manier kan er per iteratieronde invloed door de opdrachtgever uitgeoefend worden op hetgeen opgeleverd moet worden en wat daarvoor verwacht wordt.

Welke projectaanpak je ook kiest, je hebt te maken met de duivelsdriehoek tijd, geld en kwaliteit. Los van de scope ontstaat er druk op de projectorganisatie zodra je tijdens een project aan een van deze grootheden gaat sleutelen. Dat leidt in veel gevallen tot ongewenst effect op de ander twee en daarmee op het verwachte resultaat.
In dit stuk is naar mijn smaak wat onderbelicht dat het begrip geld twee dimensies kent: kosten en opbrengsten. Wie eerst kijkt naar wat iets opbrengt heeft meer argumenten om te investeren, of om dat juist niet te doen.
Dit illustreert eens te meer het belang van een gedegen voortraject waarbij de belangrijkste vragen zijn: wat willen we precies (of: waar moeten we precies aan voldoen) en wat levert het op? Pas dan kan antwoord gegeven worden op de vraag wat het mag kosten en wanneer we het willen (of moeten) hebben.

De wijze van projectenmanagen hangt helaas toch af van het type project. Wanneer het gaat om een innovatief project dan is procedure en procesmanagen, niet voldoende om te komen tot een succesvol eindresultaat. Er is dan namelijk meer kennis van de inhoud nodig bij het projectmanagement om de goede keuzes te kunnen maken. Het (in)directe gevolg van innovatief is dat niet alles voorspelbaar is door herhalingseffecten elders. Dit in tegenstelling tot een "15 krentenbollen in een dozijn" project, waar elke volgende stap goed voorspelbaar is. Dan is procesmanagement de cruciale factor.

Een goede optie: manage ICT projecten NIET zo zeer op tijd en geld maar op SCOPE.
Vaak komen er tijdens de uitvoering van een project allerlei zaken tevoorschijn die niet in de scope gedefinieerd waren en die dan toch maar "terloops" meegenomen worden binnen het project. Geen wonder dat in deze gevallen de budgetten tijd/geld overschreden worden.

Dit geldt niet alleen voor ICT. Voorbeelden zijn Heathrow Terminal 5 en RandstadRail, projecten die op tijd en binnen budget werden opgeleverd maar waar direct na oplevering de chaos compleet was. Dit is veel meer regel dan uitzondering wanneer gestuurd wordt op tijd en geld.

In het boek “the Handbook of Project-Based Maangement” (1999)( sneed J.Rodney Turner dit onderwerp aan. Een citaat:
“There is an apocryphal story about research conducted in Australia into how projects were perceived five years after completion. All the project completed to time, cost and specification were five years later perceived to be failures. The implication is that in the drive for time, cost and specifications, the project team sacrificed functionality and the product of the project had proved less than useful”

Het antwoord ligt wel degelijk in PRINCE2 en MSP. Want juist hier wordt niet uitgegaan van de ijzeren driehoek maar van lange termijn succes; PRINCE2 kent dan ook 6 dimensies voor beheersing, niet 2 of 3. Er is dan ook geen sprake van ICT-projecten want ICT is een middel en geen doel. Tenzij je aan de kant van de leverancier zit. Het is van het allergrootste belang dat begrepen wordt dat de (interne) leverancier een volgende rol heeft en geen leidende. Want een (interne) leverancier kan eigenlijk niet anders dan zich op de projectplanning en niet op de business case te richten. Een leverancier zal zich op de werkzaamheden richten en daarmee met ontwikkelmethodieken aankomen, zoals Agile. En daarmee komt voor het projectmanagement sturing op tijd en geld weer in beeld. Zie ook voor toelichting: http://www.projectenmanagen.nl/gastcolumns/prince2-bureaucratisch

@ Nico Viergever
Beste Nico,
Ik kan het in de basis al niet met je eens zijn. Reden hiervoor is dat nergens in Itil of Prince2 de materiekennis van IT wordt uitgelegd, laat staan dat de partij aan de overkant dit zou weten. Men weet niets van de materie, men weet niets van het basale bewegen van de materie, men weet niets van de lineaire wetmatigheden. De reden? Omdat 85% van de IT'ers dat nooit hebben geleerd 99% van al die PM's die zich in de IT begeven.

Kijk even naar de twee hele simpele vragen ter toetsing, en dan weet je genoeg als je de uitgebreide verklaringen van al en diegenen krijgt.
Bij deze mag je vrij gebruik maken van een simpele doelmatige tooltje genaamd de Civile Matrix. http://www.numoquest.nl/civilematrix.html .
Daar vind je de absolute basis weer terug van de IT en de wetmatigheden. Conformeer je je daar niet aan? Prima, dan weet je dat je project jammerlijk uit zal lopen.

Een hele grote troost? Ik hoef de rekening daarvan niet te betalen.

;O)

@NumoQuest: Interessante site, maar helaas maak je je net als anderen evengoed schuldig aan vaagheid. Veel uitleg, veel informatie, maar weinig concrete voorbeelden van resultaten, referenties of anderszins. Maar het ziet er geloofwaardig uit. Je noemt twee eenvoudige vragen. Helaas kon ik die niet vinden, noch het antwoord. Wellicht interpreteer ik de hint verkeerd. Nog wel een tip: corrigeer de spelfouten, want dat past echt niet in een zo goed verzorgde site.
Dan de matrix. Eenvoudig en krachtig, maat slecht uitgelegd. Naar mijn idee zou je liever een cyclisch model maken, waarbij het probleem de start van een volgende cyclus markeert. Dat kan dan dezelfde cyclus zijn (indien het een showstopper blijkt), of het kan een nieuwe cyclus zijn, gericht op de oplossing van dat probleem, of van een volgende fase waarin dat probleem als onderdeel wordt meegenomen. Zie een project als een dynamisch geheel, een verzameling wijzigingen of veranderingen waarvan het uiteindelijke doel slechts is te komen tot een verbeterde, ‘hogere’ of volwassener versie van de “business as usual”.

@NumoQuest
Het gaat er niet om dat je als klant iets van IT hoeft te weten. Het gaat erom dat je controle hebt over je doelen. IT is een een middel, geen doel.
Als ik een auto koop, hoef ik ook niets van de techniek te weten. Ik hoef alleen te weten of aan mijn functionele eisen wordt voldaan.

@Nico leuke vergelijking inderdaad. Als je een auto koopt start je ook niet blanco zoals je bij een ict systeem vaak doet. Je weet al ongeveer in welk segment je wil kopen (hoofd requirements) en dan ga je op basis van keuzes verfijnen (detail requirements). Bij ict gaan we altijd weer van nul af aan beginnen. Met als gevolg dat van requirement owners en opstellers een soort super abstractie niveau wordt gevraagd om je een toekomstige nieuwe oplsossing voor te stellen, en je makkelijk dingen vergeet. Waarom wordt er niet meer met standaard checklists en templates / keuze lijsten gewerkt per te automatiseren segment?

De resultaten van dit onderzoek verbazen me niets. Veel it-projecten die ik langs zie komen lijken te zijn vergeten dat er achter ieder IT-project een Business Case zit, ook al is die vaak niet uitgeschreven, waarin de waarom-vraag is beantwoord. Dit vertaalt zich uiteindelijk in een IT-project, dat een groter of kleiner deel van de waarom-vraag voor zijn rekening neemt. Dat project beweegt zich binnen de duivelsdriehoek van tijd, geld en kwaliteit. Hierbij zie ik scope gemakshalve als één van de dimensies van kwaliteit.

Als je een project dan perfect op tijd en geld weet te sturen, is de kans behoorlijk groot dat je niet goed scoort op kwaliteit. Voor de eigenaar van de Business Case appelleert de kwaliteit namelijk vaak het meest aan de beantwoording van de waarom-vraag. Ik heb met projectmanagers gewerkt die zelden op tijd en/of binnen budget opleverden, maar altijd projecten uitvoerden die als succesvol werden ervaren.

Waarom? Omdat ze het echte issue adresseerden waarvoor het IT-project (mede) een oplossing moest bieden. Het gaat niet om de techniek, of het nu IT is of niet. Het gaat om de vraag achter de vraag. Daar gaat Prince2 of MSP niet bij helpen.

Je zou het idee krijgen dat de falende IT projecten zoals hier bedoeld een collectief manco hebben aan meten van de effectiviteit.

Effectiviteit dan gedefinieerd als: "doet het systeem voor de organisatie wat het moet doen, en kan de werkvloer ermee overweg?".

Immers als dit gedurende de looptijd van het project (en op het eind) gemeten kan worden, dan moet het toch van doorslaggevend gewicht zijn in de beoordeling van het project (je kan een project toch niet succesvol noemen als het niet effectief is?).

Bestaan er (standaard)methoden om dit te meten, en worden ze gebruikt? Tegenwoordig kan je tegen heel geringe kosten je medewerkers om commentaar vragen.

Een dergelijke meting zou je niet alleen kunnen gebruiken om nieuwe projecten te beoordelen, maar ook om het functioneren van bestaande IT structuren in kaart te brengen.

Weet iemand hier iets van?

Beste Charles Li,

Het probleem zit aan twee kanten. Veel IT'ers, je kut het ze niet kwalijk nemen, hebben weinig tot geen oog voor de wetmatigheden van de materie IT. Ongetwijfeld grote professionals in hun vak gebied, maar.... daar is dan alles mee gezegd.

In de tweede plaats heb je dan Ego/politici/beslissingsnemers en Non IT management die van die merites al helemaal geen kaas hebben gegeten. Die worden dan na een tender bijvoorbeeld, geconfronteerd met zg 'voorziene onvoorziene omstandigheden' of domweg voor voldongen feiten gesteld.

De commerciële kant van het verhaal, de hele goten in Nederland, die kampen ht uiteraard volkomen ten dienste zijn maar om de tender binnen te halen komen ze met een meest uitgekleed scenario. De rekeningen komen pas als men de tender binnen heeft. Ook die zijn dus niet gebaat bij het achterste van hun tong te laten zien.

Wil je orde op zaken stellen dan zul je enkele zaken moeten zien, begrijpen en accepteren. Daar hoef je overigens geen universitaire studie voor te hebben gedaan. Je hoeft alleen maar op dezelfde manier tegen IT als materie aan te kijken.

Werp even een blik op http://www.numoquest.nl/civilematrix.html en je begrijpt wat wordt bedoeld. Veel zijn er aan gelegen de IT als materie helemaal niet zo eenvoudig te maken.

Stel je toch voor zeg dat je IT gebruiken zou waar die voor is bedoeld.

Besparen.


@NumoQuest, het is niet nodig om zo vaak je url te vermelden, als mensen je willen bereiken kan dat via je profiel

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

×
×