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”

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!

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.

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?

Het voordeel van zelfstandige zijn, is dat ik tussen twee klussen in, tijd heb om een geheel ander project aan te pakken. Verschillende plekken in huis konden wel een nieuwe verflaag gebruiken, dus is schilder Teus weer enkele dagen over de vloer. Teus is net als ik, zelfstandige in de regio Woerden, en het is erg prettig zaken met hem doen.

Omdat mijn passie nu eenmaal ligt bij het uitvoeren van ICT projecten, zie ik al snel een overeenkomst tussen zo’n schilderklus en een ICT systeem. En een manier om aan mensen, die niet zo bekend zijn met de materie, uit te leggen wat mijn rol in een ICT project inhoudt.

Zie de schilder als de ICT leverancier, en mijzelf als klant die een verbetering wil doorvoeren in de organisatie (in huis). Voordat de leverancier kan beginnen, zal er nog het een en ander moeten gebeuren. Er moet een inventarisatie gemaakt worden van het werk. Vervolgens een planning, waarbij het proces van de klant voorop staat. Een groot schilderbedrijf zal al het werk achter elkaar willen uitvoeren, voor mij als klant is dat niet handig, want dat moet ik woonkamer, keuken, gang, berging, toilet en hal tegelijk leeg ruimen. Teus is gelukkig zo flexibel dat hij een week tussen de verschillende onderdelen laat. Tenslotte moet ik als klant de voorwaarden scheppen zodat de leverancier aan de slag kan, bijv. ruimten leeg ruimen (in een ICT project: oa infrastructuur en toegang regelen, medewerkers informeren en betrekken).

Dan breekt de fase van realisatie aan: de leverancier doet waar hij goed in is, en als klant hou ik de vinger aan de pols. Gebeuren de juiste dingen en loopt alles op schema? Als ik punten ter verbetering zie (testen), of ik heb nog wat extra wensen, dan noteer ik die op een lijstje (issues en testbevindingen) en bespreek die met mijn leverancier. Ik heb gelukkig iemand getroffen die gedurende de uitvoering ook zelf extra punten opmerkt (een traphek dat vastgezet moet worden) en bereid is te helpen met werk dat eigenlijk door mij als klant uitgevoerd moet worden (een kastje ophangen).

In de implementatie fase wordt het geleverde in gebruik genomen. Ik plaats alle kasten weer op hun plek en ruim ze in. In een ICT project worden er bijvoorbeeld gegevens ingevoerd, medewerkers en een helpdesk geïnstrueerd, werkinstructies geschreven, formulieren aangepast en klanten ingelicht.

Als een project de juiste zorg en aandacht heeft gehad, en de leverancier goed is in zijn vakgebied, dan kan het bijna niet anders of het project is geslaagd en de medewerkers (huisgenoten) hebben voor jaren plezier van de gedane arbeid!

Nu ik zelf de tijd had, kon ik dit allemaal zelf begeleiden. Mijn klanten hebben altijd een “winkel open te houden”, en besteden (een deel van) het “klant” werk aan mij uit. Dat kan de inventarisatie, projectleiding, testen of implementatie zijn. Iemand inhuren voor deze activiteiten zegt niets over de kwaliteiten van leverancier of klant. Dit getuigt slechts van een goed inzicht in de situatie.

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.

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 steunt Marianne in haar strijd tegen borstkanker

Monday , 20, June 2011 Comments Off on TH Consultancy steunt Marianne in haar strijd tegen borstkanker

Op 8 en 9 oktober 2011 gaat Marianne Checkley in twee dagen van Amersfoort naar Amsterdam lopen, in totaal een afstand van 60 kilometer. Zij doet dit samen met vele andere enthousiaste lopers van de stichting “A Sister’s Hope”. Deze stichting organiseert de loop met als doel een groot geldbedrag op te halen om beter onderzoek naar borstkanker mogelijk te maken.

Om deel te mogen nemen aan dit evenement heeft zij toegezegd minimaal 1.500 euro in te zamelen.  TH Consultancy steunt Marianne in dit geweldige initiatief, maar ze kan nog meer sponsors gebruiken!

Marianne ook sponsoren? Je kunt je bijdrage storten op ING Rekening 2947137 onder vermelding van deelnemersnummer 4110 Marianne Checkley

Marianne is net als TH Consultancy lid van ondernemersvereniging ZOOOM, collectief voor ZZP-ers uit Woerden

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.

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!