De zes steden die zijn aangesloten bij de samenwerking Drechtsteden moeten gezamenlijk meer dan twee miljoen euro betalen om oude applicaties in de lucht te houden. Eigenlijk had het servicecentrum Drechtsteden (SCD) in 2009 al moeten werken met een nieuw platform. Er zou sprake zijn van een misrekening in de business case.
Een misrekening in de business case zorgt ervoor dat het samenwerkingsverband Drechtsteden meer dan twee miljoen extra moet betalen aan ict. In de berekening was opgenomen dat de Drechtsteden al in 2009 van een gezamenlijk ict-platform gebruik konden maken. Dat blijkt 2010 te zijn. Binnen de samenwerking zijn de steden Alblasserdam, Dordrecht, Hendrik-Ido-Ambacht, Papendrecht, Sliedrecht en Zwijndrecht aangesloten.
Het gaat om de business case die is gemaakt voor het Servicecentrum Drechtsteden. Dat bedient de zes aangesloten steden, maar ook de regio Zuid-Holland Zuid en de Gemeenschappelijke Regeling Drechtsteden. In dit centrum zijn medewerkers van de aangesloten gemeenten ondergebracht die werkzaam zijn op het gebied van financiën, personeelszaken, communicatie en ict. Acht ict-organisatie moeten worden teruggebracht naar één. Het gaat om honderden applicaties die de acht organisaties gebruiken. Woordvoerster Paulien Schildhuizen kan niet zeggen van welke leverancier het platform is. "De bedoeling was dat we in 2009 al met het platform konden werken. Nu blijkt dat het systeem in 2010 klaar is en overal kan worden geïmplementeerd", zegt ze.
Beheer
Een groot deel van de twee miljoen gaat zitten in het beheer van de overige systemen, zegt wethouder Hans Tanis van de gemeente Sliedrecht. Binnen het samenwerkingsverband Drechtsteden is hij verantwoordelijk voor de automatisering. Volgens hem is een misrekening niet de enige reden dat er extra budget nodig is. "Achteraf bleek dat er bij de gemeenten meer applicaties draaien dan dat ze bij het maken van de businesscase hebben aangegeven", aldus Tanis.
Het is nog niet duidelijk wie het geld gaat ophoesten. Waarschijnlijk wordt dat door de gemeenten gedaan, denkt Tanis. Het samenvoegen van de verschillende afdelingen van de zes gemeenten moet vanaf 2011 tussen 6,5 en 7,5 miljoen euro per jaar gaan opleveren.
“Achteraf bleek dat er bij de gemeenten meer applicaties draaien dan dat ze bij het maken van de businesscase hebben aangegeven”, aldus Tanis.
“Hebben aangegeven” ??? Als uitvoerende organisatie voer je zelf toch deze inventarisatie uit !. En dat met al die mooie beschikbare tools die dit voor je in kaart brengen. Jammer voor de burger die dit uiteindelijk zal moeten ophoesten.
Gelukkig werk ik bij een professionele organisatie die projecten Fixed-Price/Turn-Key en met resultaat-verplichting uitvoert. Duidelijkheid voor de klant over doorlooptijden en financien.
Aardige reactie van Mees, maar niet helemaal mijn mening. Ik denk dat het uitvoeren van projecten met een resultaatverplichting op basis van fixed price altijd een wisselwerking zijn tussen een professionale opdrachtgever en professionele opdrachtnemer. Dit kan nooit alleen het probleem zijn van de uitvoerder.
Ik denk dat de kern van het probleem meer is gelegen is de wijze van beheersen van de risico’s. Hiermee had het probleem misschien niet kunnen worden voorkomen, maar was het vooraf beter in kaart geweest wat de risico’s waren. Als dit was verwerkt in een betere business case was het nu waarschijnlijk niet zo’n probleem geweest.
Allemaal onzin. Het grote aantal vertrokken vaste personeelsleden ivm ongenoegen is een van de belangrijkste problemen. Het over de TOP inhuren van niet samenwerkenden (te dure) consultants heeft dit tot gevolg. 2 miljoen is niet het juiste bedrag. Dit bedrag ligt veel hoger.
DE BUSINESS CASE:
BUSINESS CASE KOSTEN,BATEN OF IS ER MEER?
Een van de belangrijke kenmerken van Projecten/Programma’s is de aandacht voor de Business case. De Business case geeft de zakelijke rechtvaardiging voor een Project en Programma. Het is voor Projecten/Programmas essentieel om te weten hoe de kosten van Projecten/Programma’s zich verhouden tot de inkomsten, wat de Opdrachtgever beoogt te bereiken met het Project/Programma” s resultaat en hoe groot daarbij de risico’s zijn. Wegen de kosten en de risico’s niet op tegen de te verwachten baten, dan is er geen valide Business case en is er ook geen reden om met het Projecten/Programma’s te starten.Blijkt gedurende de uitvoering van het Project/Programma?s dat er geen valide Business case meer is, dan moet het Project/Programma alsnog gestopt worden. Het Project/Programma kan dan alleen worden voortgezet in een alternatieve vorm, als daarvoor wel een positieve Business case is. De Business case moet worden opgesteld aan het begin van het Project/Programma en moet gedurende de looptijd van het Project/Programma regelmatig worden geactualiseerd. Van alle belanghebbenden van een Project/Programma wordt verwacht dat zij (meetbare) informatie aanleveren die van belang kan zijn voor de Business case of het halen van de doelstellingen van de Business case.
WELKE INFORMATIE MOET DE BUSINESS CASE BEVATTEN?
De Business case is de beschrijving van de zakelijke rechtvaardiging voor het uitvoeren van het Project/Programma, op basis van kosten en baten van het Project/Programma en de bijbehorende risico’s. Daarbij moeten alle veranderingen die het gevolg zijn van het in gebruik nemen van het Project/Programma resultaat in de afweging worden meegenomen. Het gaat niet alleen om de directe veranderingen die optreden, maar om ALLE effecten die het gevolg zijn van het in gebruik nemen van het Project/Programma resultaat.
IN DE BUSINESS CASE DIENEN DE VOLGENDE ONDERWERPEN IN IEDER GEVAL BELICHT EN GECONCRETISEERD TE WORDEN:
Redenen – hierbij worden de redenen voor het Project/Programma uitgewerkt. Deze redenen moeten in het Project/Programma mandaat zijn beschreven. Is dit niet het geval, dan moeten de redenen worden uitgezocht en beschreven. Ook is het belangrijk hierbij de sense of urgency aan te geven.
Opties – de verschillende alternatieven die zijn bekeken om de beschreven redenen/doelstellingen van de Opdrachtgever te realiseren, inclusief de redenen waarom er niet voor is gekozen. Bij deze opties altijd de nuloptie meenemen: wat gebeurt er als we niets doen? De nuloptie geldt als basisoptie voor de Business case. De andere opties worden met de nuloptie vergeleken.
Baten – hierin wordt een overzicht gegeven van de te realiseren baten/opbrengsten die met het op te leveren resultaat behaald kunnen worden. De verschillende baten moeten concreet en meetbaar worden geformuleerd. De baten moeten altijd worden gedefinieerd ten opzichte van de nuloptie. Ook is het belangrijk om een inschatting te geven wanneer een bate kan worden verwacht en hoe deze te meten is. Ook het verdwijnen/verminderen van huidige inkomsten of een verhoging van de huidige exploitatiekosten moet worden meegenomen als baten, maar dan als nadeel ofwel als negatieve baten. Bij de inschatting van de baten is het belangrijk meerdere scenario’s door te rekenen: een optimistisch, een gemiddeld en een pessimistisch scenario. Dit wordt ook wel een GAP-analyse genoemd (Good-Average-Poor).
Risico’s – opsomming van de belangrijkste risico’s die een aanzienlijke impact kunnen hebben op het Projecten/Programma’s. Denk hierbij aan risico’s die betrekking hebben op mensen, locatie, organisatie, diensten en processen en niet alleen risico’s van infrastructuur, gegevens en applicaties. Details van de risico’s worden in het Risicologboek weergegeven en kunnen hier worden weggelaten.
Kosten en tijdlijn – in de Business case wordt een overzicht gegeven van de kosten die het uitvoeren van het Projecten/Programma’s met zich meebrengt. Ook moet hierbij worden aangegeven wanneer deze kosten worden gemaakt. Deze informatie wordt verkregen uit het Projecten/Programma plan. Het kan nodig zijn deze informatie in meer detail weer te geven in de Business case, vooral wanneer een gefaseerd budget wordt toegekend aan het Projecten/Programma’s. Dit wordt voornamelijk toegepast bij Projecten/Programma’sen die een lange looptijd hebben.
Investeringsaanvraag – dit is het verzoek om de investering voor het Projecten/Programma’s goed te keuren en daarmee de uitvoering van het Projecten/Programma’s goed te keuren op basis van de afweging van de geraamde kosten, baten en risico?s van het Projecten/Programma’s. Centraal staat de vraag of de verwachte baten over de Project/Programma levensduur de te maken investering in het Project/Programma rechtvaardigen. Hiervoor is het noodzakelijk om de baten concreet en meetbaar te definieren.
Er zijn vele manieren om de Business case op te stellen. Vaak is dit afhankelijk van de gebruikte standaard. Ook is het belangrijk om te kijken of het Project/Programma erg afhankelijk is van een specifieke bate. Het kan dan noodzakelijk blijken om deze bate extra in de gaten te houden en hier specifieke afspraken over te maken. Er kan bijvoorbeeld worden afgesproken om extra aandacht aan dit aspect te geven in de reguliere rapportages of er specifiek over deze bate meer frequent zal worden gerapporteerd.
BUSINESS CASE VAN DE KLANT EN VAN DE LEVERANCIER
Naast de klant heeft ook de leverancier in het Project/Programma een Business case. Voor de leverancier moet er ook een zakelijke rechtvaardiging zijn om aan het Project/Programma mee te doen. De Business case van de leverancier is meestal het rendement van de opdracht zelf, maar kan ook de te verwachten stijging van de omzet op lange termijn zijn. Bijvoorbeeld als dit Projecten/Programma’s een voorbeeld Project/Programma is, of als de leverancier zich met dit Project/Programma een sterkere positie in de markt kan verwerven.
Wanneer bij een Project/Programma gesproken wordt over een Business case, dan wordt daarmee meestal de Business case van de klant bedoeld.
De Business case van de klant wordt ook vaak Total Cost of Ownership genoemd. De Business case van de leverancier wordt ook vaak de Integrale kostprijs genoemd. Deze begrippen worden door verschillende organisaties verschillend gedefinieerd en kunnen daarmee afwijken van de eigenlijke definitie van Business case.
ONTWIKKELEN VAN DE BUSINESS CASE
De Business case voor een Project/Programma wordt vaak al gemaakt voordat het eigenlijke Project/Programma van start gaat. De eerste opstelling van een Business case kan onderdeel zijn van het jaarlijkse proces om het businessplan van de organisatie voor het komende jaar/jaren op te stellen. Het kan ook onderdeel zijn van de Business case van het programma waarvan het Project/Programma een onderdeel is. Vaak wordt er, voordat het Programmamandaat wordt gegeven, ook eerst een haalbaarheidsstudie gedaan voor de verschillende opties. Per optie wordt dan de betreffende Business case opgesteld, van waaruit het management de keuze maakt om het eigenlijke Projecten/Programma’s uit te voeren.
Er is dus al vaak een Business case voordat het Project/Programma start. In dat geval hoeft in het Project/Programma zelf de Business case alleen te worden geactualiseerd en te worden uitgewerkt. Het kan echter ook zo zijn dat er bij de Project/Programma aanvraag er nog geen Business case is. In dat geval zal de Business case moeten worden opgesteld in het Project/Programma.
De Opdrachtgever is eigenaar van de Business case en daarmee verantwoordelijk voor de ontwikkeling hiervan. Hij beoordeelt de doelstelling, kosten, baten en risico?’ in de Business case, en of de Business case past binnen de strategische doelstellingen van de lijnorganisatie of het programma. De Opdrachtgever is ook degene die ervoor verantwoordelijk is dat de gedefinieerde doelstellingen, na het opleveren van het Project/Programma resultaat, ook werkelijk worden gerealiseerd.
Het maken van de Business case kan worden uitgevoerd door de Project/Programma manager. Dat hoeft echter niet. De Project/Programma manager moet er wel op toezien dat er een Business case is en hij moet voor de Opdrachtgever wel de uitgangspunten van de Business case bewaken.
Voor een groot en gecompliceerd Project/Programma zal een groep van specialisten nodig zijn om de Business case op te stellen. In een klein Project/Programma zal een persoon al voldoende kunnen zijn. Soms is het verstandig om een overleg met (alle) stakeholders te beleggen om de informatie te verkrijgen om de Business case op te stellen.
Belangrijk is om aan het begin van het Project/Programma een nulmeting te doen voor het bepalen van de huidige stand van de gedefinieerde doelstellingen. Deze meting moet elke keer, als de Business case wordt geactualiseerd, worden herhaald. Op basis van de nulmeting kan de nuloptie en de verwachte toegevoegde waarde van het huidige Project/Programma opnieuw worden doorgerekend en vergeleken. Op deze wijze kan worden nagegaan of er nog steeds een zakelijke rechtvaardiging is om het Project/Programma voor te zetten.
De Project/Programma voorbereiding start met de Project/Programma aanvraag op basis van het Project/Programma mandaat. In het Project/Programma mandaat moet de klant eigenlijk al de redenen aangeven waarom het Project/Programma noodzakelijk is. Tijdens de Projecten/Programma voorbereiding zal de Project/Programma manager de hoofdlijnen van de Business case in het Project/Programma voorstel vastleggen, aangezien deze hoofdlijnen mede de basis zijn waarop de Stuurgroep moet beslissen. De Business case moet voldoende informatie bevatten, zodat de Stuurgroep weloverwogen kan beslissen of er een voldoende basis is voor het Project/Programma.
Na afronding van het Project/Programma wordt de Business case gebruikt om na te gaan of met het Project/Programma resultaat de baten worden gerealiseerd die waren voorzien. Dit kan echter niet direct bij de oplevering van het Project/Programma worden vastgesteld. Allereerst moet het resultaat een tijd in gebruik zijn, voordat kan worden vastgesteld of de verwachte baten ook daadwerkelijk worden gerealiseerd. Bij afronding van het Project/Programma wordt tevens voor de laatste keer de nulmeting bijgewerkt.
Deze laatste meting is uitgangspunt voor de post Project/Programma review. De Opdrachtgever is ervoor verantwoordelijk dat de baten ook daadwerkelijk worden gerealiseerd. Door middel van een post Project/Programma beoordeling moet dit worden aangetoond.
De Project/Programma manager is verantwoordelijk voor het inplannen van de post Project/Programma beoordeling en het opstellen van een plan voor de post Projecten/Programma beoordeling voordat het Project/Programma wordt opgeleverd.
MISREKENING ICT KOST DRECHTSTEDEN TWEE MILJOEN?
KOMT HET VAKER VOOR DAT ER EEN ROOSKLEURIG BUSINESSCASE WORDT GESCHREVEN?
HOE KAN DAT?
HOE KUN JE DAT VOORKOMEN?
ANALYSE BC DRECHTSTEDE
Aan de hand van de verwijzing https://www.computable.nl/artikel/ict_topics/beleid/2914894/2379250/misrekening-ict-kost-drechtsteden-twee-miljoen.html heb ik voor het beantwoorden van de vragen e.e.a geanalyseerd en als volgt samengevat.
INLEIDING:
Het gaat om de business case die is gemaakt voor het Servicecentrum Drechtsteden. Dat bedient de zes aangesloten steden, maar ook de regio Zuid-Holland Zuid en de Gemeenschappelijke Regeling Drechtsteden. In dit centrum zijn medewerkers van de aangesloten gemeenten ondergebracht die werkzaam zijn op het gebied van financi?n, personeelszaken, communicatie en ict.
DOEL EN RESULTAAT PROJECT:
A. De acht ict- organisaties moeten worden teruggebracht naar ??n.
B. Het samenvoegen van de verschillende afdelingen van de zes gemeenten moet vanaf 2011 tussen 6,5 en 7,5 miljoen euro per jaar gaan opleveren.
ONTSTANE PROBLEMATIEK:
1. De zes steden die zijn aangesloten bij de samenwerking Drechtsteden moeten gezamenlijk meer dan twee miljoen euro betalen om oude applicaties in de lucht te houden. Het gaat om honderden applicaties die de acht organisaties gebruiken. Een groot deel van de twee miljoen gaan zitten in het beheer van de overige systemen.Er blijken dat bij de acht gemeenten meer applicaties draaien dan dat ze bij het maken van de businesscase hebben aangegeven.
2. In de berekening was opgenomen dat de Drechtsteden al in 2009 van een gezamenlijk ict-platform gebruik konden maken. Dat blijkt 2010 te zijn.
3. Woordvoerster Paulien Schildhuizen kan niet zeggen van welke leverancier het platform is. “De bedoeling was dat we in 2009 al met het platform konden werken. Nu blijkt dat het systeem in 2010 klaar is en overal kan worden geimplementeerd”, zegt ze.
Het is nog niet duidelijk wie het geld gaat ophoesten. Waarschijnlijk wordt dat door de gemeenten gedaan, denkt Tanis.
GEVOLGEN:
Een misrekening in de business case zorgt ervoor dat het samenwerkingsverband Drechtsteden meer dan twee miljoen extra moet betalen aan ict.
CONCLUDEREND:
Kan je stellen dat de reden van decentralisatie naar een centrale ICT platform een goede reden is en dat de verwachte jaarlijkse kostenbesparingen van 6,5 en 7,5 miljoen met de investeringsaanvraag valide is. Ik hoop wel dat het verschil van 1 miljoen in deze mededeling niet waar is. Ik neem ook aan dat in het vooronderzoek alle opties zijn bekeken en dat men de juiste keuze heeft gemaakt. In het schrijven wordt niet gemeld of er nog andere alternatieven waren. En of er gekeken is naar de risico’s.
In ieder geval heeft men wel gekeken naar de tijdslijn en daar al een indicatieve planning 2009 voor afgegeven.
IN COMPLETE BEREIK OFWEL SCOPE PUNT 1 EN 2
De vraag nu is bij punt 1 of er wel een misrekening heeft plaatsgevonden, zoals wordt gesuggereerd? Ik denk in beginsel niet. Het projectteam heeft op basis van het opgegeven bereik (scope) een calculatie gemaakt en waarschijnlijk een kloppende berekening gemaakt voor beheer. Echter het project en de beheerorganisatie zijn verrast (!) doordat het uitgangspunt afweek van de werkelijkheid. Het bereik (scope) bleek vele malen groter dan gecalculeerd.
De kosten (buiten de extra projectkosten) voor deze beheer post ligt dus 2 miljoen hoger dan verwacht. M.a.w de beheerskosten moeten opnieuw gewaardeerd worden in relatie met de verwachte baten van 6,5 en 7,5 miljoen.
Let op
Deze twee miljoen zijn beheerskosten die vanuit lijnmanagement betaald moeten worden. Deze kosten vallen uit het bereik (scope) van het project. Het project heeft enkel ?en alleen als resultaat om acht ICT afdelingen naar een platform te brengen en deze over te dragen aan de beheersorganisatie. Dit valt niet meer onder de verantwoording van het project. Bij overgang hoort het project ontmanteld te worden.
TIJDSBEREKENING 3
Als gevolg van de incomplete scope uit de punten 1 en 2 maakt het nogal logisch dat er een tijdtekort plaatsvond. Mogelijk was het project op basis van het 1e bereik (scope) op tijd geweest. De ontdekking van de nog niet in kaart gebrachte applicaties maakte het noodzakelijk voor het project om door te starten en een 2e oplevertijd van 2010 af te geven. Kortom, een andere oplevertijd is een gevolg van de punten 1 en 2.
ORGANISATIE 3 EN 4
Wat wel zorgelijk is dat ze niet weten wie de leverancier is van het platform en hoe de organisaties e.e.a gaan verrekenen. Of willen ze dat niet vermelden in het artikel? Als er een goede projectorganisatie met stuurgroep aanwezig is dan kent men haar stakeholders om de vernieuwde situatie te bespreken en te herzien qua business case. Het is duidelijk dat er wijziging heeft plaatsgevonden met consequenties op de business case. De BC dient dan ook in de fase herberekend te worden met het aanpassen van het project plan en wat er al zoal bij hoort.
ROOSKLEURIGE BUSINESS CASE?
In deze case kan je niet zeggen dat de BC te rooskleurig is beschreven. De BC was niet compleet door het missen van de juiste complete informatie. Namelijk de compleetheid van het juiste bereik (scope). Deze fout zal consequenties hebben op de eerdere berekeningen. Echter gezien de jaarlijkse besparingen van 6,5 of 7,5 miljoen lijkt me de gedane keuze een goede. De return of investment zal mogelijk iets langer duren maar op termijn winst opleveren.
KOMT EEN ROOSKLEURIGE BC VOOR?
Ik zie een rooskleurige BC meer als de realiteitswaarde ontkracht wordt door een bewuste gecre?erde tunnelvisie om iets te hebben of te doen en dit willens ?en wetens adviezen te negeren. De rationaliteit wordt uitgeschakeld/ontkracht en de BC houders denderen maar door totdat ze hun doelen hebben bereikt. Dit zie je in het bedrijfsleven en overheden. Bij de laatste groep valt het meer op door het openbaar politieke bestuur en de grootschaligheid. Actueel is nu de aanschaf van de JFS s.
KOMT DIT DAGELIJKS VOOR?
In het bedrijfsleven/overheid of priv? . Iedereen heeft of vind wel zijn/haar emotionele redenen om een persoonlijke wens om te zetten in een rooskleurig verhaal en deze te vertalen naar meetcriteria. Wie kent niet de geluiden als:
Ik heb niet de juiste kleur blouse of schoenen bij mijn rok
Of die stereo-installatie of die doos gereedschap is het einde
Een eigen boot of caravan lijkt ons ideaal, kunnen we elk weekend?..en in de vakantie
Dat huis wat we gezien hebben is geweldig?..die oude keuken en rotte schuur stelt niets voor
In het bedrijfsleven gaat het niet anders daar heeft men andere redenen
Wetgeving dwingt ons..
Oude techniek beperkt ons..
Kostenbesparing is nu nodig en daarom gaan we centraliseren..
Er moet een tunnel komen, we kunnen die veldmuis niet verdrijven door een weg..
Een SAAB straaljager kan echt niet. Deze is 1 decibel luider dan de JFS
We moeten als overheid een railverbinding hebben (naast een kanaal) van ?naar..
De regering of raad van bestuur heeft besloten?.
MAAR KUNNEN WE HIER WAT AAN DOEN?
Ja, we kunnen hieraan wat doen door een objectieve meting aan de BC te koppelen die de emotie eruit haalt en de BC een zekere mate van realiteitswaarde geeft. Dit begint al bij het maken van een strategie en missie (0). Dit kan beschouwd worden als de embryonale fase van een verandering. Een verkeerde niet onderbouwde strategie en missie levert al per direct een gevaar op voor de nabije toekomst. Omdat op basis van de missie en visie de BC wordt gemaakt om de gewenste verandering van de organisatie tussen heden ?en toekomst te beschrijven in een `blauwprint` en deze via projecten/programma?s te realiseren. De uitkomsten en resultaten kunnen dan weleens tegenvallen.
Daarom dient de BC goed in de gaten gehouden te worden en telkens worden geijkt op de dan geldende maatstaven. De wereld om ons heen verandert snel en kan in de historische tijd gemaakte plannen nog wel eens achterhalen. Dit betekent je doelen en het project of programma bijstellen.
STANDAARD FOUT BIJ HET MAKEN VAN DE BC (OOK BIJ DRECHTSTEDEN)
In de pre-projectfase of aanbesteding wordt een project gecalculeerd op het dan bekende bereik ofwel scope. In de gunningfase speelt de inkoop een cruciale rol door op basis van NEVI 1 en 2 technieken ?het vet van de botten? uit te onderhandelen. Na gunning krijgt de opdrachtnemer het project of programma in handen en zal wel/niet professioneel e.e.a voorbereiden en onderzoeken om een duidelijk beeld te hebben of te krijgen over (1) heden, (2) toekomst ?en de (3) verandering met haar doelen en resultaten.
Als de punten 1,2 en 3 niet helder/volledig en geaccordeerd zijn kan je nooit een betrouwbare ?en in balanszijnde berekening maken op de overige stuurmiddelen als organisatie, tijd ?en budget. Meetbare kwaliteit hoort hier dan ook bij.
Bij Drechtstede heeft men ook de punten 1,2 en 3 niet zorgvuldig ingevuld. Ze wisten niet hoeveel applicaties er heden (1) waren. Ze wisten wel waar ze naar toe wilden (2), namelijk ??n platform. Maar de verandering (3) was door het missen van de huidige situatie (1) incompleet, met als gevolg tijdsoverschrijding van 2009 naar 2010 en een veranderde BC met haar waarden. Een onafhankelijk Quality Assurance met BC toetsing bij dit project had dit opgemerkt en vooraf kunnen herstellen.
HOE TE VOORKOMEN?
Professioneel project/programma management met kwalitatieve sturing in combinatie met een BC en juiste organisatorische competenties had dit risico ernstig verlaagd. Binnen de overheid is nu een pilot gestart om GATEWAY (een soort beoordelingssysteem van OGC) in te voeren voor dergelijke ICT projecten. Het GATEWAY model zal binnen de overheid intern ?en zonder gebruikmaking van externen gebruikt gaan worden. Mogelijk komen er later externen bij.
Onder het model ligt PRINCE2 en MSP. M.a.w als je goed projecten kan doen met gebruikmaking van genoemde methodieken dan krijg je de uitkomsten waar GATEWAY naar vraagt vica versa. Het initiatief is goed maar de ?slager moet niet vrijblijvend zijn eigen vlees keuren?