'Grote projecten zijn gedoemd te mislukken'. Albert Boonstra heeft het voor ons uitgezocht. Zo'n ronkende uitspraak is niet nieuw maar toch gedoemd om de aandacht te trekken.
Voorbeelden van mislukte ict-projecten zijn er genoeg: Studiefinanciering midden jaren '80 verslikte zich. Recenter zijn weer een stuk of wat projecten gesneuveld (epd). Veel besluiten worden niet met het verstand genomen, maar heel democratisch op basis van een quorum aan jaknikkers. En achteraf constateren beslissers quasi verbaasd, dat die kritische geluiden niet konden doordringen (Betuwelijn, HSL et cetera).
Een project heeft normaal gesproken een begin, een helder gedefinieerd eindpunt, éénduidige leiding, een omkaderd budget, een omkaderde inzet, een concreet resultaat. Het 'rijtje' Do's en Don'ts bij projecten en projectmanagement wordt in opiniebijdragen geregeld aangevuld en herhaald: teveel of te weinig controle, het nut van CMM; Zelf haal ik graag John Kotter aan. 'De kosten, de tijdsduur en de uiteenlopende belangen van de betrokken partijen worden onderschat' zo zegt Boonstra; Dat is eigenlijk 'Kotter revisited'. Een andere manier van zeggen is dat veel projecten beter als iets anders dan als project uitgevoerd hadden kunnen worden. Zelfs de Deltawerken kwamen niet zonder slag of stoot af. We zijn er misschien wel trots op, maar echt 'af' zijn ze nooit. Er is nu wel een ander soort beheersorganisatie dan vóór ze er waren.
Ik noem ict altijd een 'modulaire business'. Samenwerking is haast altijd het uitgangspunt en elk specialisme heeft voor elke dienst en product een rol die net een tikje verschilt. Apple vind ik een mooi voorbeeld. Het houdt de regie, besteedt veel zaken uit. Maak je zo'n kastje open dan rollen er onderdelen uit die vrijwel allemaal niet bij Apple zijn gemaakt. Passende blokjes samen vormen één dienst/product. Maar, zijn dat soort ontwikkelingen ook echt projecten? Of gaat het gewoon om ontwikkelingen die altijd maar doorgaan, zo lang (of net iets langer dan) ze winstgevende perspectieven hebben? De MP3 speler bestond allang voor Apple hem opnieuw uitvond. De telefoon ook. Zelfs de (tablet) pc. Apple heeft trefzeker en briljant nèt dat unieke stukje extra bedacht en ingebouwd. Apple heeft in een groter perspectief de volgende ontwikkelfase ingezet.
Geen eindpunt
Vele ict-ontwikkelingen kennen geen vooraf gedefinieerd eindpunt, maar alleen een (volgend) tussenstation. Een uitbesteding van een ict-dienst bijvoorbeeld, dat is een fase; Het lijkt wel een project, maar de dienst houdt na afloop van het project (als het goed is) niet op, ziet er slechts anders uit. Het uitgangspunt bij zulke ontwikkelingen is niet een 'begin' en een 'einde' binnen een beperkt budget. Natuurlijk is er getouwtrek om politieke belangen. Die dienst móét tot hoge prijzen doorgaan, it is immers de ruggengraat van een bedrijf. Het gaat bijvoorbeeld om 'future proof' development, incrementele besluiten, samenwerking, visie en overdracht. Dat zijn subtiel andere kaders dan die van een enge gedefinieerd it-project. Een te eng gedefinieerd project komt niet op CMM level 2 (repeatable) omdat het nooit herhaald wordt. Het project komt daardoor nooit in een stadium van volwassenheid.
Om alsnog naar 'optimization' te streven kiest de projectleiding vaak voor sturing, vanuit technisch perspectief: Strakke ontwerpen, visionaire architectuur, krachtige controle, Prince2. Dat ontkent de aard van veel ict-ontwikkelingen: Vaak verrassend creatieve, gefaseerde vooruitgang. Werkende ict steunt op modules van technologie die nu ter beschikking staan. Ict is volgens mij die modulaire business, omdat bouwstenen elk voor zich wèl repeatable of zelfs optimized kunnen zijn, ook al is de dienst die er uit voorkomt dat (nog) niet. Een ict-implementatie veronderstelt ondersteuning, continuïteit, service, opleiding, doorontwikkeling, alignment, compliance, imbedding in de omgeving, acceptatie, nieuwe releases, enzovoort. Geen reuzenstap, maar vele kleine bouwstenen van 'fit'.
Grootschaligheid
Vanwaar toch die voorkeur voor grootschaligheid onder een projectopzet? Grootschalige plannen lijken vanuit technisch perspectief voordeliger: Je kunt vooraf met 'alles' rekening houden en een optimale aansluiting op de praktijk ontwerpen. Technisch klopt dat heel misschien (als niets tegenzit) maar de omgeving is verre van 'controlled', eerder dynamisch of chaotisch. Organisatorisch stelt dat zeer hoge eisen aan leiders en uitvoerenden. Grootschaligheid is namelijk op zichzelf al moeilijk te beheersen en doorgaans matig voor de kwaliteit. Grote veranderingen roepen op zichzelf al Governance vraagstukken op. Bij taken en zaken die qua doelstelling helemaal geen project moeten heten, kunnen we daarom beter incrementeel te werk gaan, de continuïteit en het toekomstperspectief voor permanente betrokkenheid tot uitgangspunt maken.
Bestuurskundig is dit gegeven allang 'common sense'. Ergens in 1989 hield Uri Rosenthal mij voor, dat moeilijke besluiten beter incrementeel kunnen worden genomen. Als één grote hap teveel is, neem dan veel kleine hapjes. Zit er eentje tussen die slecht smaakt, dan krijg je die tenminste niet met de rest mee naar binnen. Dat is de essentie van incrementele besluitvorming. Voor veel ict-veranderingen is het een zege.
Vermijd het krampachtige projectgedoe over beheersing, methoden, paraafjes halen bij stuurgroepen voor 'changes'. Kies voor incrementele, beheersbare ontwikkeling, overdracht, voor blijvende betrokkenheid van de juiste mensen in de juiste fase. Niet de tunnel is de essentie, maar een werkende dienstregeling. Als een ict-ontwikkeling een levensvatbaar bestaansrecht heeft, dan is dat een succesvolle nieuwe (volwassen) ict-functie, een dienstregeling, in plaats van een mislukt traject.
Een project is niet meer dan het beschrijven van de huidige situatie (ook wel CMO of Ist genoemd), de gewenste situatie (ook wel FMO of Sol genoemd). Uit deze twee beschrijvingen volgt dan Wat er moet gebeuren, Wie dit moet doen, Wanneer en Hoe. Het gaat al mis bij het beschrijven van de huidige en de gewenste situatie. Beschijvingen van de huidige situatie zijn niet altijd actueel en/of compleet, kennis is versnipperd over verschillende afdelingen die niet met elkaar communiceren en het project moet door dus we kunnen niet wachtten totdat alles is uitgezocht. Voor wat betreft de gewenste situatie laat de beschrijving vaak (veel) ruimte over voor allerlei aannames waardoor er al snel verschillende opvattingen ontstaan, vaak bevat het tegenstrijdige keuzes (badkamer op de 1e verdieping, maar afvoer op de begane grond of omgekeerd) al dan niet gebaseerd op “politieke motieven”. Beheerders willen graag elk risico op verstoring vermijden en projectmedewerkers willen ongehinderd zoveel mogelijk wijzigingen doorvoeren (testen en nadenken kosten alleen maar tijd) en daarom werken ze elkaar vaak tegen. De politieke belangen zijn vaak zo groot dat het project al een succes is voordat er is begonnen ongeachte het werkelijke resultaat.