Het belang van Requirements Management en samenwerking met de Business

Begin dit jaar verhuisde ik met mijn gezin naar een nieuw huis. Verhuizingen zijn altijd hectisch, zo ook die van ons. Uiteindelijk ben je over met al je spullen en staat alles min of meer op de plek waar je denkt dat het moet staan. Alle essentiële klusjes zijn gedaan en alles is redelijk aan kant. Natuurlijk blijven er altijd klusjes die nog heel lang in je achterhoofd geregistreerd staan onder “moet ik nog doen, maar kan later wel”. Één zo’n klusje was het op de juiste hoogte hangen van een fotolijst. Klinkt simpel, zou je denken, en dat was het ook. Kwestie van meten, boren, schroefje d’r in, lijstje eraan ophangen en klaar. 

Het ging om een foto van één van de kinderen. De foto’s van z’n broer en zus hingen ernaast. Drie vierkante lijsten van 50 bij 50 cm. Het zijn schitterende afdrukken van mijn prachtige kinderen op canvas dat op een houten frame gespannen zit. Bij de verhuizing waren ze tijdelijk aan de reeds aanwezige schroeven in de muur gehangen. Twee van de drie foto’s hingen keurig met de bovenkantjes gelijk, maar de derde hing 5 cm lager (zie bovenstaand plaatje). Dat heeft mijn vrouw (de business) een tijd lang zonder klachten geaccepteerd. Een onuitgesproken issue dus. Ik (ICT-er) besloot om dit potentiële issue pro-actief op te pakken, en vol goeie moed ging ik ermee aan de slag. Een kwartiertje later bekeek ik tevreden mijn resultaat. De foto’s hangen keurig op de zelfde hoogte, met gelijke onderlinge afstand van elkaar (zie onderstaand plaatje).

Even resumerend: ik had zonder samenspraak met de business een oplossing voor een potentiële issue geïmplementeerd. Ik had geen idee van de verwachtingen van de business, nog van de exacte wensen t.a.v. de implementatie van de verwachte oplossing. A recipe for disaster?

Later op de dag presenteerde ik de oplossing aan de business (mijn vrouw). De reactie was als volgt: “waarom hangt de jongste nog steeds helemaal rechts?”. Ai! Maar ik sprong meteen in aktie. In een handomdraai verwisselde ik de meest linker en de meest rechter foto van plekje aan de muur. Resultaat: 

Shit! Dit was niet in de lijn der verwachtingen. Noch die van mijzelf, noch die van de business. Ik had het issue alleen maar vergroot in plaats van opgelost. Ik had de scope van mijn project ook veel te smal gehouden (verhang foto 3), en impliciet aannames gedaan over de de verwachtingen en wensen van de business én over de flexibiliteit van mijn oplossing. Mijn oplossing ging namelijk uit van een aangenomen uniformiteit in de constructie van de fotolijsten. Echter, die bleek toch niet zo uniform als ik dacht. Fotolijst 3 was namelijk 2 jaar later geproduceerd dan fotolijsten 1 en 2. En jawel, er is een “architectuurafwijking” tussen de twee. Zie onderstaande plaat. Ik kon de haren wel uit mijn kop trekken. Destijds had ik bij het bestellen van lijst 3 de gewenste lijst-dikte moeten opgeven. Fotolijsten 1 en 2 waren mijn referentie-architectuur. Kortom: de oorzaak van het onverwachte resultaat ligt bij de uitvoering van een eerder project. Was ik toen maar uitgegaan van de reeds aanwezige standaard-maten!

Mijn project had dus een diepgaander onderzoek moeten doen naar de exacte requirements van de business en naar de mogelijke oplossingen. Dit had ik in samenspraak met de business moeten doen, en dan was iedereen tevreden geweest. Ik had mijn snelle oplossing naast enkele andere oplossingen moeten zetten en die bespreken met mijn vrouw. Ik zie nu (achteraf) ook de volgende oplossingsrichtingen:

1. eerst de dikte van het houten frame van foto 3 gelijk maken aan die van lijst 1 en 2, en dan pas verhangen

2. een generiek, verstelbaar fotolijst-ophangsysteem (een BAVO voor de ophanging van lijsten) selecteren en implementeren welke kan omgaan met de afwijkende afmetingen van de frames

3. de diktes van de frames van fotolijsten 1 en 2 verkleinen (even de schaaf erover…) en gelijk maken aan die van lijst 3

Je ziet het, ik heb mijn les hier wel uit gehaald. Doe er zelf ook maar je voordeel mee!

De kunst van het neerzetten

Koud kunstje
Een nieuwe applicatie “neerzetten” is een vertrouwd kunstje. Iedereen schijnt het te kunnen, dus kun je het makkelijk uitbesteden (software developers kun je met containers tegelijk bestellen). Neerzetten is dan het proces dat begint vanaf het moment dat het project accoord krijgt om te starten tot en met de oplevering. Het omvat ruwweg het ontwerp (O), de bouw (B), het testen (T) en het opleveren van de applicatie. Zo gepiept.

Pilots
Voor de zekerheid kan je eerst even in een kleine context kan experimenteren met een pilot project, waaruit dan zo’n geweldig goed resultaat komt dat je er meteen mee live kunt gaan in de hele organisatie. Scheelt vaak ook een hele hoop bureaucratisch gedoe.

Agile
Vaak wordt het neerzetproces ook opgeknipt in meerdere kleine nederzettinkjes. Agile, noemen ze dat dan in mooi Nederlands. De agile variant “Scrum” is heel populair de laatste tijd. Ik zie dan altijd een karate-dojo voor me waarin de scrum master met oosterse bewegingen zijn kunsten vertoont, maar dat terzijde. In een agile aanpak wordt er met regelmatige tussenpozen, steeds een deel van de beoogde applicatie bij aangezet. Iedere aanzetting doorloopt de stapjes O, B en T. Zo krijgt de opdrachtgever regelmatig de gelegenheid om nieuwe requirements toe te voegen (of juistom requirements af te zwakken of in zijn geheel te laten vallen als hij doorkrijgt dat het kunstje toch wat ingewikkelder blijkt als eerst ingeschat). Het mooie is in ieder geval dat de opdrachtgever veel momenten krijgt om invloed uit te oefenen.

Iemand ander’s probleem
Nu wil het geval dat ik nét even iets te vaak heb gezien dat er bij het neerzetten van een applicatie iets heel belangrijks wordt vergeten, of gemakshalve beschouwd als iemand ander’s probleem, namelijk: het in beheer nemen. Zou dat dan soms heel erg lastig en ingewikkeld zijn? Lastig? Nee, wel anders. Het in beheer nemen van iets houdt in dat je de verantwoordelijkheid op je neemt om erop toe te zien dat de conditie van het in beheer genomene op peil blijft. Zo zorgt een museum ervoor dat de conditie van door anderen gemaakte kunstwerken op een dusdanig niveau blijven dat de de mensheid nog lang van de kunstwerken mag blijven genieten.

Applicatiebeheer
Om een applicatie met een kunstwerk te vergelijken gaat misschien wat ver. Applicaties zijn vaak veel kortere levensduren toegedacht. Dat ze het vervolgens veel langer uithouden dan ooit werd bedacht mag dan wellicht worden toegeschreven aan de bovenmenselijke inspanningen van het applicatiebeheer dat tot uiterste ROI werd gerekt. In het geval van applicaties houdt beheer ten minste in dat deze functioneel bruikbaar blijven en waarde blijven houden.

Instortgevaar
In de praktijk (vooral bij de wat bejaardere applicaties) lijkt applicatiebeheer vooral op het voorkomen van instorten. Gek genoeg zijn we altijd weer heel verbaasd als een applicatie plotseling bijna “over datum is”. De oorspronkelijke leverancier heeft de stekker eruit getrokken en had daar al jaren van te voren voor gewaarschuwd. Er komen echt geen patches meer. Vanaf Windows 7 wordt de werking niet meer gegarandeerd. Gelukkig kon de levensduur van XP dan weer collectief met ruim 10 jaar worden gerekt.

Paniek! Gauw een pilot!
En als het boeltje dan echt bijna op instorten staat, dan moet in allerijl een vervangende applicatie worden neergezet, en vlug een beetje, want tijd is geld. En om zowel budgettaire als bureaucratische motieven beginnen we dan met een experimentje met een nieuwe veelbelovende technologietrend. Voila, een nieuw pilot project is geboren. En wonder boven wonder, die nieuwe technologie werkt fantastisch! En het kost niks, want het is nog open source ook! Eh, beheer, zouden jullie zo vriendelijk willen zijn om de verantwoordelijkheid op je te nemen om deze nieuwe applicatie met die bovenmenselijke zorg die we van jullie gewend zijn voor ons te onderhouden? Fijn! Het kringetje is weer rond.

Beheerbelang
Beheer is meestal de onuitgenodigde gast bij het neerzetten. Op zijn best wordt deze gast vlak voor oplevering uitgenodigd om te beoordelen of het opgeleverde in beheer genomen kan worden. Dan valt er niks meer bij te sturen voor beheer. Beheer is een belangrijke stakeholder in de organisatie, met eigen belangen die indirect altijd die van de organisatie behartigen. Laat ze van begin af aan meestrijden in de scrum-dojo en je zult zien dat dat in beheer nemen ook een koud kunstje kan zijn.