Project mislukt, opdracht geslaagd?

Als testmanager heb ik als opdracht een gestructureerde acceptatietest op de opgeleverde producten te organiseren. Het resultaat is meestal een verslag waarin een advies tot acceptatie staat, onder voorwaarde dat er nog een aantal zaken aangepast worden.

Soms loopt het anders. Dan blijkt uit een test dat er een groot gat is tussen het opgeleverde product en hetgeen de organisatie verwacht. Een gat zo groot dat dit niet binnen redelijke tijd en met redelijk budget valt op te lossen. Of er worden te veel zaken ontdekt die binnen de gekozen technische architectuur niet zijn te repareren, ongeacht hoeveel tijd en geld er nog ingestopt gaat worden.

Er is dan helaas maar één goede oplossing: stoppen met het project. Een dramatisch besluit voor projecten die vaak al meer dan een jaar lopen voordat ik aan boord ben gekomen. Er gaan vaak weken tot maanden overheen om de knoop door te hakken. Managers zijn geneigd door te gaan met hetgeen waar ze al zo veel tijd en geld ingestopt hebben.

Formeel heb ik in zo’n geval de opdracht succesvol voltooid. De georganiseerde test heeft het gebrek aan kwaliteit aangetoond en de opdrachtgever is behoed voor verdere investeringen in een systeem zonder toekomst. Toch voelt het anders. Ik draag liever bij aan een succesvol project. Maar, als het moet, neem ik mijn verantwoordelijkheid om een negatief oordeel te vellen.

 “Als ik geen Nee kan zeggen, is mijn Ja ook niets waard”

Waarom gaat het dan toch zo vaak mis? Donkere wolken boven het ICT project

In mijn vorige blog Het eenVoudig model voor systeemontwikkeling heb ik beschreven hoe simpel een ICT ontwikkelingstraject zou kunnen verlopen. Helaas is de praktijk vaak anders en gaan er gedurende het project allerlei dingen mis. In het ergste geval worden deze pas opgemerkt in de implementatiefase. Vaak roept een opdrachtgever mijn hulp in, wanneer de ICT leverancier een systeem heeft opgeleverd en er een formele acceptatie moet plaatsvinden. Op dat moment blijkt dat het opgeleverde systeem niet, of beperkt aan de verwachting voldoet. Oorzaken van deze problemen liggen al in een eerdere fase. In de praktijk kom ik de volgende oorzaken tegen:

1. De wens is onvoldoende duidelijk. Als gevolg schiet ook het ontwerp en de bouw tekort. Een variant hierop is een wens die te beperkt is uitgewerkt. Slechts een deel van het proces is in beschouwing genomen, in plaats van het gehele proces van input tot output.

2. Gedurende het project verandert de wens in een bepaalde verwachting, die niet meer overeenkomt met de oorspronkelijke wens. Tijdens test en acceptatie wordt het opgeleverde systeem vergeleken met de verwachting, hetgeen tot discrepanties leidt.

3. De specificaties komen niet overeen met de wens. Er gaat iets mis in de vertaalslag van wens naar ontwerp, vaak doordat klant en ICT leverancier elkaar niet goed begrijpen.

4. De specificaties zijn technisch of procesmatig onjuist. Ze zijn weliswaar een juiste vertaling van de wens, maar in feite “kan het zo niet werken”. De oorzaak hiervan zijn bijvoorbeeld beperkingen die gesteld worden door de gebruikte techniek, wetgeving, aanwezige gegevens of personele randvoorwaarden.

5. Het opgeleverde product komt niet overeen met het ontwerp. Dit heeft alles te maken met kwaliteit tijdens de bouw of inrichting.
Helaas komt het nog steeds voor dat een leverancier een systeem oplevert waar nog grote technische problemen in voorkomen of dat overduidelijk niet voldoet aan de specificaties.

Veel van deze oorzaken kunt u als klant of gebruiker van ICT voorkomen. In mijn volgende blog zal ik bespreken welke maatregelen u kunt treffen.

Het eenVoudig model voor systeemontwikkeling

Een bekend model voor het ontwikkelen van maatwerk ICT systemen is het V-model, dat uit de jaren 70 van de vorige eeuw stamt. De tijd is veranderd en ik maak dingen graag simpel, dus heb ik een eigen versie ontwikkeld: het eenVoudig model voor systeemontwikkeling.

Een nieuw ICT systeem begint altijd met een Wens aan de klantzijde. Die wens heeft vaak te maken met het efficiënter willen maken van bedrijfsprocessen, maar kan ook het gevolg zijn van het moeten voldoen aan eisen en wensen die de omgeving stelt. Op basis van de wens die een organisatie heeft, wordt contact gezocht met een ICT leverancier.

Deze leverancier vertaalt de wens in een Ontwerp. Zo’n ontwerp kan een heel uitgebreid functioneel en technisch ontwerp zijn of slechts enkele A4-tjes. Wat ook mogelijk is, is dat het ontwerp meer procesmatig van opzet is, en de klant zelf een groot aandeel heeft in het opstellen van dit ontwerp. In ieder geval bevindt het product “Ontwerp” zich op het grensvlak van klant en leverancier. Het ontwerp maakt de oplossing voor de wens concreet.

Op basis van het ontwerp gaat de leverancier aan de slag met de Bouw. Dit bouwen kan het geheel ontwikkelen van een systeem zijn, maar ook het inrichten van een pakket of het modeleren van bouwblokken. Deze fase van het traject bevindt zich vaak buiten blikveld van de klant.

Hoe anders is dat in de volgende activiteit! Want na een test door de leverancier, zal de klant zelf moeten gaan Testen of het opleverde product aan de verwachtingen voldoet. Indien dat niet of deels zo is, past de leverancier het product aan, waarna een formele Acceptatie door de klant volgt.

De leverancier is nu klaar, aan klantzijde moet het nieuwe systeem nu echt gaan draaien. Er moeten mensen worden opgeleid, processen aangepast, klanten geïnformeerd, formulieren ontwikkeld, brieven aangepast, communicatie opgestart etc. Al deze activiteiten vormen de werkelijke Implementatie van een systeem.

Opvallend is dat in een ICT project slechts 1 van de 6 onderdelen volledig door de ICT leverancier wordt opgepakt! TH-Consultancy ondersteunt organisaties in het managen van de andere projectonderdelen.

Volgende keer: als het zo eenVoudig is, waarom gaat het dan toch zo vaak mis?

Coda Financials implementatie

Deze week was mijn, voorlopig, laatste werkdag bij Amvest, een ontwikkelaar en belegger in vastgoed.

Per 1 januari 2012 is Amvest overgestapt naar Coda Financials V12, Purchasing en Invoice Matching. Dit betekende een geheel nieuwe inrichting van twee deelsystemen voor factuur- en opdrachtmanagement en een conversie van de oude financiële administratie naar de nieuwe webversie van Coda.

De consultants van leverancier Unit4, namen de technische inrichting en conversie voor hun rekening. TH Consultancy was ingehuurd om de opdrachtgever te ondersteunen bij de interne organisatie van dit project: het testen, inventariseren van gebruikerswensen, bijhouden van issues en het geven van instructie.

Door een succesvolle samenwerking van opdrachtgever (Amvest), ICT leverancier (Unit4) en onafhankelijk test- en implementatie deskundige (TH-Consultancy), is de invoering in januari 2012 bijna geruisloos verlopen. Op het moment dat het nieuwe boekjaar opende, stond het ingerichte en goed geteste systeem klaar. De werkinstructies waren gereed en gedurende de eerste maand was ik beschikbaar voor instructie en vragen. Gevolg was dat de gebruikers direct aan de slag konden en enthousiast waren over het gebruikersgemak en de inzichtelijkheid van de nieuwe software.

Software testen in design lingerie

De afgelopen maand is onze nationale lingerie koningin Marlies Dekkers in de diverse media negatief in het nieuws geweest, oa in ondernemersblad Sprout.
Het artikel leidde tot een welles-nietes spelletje over de onjuistheden in het financieel jaarverslag van de MD Group. Interessant zijn de lessen die we uit de gepubliceerde verhalen kunnen trekken, zie ook “8 lessen voor groeiende ondernemers”.

Zo noemt één van de geïnterviewde personen het ontbreken van een georganiseerde test bij de overgang naar nieuwe IT systemen. Logisch, als het ontwerpen van BH’s je core business is, staat je hoofd waarschijnlijk niet naar het testen van je nieuwe logistieke en financiële systemen. Ik kan me goed voorstellen dat je vertrouwt op de blauwe ogen van je ICT leverancier als hij zegt dat je systemen compatible zijn. Helaas is de praktijk vaak anders; een gedegen en vooral onafhankelijke test blijkt noodzakelijk om te bereiken dat ICT systemen en bedrijfskritieke processen naadloos op elkaar aansluiten. En zijn je processen op orde, dan zal het niet zo snel voorkomen dat er nog voor 1,9 miljoen aan niet verwerkte facturen ligt en je financiële cijfers niet kloppen.

Marlies geeft aan inmiddels weer winst te maken en enthousiast door te gaan met ontwerpen en verkopen. Ik ga minstens zo enthousiast door met het testen en implementeren van ICT, ook bij minder “stoute” opdrachtgevers.