4 De spagaat van ICT-projecten Peter Blom
ICT-projecten worden voortdurend geconfronteerd met de uitdaging om de vraag van een gebruiker te vertalen naar een uiteindelijke levering van een ICT-dienst. Waarom is deze uitdaging nu zo moeilijk? Uit de praktijk blijkt dat de verschillende werelden van de bedrijfsgerichte vrager, de technisch ingestelde ICT’er, de tussenpersonen van leveranciers, de ICT-afdeling enzovoort, elkaar niet altijd goed verstaan en daardoor elkaar niet altijd goed begrijpen. De oorzaak ligt voor een groot deel in hun achtergrond, de werkomgeving en de opleidingen. Zo ontstaan verschillende beelden van de werkelijkheid. Ook verschillen in menstypen en in verwachting van het eindresultaat spelen een rol. De vraag dringt zich op of deze verschillen wel te overbruggen zijn. Het antwoord is: natuurlijk zijn die te overbruggen. Discpline! Er wordt al vele jaren geschreven over projecten die maar niet op tijd en binnen budget te realiseren zijn. Daarom is gezocht naar handzame structuren om projecten beheersbaar te maken. Er zijn allerlei standaardwerkwijzen bedacht die organisaties moeten helpen de vraag en het eindresultaat beter op elkaar af te stemmen. Toch zitten we na al die jaren nog steeds met de vraag: waarom lukt het vaak niet om een project succesvol binnen tijd en budget af te ronden. Het antwoord is simpel: discipline! Laten we eens het proces van verwerving bezien vanuit de gezichtspunten bedrijf, leverancier, tijd en
38
uitvoerder. Daarna zoemen we in op risico-analyse, overeenkomst en afspraken. Het bedrijf Om een goed inzicht te krijgen in de dagelijkse gang van zaken is het voor een bedrijf belangrijk alles te weten te komen over klanten en over leveranciers, informatie over de eigen organisatie, zoals verkoopinformatie, voorraden, werkorders, facturen, maar ook de communicatie met de buitenwereld. Voor de verwerking van al die informatie en communicatie worden ICT-systemen gebruikt. Logisch dat directies besluiten nemen over de strategische toepassing van ICT in hun bedrijf. De directie neemt echter deze besluiten op het metaniveau; dat kunnen besluiten zijn als: “Wij willen precies weten welke klanten tachtig procent van onze omzet leveren” of “Wij willen dat de informatiestromen in de logistieke afdelingen zodanig zijn dat we de voorraden kunnen minimaliseren”. Wat gebeurt er vervolgens met dergelijke besluiten? Er zijn twee mogelijkheden. Of de ICT-afdeling óf de meest betrokken bedrijfsafdeling krijgt de opdracht een voorstel voor te bereiden en uit te werken. Dan hebben we al direct te maken met twee verschillende inzichten. De ICT-afdeling is geneigd te zoeken naar de best mogelijke en passende oplossing vanuit de technologie en in het gunstigste geval vanuit de resultaatverwachting van de mensen van die afdeling. De bedrijfsafdeling daarentegen kijkt naar de functionaliteit en koppelt deze niet of slechts beperkt aan de technische mogelijkheden en de daaraan verbon-
Hoe werkt het vertalen? Bij veel projecten zien we hoe de vertaling van functionele eisen naar
den kosten. Deze functionaliteit moet dan weer ‘vertaald’ worden naar een ICT-oplossing. Om tot een informatiesysteem te komen wordt aan leveranciers gevraagd een oplossing te bieden. Er moet dus een offerteaanvraag komen. Meestal is het de afdeling met de meeste ‘macht’ in de organisatie die de inhoud van de vraag in de offerteaanvraag aanstuurt. Het kan zijn dat dan speciaal geformeerde teams gezamenlijk vaststellen hoe die vraag moet luiden. Het issue wordt al zichtbaar. Naast management en afdelingen binnen de organisatie komt er nu ook nog eens een leverancier bij. Allemaal hebben ze een andere achtergrond en daarmee een ander taalgebruik. Biedt nu de uiteindelijk ‘vertaalde’ oplossing inderdaad de functionaliteit die gevraagd wordt? Is de gevraagde functionaliteit wel de meest efficiënte voor het beantwoorden van de bedrijfseconomische vraag van het bedrijf? Juist in deze ‘vertalingen’ liggen de problemen verborgen die pas zichtbaar worden bij de uiteindelijke realisatie. We hebben dus binnen het bedrijf al te maken met verschillende gezichtspunten: het management, de business-unit, de gebruiker en de ICT-afdeling. De leverancier De leveranciers van hardware, software en diensten hebben een geheel eigen dynamiek. De verkopers zijn op jacht naar omzet. Per kwartaal of zelfs per maand. Het gaat dan niet meer om de oplossing, laat staan de juiste oplossing, maar om de omzet op het juiste moment.
Verkoop heeft een tardoor ICT-systemen geboden funcget. Wordt het target tionaliteit van elkaar afwijken. niet gehaald, dan zijn Daarnaast worden in veel projecten carrièrekansen gemide functionele eisen gewijzigd, soms nimaliseerd of kan er zelfs continu. Dit staat een goede zelfs ontslag dreigen. vertaling in de weg. De gewijzigde Wordt er beter situatie kan in sommige gevallen gepresteerd dan het zelfs het oorspronkelijke ontwerp target, dan vallen ‘onderuit’ halen. Het zou eigenlijk bonussen en roem de beter zijn een nieuw ontwerp te verkopers toe. Binnen maken, maar daar ontbreekt in de verkooporganisaties meeste projecten de tijd voor. worden deze effecten zelfs gestapeld: verkopers, verkoopmanagement, de verkoopdirecteur en de directie. Deze dynamiek geldt voor iedere laag en voor ieder individu in een laag hetzelfde. Allemaal leggen zij verantwoording af over hun resultaten; aan hun manager of directie of aan de aandeelhouder. Allemaal voelen zij de druk tot presteren en het behalen van hun target. Het verkoopmanagement speelt zelfs hiermee door de targets hoger te maken dan realistisch is. Dan komt de vertaalde vraag in de offerteaanvraag die nu door de leverancier opnieuw wordt vertaald. Enerzijds naar verkoopdoelstellingen en anderzijds naar wat de leverancier in staat is als oplossing te leveren. Deze twee vertalingen botsen nogal eens. Meestal is de verkoopdoelstelling leidend en de realisatie volgend. De organisatie van de leverancier moet dus maar zien waar te maken wat er door de Verkoop is
39
beloofd. De ene leverancier communiceert intern beter op dit vlak dan de andere, maar iedere offerte die wordt uitgebracht, herbergt onzichtbare vraagtekens en daarmee potentiële problemen. Deze vragen kunnen, bewust of onbewust, onbeantwoord zijn gebleven. Om verkooptechnische redenen kan een leverancier een vraagstuk dat veel geld kost doorschuiven naar de toekomst; wellicht valt het dan onder meerwerk en zijn de prijzen op offerte nu acceptabel. Ook gebeurt het dat tijdverslindende onderdelen onuitgewerkt op de offerte staan. Het project krijgt de uitwerking dan later voorgeschoteld. Daarmee komen we direct in het tijdselement terecht.
change-managementproces voor zowel functionele als technische eisen. De doelstelling daarvan moet zijn dat het project flexibel gehouden kan worden zonder al te veel wijzigingen in kosten en in tijd. Om dat proces te kunnen managen is het van belang besluiten en keuzen goed te beschrijven, zodat later altijd kan worden teruggevonden waarom een besluit is genomen of een keuze is gedaan. Die beschrijving van besluiten en keuzen is onmisbaar wanneer het project problemen ondervindt die tijd en helaas vaak ook geld en middelen kosten.
De uitvoerder De uitvoering zelf is vaak onderdeel van de offerteaanvraag. Het is zowel voor de opdrachtgever als de leverancier lastig om van te voren de totale De tijd Bij ICT-projecten verloopt er nogal wat tijd tussen de inspanning in te schatten. Het gaat om tijd, expertise, support die men van elkaar verwacht enzovoort. eerste gedachte over een bedrijfssysteem en de De opdrachtgever gaat over het algemeen uit van daadwerkelijke implementatie en oplevering. Die tijd het meest eenvoudige model van invoering. Dit verschilt per organisatie. In de regel geldt dat hoe model is vaak technisch georiënteerd; technisch op groter de organisatie is, hoe meer tijd er zit tussen ICT-vlak, maar ook technisch op de opstelling van eisen en wenhet vlak van de uiteindelijke sen en de uiteindelijke invoering gebruikers. De gedachte erachvan de oplossing. Niet nodig en toch gekocht ter is: hoe krijgen we de techHet lastige is dat intussen de Bij een groot bedrijf stonden pas niek geïnstalleerd en beschikomstandigheden kunnen zijn aangeschafte pc’s in de gang opgebaar? gewijzigd en waarschijnlijk zal stapeld. Ze werden niet gebruikt. Bij dat ook zo zijn. Dit kunnen navraag bleek dat de leverancier de Een technisch uitgangspunt kan omstandigheden van bedrijfsopdrachtgever zodanig onder druk problemen opleveren tijdens de economische of technische had gezet dat deze uiteindelijk de uitvoering. Natuurlijk moet het aard zijn. pc’s gekocht had, terwijl hij ze niet project zich bezighouden met Daarom is het goed in ieder nodig had. het beschikbaar maken van de geval te zorgen voor een goed
40
technische omgeving, maar ook de implementatie in de organisatie en de gebruikers komen daarbij aan de orde. Wellicht moeten processen geherdefinieerd worden, gebruikers worden opgeleid en dergelijke. Vanuit zowel de ICT-afdeling als de gebruikersorganisatie komen er vragen of er voldoende capaciteit beschikbaar is. Is de voorbereiding van het project voldoende geweest? Is de ICT-organisatie voorbereid of zelfs in staat om de nieuwe omgeving te beheersen? Hebben de gebruikersorganisatie en de ICT-afdeling nieuwe afspraken met elkaar gemaakt? Wanneer zijn die afspraken van kracht? Met andere woorden: is er rekening gehouden met de periode van invoering en hoe is de overgang naar de reguliere serviceverlening afgesproken? Hoe is de opleiding of training georganiseerd? Standaardtegenvallers zijn: “Er is niet besteld wat geoffreerd is”, “Kabels zijn te kort gedimensioneerd”, “De software heeft een nieuwe release die andere hardwaretechnische vereisten heeft”, enzovoort. Voor de uitvoerder een hele klus om alles ‘on track’ en beheersbaar te houden. Ten slotte komen in het project alle losse eindjes bij elkaar die van te voren bewust of onbewust niet die aandacht hebben gekregen die noodzakelijk is. Risicoanalyse Een aantal zaken kunnen van te voren worden opgelost door het uitvoeren van een goede risicoanalyse die gedurende het gehele project actief bijgehouden wordt. Het belangrijkste daarbij is – in mijn ogen – dat elke zaak die bij een project betrok-
ken is boven tafel komt en zichtbaar wordt en dat daarover een besluit wordt genomen. Wat als zaken vergeten zijn en pas halverwege het project boven tafel komen? Dan is de kans groot dat Murphy’s Law van toepassing is: vergeten zaken komen op het meest ongelukkige moment te voorschijn. Helaas zien we dat in de praktijk te weinig aandacht wordt geschonken aan risico’s die een invoering met zich mee kan brengen. Ondanks de verschillende hulpmiddelen die vrij op de markt beschikbaar zijn, blijkt dat risicoanalyse niet de noodzakelijke prioriteit krijgt. Soms wordt er wel een globale inschatting gemaakt, terwijl een systeem van inventariseren, maatregelen nemen en ten slotte beheren ontbreekt. Het gevolg is dat aspecten aandacht krijgen door een individuele inbreng of interesse, waarna tijdens de uitvoering allerlei onverwachte zaken naar voren komen. Daarbij is het zo dat hoe later in het project deze zaken naar boven komen, hoe moeilijker en duurder de maatregelen worden. Overeenkomst Ook de overeenkomst is in een ICT-project een middel waarmee een projectleider een project goed kan laten verlopen. Immers, het geheel van leveringen (hardware, software en diensten) wordt samengevoegd in een overeenkomst. Die overeenkomst mag echter pas worden vastgelegd als de keuze is gemaakt voor een oplossing (hardware en software) waarvan de technologie, de functionaliteit, de aanpassing op de bestaande infrastructuur, de invoering, enzovoort passen op de bestaande situatie.
41
De rechter over omschrijvingen In een conflict tussen opdrachtgever en leverancier dat uiteindelijk voor de rechter kwam, oordeelde de rechter dat de omschrijving van de werkzaamheden zo vaag was dat er geen uitspraak kon worden gedaan over het conflict. Dit kostte uiteindelijk de opdrachtgever geld en tijd en vervolgens moest de opdrachtgever ook verder met dezelfde leverancier.
Veel bedrijven denken dat zo’n document pas nodig is wanneer er conflicten ontstaan. De ervaring leert dat, wanneer er inderdaad een conflict ontstaat, de omschrijving en de artikelen niet altijd de verzekering bieden die de opdrachtgever of de
leverancier ervan verwacht. Het ontbreekt in overeenkomsten vaak aan duidelijkheid en eenvoud. Zelfs de omschrijving van de bedoeling van het project is in de overeenkomst vaak niet helder. Wanneer iemand daar later – wellicht met een juridisch oog – naar kijkt, dan ontbreekt het beeld van wat de partijen nu precies beoogden met deze overeenkomst. Daarnaast is het goed een dergelijke overeenkomst te beschouwen als een werkdocument dat gedurende de loop van een project kan veranderen. Bij grote projecten komen uiteraard meer veranderingen voor dan bij kleine. Een goede change-managementprocedure die is vastgelegd in de overeenkomst bevat ruimte voor veranderingen. Ruimte om de consequenties van de wijzigingen uit te werken en door beide partijen te laten accorderen. Gevolgen voor de doorloop van het project kunnen dan weer in de planning worden verwerkt.
42
Afspraken Op het moment van de uitvoering komt alles wat hier genoemd is weer samen. Dan blijkt of de functionele wensen goed waren opgenomen, of de oplossing wel of niet of gedeeltelijk in de bestaande infrastructuur is in te passen, of de hardware- of softwareleveringen wel of niet op tijd kunnen plaatsvinden, of de voor de uitvoering beschikbare mensen zoals programmeurs, testers, projectleiders al dan niet moeilijk leverbaar zijn enzovoort. Voorbereiding en discipline zijn hierbij noodzakelijke voorwaarden; voorbereiding om zoveel mogelijk zaken boven tafel te krijgen en discipline om gedurende het project de voortgang bij te houden en te beheersen. Uiteindelijk is het resultaat rechtevenredig met de kwaliteit van de voorbereiding en de discipline. Het belang van voorbereiding is wel duidelijk, maar wat kan discipline bijdragen? Discipline betekent dat men zich aan afspraken houdt en dat kan alleen wanneer er afspraken zijn gemaakt. Sommige afspraken kunnen in de overeenkomst staan, andere in het projectdocument. De afspraken moeten voor alle partijen helder en duidelijk zijn. Wellicht nog belangrijker is dat zij door alle partijen geaccepteerd zijn. Pas wanneer het voor alle betrokken partijen duidelijk is wat deze afspraken inhouden en betekenen, kan men zich daaraan houden. De afspraken moeten op schrift gesteld zijn, betrokkenen moeten zich aan de gemaakte afspraken houden en wie zich niet aan de afspraken houdt,
moet daarop worden aangesproken. Dit alles vergt discipline. Soms zijn wijzigingen noodzakelijk, dus maak van te voren afspraken hoe betrokkenen daarmee moeten omgaan. Leg vast wie wat besluit en hoe er met de consequenties wordt omgegaan. Er wordt dus van de verschillende partijen gevraagd discipline op te brengen en zich te conformeren aan regels. Conclusie In de jaren zeventig van de vorige eeuw zagen we bij het ontwikkelen van applicaties, dat het een beter gebruik van de tijd is om voorafgaand aan het programmeren eerst goed na te denken over het ontwerp. Nu in de nieuwe eeuw zien we precies hetzelfde mechanisme. De tijd die men in de voorbereiding, het maken en vastleggen van afspraken enzovoort steekt, wordt dubbel en dwars terugverdiend in de loop van het project. Het voorkomt dat later in het project door onduidelijkheden zaken moeten worden overgedaan of dat er aan het eind een conflict tussen de partijen ontstaat. Zonder deze voorbereiding wordt in alle gevallen tijd en geld verloren. Eenmaal goed doorgesproken en vastgelegd in welke vorm dan ook, mag het document niet in de archiefkast opgeborgen worden. Juist niet. Het is en blijft een werkdocument gedurende de gehele looptijd van de overeenkomst of het project. Dat betekent dat de betrokken medewerkers tijdens statusbijeenkomsten van het project de voortgang
kunnen toetsen aan de afspraken. Lopen deze niet meer synchroon, dan is het zaak zo snel mogelijk wijzigingen in de oorspronkelijke afspraken te maken en de consequenties daarvan onder ogen te zien. Een stuurgroep waarin ten minste de verschillende partijen zitting hebben kan dan een uitspraak doen. De verschillen tussen de verwachtingen die een ICTafdeling heeft en de vragende afdeling komen steeds meer onder controle door middel van goede afspraken. Deze afspraken worden dan vastgelegd in Service Level Agreements (SLA), Operational Level Agreements (OLA) of Service Agreements (SA). Daarmee wordt beter zichtbaar wat is afgesproken en kunnen de partijen er ieder vanuit de eigen omgeving invulling aan geven. In theorie zou daarmee alle verwarring uit de wereld geholpen moeten zijn. Alleen zien we dat het in de praktijk niet zo is. De verwarring ontstaat al door de andere uitgangspositie van de betrokkenen. De vragende partij heeft de vraag geformuleerd vanuit de positie van de benodigde functionaliteit voor het behalen van hun bedrijfsdoelstelling. Toegegeven, dat is het ideale plaatje. In werkelijkheid worden de vragen gesteld vanuit een nog onvolledig plan of ten minste een plan dat nog niet ver genoeg is doordacht. Dat betekent dat de vraag geformuleerd wordt voordat de gewenste eindsituatie geheel duidelijk is en vast staat. Er schuilt achter dit verschijnsel een groot aantal andere zaken zoals: de psychologie van de mens en
43
zijn type, zoals verkopers, programmeurs, businessunit-managers, eindgebruikers, maar ook de bedrijfsprocessen en de organisatievorm, de wijze van besluitvorming enzovoort. Ieder aspect heeft zijn eigen dynamiek en eigenschappen. Uiteindelijk is er maar één uitweg voor dit probleem: goede afspraken maken. In deze afspraken dienen alle aspecten aan de orde te komen en dient daarover in gezamenlijkheid besloten te worden. Het gevaar zit hem juist in twee aspecten: 1. onvolledig overzicht van alle relevante zaken waarover in gezamenlijkheid een besluit genomen dient te worden; 2. verschillen in interpretatie door de verschillende deelnemers.
44
Vervolgens moeten deze afspraken in een werkdocument worden vastgelegd. Dit kan een contract zijn of een service-levelovereenkomst of anders, al naar gelang de aard van het project. Het belangrijkste is dat het een werkdocument is waarin heldere regels zijn omschreven voor het change-management. Op deze manier is de uitkomst van een project beter voorspelbaar en kunnen verschillen tussen de partijen beter worden overbrugd. Het resultaat? Een beheerst project met het gewenste resultaat; bijna te mooi om waar te zijn. De emotie ligt dan in samen vieren van het succes!
