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.
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