In een vorige bijdrage is gepleit voor het opsplitsen van het management van ICT-projecten in afzonderlijke projecten, te weten: analyse, ontwikkeling en implementatie. De doelstellingen, deelnemers en werkwijzen, en daarmee de risico’s en doorlooptijden van deze activiteiten, kunnen namelijk nogal uiteenlopen. In dat geval is het beter ze onder te brengen in afzonderlijke projecten. Zelfs als een kortcyclische iteratieve methodiek wordt gevolgd
In deze bijdrage staat het management van ontwikkelactiviteiten centraal. Hierbij draait het om het omzetten van specificaties in code. Dat kan door selectie of door eigen ontwikkeling. Feitelijk gaat het vrijwel altijd om een combinatie: iedere selectie vereist enige aanpassing en ook in geval van ontwikkeling moeten er keuzes worden gemaakt (bijvoorbeeld: welke technologie wordt gebruikt).
Software is maatwerk, dat geldt zeker voor bedrijfssoftware. Deze constatering legt meteen de vinger op de zere plek: moet de ICT het bedrijf volgen of het bedrijf de ICT? De praktijk is natuurlijk niet zo zwart – wit. Vaak is er al een behoorlijk aantal applicaties aanwezig en gaat het meer om aanpassingen en / of uitbreidingen. Het komt ook voor dat een of meerdere applicaties (moeten) worden vervangen. Met andere woorden: er kunnen veel verschillende redenen zijn om ICT te ontwikkelen.
ICT moet meestal worden ingepast in een bestaande omgeving. Dit betekent dat ook die delen of aspecten van de omgeving die relevant zijn voor het goed functioneren van de in te passen ICT in kaart moeten worden gebracht. Deze eisen worden onder de zgn. niet-functionele eisen geschaard. Deze eisen worden nogal eens vergeten. Ook kunnen architectuureisen van toepassing zijn.
Vaak omvat de reeds aanwezige ICT verschillende technologieën, generaties of licenties / leveranciers. Deze moeten ook in kaart worden gebracht. Vaak ontbreekt het overzicht en vergt dit een (niet altijd voorziene) inspanning.
Maatwerk kan problemen geven bij upgrades en updates (versiebeheer). Het niet volgen van releases kan leiden tot beperkingen in de functionaliteit en / of tot beveiligingsrisico’s. Het aanpassen van de (product-)standaard(en) kan echter ook leiden tot problemen; niet alleen technisch maar ook qua ondersteuning (beheer en onderhoud) en qua scholing.
Het is raadzaam om bij de keuze van bedrijfssoftware de Total Costs of Ownership (TCO) als kostenpost te nemen en niet alleen te kijken naar de investeringskosten. Een vuistregel is dat de TCO circa 3x de investeringskosten bedragen. Als je dit afzet tegen de verwachte baten dan kunnen business cases er soms heel anders uit zien. Het kan voordelig zijn om deze kosten op enigerlei wijze te delen met anderen (partners of leveranciers). Dan ziet het plaatje er natuurlijk weer anders uit.
Stel dat je weet wat je eisen zijn en ook welke randvoorwaarden van toepassing zijn. Hoe maak je dan de beste keuze? ICT is een zeer uitgebreid, gefragmenteerd en specialistisch terrein, niet alleen technisch maar ook commercieel. Bovendien zijn er hypes en ontwikkelingen gaan soms snel.
Een goed uitgangspunt is om geen software te ontwikkelen die al bestaat. Het gaat hierbij niet alleen om applicaties maar ook om bouwstenen en tools. Maar hoe weet je wat beschikbaar of nodig is? Welke producten en diensten zijn beschikbaar en wat kosten die? Wat is de noodzaak, c.q. wat zijn de mogelijkheden, tot aanpassing / ontwikkeling? Wat betekent dit voor het beheer en onderhoud? Beantwoording van deze, en veel andere, vragen vereist veel kennis van de software-markt.
Een ander uitgangspunt is om geen “early adopter” te zijn en alleen bewezen technologie te gebruiken. Ook het hanteren van dit uitgangspunt vereist enige kennis van de software-markt.
Veel bedrijven hebben gegevens en / of processen die in eigen beheer moeten blijven. Deze vormen een deel van het kapitaal van het bedrijf. Ook zijn veel bedrijfsprocessen afhankelijk van ICT. Hoeveel downtime is acceptabel en hoe ga je hiermee om? Je kunt bijvoorbeeld wel boetebedingen opnemen in een Service Level Agreement (SLA) maar is daarmee het bedrijfsrisico afgedekt? Vaak zijn er ook externe regels waar een bedrijf aan gehouden is (compliance). Ook zijn er vragen m.b.t. leveranciers. Bijvoorbeeld: welke leveranciers zijn betrouwbaar? Wat als een leverancier wordt overgenomen of failliet gaat of als leveranciers hun krachten bundelen?
ICT is een zeer specialistisch terrein maar is voor de meeste bedrijven doorgaans geen “core business” maar hooguit een “enabler”. Bovengenoemde algemene overwegingen / valkuilen m.b.t. uitbesteden of zelf doen komen vaak nu pas boven de kim. Door portfolio’s van succesvolle projecten te bekijken, referenties te vragen en anderszins kennis te nemen van ervaringen van anderen kan worden voorkomen met de verkeerde partijen in zee te gaan. Ook het laten uitvoeren van test-opdrachten c.q. -projecten kan soms handig zijn.
De meeste mensen realiseren zich niet hoeveel details er nodig zijn om een computer iets te laten doen wat bedrijfsmatig nuttig is. Computers zijn buitengewoon simpel en kunnen alleen een beperkt aantal expliciete instructies uitvoeren. Dat kunnen ze echter zo snel dat wat er “onder de motorkap” gebeurt, “onder de motorkap” blijft en een gebruiker alleen het eindresultaat ziet. Bij de vertaling van gebruik naar uitvoering wordt echter een enorme hoeveelheid standaarden en stappen gebruikt. Veel hiervan is al gestandaardiseerd en vereenvoudigd. Desalniettemin zijn voor de ontwikkeling van ICT een groot aantal specialisten nodig die in teamverband tot een resultaat moeten komen.
Kenmerkend voor de ontwikkeling van bedrijfssoftware is dat het grootste deel van de instructies onzichtbaar is en het resultaat pas waarneembaar is op het koppelvlak tussen mens en machine. Als dan blijkt dat het resultaat niet voldoet dan kan het een hele puzzel zijn om te achterhalen waarom dat zo is.
Een grote uitdaging bij het managen van ICT ontwikkeling is hoe je verschillende specialisten laat samenwerken. Omdat de meeste ICT projectgewijs wordt ontwikkeld gaat het meestal om projectteams. Deze teams worden naar behoefte samengesteld en kort na oplevering ontbonden, m.a.w. ontwikkelteams zijn gelegenheidsteams. Professionals kun je het best aansturen op basis van resultaten. Deelresultaten moet je dus ook smart maken zodat er op gestuurd kan worden (door ze bijvoorbeeld te koppelen aan testresultaten).
De hoeveelheid details en de onzichtbaarheid van veel coderingen maakt het managen van ontwikkel-projecten niet eenvoudig en maken duidelijk waarom er tijdens de ontwikkeling veel wordt getest. Er zijn veel verschillende soorten testen en test-technieken en -strategieën (ook het testen van software is een specialisme). Zo zijn er bijvoorbeeld unittesten, ketentesten, regressietesten, conversietesten en integratietesten. Uiteraard stelt dit hoge eisen aan het versiebeheer en de documentatie.
Vanuit gebruiksperspectief zijn met name de integratietesten interessant. Deze bieden niet alleen de mogelijkheid te demonstreren (hoe ver is men, wat is er mogelijk) maar ook om toekomstige gebruikers te scholen.
De ontwikkeling kan worden afgesloten als het resultaat door de gebruikers wordt geaccepteerd (vast te stellen door het afnemen van een acceptatie- of oplevertest). De vraag is dan natuurlijk wanneer is het voldoende en wie bepaald dat (wie zijn de gebruikers)?