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”

Laat de zon weer schijnen

Zoals beloofd, laat ik u niet in de donkere wolken zitten, en bespreek ik in deze blog hoe de zon weer boven ieder ICT project kan gaan schijnen.

Het allerbelangrijkste is dat de wens duidelijk is. Stop tijd in het beschrijven hiervan, maak procesbeschrijvingen, workflows, inventariseer rollen en autorisaties, werk berekeningen uit. Doe alles wat mogelijk is om uw leverancier duidelijk te maken wat u wilt. Doe dit in nauwe samenwerking, zodat uw ICT levenacier u kan inspireren, maar uw bedrijfsproces het uitgangspunt blijft. Elk uur dat u in het voortraject stopt, betaalt zich later in een veelvoud terug!

Laat beschrijvingen en ontwerpen reviewen door specialisten uit verschillende rollen  (beheerder, gebruiker, lijnmanager, vakspecialist, ontwikkelaar, tester). In een zg. Fagan inspectie beoordelen meerdere deelnemers een product vanuit de verschillende rollen. Dit is een krachtig middel waarbij de deelnemers elkaar inspireren tot het kritisch bekijken en waarbij een gezamenlijke verwachting wordt gecreëerd.

Benoem iemand die al deze activiteiten coördineert. Laat deze persoon ook het verwachtingenmanagement op zich nemen door kerngebruikers continu te blijven betrekken. Verwachtingen verschuiven nu eenmaal, zorg dat dit gemonitord wordt. Wat leidt tot een nieuwe wens? Wat kan tijdelijk geparkeerd worden? Wat is echt nodig in een eerste oplevering?

Communiceer deze wijzigingen met de leverancier. Hou een goede registratie bij van wijzigingen en bevindingen in een geschikte tool, bijvoorbeeld de gratis tool Mantis. Zorg dat u continu inzicht heeft in de status (bijv. nieuw, toegewezen, aangepast, gesloten, uitgesteld)

Stuur bij uw leverancier aan op deelopleveringen, iedere 3 weken. Laat betrokken personen de tussenproducten direct beoordelen en hou ze daarmee betrokken.

Organiseer testen door testers en gebruikers. Maak een integrale planning voor opleveringen en testen. Een product is pas af als het ook geverifieerd is. Overleg direct met uw leverancier als de opgeleverde deelproducten niet overeenkomen met de verwachting. Analyseer de oorzaak en plan zo nodig nieuwe cycli.

Ook als u uw project zonder deze maatregelen bent begonnen, is het niet te laat om deze alsnog in te voeren. Iedere dag is een dag dat u de zon kan laten doorbreken!

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.