Waarom projecten onderverdelen in kleine stappen

Er zijn 0 waarderingen

Project management, CRM, IT, netwerk infra, verander management

Als de invoering van nieuwe zakelijke software mislukt, wordt met vingers gewezen en komen de advocaten uit hun holen. Die dienen dan, zoals onlangs in het geval van SAP, een schadeclaim in die in de miljoenen loopt. Zorgvuldig plannen, duidelijke keuzes maken en doordacht implementeren kan blunders en peperdure rechtszaken voorkomen. Over het belang van heldere verantwoordelijkheden, doelen en contracten.

Uit Europees onderzoek van de Economist Intelligence Unit (EIU) in opdracht van BTO-producent Mercury, blijkt dat slechts 49 procent van alle technologische projecten tot een meetbaar zakelijk rendement leidt. De projectrisico’s worden het meest onderschat. Wanneer planningen en deadlines worden overschreden, loopt niet alleen de invoering van de nieuwe zakelijke software vertraging op, maar ontstaat ook bedrijfseconomische schade. Zo ontstaat een permanente opwaartse kostenspiraal, en komen bovendien de kerntaken van het bedrijf in de knel.

Na een vastgelopen IT-project ontstaat regelmatig een uitzichtloos meningsverschil tussen de klant en de softwareleverancier of de IT-dienstverlener die belast was met de invoering van de software. De partijen dagen elkaar voor het gerecht, en het uur van de advocaten heeft geslagen. Zo moest J.D. Edwards, inmiddels opgegaan in Oracle, in 2003 zijn teleurgestelde klant Evans Industries 1,8 miljoen dollar betalen, omdat de invoering van een groot ERP-project was mislukt.

Op zijn beurt klaagde doe-het-zelfketen Hornbach softwareconcern SAP aan, omdat bij de invoering van SAP-software problemen waren ontstaan. De bedrijven kwamen buiten het gerecht tot een vergelijk. Ook de Amerikaanse afvalverwerker Waste Management daagde onlangs SAP voor het gerecht. De schadeclaim voor levering van, naar verluidt, onbruikbare software bedraagt meer dan honderd miljoen dollar.

Maar wat gaat er dan fout bij IT-projecten? Consultants van Infora zien de belangrijkste problemen in eisen die gedurende de loop van een project verschuiven, gebrekkig projectmanagement en gebrekkige controlling, beperkte middelen en technische gebreken.

Over het algemeen zijn de problemen complex en veelzijdig, en heeft zowel aanbieder als gebruiker zijn huiswerk niet naar behoren gedaan. Er ontstaan vooral grote risico’s als er niet voldoende afspraken worden gemaakt over doelen en prestaties, en er niet voldoende wordt gecommuniceerd.

Helmut Strohmeier, directeur van de vakgroep IT-projectmanagement bij de DuitseMaatschappij voor Projectmanagement stelt dat implementatie van software vaak wordt gezien als “slechts” een IT-project, en niet als een project dat de gehele organisatie raakt. Door invoering van nieuwe zakelijke software veranderen echter ook processen en daarmee structuren binnen de organisatie, en worden tot op zekere hoogte ook verantwoordelijkheden opnieuw vastgesteld.

Hoe een softwarepakket ingrijpt in processen binnen een onderneming, staat volgens Helmut Strohmeier niet van tevoren vast. Daarom zijn de eisen niet van meet af aan specificeerbaar. Vaak wordt pas in de loop van een project duidelijk welke doelstellingen met een pakket behaald moeten kunnen worden.

“Het gaat erom deze leerprocessen zo goed mogelijk te organiseren”, legt Strohmeier uit. “Dat is ook het verschil met technische producten als auto’s of apparaten, waarvan de verschillende typen beter met elkaar vergeleken kunnen worden, en die precies zo geconfigureerd kunnen worden dat ze bepaalde doelstellingen halen.”

Al bij keuze en aanschaf van een pakket worden vaak fouten gemaakt. De eisen waaraan de nieuwe software moet voldoen zijn dan ongestructureerd geformuleerd, er wordt te weinig gebruikt gemaakt van de kennis van experts, of zakelijke beslissingsbevoegden zijn vooringenomen ten aanzien van bepaalde softwareproducten, wat tot “ideologisch” vernauwde, en vaak zelfs emotionele discussies leidt.

Daardoor worden beslissingen uitgesteld en ontstaan eeuwige projecten, die al mislukt zijn voor ze goed en wel zijn begonnen. Vaak wordt de keuze voor een product niet goed genoeg beargumenteerd, zijn argumenten niet helder, en worden beslissingstrajecten niet voldoende gedocumenteerd.

“Business en IT moeten het al in de aanloop naar een project eens worden over de selectieprocedure, die op een vergelijkbare manier wordt doorlopen als het invoeringstraject zelf”, legt Johannes Dorsch van IT-consultancybedrijf Experton Group uit. “Tijdpaden, acties en bevoegdheden van de zakelijke leiding moeten vooraf worden vastgelegd, en onderschreven door iedereen die bij het keuzeproces betrokken is. En ook actieve steun van de zakelijke leiding en het management zijn een absolute voorwaarde voor een succesvolle ondernemingsbrede implementatie van zakelijke software.”

Om kwalitatief hoogstaande en meetbare resultaten te behalen, moet absoluut gestructureerd te werk worden gegaan – bij de keuze voor een product, maar vervolgens ook bij de invoering ervan.

De keuze verloopt in meerdere stappen. Allereerst moeten de verdeling van verantwoordelijkheden en de procedure op elkaar worden afgestemd, moeten de eisen globaal worden gestructureerd en door de verschillende betrokkenen onderschreven, en moet een voorlopig functioneel ontwerp worden opgesteld. Op basis daarvan worden de inhoudelijke punten uitgewerkt, worden eisen geconcretiseerd en wordt het uiteindelijke functioneel ontwerp ondertekend.

Hierop volgt het proces van waardetoekenning. Daarbij worden alle eisen uit het functioneel ontwerp gewogen, wordt de markt geanalyseerd, worden mogelijke oplossingen beoordeeld aan de hand van rentabiliteitsprincipes en wordt een beslismodel ontworpen.

De meest voorkomende problemen bij lopende invoeringstrajecten betreffen een gebrek aan transparantie en sturing. Johannes Dorsch benadrukt: “Daarom is het van groot belang een gedetailleerd projectplan te hanteren, waarin alle handelingen, mijlpalen en verantwoordelijkheden zijn vastgelegd.”

De status van een project moet voortdurend opnieuw gepeild worden, om de voortgang te documenteren en te kunnen beoordelen. Afhankelijk van het type eis kan er gebruik worden gemaakt van een plan/feit-vergelijking, een trendanalyse of een verfijnde earned value-analyse. “Omwille van hun dynamiek en complexiteit moet bij IT-projecten regelmatig de voortgang van het project worden gepeild, evenals de problemen die optreden. Vervolgens moeten aanpassingen in de projectplanning en tegenmaatregelen snel worden opgestart en doorgevoerd”, bevestigt Experton-consultant Dorsch.

Daarvoor bestaan beproefde methodes. Een mogelijkheid biedt het “Project Management Office” (PMO), ofwel het projectbureau. De Amerikaanse projectmanagementgoeroe Tom DeMarco noemt dat de ‘war room’. Daarbij gaat het om een centraal organisatieonderdeel dat zorg draagt voor effectieve, vakkundige, tijdige en voordelige afwikkeling van projecten binnen een onderneming.

Tot de kerntaken van het projectbureau behoren onder meer de registratie van projectmatige basisgegevens en gegevens ten aanzien van afsprakenmanagement.

Medewerkers van het projectbureau stellen beoordelingen op van projectgegevens, printen en verspreiden projectplannen en verslagen. Ze stellen een databank op met projectgegevens en ervaringen, en houden deze voortdurend up to date. Het door hen onderhouden informatiesysteem vormt de basis voor alle beslissingen die door de projectleiding worden genomen.

Een andere optie is het gebruik van het Project Management Maturity Model (PMMM), het model dat in 1993 door het Software Engineering Institute van de Carnegie Mellon universiteit ontwikkeld werd uit het Capability Maturity Model voor softwareontwikkeling.

In het PMMM staat de eerste fase voor een ongedocumenteerde, niet reproduceerbare benadering van projecten, waarbij als het ware uit de losse pols gewerkt wordt. De vijfde fase staat voor een volledig geïmplementeerde, ondernemingsbrede standaard voor projecten, die voortdurend gecontroleerd en geoptimaliseerd wordt.

Hoe hoger het ontwikkelingsniveau is dat een organisatie bereikt, hoe sneller en hoe beter problemen onderkend en uit de weg geruimd worden. Net als binnen het kwaliteitsmanagement, is het doel te zorgen voor een continu verbeteringsproces voor het projectmanagement.

Een project zonder fouten bestaat niet. Daarom geldt: verantwoordelijkheden, prestaties en doelen moeten contractueel helder, bindend en eenduidig geregeld zijn, want het aanschaffen en invoeren van nieuwe zakelijke software is een strategische investering. Slecht uitgewerkte contracten maken van een investering een rommelende juridische vulkaan.

Er bestaat (in elk geval in Nederland) geen wettelijk vastgelegde contractvorm voor de aankoop en invoering van software. In de meeste gevallen bepaalt de softwareleverancier deze echter, bijvoorbeeld door middel van licentie- of gebruiksovereenkomsten. Voor de klant is van cruciaal belang dat er in het contract een formele afname van het ingevoerde softwareproduct of -systeem wordt vastgelegd.

Is dat niet het geval, dan wordt het contract beschouwd als een normaal koopcontract, en moet de overeengekomen prijs direct worden betaald. Mocht de software niet naar behoren functioneren, dan rust de bewijsplicht bij de klant. Met een juist geformuleerd contract kunt u deze klippen omzeilen.

Een contract begint met een beschrijving van de prestaties die de producent levert. Als klant is het heel belangrijk een dergelijke overeenkomst nauwkeurig te bestuderen; als je later aanpassingen wilt die van de standaard afwijken, dan wordt dat veelal een dure aangelegenheid.

Ook moet de klant van de opdrachtnemer (de producent of de IT-leverancier) eisen dat hij zijn prestaties vastlegt in een functioneel ontwerp en een eisenspecificatie. Dit kan bijvoorbeeld inhouden: levering inclusief onderhoud, installatie, aanpassing, scholing, datamigratie en ingebruikname.

Afspraken over te leveren diensten, bijvoorbeeld op het gebied van hosting- of outsourcingprojecten en ten aanzien van beschikbaarheid en uitvaltijd, moeten worden vastgelegd in een service level agreement. Eveneens van groot belang zijn de aansprakelijkheidsclausules. Waakzaamheid is geboden wanneer de opdrachtnemer over afzonderlijke clausules wil onderhandelen.

Maar niet alles valt contractueel te ondervangen. “In hun huidige vorm worden projectcontracten, aannemingscontracten bijvoorbeeld, niet opgesteld met het oog op het latere succes”, legt Helmut Strohmeier uit. Volgens hem gaat het er met name om zich tegen eventuele mislukkingen in te dekken, en daarvoor een schuldige aan te wijzen.

Zijn conclusie: “Bij IT-projecten met een hoge organisatiefactor moeten we af van de aannemingscontracten. Als we ze überhaupt afsluiten, dan alleen voor kleine deelprojecten, zoals de implementatie van een bepaald proces.” Opdrachtgever en opdrachtnemer moeten zich volgens hem vooral inspannen om de samenwerking voortdurend te blijven verbeteren. De belangrijkste ingrediënten daarvoor: wederzijds vertrouwen, en anders vormgegeven contracten.