Hebzucht laat IT-projecten slagen

28 juli 2014  |  Categorie: Vloeiend veranderen

IT-projecten succesvol makenIT-projecten… Je hoort zo vaak over de mislukkingen. Kan het dan echt niet anders? Jawel hoor. Er is nu een perverse oplossing!

1. Kies een Agile-methode

Bijvoorbeeld Scrum. Kort door de bocht betekent dat dat het project in hele korte “sprints” van ongeveer een maand wordt doorlopen, waarbij het team telkens een deel van het eindproduct bedenkt, maakt en aflevert. De doorlooptijd en te besteden manuren zijn gefixeerd. Vorm en hoeveelheid eindproduct zijn variabel.

2. Geef perverse prikkels

Het team mag na elke sprint de “poet” onder elkaar verdelen. Nu komt het: de uit te keren som geld is direct afhankelijk van de klanttevredenheid. De opdrachtgever geeft na elke sprint een rapportcijfer tussen 1 en 100. Dat is het percentage van de totale sprint-poet dat de teamleden krijgen. Het resterende deel wordt aan een goed doel geschonken.
Bijvoorbeeld: Het project kost totaal 100.000 euro en bestaat uit 5 sprints. Elke sprint kost dan € 20.000. Stel, de opdrachtgever is erg tevreden en beoordeelt met een 90. De teamleden hebben dan 90% van € 20.000 = € 18.000 te verdelen. € 2.000 gaat naar een goed doel.

Resultaat: win-win

Perspectief van de opdrachtgever: een enthousiast team heeft zijn tevredenheid als drijfveer. Hij weet exact wat het gaat kosten en hoe lang het gaat duren. Bij het geven van zijn rapportcijfer moet hij zo precies mogelijk zijn. Want een onredelijk lage score drukt de motivatie van het team, waardoor de totale kwaliteit zal zakken. Onrealistisch hoog maakt het team lui. In alle gevallen geeft hij precies evenveel geld uit.
Perspectief van het team: de klant centraal zetten. Hoe tevredener de klant, hoe meer salaris ze krijgen. Is er iemand die zijn snor drukt? Dan zal de rest van het team hem onder druk zetten beter werk te leveren (of hem eruit zetten). Alles wordt in het werk gesteld om de klant tevreden te stellen.

Tot zover de divergerende brainstorm die ik onlangs had met oud-collega Johan. Natuurlijk, er zijn vele mitsen en maren. Zoals: alsof alleen het team verantwoordelijk is voor het slagen van een project. Nee, niet echt. Maar dit is wel een spectaculaire methode die het team optimaal motiveert en de klant centraal stelt.

Wie durft?

Reacties

  1. Johan schreef:

    Deel van het idee was ook nog iets als: je blijft bijelkaar zolang je beide tevreden bent. Is een opdrachtgever oprecht ontevreden dan zoekt hij vanzelf een ander team, maar is een klant te negatief over een goed team dan zoekt het team z.s.m. een andere opdrachtgever.
    Er is van beide kanten groot belang om ook de ander tevreden te houden in plaats elkaar willen ‘plukken’ via contracten, requirements, meerwerk,…
    Kortom, een heel positief geheel. Geen idealisme te bekennen in dit stuk overigens 🙂

  2. Mark schreef:

    Probleem met ‘perverse’ prikkels is dat ze mensen wel harder laten rennen, maar dat ze ophouden on zich heen te kijken: creativiteit lijdt eronder. Dit is overigens niet een vermoeden of (alleen) een eigen ervaring, maar is buitengewoon vaak onderzocht en aangetoond. Vgl Daniel Pink: ‘Drive’ (Zie ook RSA Animate – Drive: The surprising truth about w…: http://youtu.be/u6XAPnuFjJc )

    1. Erik Mathlener schreef:

      Dankjewel Mark. Hele mooie van RSAnimate. Daarin zeggen ze dat de beste motivatie (voor deze doelgroep) komt uit Autonomy, Mastery en Purpose. Klinkt goed, zo willen de meesten ongetwijfeld werken. En ik zie een beetje de eerste, maar zeker de derde ook terug in mijn voorstel.
      Autonomie: het team is de baas over wat er gebeurt. Linksaf of rechtsaf? De teamleden bepalen het (samen) zelf.
      Doel: ze hebben beslist een doel. Een gezamenlijk doel zelfs. En dat is de hoogste klantwaardering krijgen die ze maar kunnen bereiken. Dat uit zich uiteindelijk in geld.
      En dat zou volgens de video juist negatief uitwerken. Hmm. Interessant punt.
      Het nastreven van een gezamenlijk doel vind ik echt heel erg mooi. Dat doel zou de uitkomst van het project kunnen zijn. En als je een maatschappelijk relevant project hebt, dan is dat prima te doen. Maar een it-project waarin een administratief systeem wordt gebouwd waarmee bijvoorbeeld managers hun kpi’s kunnen zien… Tja, welke it-er wordt daar nu warm van?

      1. Mark Meinema schreef:

        De meeste IT-ers gaan inderdaad niet blij kijken van KPI’s of andere crap… Maar de meeste IT-ers gaan volgens mij ook vooral voor het zo elegant mogelijk oplossen van de puzzel. Als dat dan een manager mooie cijfertjes oplevert: tof… 😉

        De meeste IT-ers (en dan heb ik het over de ‘echte’ nerds) die ik ken gaan (soms al hun hele leven) voor het coden zelf. De motivatie ervoor is heel intrinsiek, merk ik…

        1. Robbert schreef:

          En daar komt nog bij dat IT’ers zelden in staat zijn uitsluitend dat te leveren wat de klant vraagt, Het kan altijd beter, anders, mooier, generieker, noem maar op, en dus ook duurder, complexer, lastiger.

  3. Robbert schreef:

    Scrum is geen methode, maar een framework, en bovendien alleen bedoeld voor de ontwikkelfase, binnen het ontwikkelteam. Dus geen projectaanpak. Helaas gaat het in veel projecten al veel eerder mis (ik noem bijvoorbeeld het “generieke datamodel”, opdrachtgevers die niet weten wat ze eigenlijk willen, wijzigend inzicht in de loop van een project). En die laatste twee zijn nou net waar scrum geweldig op vast kan lopen.

    Tijdens de cursus scrum wordt het al verteld: met Scrum levert een project meer geld op (aan de leverancier wel te verstaan).
    Scrum is geen fixed price methode. Het aantal sprints staat niet vast.

    Die perverse prikkel kun je vervangen door een stimulans. Hang een planning op de muur en laat iedereen de taak die af is inkleuren. Het is net de kleuterschool; en het werkt. En wie de meeste taken af heeft mag een dag in groene letters programmeren.

    1. Erik Mathlener schreef:

      Haha, in groene letters programmeren, wat een vondst. Tja, vroeger deed ik dat daadwerkelijk. Het kon ook amberkleurig trouwens.
      Ik noemde Scrum als voorbeeld, omdat dat redelijk hip is tegenwoordig. Het ging me om het Agile-idee waarin tijd en geld vaststaan.
      Tja, er zijn inderdaad vele faaloorzaken te noemen waar een team niet altijd invloed op heeft. Misschien moeten we het concept dan nog uitbreiden met een omgekeerde prikkel: het team geeft ook een oordeel over de opdrachtgever. Hoe hoger de score, hoe lager de prijs? 🙂

      1. Robbert schreef:

        Vroeger op de lagere school mochten we na 10 stempels (of later plakkertjes) een dag met groene inkt schrijven, vandaar. Had even niet meer gedacht aan de good old monochrome beeldschermen. Past wel bij Scrum overigens, want dat stamt ook al ergens uit 1985. Eerder retro dan hip dus…..

        Ik zie meer in negatieve prikkels (handhaving): projectleden die verzaken moeten voelen. Wie op de Daily Scrum te laat is moet tracteren etc. Zie jij het trouwens al voor je: java-programmeurs die allemaal al om 9 uur ‘s ochtends aanwezig zijn? Zelfs na hun bridge-avond?

        Uit wikipedia: :”Scrum wordt veel gebruikt bij producten waarvan de klant / gebruiker nog niet goed weet wat hij wil”.

        En daar zit nou precies de oorzaak van het probleem: de klant weet niet wat hij wil, maar het project vaak (denkt men) wel.

        1. Erik Mathlener schreef:

          Met “het project” bedoel je de teamleden, denk ik? Wel, het is hun taak om de klant (opdrachtgever én eindgebruikers) serieus te nemen en ze te helpen bij het uitvinden wat ze willen. Zelf invullen is natuurlijk uit den boze! Uiteindelijk leidt dat tot een ontevreden klant, een lage score en daarmee een bijzonder laag salaris voor het hele team. Sociale druk ontstaat daarmee vanzelf.
          In de brainstorm was het nog niet uitgekristalliseerd, maar ik ben er voorstander van om de teamleden géén salaris te geven. Hun “deel van de poet” IS het salaris. Ontevreden klant? Dan geen salaris. Tevreden klant? Dan heel veel salaris. Als dát geen prikkel is om op tijd te komen…

  4. Albert schreef:

    Perverse prikkels zijn pervers….

Laat een reactie achter en start een discussie!

Privacy Voorkeuren