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.

De handen in samenwerking, maar niet vast

Deze zomer rondde ik het 4e project in 2 jaar tijd af bij een van mijn grootste opdrachtgevers, de Hogeschool Arnhem en Nijmegen. Bij het afscheid ontving ik een replica van Rodin. Ik kijk met veel plezier naar dit mooie beeldje, vooral vanwege de toespraak die ik erbij kreeg:

Ik wil je bedanken voor alle inzet die je gedaan hebt voor de organisatie, voor het team en voor enkele individuen. Op zich zou je kunnen zeggen “daarvoor was ik immers ingehuurd” maar je ging toch wat verder dan enkel dat. Je ging niet alleen voor de klus maar ook voor het hoger liggende doel, de reden van de klus, als het lagerliggende, de mensen die betrokken waren. Ondanks die betrokkenheid heb je je eigen zelfstandigheid en vasthoudendheid, daarom symboliseert dit cadeau: de handen in samenwerking maar niet vast.

“De handen in samenwerking, maar niet vast”, beter kun je wat mij betreft de ideale samenwerking tussen een ZZP-er en een organisatie niet typeren!
Formeel gaat een project erom met beperkte tijd en middelen het geplande resultaat te behalen, waarna de partijen weer uiteen gaan. Het ideaal van de overtuigde ZZP-er gaat verder: er moet een resultaat komen waar alle betrokkenen trots op kunnen zijn, een product waar de klant nog lang baat van zal hebben, waar de werknemers met plezier gebruik van maken. En een samenwerking waar iedereen met plezier aan terug kan denken.

TH Consultancy feliciteert de Hogeschool Arnhem en Nijmegen

Het nieuwe Tentamen Organisatie Systeem voor de Hogeschool Arnhem en Nijmegen is gisteren formeel opgeleverd aan de stuurgroep. Een mijlpaal en een gebakje waard!

Half november 2010 ben ik als projectmanager begonnen aan de herstart van dit project, met de planning dat er rond 1 maart 2011 een werkend systeem zou moeten staan. Het is tot het laatst aan toe hard werken en doorbijten geweest, want zoals ieder project, kreeg ook dit project te maken met impliciete verwachtingen, tekort aan man/vrouw kracht, functionaliteit die complexer is dan het in eerste instantie lijkt en diverse onverwachtse wendingen.

De komende periode gaat het tentamenbureau schaduwdraaien met het systeem en het projectteam aan de slag met de wensen en wijzigingsverzoeken die gedurende het project ontstaan zijn. Hierdoor zal het systeem de komende maanden nog beter gaan bijdragen aan een efficiënt en effectief planningsproces van de tentamen organisatie binnen de Hogeschool.

Met dank aan de programmeurs, database beheerders, testers, server beheerders en gebruikers die dit project naast hun reguliere werk moesten uitvoeren, kan ik zeggen: yes, we did it! Het kan, het is mogelijk, het bestaat!

PS Het HEMA bestelproces van gebak met zelf ontworpen afbeelding vind ik ook een geweldig voorbeeld van IT die werkt (zie mijn vorige blog), binnen een paar muisklikken een leuk gebakje ontworpen, heldere terugkoppeling en een snelle levering!