terug
2018-01-05

Frans van Besouw

Ons tandemcontract

Gepubliceerd op 2018-01-05 door Frans van Besouw

Een bedrijf start een project om een nieuwe applicatie te bouwen of een bestaande te vervangen. Om dat project te bemensen zijn extra IT-ers nodig, want “de winkel moet open blijven” en “we gaan technologie inzetten die we zelf nog niet beheersen”. Het bedrijf wil geen nieuwe mensen in dienst nemen, maar ze alleen inhuren voor de duur van het project.

Inspanningsverplichting

Detachering is een veelvoorkomende manier om IT-ers in te huren. In de Nederlandse markt voor IT-ers huur je iemand in via een detacheringsorganisatie. Verschillende detacheerders dragen één of meer mensen voor. Je spreekt ze en kiest degene die goede papieren heeft en waarmee je een klik voelt. Vervolgens onderhandel je over het uurtarief en sluit je een contract op basis van een inspanningsverplichting met de detacheringsorganisatie. Dat contract zegt bijvoorbeeld dat de gedetacheerde verplicht is zich 40 uur per week voor een periode van pak-hem-beet drie maanden in te spannen voor het project. Die periode is te verlengen.

Resultaatsverplichting

Een andere manier is om een IT-bedrijf in te huren dat de opdracht krijgt om het nieuwe systeem te bouwen. Dit IT-bedrijf kun je dan vergelijken met een aannemer in de bouw en daar hoort een offerte bij. De inkopende organisatie heeft een duidelijk bestek, want anders kan de aannemer de offerte niet opstellen. Op basis van het bestek offreert het IT-bedrijf een bedrag en als de offerte is uitonderhandeld en geaccepteerd gaat de aannemer een resultaatsverplichting aan. Meestal huurt het bedrijf ook nog een tweede bedrijf in: die krijgt de rol van “architect”, en ziet toe op het werk van de aannemer.

Als u het spel niet zo goed beheerst...

Hoe gaat het dan verder? In beide gevallen ontstaat er als vanzelf gedoe. De gedetacheerde IT-ers spannen zich ongetwijfeld in maar het duurt vaak lang, het systeem doet niet wat het moet doen en er zijn veel “bugs”. Ook met een resultaatsverplichting is er vaak een mismatch tussen wat je had gewild en wat je krijgt. Je krijgt met name minder dan je dacht te krijgen en de aannemer en architect krijgen het ook nog met elkaar aan de stok.

Als je het gedoe bespreekbaar maakt, blijkt het heel moeilijk zaken beter op orde te krijgen. IT-bedrijven gespecialiseerd in detachering zijn zeer vaardig in het maximaliseren van hun inspanning. Voor u het weet worden die 6 maanden er 12 en heeft u een tweede expert ingehuurd. IT-bedrijven gespecialiseerd in resultaatsverplichting zijn zeer vaardig in onderhandeling en besluitvorming over het resultaat. Als u zelf dat spel niet goed beheerst dan betaalt u meer voor het afgesproken resultaat of u krijgt minder voor het overeengekomen bedrag.

Niemand blij

En wat vinden de IT-ers die u ingehuurd heeft of die via de aanneemsom bij u werk komen verrichten? Ik kan alleen voor mezelf spreken, maar ik vind het heel vervelend. Bij detachering is de invloed op wat je doet klein, de opdrachtgever beschouwt je heel erg als “handjes” en het werk dat je moet doen is opgedeeld in kleine taken. Hoe groter het project en het projectteam des te meer opgeknipt. En met al die kleine taakjes zit je natuurlijk vaak te niksen. Ook is er veel onderlinge concurrentie, zeker als er IT-ers van verschillende bedrijven zijn. Vaak ontvang je van je detacheringsorganisatie een bonus als je voor een collega een plek weet te creëren. En het ergste: het komt nooit af.

Zit je op een aanneem-klus, dan weet je als IT-er dat de vraag en het eigen aanbod niet goed op elkaar aansluiten, dat sales iets verkocht heeft dat niet gemaakt kan worden voor die prijs. Je doet niet wat het beste voor de klant of zijn probleem/vraag is. En door je eigen organisatie wordt je onder druk gezet om zo snel mogelijk klaar zijn.

In beide gevallen geldt dat de afstemming tussen inhoud, de tijdsinspanning en gewenste kwaliteit niet in evenwicht zijn. Je kunt je ei niet kwijt. Je voelt je onderbenut; je wilt graag veel meer bijdragen aan het succes van de klant. Je voelt frustratie... En eigenlijk ben je pas trots als je iets maakt wat werkt en waar de klant blij mee is.

Een contract dat loont

Inspannings- en resultaatsverplichting zijn de gangbare vormen om IT-ers in te huren maar deze contractvormen zijn voor zowel de opdrachtgever als de IT-er niet optimaal. De traditionele IT-bedrijven zijn het meest gebaat bij deze vormen, het is alleen wel lastig voor ze om klanten en werknemers tevreden te houden.

Zijn er ook IT-bedrijven die dat anders doen? Ja, wij bijvoorbeeld. Wij willen een contract hebben waarbij het loont dat de klant waar voor zijn geld krijgt en de IT-er tegelijkertijd ruimte krijgt kwalitatief goede software te leveren. Opdat wij –als IT-bedrijf– niet steeds gedoe hebben dat we steeds maar weer moeten glad strijken. Dat lukt niet altijd en we vinden het vooral niet leuk. We komen liever blije klanten en collega’s tegen.

Ons belang is te zorgen voor een continue stroom van werk, waarbij onze mensen zo’n 80% van hun tijd werk doen binnen klussen die wij met klanten klaren. Die andere 20% gaat op aan scholing en werkzaamheden voor SpronQ, zoals een blog schrijven, de website onderhouden of een selectiegesprek voeren. Continue wil zeggen dat we een pijplijn hebben van werk en dat de conversie van die pijplijn goed in te schatten is.

Een contract dat meet

Bottom-line is dat wij IT-applicaties opleveren waar de klanten met (let op: er staat uitdrukkelijk met en niet voor) wie we die software bouwen blij van worden. We willen ons vakmanschap tonen, ons ei kwijt. We praten en denken mee over hoe IT het best het werk kan ondersteunen. De klant onderneemt, wij voorzien in gereedschap. Klant en IT-er, business en wij werken samen.

Samen stellen we een team samen. De klant zorgt voor materiedeskundigen en levert zo mogelijk eigen IT-ers, wij leveren IT-ers. Samen bepalen we een maandbudget waarvoor het team aan de slag gaat.

Het contract zou er aan moeten bijdragen dat we (klant en IT-er) het werk als een team doen en moet mogelijk maken wij ons ei kwijt kunnen en dat de klant blij wordt van de samenwerking. Hoe? Gewoon door wekelijks iedereen te vragen: “kan de IT-er zijn ei kwijt?”, “is de klant blij?”. En ieder teamlid geeft antwoord (een score van 1 tot en met 10).

Een andere maatstaf is een beoordeling van wat gebouwd is. We werken zodanig dat twee of drie-wekelijks voortgang beoordeeld kan worden (demo, in scrum-terminologie). Als wij en de klant tevreden zijn over wat gebouwd is, kunnen we dat ook scoren op een schaal van 1 tot 10.

“Zachte” criteria aanvullen met “harde”

Of de samenwerking goed verloopt en of dat wat opgeleverd wordt “werkt” zijn feitelijk zachte criteria omdat het menselijke beoordelingen zijn, gevoel. Maar IT moet toch ook hard beoordeeld kunnen worden? Volgens ons ook.

In de moderne IT-wereld spreken we van fitness functions. Eigenlijk een uitbreiding van het concept geautomatiseerd testen naar het testen van allerlei eisen en non-functional requirements die IT-architecten stellen. Alles wat wij maken, leveren we uit via een continuous deployment pipeline. In die pipeline zitten een groot aantal geautomatiseerde testen, van eenvoudige unit-testen via code quality testen en integratietesten naar security testen. De pipeline met automatische testen is het bewijs dat we kwalitatief goede software opleveren.

Een contract dat stuurt

Als ieders score een 10 is en als alle testen slagen, dan is het natuurlijk goed. Is de score lager of falen sommige testen, dan is er mogelijk een spanning. Het managen van het contract omvat dan eigenlijk het managen van deze spanningen. Het contract heeft dus ook een aspect waarin besluitvorming over wel-en-wee van het werk en het team organiseert. Wij besluiten het liefst holacratisch. IT-maken is mensenwerk, een team effort waarin iedereen moet kunnen meeprat en meesturen. Het werk, de voortgang en de kwaliteit ervan worden wekelijks besproken in “tactical meeting”. Zijn er “spanningen”, gaan dingen niet zoals verwacht en moeten extra dingen geregeld worden dan sturen we deze door naar een “governance meeting”. Holacratie werkt met circles en doelen, met rollen en verantwoordelijkheden. De inrichting hiervan, en daarmee de wijze waarop het contract gemanaged wordt, is onderdeel van het contract.

Tandemcontract

Wij willen geen detachteringscontract, geen aanneming. Beide zijn misschien op korte termijn goed voor onze portefeuille maar op langere termijn is iedereen ontevreden. Het is in onze ogen dan ook niet meer van deze tijd. Wij noemen de combinatie van “zachte” beoordelingen, “harde” fitness functions en holacratische besluitvorming over spanningen een tandemcontract. En we hebben ook gewoon een aansprakelijkheidsverzekering...

Frans van Besouw, Business Consultant at SpronQ