Houston, hebben we een probleem?

Stel nu dat we morgen in een raket naar de maan gaan. Dan is het handig dat we ons fatsoenlijk voorbereiden. En dat we dus niet na een tijdje denken: “Gaan we wel goed?” Een pathetische voorstelling van zaken? In de wereld van de IT is dit (bijna) dagelijkse kost…

Natuurlijk weten ervaren ruimtereizigers, die ons vergezellen, precies waar zij naartoe moeten. Zij hebben zich uitstekend voorbereid en worden elke seconde op aarde gevolgd door de NASA. Ze sturen de raket iets bij naar links en rechts zodat wij uiteindelijk op de maan landen. De landing zone.

Zo zou het ook in de IT moeten gaan. Natuurlijk kun je tussendoor wat draaien en sturen, maar je weet wel van tevoren waar je wilt gaan landen als je IT-dienstverlening gaat uitvragen of aanbesteden. Technisch weet je wat je nu hebt, je volgt de innovaties en trends in de markt, kortom: er is een antwoord op de uiteindelijke vraag. Je weet wat je nu betaalt, je kent de budgetten en verwachtingen van de organisatie en dus wat je wil uitgeven aan de toekomstige oplossing.

Daar komen de aanbiedingen

Maar wat nu, als leveranciers antwoorden gaan geven en/of aanbiedingen gaan doen die, naar later blijkt, compleet buiten de verwachtingen vallen? Hoe stuur je die dan bij? Hoe ga je om met de extra diensten die zij leveren of voorstellen, die ze eigenlijk niet goed beschreven hebben en wel in de prijs hebben opgenomen? Als je dat financieel goed voorbereid, is er vaak weinig aan de hand. Door het maken van een landing zone schets je van tevoren financiële kaders. Een business case is overigens ook een goede start. Zo creëer je een basis om de discussies met de verschillende partijen aan te kunnen gaan en kunnen verwachtingen aangaande budgetten tegen het licht gehouden worden. Daarnaast kan de technische of functionele oplossing op scope getoetst worden.

Vaak worden de financiën gek genoeg niet standaard meegenomen of afgekaderd. Het is ook veel leuker om over techniek en functionaliteit te praten en te kijken hoe innovaties zo goed mogelijk kunnen worden ingezet. Uitbesteden is communiceren en gedurende het proces ontstaan kleine en grote interpretatieverschillen die mensen met elkaar hebben. Je kunt samen met de leverancier een extra workshop plannen, hem nog eens uitleggen wat je bedoelt en eventueel additionele informatie verstrekken. Misschien heeft de leverancier iets over het hoofd gezien en kun je het proces op deze manier tussentijds bijsturen. Maar zorg dat de grote lijnen vanaf het begin staan. Of het nu om BVP (Best Value Procurement) gaat of meer traditionele aanbestedingsvormen zoals bijvoorbeeld RFI (Request for Information) en RFP (Request for Proposal). De financiën zijn een belangrijk onderdeel van het beoordelen van aanbiedingen en geven veel inzicht in de uiteindelijke scope van de technische of functionele oplossing. Met het maken van een business case of een landing zone, naast het nadenken over de techniek, krijg je niet alleen een goed beeld van de vraag en de oplossing, maar ook over: wat gaat het kosten? Is het reëel wat de leverancier vraagt voor de aangeboden oplossing? En past de aanbieding binnen gestelde verwachtingen en budgetten?

Hoe doen wij dat?

De klant heeft een vraag en zet deze in de markt in een tendertraject. Wij kunnen, met onze ruime benchmarkervaring, op basis van die vraag eigenlijk hetzelfde doen als de leveranciers, alleen niet op basis van techniek en oplossingen maar op basis van onze gegevens in de database. Zo kunnen we de markt financieel in kaart brengen door het gemiddelde, de onderkant en de bovenkant aan te geven van wat het zou mogen kosten als een klant deze vraag stelt. Door de aanbiedingen van de leveranciers vervolgens ten opzichte van deze landing zone te plotten, wordt voer voor sturing en discussie geleverd. Waarom is deze dienst zo duur? Dit volume klopt toch niet? De prijs voor dit component is wel heel laag, is de leverancier hier iets vergeten?

We worden geregeld gevraagd door klanten om te helpen bij het maken en vaststellen van een landing zone. Maar we haken vaak laat in het proces aan. Klanten schakelen ons laat in om inzicht te krijgen in de realiteitszin van de aanbiedingen en de oplossingen die leveranciers voorstellen. Klanten gaan relatief, financieel gezien, minder goed voorbereid te werk dan op het gebied van de techniek en functionele oplossingen. De boodschap? Bereid je zowel technisch en functioneel als financieel goed voor op wat er op je pad kan komen om te voorkomen dat je op de maan in een net iets te steile krater landt…

Applicaties meten: een hoop kluitjes in het riet

Laatst was ik in een schoenenwinkel. ‘Volgens mij heeft u maat 9,5’ zei de vriendelijke dame die al een doos met sneakers voor mijn neus had gezet. Ik dacht: 9,5? Ik heb 42,5! Bleek 9,5 de US-maat te zijn. Zo kan het dus ook: er wordt gemeten met twee maten maar je kunt eenvoudig een vergelijking maken met behulp van een vertaaltabel. Gaat het om het meten van applicatie omvang dan heb je een hoop kluitjes in het riet. Het wordt tijd dat meetvarianten met elkaar in verhouding worden gebracht zodat we geen appels en peren meer hebben.

Er zijn talloze meetvarianten om applicatie omvang te meten. Enerzijds heb je de regels code die in de applicatie zitten, ofwel de fysiek getypte code die zegt wat de applicatie doet. Daarnaast zijn er varianten die meer uitgaan van functionaliteit, de documentatie en van de gebruiker. Die beoordeling wordt uitgedrukt in functiepunten. En dan heb je daarin ook nog veel verschillende smaken, bedacht door verschillende instanties. En ze proberen allemaal hun methode te standardiseren en beschrijven tot norm. In Nederland hebben we de Nesma, in de VS de IFPUG en Cosmic in Canada. Om er maar een paar te noemen.

En dan heb je nog de agile-clubs. Zij schatten met het spelletje Planning Poker of Scrum Poker in om te zien hoe groot de functionaliteit is en hoeveel effort je er in zou moeten steken om de applicatie te kunnen bouwen. Zij drukken dat uit met storypoints. Weer een methode. Weer een schoenmaat. Het is eenvoudigweg een complex landschap met verschillende maten. En omdat er zoveel ‘eilandjes’ zijn krijg je natuurlijk nooit één grote dataset.

De vraag is: hoe creëer je een methode waardoor al die waarden omrekenbaar zijn en je van functiepunten regels code kunt maken, van storypoints functiepunten, van functiepunten storypoints… Toch ook een vertaaltabel zoals bij de schoenmaten? In de sociologie bestaat het principe dat als je maar genoeg mensen dezelfde vraag stelt, het gemiddelde antwoord altijd goed is, of vrijwel goed. Vraag honderd mensen hoe zwaar een bepaalde koe is en het gemiddelde zit griezelig dichtbij de waarheid. Als al die mensen op verschillende manieren de applicatie gaan meten, lukt het ook om één waarheid te vinden. Er moet dus een standaard komen, om alle kennis die er is om de juiste maat van een applicatie te kunnen aangeven, echt goed te kunnen gebruiken.

Maar het is net politiek. Er zijn officiële, internationale groepen die zeggen: wat wij hebben bedacht is een goede manier om te meten, een waarheid. En dus zijn maten moeilijk vergelijkbaar, ieder team heeft zijn eigen methodes, zijn eigen dynamiek.

Er zouden rekenregels moeten komen. Iedereen mag het op zijn eigen manier doen, applicaties meten. Maar laten we in ieder geval vaststellen dat we dezelfde applicatie aan het meten zijn. Daar moeten dus relaties tussen zijn. Een model dat alles bij elkaar brengt, omrekent en vertaalt. Een omrekenmethode, zoals bij buitenlandse valuta. Of bij schoenmaten.

Nu nog een list verzinnen hoe. Wie de schoen past…