SPEER - een alternatieve aanpak

SPEER – een alternatief

In het vorige deel van deze serie werd beschreven waarom en hoe SPEER tot zoveel problemen heeft geleid. De kernpunten waren:

Verkeerde redenen (Business Case): problemen met ICT-onderhoud en -beheer en hiervan afgeleid standaardisatie door ICT en efficiëntie.

Verkeerde sturing. ICT is een middel, geen doel (tenzij de betrokken organisatie een ICT-leverancier is). Daarom is het funest om de sturing bij een ICT-staforgaan te beleggen. Want deze organisatie is een interne leverancier, heeft dus een aan de lijnorganisatie tegenstrijdige Business Case en ziet ICT als doel. Voeg daaraan toe dat de regie belegd was bij een externe, commerciële leverancier en de meeste ingrediënten voor chaos en mislukken zijn aanwezig.

Door de omvang en complexiteit van de Defensieorganisatie, en dus van het project, werd ook de omvang van het mislukken exponentieel vergroot.

Laten wij, vooral ook omdat grote groepen bij Defensie een PRINCE2 training hadden doorlopen, SPEER eens benaderen vanuit een PRINCE2 perspectief. Daarbij moet direct worden aangetekend dat de PRINCE2 aanpak bepaald niet voor de hand liggend of aan te raden was geweest voor deze omvang en complexiteit. Maar wijze lessen kunnen wel worden getrokken.

ICT-projecten komen in de problemen omdat het ICT-projecten zijn

De basis - eindverantwoordelijkheid

De projecteigenaar - Executive

In de PRINCE2 gedachte kan een project alleen goed geleid worden als het einddoel duidelijk is: wat wil men met dit project bereiken? Dan is het noodzakelijk dat er ook iemand eindverantwoordelijk is voor de Business Case. De kern van de Business Case is een afweging tussen de verwachte baten en de verwachte kosten, zowel projectkosten als kosten van gebruik en beheer.

Het kan dan niet zo zijn dat een staffunctionaris de eigenaar is van de Business Case die alle gelederen van de organisatie raakt, waar baten en lasten dus vooral buiten het domein van die stafafdeling worden gerealiseerd. Vanuit een hiërarchisch standpunt is dit volstrekt onmogelijk. De eigenaar – wij praten niet over een sponsor want een sponsor zal zich nooit verantwoordelijk voelen – zal dan ook organisatie-overstijgende macht, dus over de domeinen waar de verandering plaatsvindt, moeten hebben om de eigenaar van de Business Case te kunnen zijn.

In het geval van SPEER had de CIO de leiding. Een principieel foute keuze.

Hoe dan wel?

De CFO is meestal de verkeerde keuze

Allereerst een grote misvatting. De “baas” van een project, de Executive, is de eigenaar van de Business Case. Een Business beschrijft de zakelijke rechtvaardiging; het hart van de Business Case is een kosten/batenanalyse.  De verwachte baten worden afgezet tegen de kosten van het project en tegen de kosten van gebruik, onderhoud en beheer.

In de dominante Tayloriaanse cultuur wordt daarom de Business Case vaak gekoppeld aan de financiële afdeling en wordt vaak een CFO als Executive genoemd. Dit is een zeer ernstige misvatting. De afdeling Financiën doet niet veel meer dan de boekhouding en is niet verantwoordelijk voor baten en kosten; als stafafdeling registreren zij slechts. De CFO is, net als de CIO, een stafmedewerker. Uit deze hoek kan slechts een Executive komen wanneer het project zich binnen dit domein afspeelt, bijvoorbeeld een project om te komen tot een nieuw financieel systeem.

Een Business Executive

Wanneer de logica van het bovenstaande wordt gevolgd, zal de conclusie eenvoudig zijn. De Executive van dit project zou de topman van het ministerie moeten zijn. Dit is niet de politiek verantwoordelijke, de minister, maar de hoogste operationeel verantwoordelijke persoon. Elk ministerie kent een topambtenaar direct onder de minister. Bij het Ministerie van Defensie is dit een militair: de Commandant de Strijdkrachten (CdS).

Maar wanneer deze persoon wordt gevraagd om de eindverantwoordelijkheid te nemen voor een “IT-project” zal er direct een voorspelbaar probleem opdoemen. Want IT-projecten moet je overlaten aan IT-specialisten. De CdS zal dus onmiddellijk doorverwijzen naar de CIO waarmee het probleem dus weer terug is. Over SPEER heb ik ook een verkorte reactie gepubliceerd op ManagementSite met als titel: “ICT-projecten komen in de problemen omdat het ICT-projecten zijn”.

Hierin ligt de kern van het probleem maar ook de oplossing. Wanneer de CdS zou zijn benaderd met de vraag waar de meeste problemen optreden, zou weleens gewezen kunnen worden naar de logistiek van de vele buitenlandse missies. Wanneer wordt besloten om dit aan te pakken, met nadruk op organisatie en met een ondergeschikte rol voor IT (als middel en niet als doel!), ontstaat een veel minder risicovol project met veel meer draagvlak binnen de organisatie. Er is dan sprake van een project waarvan de rechtvaardiging duidelijk is en gedragen wordt; er is dan sprake van een Business Case! Met deze aanpak is er geen sprake meer van een IT-project.

Verantwoordelijk voor de baten – Senior User

Verreweg de belangrijkste vraag bij verandering en de focus van “Stakeholder management” is: Wat heb ik eraan? What is in it for me?

Ook hier is de typisch Tayloristische aanpak niet de beste want die gaat uit van wantrouwen en geeft daarom de belangrijkste belanghebbende, zij die moeten gaan veranderen, geen belangrijke stem. In “ICT-projecten” resulteert dit meestal in gebrekkig draagvlak en weinig bruikbare bijdragen waardoor de ICT-experts dan maar gaan verzinnen wat gemaakt moet gaan worden.

Het PRINCE2 model stelt daarom dat in een Stuurgroep (Project Board) een rol verantwoordelijk moet worden gesteld voor de specificatie van wat het project zal moeten leveren. Dat wordt, als het goed is direct afgeleid, van de geplande baten van het project.

Dit is in het kort de rol van de Senior User; eindverantwoordelijk van de te realiseren baten en daarmee eindverantwoordelijk voor de specificatie van de gewenste kwaliteit van het project.

In het geval van SPEER ligt het dan voor de hand om voor elk organisatiedeel een Senior User in de Stuurgroep op te nemen.

SPEER Stuurgroep

Overigens gaat het PRINCE2 model op dit punt ernstig mank; omdat de Senior User eindverantwoordelijk is voor alle baten binnen zijn/haar domein, zijn er dus topfunctionarissen nodig. Wanneer zowel Executive als Senior Users zich zo hoog in de hiërarchie bevinden en zich zo ver van de werkvloer bevinden, is te verwachten dat de Stuurgroep niet optimaal zal functioneren. Een alternatief is dat de Stuurgroep enorm wordt uitgebreid zodat meer operationele manager besluiten kunnen nemen. Maar dit zal dan de consequentie hebben dat de Stuurgroep onwerkbaar groot zal worden. Een ander alternatief, een User Board als adviesorgaan van de Senior User, zal om dezelfde reden bij de omvang van dit project ook niet of nauwelijks werken. Kortom: PRINCE2 is voor de omvang van PRINCE2 niet bepaald een geschikte aanpak. Het MSP-model zou mijn voorkeur genieten.

ICT-kennis?

Maar gebruikers hebben geen benul van ICT. Waarom zou dan een Senior User beslissingen kunnen nemen over ICT in een ICT-project? Nogmaals: ICT is een middel en geen doel (behalve dan voor ICT-leveranciers). Gebruikers hoeven niets van ICT te weten; zij weten heel goed hoe hun processen moeten weten ingericht en ICT dient dit te ondersteunen. ICT-ers kunnen hierbij in de rol van leverancier suggesties maken. Maar de beslissing ligt aan de gebruikerskant; daar ligt immers ook de verantwoordelijkheid voor de realisatie van de baten.

Management Fases

Als wij deze praktische problemen van het toepassen van PRINCE2 even terzijde leggen en ons concentreren op de rolverdeling en andere aspecten van de aanpak, dan is een ander significant idee te overwegen: het werken met Management Fases.

Stel dat SPEER op de volgende wijze wordt opgedeeld in Management Fases. Eerst wordt concentreert het project zich op de Landmacht. Daarna komt de Luchtmacht aan bod en wanneer dit deel is afgerond, is de Marine aan bod. Tenslotte is het aan de Marechaussee en de Centrale Staf.

SPEER met Management Fases

 

Een flexibele Stuurgroep

Deze opzet heeft consequenties voor de projectorganisatie. Gedurende het project zal de Stuurgroep wijzigen want per Fase komen andere gebruikers (en mogelijk andere leveranciers) aan de orde. Theoretisch binnen het PRINCE2 model is dit geen enkel probleem. Is deze opzet praktisch ook werkbaar? Als startpunt zeker maar gezien de omvang van SPEER zal deze structuur nog te grof zijn. Het doel is om aan te tonen dat ook een Stuurgroep flexibel dient te zijn en naadloos moet aansluiten op de materie waarover beslissingen moeten worden genomen. 

Dit is een inefficiënte werkwijze!

Vanuit de Tayloriaanse denkwijze is dit een logische reflex. Deze aanpak zal erin resulteren dat elke organisatiedeel een eigen visie zal implementeren. Een standaardoplossing is hiermee minder waarschijnlijk en het zou zelfs kunnen resulteren in verschillende SAP-implementaties.

Maar is dit echt een probleem? Het huidige SPEER is zeer ineffectief en gebruikers zijn zeer ontevreden. De opbrengsten zullen daardoor ondermaats zijn. Ook zullen de kosten voor onderhoud en beheer, met vele wijzigingsverzoeken, erg hoog zijn.

De gefaseerde aanpak had een veel sneller en goedkoper project opgeleverd dat een hogere kwaliteit had opgeleverd. En dus hogere opbrengsten en lagere kosten van gebruik, onderhoud en beheer. Het toont meer weer eens aan dat de typisch Tayloriaanse denkwijze die zich richt op efficiëntie met stafafdelingen (in dit geval de CIO) als drijvende krachten slechts kostbare schijnefficiëntie oplevert. Echte efficiëntie is slechts een bijproduct van effectiviteit. Dat is de kern van deze serie over organisatiecultuur.

Overigens is het natuurlijk wel verstandig om op een lager niveau een vorm van consistentie te bewaken. Hier ligt een belangrijke rol voor de (toekomstige) leverancier van onderhoud en beheer. Wanneer deze eenheid geen leveranciersrol (Senior Supplier) binnen het project heeft, is het sterk aan te raden om als Senior User vertegenwoordigd te zijn gedurende het volledige project. Maar dat zal dan niet gaan om producten die de eindgebruiker direct raken. Het zal gaan om meer technische producten die nodig zijn om flexibiliteit en effectief onderhoud en beheer mogelijk te maken.

Over de auteur

Specialist in effective change.

Accredited MSP™ and PRINCE2® trainer.

comments powered by Disqus