Als er gekeken wordt naar de verschillende soorten projecten en de vraag ‘in hoeverre de ict-sector hierin afwijkt ’ dan rijst de vraag of projecten te classificeren zijn. Dat blijkt mogelijk. Er zijn twee variabelen die in ieder type of soort project te herkennen zijn. Enerzijds spreekt men van projecten waar het 'doel' of 'product' duidelijk, of juist onduidelijk, gedefinieerd is. Anderzijds zijn binnen projecten de 'methoden van werken' of 'processen' duidelijk, of juist onduidelijk.
Om een onderscheid te kunnen maken tussen de verschillende typen projecten kan je een indeling maken op basis van methoden en gedefinieerde doelen. Het principe achter deze indeling is dat je deze punten als onderdeel naast andere meetpunten kan gebruiken om de kans te berekenen of een project het beoogde resultaat of gewenste effect kan halen. M.a.w. hoe beter de methoden en de doelen gedefinieerd zijn des te groter is de kans op voorspelbaarsucces. De meest voorkomende type projecten zijn dan als volgt te beschrijven:
Research en cultuurverandering
Dit zijn projecten waarbij de eisen en wensen van de gebruiker niet of nauwelijks concreet vast te leggen zijn. Deze moeten gedurende het project ontstaan.De projecten zijn tactisch of operationeel van aard en bij de start functiegericht. Bij dit type project is de betrokkenheid van de gebruiker beperkt. De uitvoering is voornamelijk in handen van specialisten. De techneuten doen het project zonder de gebruiker erbij te betrekken. Met een groot risico dat een resultaat wordt opgeleverd waar de gebruiker niet blij mee is en niet wil accepteren of gebruiken. Hiermee valt het project in de categorie mislukt. Het gewenste effect zal niet gehaald worden omdat de methoden goed gedefineerd zijn maar de doelen niet.
Productontwikkelprojecten
In dit type project is het doel goed gedefinieerd maar hoe dat doel te bereiken is vaak niet duidelijk. Hierbij kan gedacht worden aan productontwikkelingsprojecten die veelal multidisciplinair worden uitgevoerd. De doorlooptijd is een prioriteit omdat de 'time to market' bepalend is wat het project onder druk zet. Omdat er veel onzekerheden zijn over de methode van aanpak hebben deze projecten meestal eerst een functiegerichte aanpak. Dit soort projecten zullen door tijdsdruk concessies doen aan kwaliteit. Het doen van concessies in combinatie de vele onderzekerheden leiden vaak tot overschrijding van de afgesproken tijd en de daaraan gekoppelde kosten. Ook voldoet het eindresultaat meestal niet aan de klantverwachtingen. Het wordt niet geaccepteerd. Het project is daarom niet geslaagd. Het gewenste effect zal ook hier niet gehaald worden omdat de doelen en methoden niet goed zijn gedefinieerd.
Systeem ontwikkeling projecten
Kenmerkend voor dit soort projecten is dat er veel onzekerheden zijn: de ervaring met de uit te voeren werkzaamheden ontbreekt en de consequenties van de risico's zijn groot. Deze projecten laten zich slecht plannen en worden daarom vaak fase voor fase in detail uitgewerkt en gepland. De complexiteit is zeer hoog omdat soms nog vage ideeën concrete resultaten dienen op te leveren. Gezien de grote impact voor de gebruiker is zijn betrokkenheid het gehele project noodzakelijk. Dit is vooral herkenbaar in Research & Development projecten. De projectorganisatie en gebruikers moeten als het ware samen op pad om het gewenste resultaat te bereiken. Dit type project valt in een hoog categorie gehalte van mislukte projecten. De kans op slagen en om binnen de stuurkaders van scope, tijd, geld en kwaliteit te blijven is bij dergelijke projecten nihil. Ook hier zijn de doelen en methoden niet goed gedefinieerd.
Bouw en Engineering
Projecten zijn voornamelijk operationele projecten en worden ook wel klassieke projecten genoemd. Het zijn projecten met bekende aspecten die gestructureerd en volgens een vast stramien worden uitgevoerd.De projecten zijn over het algemeen product georiënteerd (PRINCE2 gedachte!) en de projectmedewerkers zijn door herhaling gespecialiseerd (juiste competenties !) in dit werk. Er zijn daardoor weinig onzekerheden en doordat de werkzaamheden al vaker zijn uitgevoerd is er een gedegen ervaring (geleerde lessen!) op basis waarvan de planning tot in de details van tevoren gemaakt kan worden. Ook zijn eventuele risico's qua kans en consequentie goed in te schatten en in te plannen. Vanwege veel standarisatie kan geconcentreerd gewerkt worden op efficiëncy. Deze projecten zullen de grootste kans hebben op succes. Daar zijn in de regel de doelen en methoden goed gedefinieerd.
Conclusie
Dan rijst het antwoordt op de vraag ‘in hoeverre de ict-sector afwijkt' met een ‘nee'. Het managen van projecten is in essentie gelijk ongeacht de sector waarin het project wordt uitgevoerd. In de praktijk blijkt wel per sector dat projecten verschillend worden ingevuld. Maar in alle gevallen is echter het projectbasisproces gelijk.
De oorzaak van projectfalen ligt (op basis van onderzoek) mijniziens dan ook op: een niet realistische en te maakbare business case, onvolwassen projectorganisaties, het ontbreken van veranderingsmanagement, niet methodisch werken of doelen stellen en niet in staat zijn om een en ander te beheersen en samen te vatten in een waterdicht contract. Uit onderzoek is gebleken dat bedrijven of projectorganisaties merendeel op de adhoc positie zitten met een beetje standaard (Pino, template management) en twee derde niet methodisch werken. Het geheel verklaart waarschijnlijk waarom projecten mislukken.
Lees een prince2 boekje, kijk wat rond in enkele bedrijven en je komt tot dezelfde conclusie.
John,
Interessante beschouwing en heel herkenbaar. Als je dezelfde beschouwing nu eens doet vanuit een project sturing perspectief. Kom je dan tot dezelfde conclusie?
Praktijk in de ICT laat her en der toch wel progressie zien in methodisch werken in de uitvoering. Echter in de sturing van projecten is zelfs Pino vaak nog een brug te ver. Herken je dat?
Het is herkenbaar omdat het een open deur is 🙂
Prince2 toetst na elke fase de resultaten aan de Business Case EN laat geeft de vrijheid om zelf de fases in te delen. Risico is dus tot minimum beperkt. In het ergste geval staakt men het project (precies op tijd).
Prince2 projecten falen dus omdat de Business Case niet goed is opgesteld en/of men de methode niet goed volgt en uitvoert.
Interessant artikel en inderdaad herkenbaar. Heb wel vaker gezien dat Pino gehanteerd wordt, dan weet de projectleider nog net een PID te maken i.p.v. een PVA, maar wat een Project Board is, dat weten ze soms niet eens. Dat is toch wel vreemd, ik heb ook ooit eens ‘de kleine Prince 2′ gelezen, en ik als techneut weet het wel.
Misschien dat naast een Prince 2 certificaat een IPMA-C of B toch wel handig is. Heb ook samengewerkt met projectleiders die IPMA gecertificeerd waren of hier mee bezig waren, en over deze PL’s was ik tevreden. Het kan natuurlijk toeval zijn, met mijn beperkte waarnemingen. Misschien hebben anderen hier nog interessants over op te merken?
Beste Opendeur (leuke naam) en Harry,
Natuurlijk is het een open deur en conclusie. Het gaat erom wat je bewust ermee doet en onderdeel maakt bij de vraagstelling moeten we dit project nu wel doen?
Uit eigen (master) onderzoek blijkt dat onder de 200 onderzochte bedrijven dat zij onvolwassen zijn of een beetje gestandaardiseerd. E.e.a wordt nog eens versterkt daar 66% niet methodisch werkt.
Dus praten over PRINCE2 of andere smaken heeft dus geen zin. En ja we weten het. We lezen het. Maar we leren er niet van. De projecten zijn gewoonweg niet te rechtvaardigen. Het is niet realistisch. We laten het maakbaar maken.
Je kan bovenstaande beschouwen als onderdeel of afweging of het project te besturen of te beheersen is. Met dergelijke uitkomsten denk ik van niet. Projecten zullen dan ontaarden in brandhaarden waar de PM als een brandweerman probeert te redden wat er te redden valt. Het resultaat zal er wel komen maar de nevenschade op tijd, budget of kwaliteit zullen groot zijn.
Dergelijke projecten vallen dan in de categorie ‘mislukt’. Een vakman zou dan in de embryonale fase van een dergelijk project ‘nee’ moeten zeggen op basis van argumenten.
Tegen onze kinderen zeggen we ook nee als ze nog niet volwassen zijn om alleen over de wereld te zeilen of naar Salou te gaan. Al die kinderen hebben een mooie en maakbaar gemaakte business case. Maar als ouder en deskundige maken we een keus op basis van realiteit, vermogen en volwassenheid. En als ze mogen dan zijn er maatregelen getroffen om het realistisch te maken.
Pas dergelijke aanpak ook eens toe bij bedrijven en haar projecten. Ik zie procesmatige beoordeling tussen thuis en werk geen verschil.
John Roos
John,
Dan kom je precies waar het pijn punt zit; er wordt geen NEE verkocht/geaccepteerd door de business. Mogelijk kunnen wij (als ict-ers) het niet goed onderbouwen en wordt de business case niet goed opgesteld, maar mijn ervaring is dat als de business erom vraagt, de business het ook krijgt. Projecten worden niet tussentijds (netjes; op basis van het niet meer halen van de business case) gestopt.
Tja, het artikel is idd geen open deur in de zin dat er nog zoveel projecten mislukken. Kennelijk moet het nog een keer uitgespeld.
Maar zoals aftervillage hierboven ook aangeeft, Business geeft gewoon een opdracht en zoekt iemand die altijd JA zegt tegen de Case.
Zelfs je kinderen zullen waarschijnlijk iets proberen in trant van : “van mamma mag het wel”..
Open deur,
Als we geen ‘nee’ meer durven te zeggen dan houdt het op. Dan hoeven projectmanagers niet meer op cursus. We hoeven alleen maar op ‘ja’ knikkers te selecteren of iedereen een vrijbrief geven. Leve de lol!
Maar in onze organisatie hebben we gelukkig nog de taken, verantwoordelijkheden, bevoegdheden en autoriteit goed belegd. Als het niet realistisch is en onvolwassen dan stemmen we niet toe.
Business case is prima benadering, maar wanneer is de rationale/rekensom zuiver en volledig? Hoe stel je objectief (moeilijk genoeg), vast of de benefit & kosten wel realistisch is geraamd qua hoogte en duur? Veel benefit componenten zijn ook erg lastig te kwantificeren. Ook de financiële interpretatie is belangrijk (netto contante waarde). Hoe stel je vervolgens vast per jaar wat de daadwerkelijke hoogte van de benefit is per jaar (benefit tracking) -dat toe te rekenen is aan het slagen van het project? Pas na verstrijken van de terugverdien tijd “weet je zeker” of project geslaagd is -of niet…
@Appelman
Wat jij noemt zijn gewoon projectrisico’s. “Gewoon” wat betreft dat het in Prince2 uitvoerig beschreven wordt, niet gewoon in de zin dat het eenvoudig is. Wat jij noemt is wellicht een van de lastigste aspecten binnen een Project.
Projectrisico’s behoren teruggekoppeld, door de Project Manager aan het Project Board. Die krijgt dan een reeel beeld van de kans van slagen van het project.
Er is vaak een druk op Project Managers om de risico’s te onderschatten of zelfs bewust te rooskleurig voor te stellen. Wordt het mandaat door het Board gegeven dan kan er geld verdiend worden en zoals aftervillage hierboven al aangaf, een project wordt zelden na evaluatie van een fase gestopt.