SPEER organisatiecultuur

SPEER als resultaat van organisatiecultuur

In het vorige deel van deze serie blogs ging ik in op de visie van PRINCE2 op projecten en hoe die visie haaks staat op de organisatiecultuur die in veel grote organisaties aanwezig is. Een organisatiecultuur die zich richt op efficiëntie door specialistische hokjes: het Taylorisme.

Dit vervolg laat zien hoe verwoestend deze organisatiecultuur uitwerkte in een van de meest groteske mislukkingen die ik de laatste jaren heb zien voorbijkomen. Het gaat om het project SPEER bij het Ministerie van Defensie. Hoewel de schaal van dit project buitengewoon was, komt dit soort projecten - en het mislukken daarvan - heel vaak voor, maar dan op een (veel) kleinere schaal.

Aanleiding

Eind 2013 werd het officiële einde van het SPEER-project aangekondigd. Al jaren was dit project een (politiek) hoofdpijndossier. Na het officiële einde leverde het Ministerie een eindevaluatie af; vervolgens kreeg ik van de politiek het verzoek deze evaluatie te beoordelen. Dit oordeel treft u hier aan.

Wat cijfers

Ik hoorde voor het eerst van SPEER in 2002. Volgens de eindevaluatie is het project in 2004 van start gegaan.

Volgens het ministerie heeft het project ongeveer €500.000.000 gekost; in een reactie daarop stelde de Algemene Rekenkamer dat de kosten eerder tot ruim €900.000.000 waren opgelopen.

Zoals gesteld werd het project formeel beëindigd in 2013, dus na een doorlooptijd van ongeveer negen jaar. Onder een andere naam gaat het project echter nog altijd verder. De kosten lopen daarmee dus ook nog altijd op.

Niet alleen aan de kostenkant was dit project een politiek hoofdpijndossier; ook aan de opbrengstenkant was er veel mis. In de afgelopen jaren heb ik diverse gebruikers gesproken die zich zeer emotioneel vol afschuw uitlieten over SPEER. Er zou niet of nauwelijks mee te werken zijn en de meest eenvoudige handelingen zouden veel tijd in beslag nemen.

Vanaf het begin fundamenteel verkeerd

Uit de evaluatie blijkt dat het toenmalige hoofd automatisering zich zorgen maakte over de onderhoudbaarheid van de sterk verouderde Legacy systemen. De oplossing was volgens hem: vervanging door een modern standaardpakket. De keuze viel uiteindelijk op het ERP pakket van SAP.

Natuurlijk had de CIO, zoals hij tegenwoordig genoemd zou worden, geen overtuigende argumenten. Moet een organisatie met andere software gaan worden omdat een (interne) leverancier dat wil? Daarom werd er iets bij verzonnen zodat een Business Case kon worden gepresenteerd. Het kwam erop neer dat organisatie breed meer gestandaardiseerd en dus meer efficiënt zou worden gewerkt. In de organisatie, die destijds ongeveer 140.000 mensen in dienst had, zouden 12.000 werkplekken gaan werken met de SAP-toepassing die vooral de logistiek functie zou moeten ondersteunen.

Een sterk vereenvoudigde weergave van de organisatiestructuur

Op basis van deze argumentatie werd SPEER gestart. Een eerste actie was de inhuur van een marktpartij die de “regiefunctie” voor zijn rekening zou nemen; dit werd een consortium van CAP Gemini en CMG. Hierbij was CAP Gemini de dominante partij; een positie die later nog versterkt werd omdat CMG in financiële problemen verkeerde en werd overgenomen door Logica, met de nodige fusieperikelen van dien.

De gemaakte fouten

Het is een typisch Tayloriaanse visie om een stafafdeling te laten bedenken hoe de werkvloer moet werken. Daar is hiervan ook sprake. Niet de logistiek medewerker, maar de IT-organisatie met een standaardpakket gaat bepalen hoe gewerkt zal gaan worden

Wanneer de fundering ondeugdelijk is, kan er nooit een goed huis worden gemaakt. De fundering van SPEER had dus o.a. de volgende gebreken:

• Omdat de IT-functie problemen heeft, moet de volledige organisatie zich aanpassen. Dit is natuurlijk het paard volledig achter de wagen spannen. Er was dus geen enkele logische aanleiding voor dit project, afgezien van de operationele problemen waarmee de CIO zich geconfronteerd zag.
• Om dit bezwaar enigszins te ondervangen, werd bedacht dat de organisatie gestandaardiseerd en dus efficiënter zou moeten werken. Dit argument zou het hart van de Business Case worden.
• De diverse Krijgsmachtdelen zullen zich per definitie verzetten tegen standaardisatie die zij niet zelf hebben bedacht. Voeg daaraan toe dat het Ministerie van Defensie van oudsher bekend staat om de stammenstijd tussen de diverse Krijgsmachtdelen. Elke stam zal de eigen standaard proberen op te leggen aan de andere stammen.
• Daarnaast is software er voor mensen en niet andersom. Draagvlak zal er daarom slechts in woord, maar niet in daad zijn. In een mechanistische visie op organisatiecultuur die kenmerkend is voor Taylorisme, worden deze gevoelens onvoldoende, of zelfs totaal niet onderkend.
• Op dezelfde wijze werd draagvlak voor SPEER vanaf het begin ondermijnd door het streven naar efficiëntie. Zeker in een organisatie waar opeenvolgende regeringen grote bezuinigingen doorvoerden, stond “meer efficiëntie” gelijk aan “banenverlies”. Gedurende de jaren dat men met SPEER voortploeterde, heeft de politiek diverse bezuinigingen doorgevoerd. Het ministerie werd enorm ingekrompen, wat uiteraard direct gevolgen had voor het verdere draagvlak van SPEER dat toch gericht was op meer efficiëntie?
• Verder valt ook het hiërarchische aspect niet te onderschatten. De verantwoordelijke voor SPEER kwam uit de Centrale Staf (die zich ook wel uitermate misleidend Bedrijfsvoering noemde). Zoals in elke organisatie staan centrale stafafdelingen bij de echte bedrijfsvoering, in dit geval de Krijgsmachtdelen, niet bepaald in hoog aanzien. Ze worden gezien als de rigide bureaucraten die met hun macht en procedures vooruitgang in de weg staan. Verder stond de toenmalige CIO als kolonel niet in de top van piramide. Een kolonel in een ambtelijke stafafdeling die moest bepalen hoe alle Krijgsmachtdelen zouden moeten gaan werken. Dat werd natuurlijk niet geaccepteerd. Zoals in hoorzittingen in 2014 ook weer duidelijk werd, is ook dit punt niet onderkend. Want Minister Hennis werd in de hoorzittingen nog altijd vergezeld door de CIO, een kolonel uit een ambtelijke stafafdeling.

Kortom, om het in PRINCE2 termen te stellen: er was geen Business Case die SPEER rechtvaardigde en er was geen sprake van de juiste Executive. En als wij het dan toch over rollen en verantwoordelijkheden hebben: de “regiefunctie” beleggen bij leveranciers (in dit geval Cap Gemini) is een ongekende blunder die helaas niet uniek is. Want iedereen begrijpt toch, zeker met kennis van PRINCE2, dat een leverancier een tegengestedle Business Case heeft?

Vooral in Tayloriaanse organisaties wordt een project gezien als een verzameling specialistische werkzaamheden waarover een specialist de leiding moet hebben en krijgen. Ook de Tijdelijke Commissie ICT o.l.v. Ton Elais borduurde hierop verder door de interne ICT-leverancier meer macht te geven met het BIT en te propageren dat binnen lijnorganisaties meer ICT-kennis moet worden opgedaan.

Defensie en PRINCE2?

Ten tijde van SPEER werd de overheid veel geld uitgegeven aan projectmanagementtrainingen volgens PRINCE2, de toen dominante aanpak. Helaas huurden de diverse ministeries, en vooral Defensie, trainers in die kwamen uit de wereld van onderhoud en beheer van ICT. Dat bleek ook duidelijk in de kwaliteit van de trainingen: er werd geen PRINCE2 maar PINO (PRINCE In Name Only) getraind, door personen die de methode niet begrepen aan personen op verkeerde niveaus die de methode niet konden toepassen. PRINCE2 is geen methode voor ICT-ers door ICT-ers. En ICT-beheer streeft naar stabiliteit terwijl projecten zijn opgezet voor verandering.

De overheid – en dus ook Defensie – heeft dus heel veel geld uitgegeven voor trainingen van lage kwaliteit die weinig effectiviteit opleverden. Saillant detail: de leverancier die veel geld heeft verdiend aan deze praktijk, werd geleid door dezelfde persoon die later de eerste CIO-Rijk werd.

Concluderend:

SPEER is een dramatisch project geweest dat vooral veroorzaakt werd door verkeerde belangen en een mechanistische aanpak, typerend voor een centrale stafafdeling. Door de nadruk te leggen op ICT als doel en niet als middel, werd er vanaf het begin niet nagedacht over ondersteuning van de organisatie maar over techniek. Voeg daaraan toe dat belanghebbenden vanaf het begin werden gedemotiveerd door “doelen” als efficiëntie en standaardisatie.

Hoe dan wel?

Om te beginnen moet gesteld worden dat het nog maar helemaal de vraag is of de PRINCE2 aanpak had gewerkt in een traject van deze omvang en complexiteit. Het was zeer waarschijnlijk te prefereren om een programmatische aanpak te kiezen. De realiteit was dat er bij SPEER geen enkele gestructureerde aanpak was te herkennen.

Maar laten wij, vooral ook omdat grote groepen bij Defensie een PRINCE2 training hadden doorlopen, SPEER eens benaderen vanuit een PRINCE2 perspectief. Dat doen wij in het volgende deel van deze blog.