Ik zie projecten vaak fouten maken die voor vertraging en extra projectkosten leiden. Alhoewel het probleem duidelijk zichtbaar is en de gevolgen duidelijk gevoeld worden, zien veel mensen het probleem over het hoofd. De naam die ik voor deze fout komt van de analogie die ik gebruik: een trui.

Een trui van je moeder

Neem de volgende situatie:

Voor haar verjaardag krijgt Anne een trui van haar moeder. De trui is speciaal door Maria, een vriendin van haar moeder, gebreid. Jammer genoeg vind Anne de trui heel lelijk. Om haar moeder niet voor de borst te storten glimlacht ze en accepteert het geschenk. Na het verjaardagsfeestje legt ze de trui in een lade en de trui wordt nooit meer gedragen.

Als je dit verhaal op de IT betrekt, dan zie je de drie-eenheid van elk project: Degene die de software gebruikt (Anne), degene die de software schrijft[1](Maria) en degene die betaalt (de moeder). In de praktijk is het meestal het management die het project betaalt.

In het voorbeeld wordt de trui nooit meer gedragen, oftewel het project wordt gestopt. In de praktijk komt dat minder vaak voor. Meestal wordt de software in productie genomen, maar heeft dure workarounds en/of aanpassingen nodig. Als de problemen te groot zijn dan wordt na enige tijd een nieuw project, met een pakket van een ander leverancier, gestart. Hierbij loop je het gevaar dat dit een zelf-versterkende cyclus wordt waarbij softwarepakketten komen en gaan, omdat geen van de pakketten voldoet aan de verwachtingen.

Justin Bieber

Hoe zorgen wij dat de trui wel gedragen wordt? Laten wij ons verhaal een klein beetje aanpassen:

Op Annes verjaardag geeft haar moeder haar een tegoedbon. Met de bon kan ze een trui laten maken door Maria. Anne laat Maria een trui met de foto van Justin Bieber erop maken. Een paar weken later draagt Anne de trui terwijl zij overnacht in de rij om concertkaartjes te krijgen voor Justin Bieber. Alle vriendinnen zijn heel jaloers op de unieke trui. Dit betekent overigens niet dat de moeder alle controle uit handen geeft. Moeder: “Nee, je mag geen goudkleurige wol gebruiken, dat is veel te duur.”

Software die doet wat het moet doen is software die gebruikt zal worden. Wie weten het beste wat er moet gebeuren? Dat zijn de gebruikers. Zij hebben uitzonderlijke kennis omdat zij dagelijks in contact komen met praktijk.

Waarom heb je niets gezegd?

Managers verwachten vaak dat mensen mondig genoeg zijn om hem/haar te vertellen als iets niet goed is. Echter, in ons verhaal zei Anne niet tegen haar moeder dat zij de trui lelijk vond. Ze vond het behouden van de relatie belangrijker dan de waarheid. Dit geldt ook binnen een bedrijf: je wilt als werknemer geen slechte beoordeling. Zelfs als mensen en signaal afgeven, verzand dat nog wel eens in politieke correctheid.

Herkenningspunten

Hoe groot is binnen jouw project het gevaar op een trui? Hier zijn mijn punten waaraan je het kan herkennen:

  • Er is geen gedeelde projectvisie of –doel.Als je bij het koffiezetapparaat praat met de business, de projectleden en de projectleiding, krijg je dan drie totaal verschillende antwoorden?
  • Er zitten nauwelijks gebruikers, d.w.z. mensen van de business die het echte werk doen, in het project.Is de Product Owner de enige gebruiker in het project? Zitten er gebruiker die niet in het project meedraaien bij de sprintdemo’s? Doen gebruikers mee aan de acceptatietesten?
  • Niet de gebruikers, maar de documentatie bepaalt wat er gebouwd wordt.In tegenstelling tot wat veel mensen denken, kan niet alles volgens het ontwerp, die in de documentatie staat, gebouwd worden.[2]Een bouwer moet daarom de intentie achter het ontwerp snappen om alternatieven voor te stellen. De intentie staat standaard niet in de documentatie. Discussie tussen bouwers en gebruikers is dus nodig om het eindproduct te maken.

Als je in jouw project één of meer van deze punten herkent, ga dan eens het gesprek aan met de Product Owner en/of het projectmanagement. Hierdoor kunnen wij hele mooie truien breien die vaak gedragen zullen worden.

[1]Bij het kopen van softwarepakket lijkt het altijd of het pakket zonder veel moeite geïmplementeerd kan worden in een bedrijf. In mijn ervaring is dat zeldenhet geval omdat elk bedrijf uniek is.

[2]Bij het opstellen van het ontwerp kun je relatief vrij over de functionaliteit nadenken. Echter, bij het implementeren van het ontwerp heb je helaas te maken met allerlei technische restricties. De praktijk is, in de praktijk, altijd weerbarstiger.